Re: Internet connectivity in the Costa Rican jungle?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internet connectivity in the Costa Rican jungle?
- To: <clrcom!hobbes!khall>
- Subject: Re: Internet connectivity in the Costa Rican jungle?
- From: uunet!MAF.CCMAIL.CompuServe.COM!ECD
Yup, Yup, that's my kind of stuff.
We would probably run some data via HF radio, but there are
a couple of units available for less than $10,000 minus
computer for what is called "Inmarsat C" which is a
satellite data system that plugs into the Internet via a
commercial system.
Two companies that I know of have them available in the U.S.
There are a bunch of European companies. The American
companies that have units are:
Trimble Navigation (Sunnyvale, CA)
(408) 730-2900
One of the others is a company called "Scientific Atlanta",
I can't lay my hands on the phone number right now, but
have the stuff in another magazine, which I will get if the
guy needs it.
My tel# is (909) 794-1151
We can't afford any of this stuff, but it is definitely the
way this guy should go.
russ
----- End Included Message -----
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20630;
29 Apr 94 15:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20620;
29 Apr 94 15:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15382;
29 Apr 94 15:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20608;
29 Apr 94 15:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20560;
29 Apr 94 15:06 EDT
Received: from garcon.cso.uiuc.edu by CNRI.Reston.VA.US id aa15354;
29 Apr 94 15:06 EDT
Received: from [128.174.33.173] (maced.cso.uiuc.edu) by garcon.cso.uiuc.edu with SMTP id AA26757
(5.67a8+/IDA-1.5 for <ietf at CNRI.Reston.VA.US>); Fri, 29 Apr 1994 14:06:00 -0500
Date: Fri, 29 Apr 1994 14:06:00 -0500
X-Sender: krol at ux1.cso.uiuc.edu
Message-Id: <a9e6c35f0d0210088e5e at [128.174.33.173]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: brad at fcr.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ed Krol <e-krol at uiuc.edu>
Subject: Costa Rican Connectivity
Cc: garyg at vita.org, ietf at CNRI.Reston.VA.US
Brad:
You might try talking to someone from VITA. They do a lot
of work putting temporary connections in really obscure
parts of the world. A lot of it is low earth satellite
email. You get two passes a day to pump a couple of hundred
kilobytes. Try:
================================================================
| Gary Garriott, Director, Informatics |
| Volunteers in Technical Assistance |
| 1600 Wilson Blvd., Suite 500 Tel. 703/276-1800 |
| Arlington, VA 22209 Fax 703/243-1865 |
| |
| Email: LEO satellite: gary garriott at vita Fidonet: 1:109/165 |
| Internet: garyg at vita.org, ggarriott at vita.org |
| gary.garriott at f165.n109.z1.fidonet.org |
================================================================
>Date: Wed, 27 Apr 94 23:23:08 EDT
>Sender: ietf-request at IETF.CNRI.Reston.VA.US
>From: Brad Parker <brad at fcr.com>
>To: ietf at CNRI.Reston.VA.US
>Cc: throop at wilder.com
>Subject: Internet connectivity in the Costa Rican jungle?
>Status: O
>
>
>I'll probably get flamed for asking this here, but I honestly could not
>think of a better place.
>
>Problem:
> A group of researchers working in a remote area of Costa Rica
>would like email connectivity to the Internet. Currently they drive 5
>hours to a small town where they share a FAX machine with about 80
>other people. They could use a slightly higher bandwidth communication
>channel. Apparently there are no phone lines anywhere near their
>location.
>
> Also, since this is not a commercial project, money is an
>issue. (so running a fiber optic cable across the country or having
>phone lines installed is not possible).
>
> I thought real hard about this but most of my experience is
>with ethernet, modems and leased lines. Even the spread spectrum
>wireless devices I've seen will only do line of sight for about 10
>miles (or less).
>
> Does anyone have any experience with VSAT? We can skip over
>the know problems with satellites (half-duplex + very long turn around
>delays). I'm just curious if this is a solution at all i.e. can one
>buy a small aperture dish + box and pump IP though it on a research
>budget.
>
> Does that "satellite cell-phone in a brief case" I saw in the
>Steven Segall movie really exist? (the one where the ship's cook
>saves the world from nuclear winter) Can I run a modem through it?
>(even at 1200 baud this would be a win). I'm only half joking here -
>I seem to recall seeing something like it on the open market. (ok,
>maybe it's a bit Dick Tracey but I had to ask).
>
> If you have any suggestions, please send them to me. I
>figured with all these bright people someone would have run across
>this sort of problem before and found a creative solution.
>
> And please, no boat full of magtape replies... ;-) These folks use
>PC's.
>
>-brad
>
>
---
Ed Krol Phone: 217 333 7886
University of Illinois
1120 DCL
1304 W. Springfield
Urbana, IL 61801
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21546;
29 Apr 94 15:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21536;
29 Apr 94 15:58 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa17458;
29 Apr 94 15:58 EDT
Received: by bitsy.MIT.EDU
id AA03331; Fri, 29 Apr 94 15:37:43 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA03323; Fri, 29 Apr 94 15:37:41 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA24299; Fri, 29 Apr 94 15:37:29 EDT
Received: from localhost (glenz at localhost) by kerby.ocsg.com (8.6.4/8.6.4, dpg hack 10jan94) id MAA06523 for cat-ietf at MIT.EDU; Fri, 29 Apr 1994 12:37:20 -0700
Date: Fri, 29 Apr 1994 12:37:20 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Glen Zorn <glenz at ocsg.com>
Message-Id: <199404291937.MAA06523 at kerby.ocsg.com>
To: cat-ietf at mit.edu
Subject: Slow days?
Folks ~
I've not recieved any messages from this list in several days. Has something
gotten screwed up or has there really been to traffic?
~gwz
Glen Zorn Senior Scientist
glenz at OCSG.COM CyberSafe Corporation
Since I was forced to write it by the alien parasite which attached itself to my
brain stem during my recent visit to an isolated area of Northern Arizona, it
could hardly be construed that this message would reflect either the opinions
or policies of my employer.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22058;
29 Apr 94 16:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22048;
29 Apr 94 16:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17916;
29 Apr 94 16:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22037;
29 Apr 94 16:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22011;
29 Apr 94 16:17 EDT
Received: from uucp7.netcom.com by CNRI.Reston.VA.US id aa17887;
29 Apr 94 16:17 EDT
Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
id NAA26596; Fri, 29 Apr 1994 13:18:49 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: lynn at bli.com
Received: by bli.com (AIX 3.2/UCB 5.64/4.03)
id AA19099; Fri, 29 Apr 1994 13:05:02 -0700
Date: Fri, 29 Apr 1994 13:05:02 -0700
Message-Id: <9404292005.AA19099 at bli.com>
To: ietf at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: speedup for experimental rfc index html
Reply-To: Lynn Wheeler <lynn at bli.com>
by popular demand i've split the html file into lots of little files
... should be a little faster now (although the aggregate no. bits is
larger because a majority of the links now require filename). shortly
I'll be getting a resting place which doesn't have as much congestion
as ftp.netcom.com (for testing, it is also possible to try
netcom1.netcom.com, netcom2.netcom.com, ...., netcom13.netcom.com).
+++++
Lynn Wheeler | email: lynn at bli.com
Britton Lee | voice: 408-370-1400
PO Box 8 | fax: 408-370-1598
Los Gatos, Ca. 95031 |
Words of wisdom from Zippy:
If a person is FAMOUS in this country, they have to go on the ROAD
for MONTHS at a time and have their name misspelled on the SIDE
of a GREYHOUND SCENICRUISER!!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22921;
29 Apr 94 17:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22912;
29 Apr 94 17:08 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa18903;
29 Apr 94 17:08 EDT
Received: by bitsy.MIT.EDU
id AA01001; Fri, 29 Apr 94 16:50:41 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA00993; Fri, 29 Apr 94 16:50:39 EDT
Received: from mgm.ctt.bellcore.com by MIT.EDU with SMTP
id AA00424; Fri, 29 Apr 94 16:50:28 EDT
Received: from shadow.secure.bellcore.com (shadow-ctt.ctt.bellcore.com) by mgm.ctt.bellcore.com with SMTP id AA24182
(5.65c/IDA-1.4.4 for <cat-ietf at mit.edu>); Fri, 29 Apr 1994 16:50:19 -0400
Received: from bartman.secure.bellcore.com.secure (bartman.secure.bellcore.com) by shadow.secure.bellcore.com with SMTP id AA24007
(5.65c/IDA-1.4.4 for <cat-ietf at mit.edu>); Fri, 29 Apr 1994 16:50:18 -0400
Date: Fri, 29 Apr 1994 16:50:18 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Lunt <lunt at ctt.bellcore.com>
Message-Id: <199404292050.AA24007 at shadow.secure.bellcore.com>
To: cat-ietf at mit.edu
Subject: Version 5 of the FTP Security Draft
I've submitted version 5 of the FTP Security Extensions
Internet Draft and placed a copy on thumper.bellcore.com. I've also
outlined the changes since version 4 below. Please let me know if
there are any remaining issues (e.g., I have no mention in the GSSAPI
appendix of how to determine buffer size growth associated with
GSS_{Sign/Seal}, and I did not make the modification to the Kerberos
V4 protocol suggested by John Myers of adding a challenge from the
server).
1. I added the following text under Section 3 in the description of
the AUTH command:
> It should be noted that "smart" clients which obscure from the user
> the text of the USER command may hinder incorporation
> of one-time password schemes (e.g., S/Key).
> It is important that the client display the text of the USER response
> to the user *prior* to prompting for a password.
> These one-time password systems may be incorporated in servers
> without need for client modification since the challenge is one way.
2. I added the following section:
> 7. State Diagram
>
> Here we present state diagrams for the new AUTH and ADAT commands,
> similar to the state diagrams in [1].
> Only the first digit of the reply codes is used.
>
> In the state diagrams below we use the symbol B for "begin", and
> the symbol W for "wait for reply". The state labelled "U" represents
> the begin state of the diagram for the Login sequence from [1].
>
>
> 5 & more AUTH types
> ------------------------------------------------
> | | 3 |
> | | -------------- |
> | | | | |
> V | V | |
> +---+ AUTH +---+ 3 +---+ ADAT +---+
> | B |---------->| W |---------->| |---------->| W |
> +---+ +---+ +---+ +---+
> | |
> |-------------------------------
> | 2, 5 & no more AUTH types
> V
> +---+
> | U |
> +---+
3. The checksum in the Kerberos V4 protocol must be sent in network
byte order (most significant byte first).
4. I added the following comment regarding buffer sizes in Kerberos V4:
> In order to stay within the allowed PBSZ, implementors should take note
> that a cleartext buffer will grow by 31 bytes
> when processed by krb_mk_safe(3) and
> will grow by 26 bytes when processed by krb_mk_priv(3).
5. Deleted the requirement that the client pass NULL for
claimant_cred_handle and mech_type for GSS_Init_Sec_Context.
6. Added a fall-back name of SERVICE:host at hostname for GSSAPI.
-- Steve
Steven J. Lunt lunt at bellcore.com
Information Technology Security RRC 1L-213
Bellcore 444 Hoes Lane
(908) 699-4244 Piscataway, NJ 08854
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25076;
29 Apr 94 20:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25066;
29 Apr 94 20:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25167;
29 Apr 94 20:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25055;
29 Apr 94 20:55 EDT
Received: from hearn.nic.surfnet.nl by IETF.CNRI.Reston.VA.US id aa25022;
29 Apr 94 20:50 EDT
Received: from IRLEARN.UCD.IE by HEARN.nic.SURFnet.nl (IBM VM SMTP V2R2)
with BSMTP id 7825; Sat, 30 Apr 94 02:42:06 CET
Received: from IRLEARN.UCD.IE (NJE origin JENNINGS at IRLEARN) by IRLEARN.UCD.IE
(LMail V1.2a/1.8a) with BSMTP id 1094; Fri, 29 Apr 1994 22:22:46 +0100
Date: Fri, 29 Apr 94 22:13:58 WET
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Jennings <JENNINGS at irlearn.ucd.ie>
Subject: Engineers Conference in Paris
To: end2end-interest-request at isi.edu, rem-conf-request at es.net,
ietf at IETF.CNRI.Reston.VA.US, big-internet at munnari.oz.au
cc: Christian Huitema <Christian.Huitema at sophia.inria.fr>,
Emmanuelle Gille <egille at interop.com>,
Susan Karlson <skarlson at interop.com>,
Mike Millikin <mmillikin at interop.com>
Message-ID: <9404292050.aa25022 at IETF.CNRI.Reston.VA.US>
Dear Sirs,
At Christian Huitema's suggestion, I write to you to request permission
to circulate on your e-mail lists the following Call for Papers for the
Engineers conference to be held at NetWorld+Interop 94 in files.
With many thanks in anticipation,
Dennis (Jennings)
Chairman, NetWorld+Interop European Programme Committee
-----------------------------------------------------------------------
=====================
First Call for Papers
-------------------
Engineers Conference
at
NetWorld+Interop 94 Paris
---------------------------------------------------------------------
Interop Company is soliciting technical papers for an Engineers
Conference to be held as part of the upcoming NetWorld+Interop
94 Paris event, October 24 - 28, 1994, in Paris.
The Engineers Conference, which will be held on Thursday/Friday
October 27 - 28, is a two-day focused event offering approaches and
solutions to practical systems and software design for networking.
All participants in the conference will be able to attend the
NetWorld+Interop 94, Paris exhibition, which will run from
October 26 - 28.
FORMAT
The conference will feature the presentation of original papers
which will have been selected by a review committee. All accepted
papers will be published in Conference Proceedings. Accepted papers
must be presented by original authors during the 2-day conference.
Conference sessions typically will be 90 minutes long and will
present three papers of 20 to 30 minutes duration.
The Engineer's Conference will concentrate on engineering design
problems in three areas: High Speed Networking, Internetworking,
and Multimedia. This conference seeks to bring together research
scholars, engineers, and vendors to address pragmatic engineering
issues in the field of networking and distributed systems
interoperability. It is an excellent forum for Engineers and
Researchers to publish papers and to be brought up to date on
solutions to today's engineering related problems.
Papers are solicited in the following areas:
* High Speed Networking: ATM, Fast Ethernet, SDH, FDDI-II,
HIPPI, SMDS, Frame Relay, Broadband ISDN, etc.
* Internetworking: Addressing Schemes, Routing Protocols,
Support of Mobility, Design of Bridges, Routers, and
Multiprotocol Brouters, Application Gateways etc.
* Multimedia Networking: Multimedia technologies, Multimedia
inteoperability, Packet Video and voice, Multimedia Mail and
Conferencing, Tele-Presence, Virtual Reality, etc.
SUBMISSION GUIDELINES
Interested authors are invited to submit an abstract (up to 600
words) clearly describing the problem and the solution offered. All
abstracts will be reviewed and authors will be notified for acceptance
or rejection of the abstract. Authors of accepted abstracts must
submit the paper before the last date. These papers are reviewed by
a technical committee for technical merit of the paper before final
acceptance.
Please note the important dates for abstract and paper submission.
All abstracts must contain the authors name, address, telephone
number, Fax number and e-mail address (if available).
Please send your abstract to:
Interop Europe
14 Place Marie-Jeanne Bassot,
92593 Levallois Peret Cedex,
Paris, France
Attention: Engineer's Conference
or e-mail it (in ASCII or PostScript) to: Paris_Engineer at interop.com
** E-mail is preferred. **
===================
= Important Dates =
===================
Abstracts due: 3 Jun, 1994
Notification to authors: 24 Jun, 1994
Draft paper due: 22 Jul, 1994
Feedback to authors: 5 Aug, 1994
Camera ready copy due: 9 Sep, 1994
Final camera reader papers must not exceed 10 A4 pages.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25226;
29 Apr 94 21:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25216;
29 Apr 94 21:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25406;
29 Apr 94 21:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25205;
29 Apr 94 21:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25161;
29 Apr 94 21:08 EDT
Received: from prwtos.crnet.cr by CNRI.Reston.VA.US id aa25350;
29 Apr 94 21:08 EDT
Date: Fri, 29 Apr 94 19:10:58 EST
Message-Id: <9404291910.AA00390 at prwtos.crnet.cr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Guy F. de Teramond" <gdt at prwtos.crnet.cr>
Reply-To: gdt at prwtos.crnet.cr
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
To: Brad Parker <brad at fcr.com>, Larry Landweber <lhl at cs.wisc.edu>
CC: ietf at CNRI.Reston.VA.US, throop at wilder.com, gdt at prwtos.crnet.cr,
abrenes at ns.cr, gguido at ns.cr
Subject: Re: your note (VSATs in the jungle!)
X-Mailer: <IMAIL v94.04.23>
In reply to:
>
>guy
>do you have any online info on vsats that you could
>send?
>
>also, did you see the following?
No, I am not suscribed to that list
Regards, Guy
>regards
>larry
>-------
>>From ietf-request at ietf.cnri.reston.va.us Wed Apr 27 22:35:51 1994
>Date: Wed, 27 Apr 94 23:23:08 EDT
>Sender: ietf-request at IETF.CNRI.Reston.VA.US
>From: Brad Parker <brad at fcr.com>
>To: ietf at CNRI.Reston.VA.US
>Cc: throop at wilder.com
>Subject: Internet connectivity in the Costa Rican jungle?
>
>I'll probably get flamed for asking this here, but I honestly could not
>think of a better place.
Why?
>
>Problem:
> A group of researchers working in a remote area of Costa Rica
>would like email connectivity to the Internet. Currently they drive 5
>hours to a small town where they share a FAX machine with about 80
>other people. They could use a slightly higher bandwidth communication
>channel. Apparently there are no phone lines anywhere near their
>location.
Could you please specify your location?
The country has a quite extendend public phone system.
>
> Also, since this is not a commercial project, money is an
>issue. (so running a fiber optic cable across the country or having
>phone lines installed is not possible).
>
> I thought real hard about this but most of my experience is
>with ethernet, modems and leased lines. Even the spread spectrum
>wireless devices I've seen will only do line of sight for about 10
>miles (or less).
Actually the CYLINK spread spectrum modems will give you a greater
distance and we use them often when it is not possible to use
band base modems or SDC modems, but probably not adequate when the
line of sight is broken in a mountain environment
>
> Does anyone have any experience with VSAT? We can skip over
>the know problems with satellites (half-duplex + very long turn around
>delays). I'm just curious if this is a solution at all i.e. can one
>buy a small aperture dish + box and pump IP though it on a research
>budget.
VSAT is a good solution, but if money is an issue I can hardly see
this as a realistic solution. VSAT links can be established over
Panamsat
PAS-1 Central Beam. You could contact Eng. Gabriela Guido at RACSA
(the local PTT) gguido at ns.cr (Phone (506) 287 04 60) for additional
information. Due to the small size of the country, the VSAT solution
is practically not used.
> Does that "satellite cell-phone in a brief case" I saw in the
>Steven Segall movie really exist? (the one where the ship's cook
>saves the world from nuclear winter) Can I run a modem through it?
>(even at 1200 baud this would be a win). I'm only half joking here -
>I seem to recall seeing something like it on the open market. (ok,
>maybe it's a bit Dick Tracey but I had to ask).
>
> If you have any suggestions, please send them to me. I
>figured with all these bright people someone would have run across
>this sort of problem before and found a creative solution.
If all of the above fails... you could try to establish a radio
link to CRNet...
Information on CRNet the National Research Network of Costa Rica
can be found by anonymous ftp on prwtos.crnet.cr (163.178.8.26)
or in gopher.cr or www.cr. Certainly your research proyect
qualifies for connection to CRNet, which actually has more than
500 nodes interconected to the Internet in Academic and
Research Institutions in the country.
Please contact Eng. Abel Brenes (506) 225 5911 (abrenes at ns.cr)
for more information.
Regards
Guy de Teramond
CRNet
> And please, no boat full of magtape replies... ;-) These folks use
>PC's.
>
>-brad
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02350;
29 Apr 94 23:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02340;
29 Apr 94 23:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27430;
29 Apr 94 23:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02198;
29 Apr 94 23:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01692;
29 Apr 94 23:42 EDT
Received: from aplmail.jhuapl.edu by CNRI.Reston.VA.US id aa27419;
29 Apr 94 23:42 EDT
Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3)
id AA25182; Fri, 29 Apr 1994 23:42:23 -0400
Received: by aplcomm.jhuapl.edu (5.0/SMI-SVR4)
id AA00458; Fri, 29 Apr 1994 23:41:28 +0500
Date: Fri, 29 Apr 1994 23:41:28 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Barry R Greene BIX x6064 <greenebr at aplcomm.jhuapl.edu>
Subject: Re: Costa Rican Connectivity
To: Ed Krol <e-krol at uiuc.edu>
Cc: brad at fcr.com, garyg at vita.org, ietf at CNRI.Reston.VA.US
In-Reply-To: <a9e6c35f0d0210088e5e at [128.174.33.173]>
Message-Id: <Pine.3.89.9404292313.A333-0100000 at aplcomm.jhuapl.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 482
Hi Brad,
Try to gopher of WWW to ns.cr. Yes, Costa Rice is directly connected to
the Internet.
Second, check the gopher in Peru. It has the most complete list of
E-mail providers in Latin America. I do not have the address with me,
but it is included with the Network Service Providers Around the World
(NSPAW) document. You can pick this up at the ISOC gopher:
gopher.isoc.reston.us
If this still does not do the trick, please let me know.
Barry Raveendran Greene
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01099;
30 Apr 94 4:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01095;
30 Apr 94 4:45 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa02458;
30 Apr 94 4:45 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0)
id SAA01936; Sat, 30 Apr 1994 18:15:12 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP
id OAA01722; Sat, 30 Apr 1994 14:23:55 +1000
Received: from hearn.nic.surfnet.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA15411; Sat, 30 Apr 1994 10:50:51 +1000 (from @HEARN.nic.SURFnet.nl:JENNINGS at IRLEARN.UCD.IE)
Message-Id: <9404300050.15411 at munnari.oz.au>
Received: from IRLEARN.UCD.IE by HEARN.nic.SURFnet.nl (IBM VM SMTP V2R2)
with BSMTP id 7825; Sat, 30 Apr 94 02:42:06 CET
Received: from IRLEARN.UCD.IE (NJE origin JENNINGS at IRLEARN) by IRLEARN.UCD.IE
(LMail V1.2a/1.8a) with BSMTP id 1094; Fri, 29 Apr 1994 22:22:46 +0100
Date: Fri, 29 Apr 94 22:13:58 WET
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Jennings <JENNINGS at irlearn.ucd.ie>
Subject: Engineers Conference in Paris
To: end2end-interest-request at isi.edu, rem-conf-request at es.net,
ietf at IETF.CNRI.Reston.VA.US, big-internet at munnari.oz.au
Cc: Christian Huitema <Christian.Huitema at sophia.inria.fr>,
Emmanuelle Gille <egille at interop.com>,
Susan Karlson <skarlson at interop.com>,
Mike Millikin <mmillikin at interop.com>
Dear Sirs,
At Christian Huitema's suggestion, I write to you to request permission
to circulate on your e-mail lists the following Call for Papers for the
Engineers conference to be held at NetWorld+Interop 94 in files.
With many thanks in anticipation,
Dennis (Jennings)
Chairman, NetWorld+Interop European Programme Committee
-----------------------------------------------------------------------
=====================
First Call for Papers
-------------------
Engineers Conference
at
NetWorld+Interop 94 Paris
---------------------------------------------------------------------
Interop Company is soliciting technical papers for an Engineers
Conference to be held as part of the upcoming NetWorld+Interop
94 Paris event, October 24 - 28, 1994, in Paris.
The Engineers Conference, which will be held on Thursday/Friday
October 27 - 28, is a two-day focused event offering approaches and
solutions to practical systems and software design for networking.
All participants in the conference will be able to attend the
NetWorld+Interop 94, Paris exhibition, which will run from
October 26 - 28.
FORMAT
The conference will feature the presentation of original papers
which will have been selected by a review committee. All accepted
papers will be published in Conference Proceedings. Accepted papers
must be presented by original authors during the 2-day conference.
Conference sessions typically will be 90 minutes long and will
present three papers of 20 to 30 minutes duration.
The Engineer's Conference will concentrate on engineering design
problems in three areas: High Speed Networking, Internetworking,
and Multimedia. This conference seeks to bring together research
scholars, engineers, and vendors to address pragmatic engineering
issues in the field of networking and distributed systems
interoperability. It is an excellent forum for Engineers and
Researchers to publish papers and to be brought up to date on
solutions to today's engineering related problems.
Papers are solicited in the following areas:
* High Speed Networking: ATM, Fast Ethernet, SDH, FDDI-II,
HIPPI, SMDS, Frame Relay, Broadband ISDN, etc.
* Internetworking: Addressing Schemes, Routing Protocols,
Support of Mobility, Design of Bridges, Routers, and
Multiprotocol Brouters, Application Gateways etc.
* Multimedia Networking: Multimedia technologies, Multimedia
inteoperability, Packet Video and voice, Multimedia Mail and
Conferencing, Tele-Presence, Virtual Reality, etc.
SUBMISSION GUIDELINES
Interested authors are invited to submit an abstract (up to 600
words) clearly describing the problem and the solution offered. All
abstracts will be reviewed and authors will be notified for acceptance
or rejection of the abstract. Authors of accepted abstracts must
submit the paper before the last date. These papers are reviewed by
a technical committee for technical merit of the paper before final
acceptance.
Please note the important dates for abstract and paper submission.
All abstracts must contain the authors name, address, telephone
number, Fax number and e-mail address (if available).
Please send your abstract to:
Interop Europe
14 Place Marie-Jeanne Bassot,
92593 Levallois Peret Cedex,
Paris, France
Attention: Engineer's Conference
or e-mail it (in ASCII or PostScript) to: Paris_Engineer at interop.com
** E-mail is preferred. **
===================
= Important Dates =
===================
Abstracts due: 3 Jun, 1994
Notification to authors: 24 Jun, 1994
Draft paper due: 22 Jul, 1994
Feedback to authors: 5 Aug, 1994
Camera ready copy due: 9 Sep, 1994
Final camera reader papers must not exceed 10 A4 pages.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03190;
30 Apr 94 12:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03186;
30 Apr 94 12:05 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa07403;
30 Apr 94 12:05 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA27677; Sat, 30 Apr 94 10:55:18 CDT
Received: by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA21173; Sat, 30 Apr 1994 10:55:14 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA21168; Sat, 30 Apr 1994 10:55:10 +0600
Received: from udel.edu (louie.udel.edu) by cray.com (Bob mailer 1.2)
id AA27664; Sat, 30 Apr 94 10:55:02 CDT
Received: from snow-white.ee.udel.edu by louie.udel.edu id aa21601;
30 Apr 94 11:47 EDT
Received: from louie.udel.edu by snow-white.ee.udel.edu id aa23861;
30 Apr 94 11:42 EDT
Date: Sat, 30 Apr 94 11:40:15 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Phuang at eecis.udel.edu
To: telnet-ietf at cray.com
Subject: Two telnet line mode ?
Message-Id: <9404301540.aa13946 at stimpy.eecis.udel.edu>
Content-Length: 540
Hello :
I am preparing the Telnet presentation, I found there are two line
modes in Telnet which are kludge line mode (line-at-a-time) and linemode
(real line mode).
Could you please tell me what's the difference between these two line
modes. Any information would be highly appreciated.
Thanks for your time.
Po-I Huang
Graduate student
Department of Computer and Information Sciences
University of Delaware
phuang at cis.udel.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15536;
1 May 94 1:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15530;
1 May 94 1:35 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa17016;
1 May 94 1:35 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA25927; Sun, 1 May 94 00:21:49 CDT
Received: by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA04704; Sun, 1 May 1994 00:21:43 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.14 Sdiv)
id AA04699; Sun, 1 May 1994 00:21:39 +0600
Received: from glare.cisco.com by cray.com (Bob mailer 1.2)
id AA25915; Sun, 1 May 94 00:21:36 CDT
Received: (billw at localhost) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id WAA24537; Sat, 30 Apr 1994 22:21:33 -0700
Date: Sat, 30 Apr 94 22:21:32 PDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Chops Westfield <billw at cisco.com>
To: Phuang at eecis.udel.edu
Cc: telnet-ietf at cray.com
Subject: Re: Two telnet line mode ?
In-Reply-To: Your message of Sat, 30 Apr 94 11:40:15 EDT
Message-Id: <CMM.0.90.2.767769692.billw at glare.cisco.com>
Content-Length: 914
I am preparing the Telnet presentation, I found there are two line
modes in Telnet which are kludge line mode (line-at-a-time) and linemode
(real line mode).
Could you please tell me what's the difference between these two line
modes. Any information would be highly appreciated.
In "kludge line mode", all you have is "line mode" or "no line mode", and
it is left for the telnet client to determin what consitutes line
terminators, editing characters, and so on. This is somewhat useful
on hosts that have a genuine "line mode" orientation.
In "real line mode", there is sufficient negotiation of those parameters
that line mode becomes useful on "sort-of" line mode systems like unix,
which are frequently interpretting commands line-at-a-time, but have so many
user-settable options within a line that the kludge line mode is
unacceptable.
BillW
cisco
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00868;
2 May 94 4:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00858;
2 May 94 4:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07008;
2 May 94 4:38 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00846;
2 May 94 4:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00783;
2 May 94 4:31 EDT
Received: from vnet.ibm.com by CNRI.Reston.VA.US id aa06931; 2 May 94 4:31 EDT
Received: from YMTVM1 by VNET.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 4921;
Mon, 02 May 94 04:30:47 EDT
Date: Mon, 2 May 94 16:30:57 JST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: hk at vnet.ibm.com
To: ietf at CNRI.Reston.VA.US
Subject: Where is the latest member lists of IESG, IAB and WG chairs?
Message-ID: <9405020431.aa06931 at CNRI.Reston.VA.US>
I'm writing introduction of IETF in Japanese and would like to know
the latest member lists of IESG, IAB and WG of IETF chairs?
I tryed the menu IETF of ietf.cnri.reston.va.us and found it was not
updated.
Thanks in advance.
Hiroshi KAWAZOE Tokyo Reserach Lab., IBM Japan
kawazoe at trl.ibm.co.jp, k at vnet.ibm.com, hk at vnet.ibm.com
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05307;
2 May 94 10:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12601;
2 May 94 10:21 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05287;
2 May 94 10:21 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05157;
2 May 94 10:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-dataencap-02.txt
Date: Mon, 02 May 94 10:15:47 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405021015.aa05157 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP LCP Option for Data Encapsulation Selection
Author(s) : J. Halpern
Filename : draft-ietf-pppext-dataencap-02.txt
Pages : 6
Date : 04/29/1994
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document defines a method for negotiating the encapsulation to be used
for the transfer of data by PPP. It applies only to links for which there
exists a "nominal" data encapsulation other than PPP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-dataencap-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-dataencap-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940429140200.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pppext-dataencap-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-dataencap-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940429140200.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06660;
2 May 94 11:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13800;
2 May 94 11:16 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06648;
2 May 94 11:16 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05167;
2 May 94 10:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tn3270e at list.nih.gov
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-tn3270e-enhancements-04.txt
Date: Mon, 02 May 94 10:15:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405021015.aa05167 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Telnet TN3270 Enhancements
Working Group of the IETF.
Title : TN3270 Enhancements
Author(s) : B. Kelly
Filename : draft-ietf-tn3270e-enhancements-04.txt
Pages : 33
Date : 04/29/1994
This document describes a protocol that more fully supports 3270 devices
than do the existing tn3270 practices. Specifically, it defines a method
of emulating both the terminal and printer members of the 3270 family of
devices via Telnet; it provides for the ability of a Telnet client to
request that it be assigned a specific device-name (also referred to as "LU
name" or "network name"); finally, it adds support for a variety of
functions such as the ATTN key, the SYSREQ key, and SNA response handling.
This protocol would be negotiated and implemented under a new Telnet Option
and would be unrelated to the Telnet 3270 Regime Option as defined in RFC
1041.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tn3270e-enhancements-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tn3270e-enhancements-04.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940429135621.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-tn3270e-enhancements-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tn3270e-enhancements-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940429135621.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08854;
3 May 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08844;
3 May 94 16:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15213;
3 May 94 16:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08833;
3 May 94 16:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08767;
3 May 94 16:32 EDT
Received: from uucp4.netcom.com by CNRI.Reston.VA.US id aa15144;
3 May 94 16:32 EDT
Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
id NAA04944; Tue, 3 May 1994 13:29:38 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: lynn at bli.com
Received: by bli.com (AIX 3.2/UCB 5.64/4.03)
id AA17000; Tue, 3 May 1994 12:51:43 -0700
Date: Tue, 3 May 1994 12:51:43 -0700
Message-Id: <9405031951.AA17000 at bli.com>
To: ietf at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: experimental ietf rfc
Reply-To: Lynn Wheeler <lynn at bli.com>
new bell&whistle is protocol index. leaves a little to be
desired with regard to format:
(nnn) protocol protocol name
rrr rfctitle
"protocol" is the protocol
"(nnn)" is corresponding "assigned" number (or ---)
"protocol name" is name of the protocol
rrr/rfctitle is rfc number & title (if there is one)
+++++
Lynn Wheeler | email: lynn at bli.com
Britton Lee | voice: 408-370-1400
PO Box 8 | fax: 408-370-1598
Los Gatos, Ca. 95031 |
Words of wisdom from Zippy:
On SECOND thought, maybe I'll heat up some BAKED BEANS and
watch REGIS PHILBIN.. It's GREAT to be ALIVE!!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09860;
3 May 94 18:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09852;
3 May 94 18:32 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa17658; 3 May 94 18:32 EDT
Received: by bitsy.MIT.EDU
id AA11149; Tue, 3 May 94 18:20:10 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA11135; Tue, 3 May 94 18:20:07 EDT
Received: from ANDREW.CMU.EDU by MIT.EDU with SMTP
id AA02054; Tue, 3 May 94 18:19:59 EDT
Received: (from postman at localhost) by andrew.cmu.edu (8.6.7/8.6.6) id SAA19986 for cat-ietf at mit.edu; Tue, 3 May 1994 18:19:56 -0400
Received: via switchmail; Tue, 3 May 1994 18:19:53 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/testq0/QF.Uhlgqye00WBwM0WOZT>;
Tue, 3 May 1994 18:18:39 -0400 (EDT)
Received: from hogtown.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr7/jm36/.Outgoing/QF.khlgqxS00WBw8Ye2wb>;
Tue, 3 May 1994 18:18:37 -0400 (EDT)
Received: from BatMail.robin.v2.14.CUILIB.3.45.SNAP.NOT.LINKED.hogtown.andrew.cmu.edu.sun4c.411
via MS.5.6.hogtown.andrew.cmu.edu.sun4c_411;
Tue, 3 May 1994 18:18:36 -0400 (EDT)
Message-Id: <ohlgqwi00WBw4Ye2ky at andrew.cmu.edu>
Date: Tue, 3 May 1994 18:18:36 -0400 (EDT)
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Gardiner Myers <jgm+ at cmu.edu>
To: cat-ietf at mit.edu
Subject: FTP security
Beak: is Not
Version 4 of the FTP Security draft has wording in the description of
the AUTH command which says that in some cases a USER command may be
sent in advance of the AUTH command.
When this is or is not allowed isn't particularly clear. The document
does state that any successful ADAT command must be followed by a USER
command.
This also isn't expressed in the state diagram Steve recently posted.
I think this can be simplified with no loss in functionality by
removing the wording allowing USER before AUTH. Any authentication
protocol which may require prior knowledge of the remote user name can
either ask for the user name as part of the authentication exchange
or, in the case where AUTH returns 234, issue the appropriate
challenge in the response to the subsequent USER command.
As someone else mentioned to me in the context of the IMAP security
work, if a userid is being transmitted as part of a strong
authentication mechanism, it should at least be integrity protected.
--
_.John G. Myers Internet: jgm+ at CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10500;
3 May 94 20:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10496;
3 May 94 20:04 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa18997;
3 May 94 20:04 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA24666; Tue, 3 May 94 18:54:10 CDT
Received: by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv)
id AA10768; Tue, 3 May 1994 18:54:06 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv)
id AA10763; Tue, 3 May 1994 18:54:01 +0600
Received: from Slapshot.Stanford.EDU by cray.com (Bob mailer 1.2)
id AA24658; Tue, 3 May 94 18:53:59 CDT
Received: (from schemers at localhost) by Slapshot.Stanford.EDU (8.6.8/8.6.6) id QAA02614; Tue, 3 May 1994 16:53:56 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Roland J. Schemers III" <schemers at slapshot.stanford.edu>
Message-Id: <9405031653.ZM2612 at Slapshot.Stanford.EDU>
Date: Tue, 3 May 1994 16:53:56 -0700
X-Mailer: Z-Mail (3.0.0 15dec93)
To: telnet-ietf at cray.com
Subject: telnet.94.02.07...
Cc: dab at cray.com
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
Content-Length: 518
I'm trying to get a hold of:
telnet.94.02.07.tar.Z
The version on ftp.cray.com has encryption ripped out. I can understand
if it was taken out for export reasons, but is there a way for an
American citizen to get it? :-)
Thanks, Roland
--
Roland J. Schemers III | Networking Systems
Authentication Services Programmer | 414 Sweet Hall +1 (415) 723-6740
Distributed Computing Operations | Stanford, CA 94305-3090
Stanford University | schemers at Slapshot.Stanford.EDU
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02591;
4 May 94 8:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02587;
4 May 94 8:50 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa04856;
4 May 94 8:50 EDT
Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2)
id AA20184; Wed, 4 May 94 07:39:35 CDT
Received: by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv)
id AA03674; Wed, 4 May 1994 07:39:30 +0600
Received: from cray.com (timbuk.cray.com) by sdiv.cray.com (5.0/CRI-5.15.orgabbr Sdiv)
id AA03668; Wed, 4 May 1994 07:39:25 +0600
Received: from tsx-11.MIT.EDU by cray.com (Bob mailer 1.2)
id AA20177; Wed, 4 May 94 07:39:23 CDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA19517; Wed, 4 May 94 08:39:10 EDT
Date: Wed, 4 May 94 08:39:10 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at athena.mit.edu>
Message-Id: <9405041239.AA19517 at tsx-11.MIT.EDU>
To: "Roland J. Schemers III" <schemers at slapshot.stanford.edu>
Cc: telnet-ietf at cray.com, dab at cray.com
In-Reply-To: Roland J. Schemers III's message of Tue, 3 May 1994 16:53:56 -0700,
<9405031653.ZM2612 at Slapshot.Stanford.EDU>
Subject: Re: telnet.94.02.07...
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Content-Length: 941
From: "Roland J. Schemers III" <schemers at Slapshot.Stanford.EDU>
Date: Tue, 3 May 1994 16:53:56 -0700
I'm trying to get a hold of:
telnet.94.02.07.tar.Z
The version on ftp.cray.com has encryption ripped out. I can understand
if it was taken out for export reasons, but is there a way for an
American citizen to get it? :-)
It's available on net-dist.mit.edu, in the directory /pub/telnet.
You'll have to read the README file to get further information about how
to get the distribution. You also must be coming from a host which can
DNS reverse-resolve to a name that's likely to be in the U.S. Contact
me if you have a DNS name ending in something like .ORG, where it's not
clear whether or not you're coming from the U.S. or Canada or not.
(We're distributing an older version of that telnet with our Kerberos V5
distribution, using similar restrictions to prevent export, on
athena-dist.mit.edu.)
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04428;
4 May 94 10:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04424;
4 May 94 10:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07515;
4 May 94 10:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04410;
4 May 94 10:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04406;
4 May 94 10:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07495;
4 May 94 10:35 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04401;
4 May 94 10:35 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-ppp at merit.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: The Point-to-Point Protocol (PPP) to Standard
Date: Wed, 04 May 94 10:35:07 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9405041035.aa04401 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider <draft-ietf-pppext-lcp-fs-01.txt>
"The Point-to-Point Protocol (PPP)" for the status of Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by May
17, 1994.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04536;
4 May 94 10:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04532;
4 May 94 10:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07647;
4 May 94 10:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04498;
4 May 94 10:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04492;
4 May 94 10:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07631;
4 May 94 10:36 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04480;
4 May 94 10:36 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-ppp at merit.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: PPP in HDLC-like Framing to Standard
Date: Wed, 04 May 94 10:36:15 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9405041036.aa04480 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider <draft-ietf-pppext-hdlc-fs-01.txt>
"PPP in HDLC-like Framing" for the status of Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by May
17, 1994.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05668;
4 May 94 11:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08822;
4 May 94 11:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05657;
4 May 94 11:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05539;
4 May 94 11:20 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: cat-ietf at mit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-cat-ftpsec-05.txt
Date: Wed, 04 May 94 11:20:33 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405041120.aa05539 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Common Authentication
Technology Working Group of the IETF.
Title : FTP Security Extensions
Author(s) : S. Lunt
Filename : draft-ietf-cat-ftpsec-05.txt
Pages : 17
Date : 05/02/1994
This document defines extensions to the FTP specification RFC 959,
"FILE TRANSFER PROTOCOL (FTP)" (October 1985), which provide strong
authentication, integrity, and confidentiality on both the control and
data channels with the introduction of new optional commands, replies,
and file transfer encodings.
The following new optional commands are introduced in this specification:
AUTH (Authentication Type),
ADAT (Authentication Data),
MIC (Integrity Protected Command),
ENC (Privacy Protected Command),
PROT (Data Channel Protection Level), and
PBSZ (Protection Buffer Size).
A new class of reply types (6yz) is also introduced for protected replies.
None of the above commands are required to be implemented, but each is
dependent on the other (except ENC, which is optional).
Note that this specification is compatible with RFC 959.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-cat-ftpsec-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-cat-ftpsec-05.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940502110539.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-cat-ftpsec-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-cat-ftpsec-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940502110539.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06724;
4 May 94 11:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06716;
4 May 94 11:57 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa10433; 4 May 94 11:57 EDT
Received: by bitsy.MIT.EDU
id AA23796; Wed, 4 May 94 11:40:29 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA23782; Wed, 4 May 94 11:40:27 EDT
Received: from mgm.ctt.bellcore.com by MIT.EDU with SMTP
id AA16149; Wed, 4 May 94 11:40:23 EDT
Received: from shadow.secure.bellcore.com (shadow-ctt.ctt.bellcore.com) by mgm.ctt.bellcore.com with SMTP id AA01984
(5.65c/IDA-1.4.4 for <cat-ietf at MIT.EDU>); Wed, 4 May 1994 11:40:20 -0400
Received: from bartman.secure.bellcore.com.secure (bartman.secure.bellcore.com) by shadow.secure.bellcore.com with SMTP id AA03474
(5.65c/IDA-1.4.4); Wed, 4 May 1994 11:40:19 -0400
Date: Wed, 4 May 1994 11:40:19 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Lunt <lunt at ctt.bellcore.com>
Message-Id: <199405041540.AA03474 at shadow.secure.bellcore.com>
To: jgm+ at cmu.edu
Subject: Re: FTP security
Cc: cat-ietf at mit.edu
There was some discussion about this on the cat mailing list
a while ago. I don't know of any current implementations that would
need the target user identity, but rather than sending USER in
advance of sending AUTH/ADAT commands, you could take the approach
which you suggest in a previous email:
> A server which does not support or permit the use of a particular
> authentiction mechanism for a particular user ...
> ... can (with appropriate
> knowledge) hide that information by mimicing the mechanism's protocol
> exchange and failing at the right point.
-- Steve
> From: John Gardiner Myers <jgm+ at CMU.EDU>
>
> Version 4 of the FTP Security draft has wording in the description of
> the AUTH command which says that in some cases a USER command may be
> sent in advance of the AUTH command.
>
> When this is or is not allowed isn't particularly clear. The document
> does state that any successful ADAT command must be followed by a USER
> command.
>
> This also isn't expressed in the state diagram Steve recently posted.
>
> I think this can be simplified with no loss in functionality by
> removing the wording allowing USER before AUTH. Any authentication
> protocol which may require prior knowledge of the remote user name can
> either ask for the user name as part of the authentication exchange
> or, in the case where AUTH returns 234, issue the appropriate
> challenge in the response to the subsequent USER command.
>
> As someone else mentioned to me in the context of the IMAP security
> work, if a userid is being transmitted as part of a strong
> authentication mechanism, it should at least be integrity protected.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08580;
4 May 94 13:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08570;
4 May 94 13:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15121;
4 May 94 13:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08556;
4 May 94 13:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08496;
4 May 94 13:34 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa14999;
4 May 94 13:34 EDT
Received: from june.cs.washington.edu by venera.isi.edu (5.65c/5.61+local-14)
id <AA06760>; Wed, 4 May 1994 10:20:27 -0700
Return-Path: <glinert>
Received: (glinert at localhost) by june.cs.washington.edu (8.6.8/7.2ju) id JAA22452; Wed, 4 May 1994 09:59:19 -0700
Date: Wed, 4 May 1994 09:59:19 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ephraim P. Glinert" <glinert at cs.washington.edu>
Message-Id: <199405041659.JAA22452 at june.cs.washington.edu>
To: end2end-interest at isi.edu, f-troup at aurora.cis.upenn.edu, ietf at isi.edu,
ir-l%uccvma.bitnet at cunyvm.cuny.edu, rem-conf-request at es.net,
rem-conf at es.net, sound at pascal.acm.org, tccc at cs.umass.edu
Subject: Deadline Extended!
Many authors have asked for some extra time to prepare their papers for
ASSETS'94, the First ACM/SIGCAPH Conference on Assistive Technologies.
The reason is that the original due date was inadvertently set too close
to last week's SIGCHI'94.
I AM THEREFORE PLEASED TO ANNOUNCE THAT THE DEADLINE FOR SUBMISSIONS TO
ASSETS'94 HAS BEEN EXTENDED TO MONDAY, MAY 16.
^^^^^^^^^^^^^^^
Please tell your friends and colleagues about this important change. We
look forward to receiving your paper, and to seeing you at the conference!
-EPG
PS. A copy of the revised CFP is attached for your reference.
\/\/\/\/\/\/\/\/\/\/\/
Call For Participation
/\/\/\/\/\/\/\/\/\/\/\
ASSETS '94
The First Annual International ACM/SIGCAPH
Conference on Assistive Technologies
October 31-November 1, 1994, Marina del Rey, California
Sponsored by the ACM's Special Interest Group on Computers and the
Physically Handicapped, ASSETS'94 is the first of a new annual series
of conferences whose goal is to provide a forum where researchers and
developers, from academia and industry, can meet to exchange ideas and
report on new developments relating to computer-based systems to help
people. The conference scope spans impairments and disabilities of all
kinds, including but not limited to: sensory (hearing, vision, touch);
motor (orthopedic); cognitive (learning, speech, mental); and emotional.
Technical papers (up to 8 pgs in length) should be of the high quality
expected at the best ACM conferences, and should either (a) present
significant, original research results of a theoretical nature, or
(b) report the results of relevant and rigorous empirical studies, or
(c) describe the ``look and feel'' and discuss the internal workings of
an implemented system. Where possible and appropriate, papers should be
accompanied by a video to clarify and reinforce the concepts discussed.
Panel proposals (up to 3 pgs in length) on timely and controversial
topics are also welcome!
All submissions will be refereed, and no more will be accepted than can
be comfortably presented in a single track (no parallel sessions). Send
7 copies of full papers and 4 copies of panel proposals, all formatted
in accordance with standard ACM two-column conference style, to the
Program Chair:
Ephraim P. Glinert
Dept. of Computer Science and Engineering, FR-35
University of Washington
Seattle, WA 98195
ALL SUBMISSIONS MUST BE RECEIVED NO LATER THAN MONDAY, MAY 16, 1994.
^^^^^^^^^^^^^^^^^^^^^
Questions should be directed to glinert at cs.washington.edu.
NOTE: ASSETS'94 will immediately precede UIST'94, which will take place
at the same site on November 2-4. See you in Marina del Rey!
========================================================================
General Chair: Theodor D. Sterling, Simon Fraser University
Program Committee: Ephraim P. Glinert (Chair)
University of Washington and RPI
Norman Alm, University of Dundee
Julie Baca, Waterways Experiment Station
Meera M. Blattner, LLNL and U.California at Davis
James L. Caldwell, IBM RISC Adaptive Technologies
S.-K. Chang, University of Pittsburgh
Patrick Demasco, University of Delaware
Alistair D.N. Edwards, University of York
Gerald L. Engel, National Science Foundation
Carl Friedlander, ISX Corp.
Hiromichi Fujisawa, Hitachi (Japan)
Ralph Guertin, MITRE Corp.
Robert J.K. Jacob, Naval Research Labs
David L. Jaffe, Palo Alto VA Medical Center
Earl Johnson, Sun Microsystems Labs
Karen Kukich, Bell Communications Research
Richard E. Ladner, University of Washington
Clayton Lewis, University of Colorado at Boulder
Elizabeth D. Mynatt, Georgia Inst. of Technology
Randy Pausch, University of Virginia
T.V. Raman, DEC Cambridge Research Laboratory
Gregg C. Vanderheiden, TRACE Center at U. Wisconsin
A. Rudy Vener, AT&T Bell Labs
Bryant W. York, Northeastern University
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07719;
5 May 94 10:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09942;
5 May 94 10:41 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07678;
5 May 94 10:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07085;
5 May 94 10:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-smtp at dimacs.rutgers.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-vaudreuil-smtp-binary-03.txt
Date: Thu, 05 May 94 10:21:02 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405051021.aa07085 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : SMTP Service Extensions for Transmission of Large and
Binary MIME Messages
Author(s) : G. Vaudreuil
Filename : draft-vaudreuil-smtp-binary-03.txt
Pages : 6
Date : 05/04/1994
This memo defines two extensions to the SMTP service. The first service
enables a SMTP client and server to negotiate the use of an alternate DATA
command "BDAT" for efficiently sending large MIME messages. The second
extension takes advantage of the BDAT command to permit the negotiated
sending of unencoded binary data.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-vaudreuil-smtp-binary-03.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-vaudreuil-smtp-binary-03.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940504171136.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-vaudreuil-smtp-binary-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-vaudreuil-smtp-binary-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940504171136.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08183;
5 May 94 10:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10382;
5 May 94 10:49 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08108;
5 May 94 10:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07934;
5 May 94 10:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospf at gated.cornell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ospf-demand-00.txt
Date: Thu, 05 May 94 10:46:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405051046.aa07934 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Open Shortest Path First IGP
Working Group of the IETF.
Title : Extending OSPF to support demand circuits
Author(s) : J. Moy
Filename : draft-ietf-ospf-demand-00.txt
Pages : 24
Date : 05/04/1994
This memo defines enhancements to the OSPF protocol that allow efficient
operation over "demand circuits". Demand circuits are those whose costs
vary with usage; charges can be based both on connect time and on
bytes/packets transmitted. Examples of such circuits include ISDN circuits,
X.25 SVCs, and dial-up lines. The periodic nature of OSPF routing traffic
requires such circuits to be open constantly, resulting in unwanted usage
charges. With the modifications described herein, OSPF Hellos and the
refresh of OSPF routing information are suppressed, allowing demand
circuits to be closed when not carrying application traffic.
Demand circuits and regular network segments (e.g., leased lines) are
allowed to be combined in any manner. In other words, there are
no topological restrictions on the demand circuit support.
However, while any OSPF network segment can be defined as a demand circuit,
only point-to-point networks receive the full benefit. When broadcast and
NBMA networks are declared demand circuits, routing update traffic
is reduced but the periodic sending of Hellos is not, which in effect
still requires that the data-link circuits be constantly open.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ospf-demand-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ospf-demand-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940504165338.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-ospf-demand-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-demand-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940504165338.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08228;
5 May 94 10:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10435;
5 May 94 10:51 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08216;
5 May 94 10:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08046;
5 May 94 10:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: i2i at sophia.inria.fr
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-iab-mou2jtc1-01.txt
Date: Thu, 05 May 94 10:48:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405051048.aa08046 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Architecture Board.
Title : Draft Memorandum of Understanding Between the Internet
Society and ISO/IEC JTC-1/SC6
Author(s) : C. Huitema
Filename : draft-iab-mou2jtc1-01.txt
Pages : 4
Date : 05/04/1994
The IAB has been working toward establishing a liaison relationship between
the Internet Society and ISO/JTC-1. A liaison with ISO/IEC JTC1/SC6 has
been offered, and there have been indications that liaisons with any of the
other SCs will be granted without problems as needed.
Further progress is subject to the preparation and approval of
a "memorandum of understanding" (MOU) between the two organizations.
The present document is a prototype of an MOU. It stresses the main points
of agreement: mutual recognition of standards, information on work programs,
information sharing and possible collaborative efforts.
In line with JTC1 decisions, this draft MOU covers liaison with SC6.
The Internet Society looks forward to establishing similar liaisons with
other appropriate JTC1 subcommittees in the near future and expects to use
the same MOU for all such liaisons.
This version is a draft. It will have to be reviewed by the members of the
Internet community and discussed with ISO/IEC JTC1.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-iab-mou2jtc1-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-iab-mou2jtc1-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940504115245.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-iab-mou2jtc1-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-iab-mou2jtc1-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940504115245.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10421;
5 May 94 12:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02429;
5 May 94 12:05 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10405;
5 May 94 12:05 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09778;
5 May 94 11:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mobile-ip at ossi.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mobileip-protocol-02.txt
Date: Thu, 05 May 94 11:41:09 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405051141.aa09778 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Routing for
Wireless/Mobile Hosts Working Group of the IETF.
Title : IP Mobility Support
Author(s) : W. Simpson
Filename : draft-ietf-mobileip-protocol-02.txt
Pages : 38
Date : 05/04/1994
This document specifies protocol enhancements that allow transparent
routing of IP datagrams to Mobile Nodes in the Internet. The Mobile Node
is always identified by its Home-Address, regardless of its current point
of attachment to the Internet. While situated away from its home, a Mobile
Node is also associated with a Care-Of-Address, which provides information
about its current point of attachment to the Internet. The protocol
provides for registering the Care-Of-Address with the Home Agent. The Home
Agent tunnels traffic destined for the Mobile Node to the Care-Of-Address.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mobileip-protocol-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mobileip-protocol-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940504102920.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-mobileip-protocol-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mobileip-protocol-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940504102920.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12231;
5 May 94 13:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12227;
5 May 94 13:13 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa23307;
5 May 94 13:13 EDT
Received: by interlock.ans.net id AA08918
(InterLock SMTP Gateway 1.1 for iwg-out at ans.net);
Thu, 5 May 1994 12:51:45 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Thu, 5 May 1994 12:51:45 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Thu, 5 May 1994 12:51:45 -0400
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: bgp at ans.net
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-bgp4-10.txt
Date: Thu, 05 May 94 11:13:55 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9405051113.aa09153 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : A Border Gateway Protocol 4 (BGP-4)
Author(s) : Y. Rekhter, T. Li
Filename : draft-ietf-bgp-bgp4-10.txt
Pages : 58
Date : 05/04/1994
This document, together with its companion document, "Application of the
Border Gateway Protocol in the Internet", define an inter-autonomous system
routing protocol for the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4-10.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-bgp-bgp4-10.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940504100128.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-bgp-bgp4-10.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4-10.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940504100128.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14719;
5 May 94 14:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14710;
5 May 94 14:36 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa06757; 5 May 94 14:36 EDT
Received: by bitsy.MIT.EDU
id AA13659; Thu, 5 May 94 14:20:16 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA13651; Thu, 5 May 94 14:20:14 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA19829; Thu, 5 May 94 14:20:11 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA24069 at pad-thai.aktis.com>; Thu, 5 May 1994 14:20:24 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA01889; Thu, 5 May 94 14:20:18 EDT
Message-Id: <9405051820.AA01889 at winkl.aktis.com>
To: dpg at ocsg.com
Cc: cat-ietf at mit.edu, gssapi at ocsg.com, linn at cam.ov.com
Subject: Re: Questions regarding GGS/Kerberos names
In-Reply-To: Your message of "Wed, 27 Apr 1994 16:58:27 PDT."
<9404272358.AA04417 at war04.ocsg.com>
Date: Thu, 05 May 1994 14:20:18 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Dennis Glatting writes:
>I have some questions regarding the specifications contained in
>Section 2 (Name Types and Object Identifiers) of the March, 1994
>Kerberos Version 5 GSS-API Mechanism draft RFC.
>
>* Section 2.2 describes the GSS name form in terms of a Kerberos
>principal. Section 2.2 seems to provide utility for a developer
>working at both the GSS and Kerberos API layers. Such cases should
>be infrequent and raise questions regarding circumvention of GSS or
>mechanism integrity.
The world would be a better place if there was one form of name which
was acceptable everywhere, supported within all end systems, and
authenticable by all security technologies. If such a universal form
existed, the very idea of a "native" form for a particular mechanism
(for Kerberos, the principal) would be moot. Unfortunately, this
isn't a question to which there's a unanimously-agreed answer. The
"best effort" currently available is, I believe, for mechanisms to
support a range of name types (thereby making it more likely that the
set of types supported by different mechanisms will overlap) and to
enable multi-type conversion and comparison features per
gss_import_name(), gss_display_name(), and gss_compare_name() within
individual implementations.
>To pass a Kerberos principal to gss_import_name() it must be
>encapsulated in a gss_buffer. This raises the question: what is the
>gss_buffer's length? Further, it implies the gss_buffer cannot be
>deleted using gss_release_buffer().
The gss_buffer's length is variable; what statement carries the
implication that gss_release_buffer() can't be used?
>* Section 2.3 describes the GSS name form: service at hostname.
>
>How is Kerberos realm information included in the form described in
>Section 2.3?
Point taken. Needs to be specified.
>* Section 2.4 appears to be no different than Section 2.1.
>
>Are sections 2.4 and 2.1 different and if they are different that
>what are the differences?
The intent was that 2.4 would refer to a simple name (e.g.,
corresponding to a user's name, without realm or instance) as might
exist locally on a host. 2.1 is more general, but there may be room
to clear up overlap here.
>* Sections 2.5 and 2.6 describe a GSS name in terms of a UID (user
>ID). Those specifications seem tailored to a UNIX environment. My
>questions regarding the forms described in Sections 2.5 and 2.6 are:
>
> * If the environment is DOS, NT, or a Mac then what is a UID?
No position; can you offer a recommendation for how (or whether) a
UID should be interpreted for each of these platforms?
> * How is Kerberos realm information included in the UID forms?
Not explicitly (at least till we start to have OSs within which a
realm specifier is part of a user's local identifier); I'd say this is
implicitly the local realm.
> * What utility do Sections 2.5 and 2.6 provide that section 2.4
> does not provide?
Accomodating alternate local representation of identity as a number or
string of digits rather than as a name.
>Kerberos has several principal types but only three are commonly
>useful to an application developer: KRB5_NT_PRINCIPAL,
>KRB5_NT_SRV_HST, and KRB5_NT_UNKNOWN. Section 2.1 addresses the
>Kerberos principal type KRB5_NT_PRINCIPAL. Section 2.3 addresses the
>Kerberos principal type KRB5_NT_SRV_HST. I see no section that
>addresses the Kerberos principal type KRB5_NT_UNKNOWN. (The most
>common use of KRB5_NT_UNKNOWN is as a parameter to
>krb5_sname_to_principal() indicating the host name is not to be
>canonicalized.)
>
>Since GSS/Kerberos names can be commonly expressed in three Kerberos
>principal forms (KRB5_NT_PRINCIPAL, KRB5_NT_SRV_HST, and
>KRB5_NT_UNKNOWN) then why not specify only those three forms? The
>remaining forms such as UID translation can be provided in OS
>specific libraries.
If there's a need to add a type corresponding to KRB5_NT_UNKNOWN,
this can be done. Note, per intro to sec. 2, that no requirement
is imposed for all implementations to support all listed name types,
and expectation that list will extend over time. Local forms (which
I expect are likely to receive wide use by application integrators) could
be handled via separate, OS-specific libraries; is there strong
sentiment that they should not be documented as alternate name types?
Given the fact that the conversion procedures those libraries would perform
can be (and are, in these cases) specific to Kerberos, it seems
natural to me for GSS-API routines to be able to accept and output
these forms directly.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28654;
5 May 94 23:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28645;
5 May 94 23:07 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa17693; 5 May 94 23:07 EDT
Received: by bitsy.MIT.EDU
id AA20171; Thu, 5 May 94 22:50:09 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA20153; Thu, 5 May 94 22:50:06 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA23208; Thu, 5 May 94 22:49:50 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id TAA21896; Thu, 5 May 1994 19:46:57 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA02173; Thu, 5 May 94 19:41:10 -0700
Date: Thu, 5 May 94 19:41:10 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405060241.AA02173 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Wray at tuxedo.enet.dec.com
Subject: A comment regarding RFC-1509
Cc: cat-ietf at mit.edu, gssapi at ocsg.com
Reply-To: dpg at ocsg.com
John:
I do not know if there is an official address to send this message so
I thought I'd start with with you and the CAT list.
I would like to propose an amendment to one of the macros defined in
RFC-1509 or if not an amendment, to raise awareness. The purpose is
to improve code efficiency.
I compiled the following code fragment on a NEXTSTATION (68040) using
GNU C 2.5.8 specifying -O as the optimization level.
#include <gssapi.h>
extern OM_uint32 eVal;
OM_uint32 aVerb;
aVerb = eVal;
if( GSS_ERROR( aVerb ))
printf("");
RFC-1509's definition of GSS_ERROR() is:
#define GSS_ERROR(x) \
((GSS_CALLING_ERROR(x) != 0) || (GSS_ROUTINE_ERROR(x) != 0))
Personally, I like the RFC's definition of GSS_ERROR(). It builds on
other error definitions -- good programming practice. However,
examination of the generated assembly code warrants consideration of
another definition of GSS_ERROR().
The compiler generated the following assembly code using RFC-1509's
definition of GSS_ERROR() and the previous code fragment.
movel _eVal,d1
movel d1,d0
andl #-16777216,d0
jne L3
movel d1,d0
andl #16711680,d0
jeq L2
L3:
pea LC0
jbsr _printf
addqw #4,sp
L2:
However, if I change the definition of GSS_ERROR() to
#define GSS_ERROR(x) \
((x & ((GSS_C_CALLING_ERROR_MASK <<
GSS_C_CALLING_ERROR_OFFSET) | \
(GSS_C_ROUTINE_ERROR_MASK <<
GSS_C_ROUTINE_ERROR_OFFSET))) != 0)
the compiler generates the following assembly code:
movel _eVal,d0
clrw d0
tstl d0
jeq L4
pea LC0
jbsr _printf
L4:
Using the new definition of GSS_ERROR() yields zippier and more
compact code. I assume other compilers would yield similar results.
A second benefit of the new GSS_ERROR() definition is it eliminates a
programming hazard. The following code fragment is a common
programming style but using the RFC's definition of GSS_ERROR() may
result in gss_inquire_cred() called more than once.
if( GSS_ERROR( gss_inquire_cred(...))) {
...
}
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29155;
6 May 94 11:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29145;
6 May 94 11:07 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa05666; 6 May 94 11:06 EDT
Received: by bitsy.MIT.EDU
id AA29019; Fri, 6 May 94 10:51:40 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA29011; Fri, 6 May 94 10:51:38 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA18557; Fri, 6 May 94 10:51:34 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA17732; Fri, 6 May 94 07:40:16 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA17757; Fri, 6 May 94 10:39:50 -0400
Message-Id: <9405061439.AA17757 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 6 May 94 10:39:51 EDT
Date: Fri, 6 May 94 10:39:51 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 06-May-1994 1022" <wray at tuxedo.enet.dec.com>
To: dpg at ocsg.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, dpg at ocsg.com
Subject: RE: A comment regarding RFC-1509
>I would like to propose an amendment to one of the macros defined in
>RFC-1509 or if not an amendment, to raise awareness. The purpose is
>to improve code efficiency.
>
>I compiled the following code fragment on a NEXTSTATION (68040) using
>GNU C 2.5.8 specifying -O as the optimization level.
>#include <gssapi.h>
> extern OM_uint32 eVal;
> OM_uint32 aVerb;
> aVerb = eVal;
> if( GSS_ERROR( aVerb ))
>
> printf("");
>
>RFC-1509's definition of GSS_ERROR() is:
>#define GSS_ERROR(x) \
> ((GSS_CALLING_ERROR(x) != 0) || (GSS_ROUTINE_ERROR(x) != 0))
>Personally, I like the RFC's definition of GSS_ERROR(). It builds on
>other error definitions -- good programming practice. However,
>examination of the generated assembly code warrants consideration of
>another definition of GSS_ERROR().
>
>The compiler generated the following assembly code using RFC-1509's
>definition of GSS_ERROR() and the previous code fragment.
> movel _eVal,d1
> movel d1,d0
> andl #-16777216,d0
> jne L3
> movel d1,d0
> andl #16711680,d0
> jeq L2
>L3:
> pea LC0
> jbsr _printf
> addqw #4,sp
>L2:
>
>However, if I change the definition of GSS_ERROR() to
>#define GSS_ERROR(x) \
> ((x & ((GSS_C_CALLING_ERROR_MASK <<
>GSS_C_CALLING_ERROR_OFFSET) | \
> (GSS_C_ROUTINE_ERROR_MASK <<
>GSS_C_ROUTINE_ERROR_OFFSET))) != 0)
>the compiler generates the following assembly code:
> movel _eVal,d0
> clrw d0
> tstl d0
> jeq L4
> pea LC0
> jbsr _printf
>L4:
>Using the new definition of GSS_ERROR() yields zippier and more
>compact code. I assume other compilers would yield similar results.
I don't think that the macro definition should be changed in the spec simply to
cause a particular compiler to generate more efficient code. A GSSAPI
implementation should be able to replace any part of the specified gssapi.h
with equivalent but more efficient code, providing the changes aren't visible
to applications.
>A second benefit of the new GSS_ERROR() definition is it eliminates a
>programming hazard. The following code fragment is a common
>programming style but using the RFC's definition of GSS_ERROR() may
>result in gss_inquire_cred() called more than once.
> if( GSS_ERROR( gss_inquire_cred(...))) {
> ...
> }
>
This, however, is a compelling reason for the change. Your version of the
macro allows a much more natural coding style. I think it highly unlikely that
any existing applications would have exploited the possible double-evaluation
of 'x' in the current version, so a change to your macro definition shouldn't
break any current code. I think this improvement ought to be incorporated into
the next revision of the bindings document.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05701;
6 May 94 14:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05697;
6 May 94 14:55 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11015;
6 May 94 14:55 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15144; Fri, 6 May 94 14:18:52 EDT
Received: from ietf.cnri.reston.va.us by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA15140; Fri, 6 May 94 14:18:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04662;
6 May 94 14:13 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce. at CNRI.Reston.VA.US, %cnri.reston.va.us at dimacs.rutgers.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Cc: ietf-822 at dimacs.rutgers.edu
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-umig-mime-voice-00.txt
Date: Fri, 06 May 94 14:13:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9405061413.aa04662 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME/ESMTP Profile for Voice Messaging
Author(s) : G. Vaudreuil
Filename : draft-umig-mime-voice-00.txt
Pages : 16
Date : 05/05/1994
A class of special purpose computers have 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 interconnect these machines.
The following document is a profile of the Internet standard MIME and EXMTP
protocols for use as a digital voice networking protocol. This profile is
based on an earlier effort in the Audio Message Interchange Specification
(AMIS) group to define a voice messaging protocol based on X.400
technology. This protocol 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 internets. This
profile will be called the voice profile in this document.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-umig-mime-voice-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-umig-mime-voice-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940505112318.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-umig-mime-voice-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-umig-mime-voice-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940505112318.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06220;
6 May 94 15:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06212;
6 May 94 15:16 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa11464; 6 May 94 15:16 EDT
Received: by bitsy.MIT.EDU
id AA02381; Fri, 6 May 94 15:00:58 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA02373; Fri, 6 May 94 15:00:57 EDT
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA10309; Fri, 6 May 94 15:00:45 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA03025; Fri, 6 May 94 14:59:20 EDT
Date: Fri, 6 May 94 14:59:20 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9405061859.AA03025 at tsx-11.MIT.EDU>
To: John Linn <linn at cam.ov.com>
Cc: dpg at ocsg.com, cat-ietf at mit.edu, gssapi at ocsg.com, linn at cam.ov.com
In-Reply-To: John Linn's message of Thu, 05 May 1994 14:20:18 -0400,
<9405051820.AA01889 at winkl.aktis.com>
Subject: Re: Questions regarding GGS/Kerberos names
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Thu, 05 May 1994 14:20:18 -0400
From: John Linn <linn at cam.ov.com>
>Kerberos has several principal types but only three are commonly
>useful to an application developer: KRB5_NT_PRINCIPAL,
>KRB5_NT_SRV_HST, and KRB5_NT_UNKNOWN. Section 2.1 addresses the
>Kerberos principal type KRB5_NT_PRINCIPAL. Section 2.3 addresses the
>Kerberos principal type KRB5_NT_SRV_HST. I see no section that
>addresses the Kerberos principal type KRB5_NT_UNKNOWN. (The most
>common use of KRB5_NT_UNKNOWN is as a parameter to
>krb5_sname_to_principal() indicating the host name is not to be
>canonicalized.)
>
>Since GSS/Kerberos names can be commonly expressed in three Kerberos
>principal forms (KRB5_NT_PRINCIPAL, KRB5_NT_SRV_HST, and
>KRB5_NT_UNKNOWN) then why not specify only those three forms? The
>remaining forms such as UID translation can be provided in OS
>specific libraries.
If there's a need to add a type corresponding to KRB5_NT_UNKNOWN,
this can be done. Note, per intro to sec. 2, that no requirement
is imposed for all implementations to support all listed name types,
and expectation that list will extend over time.
Note that Kerberos "name types" is meant to be use purely as a hint, so
that the application program has some idea how to interpret the name.
It is not part of the name in that two principals which are otherwise
identical except one is of type KRB5_NT_PRINCIPAL and one of type
KRB5_NT_SRV_HST are still considered the same name. So they are not
different name types in the GSSAPI sense; principal names with different
KRB5_NT's are imported, exported, and displayed in the same way.
I see no need to extend a new type for KRB5_NT_UNKNOWN. It's main use
in krb5_sname_to_principal is to be able to create krb5 service names
such as zephyr/zephyr at ATHENA.MIT.EDU. I'm not really convinced that
this is really necessary for most GSSAPI applications, though.
- Ted
P.S. The main use for Krb5 NT's was when we were worried that DCE was
putting UUID's in Kerberos V5 names, so we wanted to give an application
programs some idea of how to parse what was in a krb5 principal. It
turns out that DCE wasn't doing this at all, and this was merely the
result of bad communication between MIT and HP.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22578;
8 May 94 1:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22570;
8 May 94 1:01 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa17345; 8 May 94 1:01 EDT
Received: by bitsy.MIT.EDU
id AA26548; Sun, 8 May 94 00:48:19 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA26540; Sun, 8 May 94 00:48:09 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA07423; Sun, 8 May 94 00:47:49 EDT
Received: (glenz at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) id VAA05694; Sat, 7 May 1994 21:46:20 -0700
Date: Sat, 7 May 1994 21:46:20 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Glen Zorn <glenz at ocsg.com>
Message-Id: <199405080446.VAA05694 at kerby.ocsg.com>
To: linn at cam.ov.com
Subject: Re: Questions regarding GGS/Kerberos names
Cc: cat-ietf at mit.edu, gssapi at ocsg.com
John Linn writes:
> Dennis Glatting writes:
>
> >I have some questions regarding the specifications contained in
> >Section 2 (Name Types and Object Identifiers) of the March, 1994
> >Kerberos Version 5 GSS-API Mechanism draft RFC.
> >
> >* Section 2.2 describes the GSS name form in terms of a Kerberos
> >principal. Section 2.2 seems to provide utility for a developer
> >working at both the GSS and Kerberos API layers. Such cases should
> >be infrequent and raise questions regarding circumvention of GSS or
> >mechanism integrity.
>
> The world would be a better place if there was one form of name which
> was acceptable everywhere, supported within all end systems, and
> authenticable by all security technologies. If such a universal form
> existed, the very idea of a "native" form for a particular mechanism
> (for Kerberos, the principal) would be moot. Unfortunately, this
> isn't a question to which there's a unanimously-agreed answer. The
> "best effort" currently available is, I believe, for mechanisms to
> support a range of name types (thereby making it more likely that the
> set of types supported by different mechanisms will overlap) and to
> enable multi-type conversion and comparison features per
> gss_import_name(), gss_display_name(), and gss_compare_name() within
> individual implementations.
>
> >To pass a Kerberos principal to gss_import_name() it must be
> >encapsulated in a gss_buffer. This raises the question: what is the
> >gss_buffer's length? Further, it implies the gss_buffer cannot be
> >deleted using gss_release_buffer().
>
> The gss_buffer's length is variable; what statement carries the
> implication that gss_release_buffer() can't be used?
RFC 1509 says:
3.18. gss_release_buffer
[...]
Purpose:
Free storage associated with a buffer format name. The storage must
^^^^^^^^^^^^^^^^
have been allocated by a GSSAPI routine [...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
But the Kerberos Version 5 GSS-API Mechanism draft says:
2.2. krb5_principal Form
[...]
The recommended symbolic name for this type is
"gss_krb5_nt_principal". The gss_buffer_desc contains a
krb5_principal value.
It seems unlikely that a krb5_principal structure would be allocated by a GSSAPI
routine. Indeed, RFC 1509 describes the contents of the input_name_buffer
parameter to gss_import_name() as "buffer, character-string, read" and says thatthe purpose of the routine is to "Convert a printable name to internal form."
A krb5_principal is certainly printable (given the right software ;-)), but to
call it a character string seems to be stretching things a bit.
>
> --jl
>
>
~ gwz
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15828;
9 May 94 9:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15820;
9 May 94 9:46 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa13872; 9 May 94 9:46 EDT
Received: by bitsy.MIT.EDU
id AA20270; Mon, 9 May 94 09:32:57 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA20262; Mon, 9 May 94 09:32:55 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA20551; Mon, 9 May 94 09:32:49 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA02242; Mon, 9 May 94 06:25:02 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA26699; Mon, 9 May 94 09:24:36 -0400
Message-Id: <9405091324.AA26699 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Mon, 9 May 94 09:24:36 EDT
Date: Mon, 9 May 94 09:24:36 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 09-May-1994 0924" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Re: Questions regarding GGS/Kerberos names
Glen,
>> >To pass a Kerberos principal to gss_import_name() it must be
>> >encapsulated in a gss_buffer. This raises the question: what is the
>> >gss_buffer's length? Further, it implies the gss_buffer cannot be
>> >deleted using gss_release_buffer().
>>
>> The gss_buffer's length is variable; what statement carries the
>> implication that gss_release_buffer() can't be used?
>>
>RFC 1509 says:
>
>3.18. gss_release_buffer
>
>[...]
>
> Purpose:
>
> Free storage associated with a buffer format name. The storage must
> ^^^^^^^^^^^^^^^^
> have been allocated by a GSSAPI routine [...]
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>But the Kerberos Version 5 GSS-API Mechanism draft says:
>
>2.2. krb5_principal Form
>
> [...]
>
> The recommended symbolic name for this type is
> "gss_krb5_nt_principal". The gss_buffer_desc contains a
> krb5_principal value.
>
>It seems unlikely that a krb5_principal structure would be allocated by a GSSAPI
>routine. Indeed, RFC 1509 describes the contents of the input_name_buffer
>parameter to gss_import_name() as "buffer, character-string, read" and says thatthe purpose of the routine is to "Convert a printable name to internal form."
>A krb5_principal is certainly printable (given the right software ;-)), but to
>call it a character string seems to be stretching things a bit.
This look like a bug in the mechanism draft. Names input to gss_import_name()
are supposed to be character strings. The draft probably meant to say
something like "The gss_bufer_desc contains a printable name corresponding to a
krb5_principal" - ie the name is a regular printable Kerberos-style principal
name. There probably ought to be an example, too.
The constraint in RFC 1509 about gss_release_buffer only working with
GSSAPI-allocated gss_buffer_desc objects is correct. If you contruct a
gss_buffer_desc object within your application, you are responsible for doing
whatever is necessary to free up the space when you're done, since GSSAPI can't
hope to know in general how to delete it (the storage might be allocated from
the heap, from the stack, from static space, or from an application-private
pool). If the GSSAPI created the object, on the other hand, gss_release_buffer
is provided to delete it.
John
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20735;
9 May 94 13:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20493;
9 May 94 13:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20714;
9 May 94 13:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18463;
9 May 94 11:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rsvp at isi.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-rsvp-spec-02.txt, .ps
Date: Mon, 09 May 94 11:41:13 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405091141.aa18463 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the RSVP - Resource Reservation
Setup Protocol Working Group of the IETF.
Title : Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification
Author(s) : L. Zhang, R. Braden, D. Estrin,
S. Herzog, S. Jamin
Filename : draft-ietf-rsvp-spec-02.txt, .ps
Pages : 48
Date : 05/06/1994
This memo describes version 1 of RSVP, a resource reservation setup
protocol designed for an integrated services Internet. RSVP provides
receiver-initiated setup of resource reservations for multicast or unicast
data flows, with good scaling and robustness properties.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-rsvp-spec-02.txt".
Or
"get draft-ietf-rsvp-spec-02.ps".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rsvp-spec-02.txt".
Or
"FILE /internet-drafts/draft-ietf-rsvp-spec-02.ps".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940506092521.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-rsvp-spec-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rsvp-spec-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940506092521.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21266;
9 May 94 13:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20990;
9 May 94 13:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21253;
9 May 94 13:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa20911;
9 May 94 13:34 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-bgp-mibv4-06.txt
Date: Mon, 09 May 94 13:34:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405091334.aa20911 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : Definitions of Managed Objects for the Fourth Version
of Border Gateway Protocol (BGP-4)
Author(s) : S. Willis, J. Burruss, J. Chu
Filename : draft-ietf-bgp-mibv4-06.txt
Pages : 21
Date : 05/06/1994
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for managing
the Border Gateway Protocol Version 4 or lower.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-mibv4-06.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-bgp-mibv4-06.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940506091404.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-bgp-mibv4-06.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-mibv4-06.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940506091404.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22446;
9 May 94 14:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22285;
9 May 94 14:16 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22427;
9 May 94 14:16 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21411;
9 May 94 13:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-bsd-compress-01.txt
Date: Mon, 09 May 94 13:50:12 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405091350.aa21411 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : PPP BSD Compression Protocol
Author(s) : V. Schryver
Filename : draft-ietf-pppext-bsd-compress-01.txt
Pages : 26
Date : 05/06/1994
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links.
This document describes the use of the Unix Compress compression protocol
for compressing PPP encapsulated packets.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-bsd-compress-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-bsd-compress-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940506134006.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pppext-bsd-compress-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-bsd-compress-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940506134006.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14257;
10 May 94 14:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16967;
10 May 94 14:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14199;
10 May 94 14:58 EDT
Received: from [132.151.1.46] by IETF.CNRI.Reston.VA.US id aa13840;
10 May 94 14:39 EDT
Received: from CNRI.Reston.Va.US (localhost) by excelsior.CNRI.Reston.Va.US (5.0/SMI-SVR4)
id AA19886; Tue, 10 May 1994 14:39:17 +0500
Message-Id: <9405101839.AA19886 at excelsior.CNRI.Reston.Va.US>
To: IETF-Announce: ;, LOCAL at excelsior.cnri.reston.va.us
MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: AREA ACTION: Service Applications Area to Close
Date: Tue, 10 May 1994 14:39:16 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
content-length: 578
The Service Applications Area of the IETF has closed down.
The six working groups still active in the SAP Area will be
moved into other areas as follows:
DNS Security (dnssec) Security
MHS-DS (mhsds) Applications
Minimal OSI Upper-Layers (thinosi) Transport Services
ONC Remote Procedure Call (oncrpc) Transport Services
Service Location (svrloc) Internet
Trusted NFS (tnfs) Security
The contact is the Internet Engineering Steering Group
<iesg at cnri.reston.va.us>.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14545;
10 May 94 15:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17774;
10 May 94 15:10 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14531;
10 May 94 15:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14453;
10 May 94 15:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tuba at lanl.gov
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-tuba-mtu-00.txt
Date: Tue, 10 May 94 15:07:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405101507.aa14453 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the TCP/UDP Over CLNP-Addressed
Networks Working Group of the IETF.
Title : CLNP Path MTU Discovery
Author(s) : D. Piscitello
Filename : draft-ietf-tuba-mtu-00.txt
Pages : 18
Date : 05/09/1994
This memo describes a technique for dynamically discovering the maximum
transmission unit (MTU) of an arbitrary CLNP path. The mechanism described
here is applicable to both "pure-stack" OSI as well as TUBA/CLNP [6]
environments, i.e., environments where Internet transport protocols (UDP
and TCP) are operated over CLNP. The memo specifies a small change to the
way routers generate one type of CLNP Error Report. For a path that passes
through a router that has not been changed, this technique might not
discover the correct Path MTU, but it will always choose a Path MTU as
accurate as, and in many cases more accurate than, the Path MTU that would
be chosen by current practice.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tuba-mtu-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tuba-mtu-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940509143636.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-tuba-mtu-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tuba-mtu-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940509143636.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22235;
10 May 94 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22227;
10 May 94 16:55 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa21114;
10 May 94 16:55 EDT
Received: by bitsy
id AA00606; Tue, 10 May 94 16:35:05 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy with SMTP
id AA00598; Tue, 10 May 94 16:35:02 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA12552; Tue, 10 May 94 16:34:50 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id NAA18483; Tue, 10 May 1994 13:34:00 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA16759; Tue, 10 May 94 13:30:14 -0700
Date: Tue, 10 May 94 13:30:14 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405102030.AA16759 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: John Linn <linn at cam.ov.com>
Subject: Re: Questions regarding GGS/Kerberos names
Cc: cat-ietf at mit.edu, gssapi at ocsg.com
Reply-To: dpg at ocsg.com
> Dennis Glatting writes:
>
> >I have some questions regarding the specifications contained in
> >Section 2 (Name Types and Object Identifiers) of the March, 1994
> >Kerberos Version 5 GSS-API Mechanism draft RFC.
> >
> >* Section 2.2 describes the GSS name form in terms of a Kerberos
> >principal. Section 2.2 seems to provide utility for a developer
> >working at both the GSS and Kerberos API layers. Such cases
> >should be infrequent and raise questions regarding circumvention
> >of GSS or mechanism integrity.
>
> The world would be a better place if there was one form of
> name which was acceptable everywhere, supported within
> all end systems, and authenticable by all security
> technologies. If such a universal form existed, the very
> idea of a "native" form for a particular mechanism (for
> Kerberos, the principal) would be moot. Unfortunately,
> this isn't a question to which there's a
> unanimously-agreed answer. The "best effort"
> currently available is, I believe, for mechanisms to
> support a range of name types (thereby making it more
> likely that the set of types supported by different
> mechanisms will overlap) and to enable multi-type
> conversion and comparison features per
> gss_import_name(), gss_display_name(), and
> gss_compare_name() within individual
> implementations.
>
My concern is two fold. First, to support native name forms may
encourage application programmers to seek service in mechanism's
libraries possibly circumventing security. My second concern is the
utility of native name forms.
I cannot think of an application where importing a native Kerberos
name into GSS is useful. Originally I thought the client side of FTP
would be an excellent example because FTP requires the user's default
credential. However, GSS supports default credentials and the
credential's name can be obtained uding gss_inquire_cred().
Suppose for a moment native name forms are stricken from the GSS
specification. What is left? I believe, native name forms
presented as strings.
> >To pass a Kerberos principal to gss_import_name() it must be
> >encapsulated in a gss_buffer. This raises the question: what is
> >the gss_buffer's length? Further, it implies the gss_buffer
> >cannot be deleted using gss_release_buffer().
>
> The gss_buffer's length is variable; what statement
> carries the implication that gss_release_buffer()
> can't be used?
>
A Kerberos principal is a complex data structure released using
krb5_free_principal(). Strings are released using free(). How is
that information passed to gss_release_buffer()?
A buffer's content can be tracked in small applications. However, as
the size and complexity of applications increase tracking buffer
contents is an undo burden.
I made the assumption there is reason data encapsulated in GSS
buffers and passed to gss_import_name() would be kept around.
> >* Sections 2.5 and 2.6 describe a GSS name in terms of a UID (user
> >ID). Those specifications seem tailored to a UNIX environment.
> >My questions regarding the forms described in Sections 2.5 and 2.6
> >are:
> >
> > * If the environment is DOS, NT, or a Mac then what is a UID?
>
> No position; can you offer a recommendation for how (or
> whether) a UID should be interpreted for each of these
> platforms?
>
I can't speak for NT but DOS and Mac do not have UIDs. Network
technologies for DOS and Mac platforms do have UID concepts but are
as varied as vendors implementations.
I believe the potential for GSS on DOS and Mac platforms is greater
than UNIX. Consequently, I think the UID name types removed from the
draft RFC. Translation of a UID to something suitable for GSS import
should be a local matter.
> >Kerberos has several principal types but only three are commonly
> >useful to an application developer: KRB5_NT_PRINCIPAL,
> >KRB5_NT_SRV_HST, and KRB5_NT_UNKNOWN. Section 2.1 addresses the
> >Kerberos principal type KRB5_NT_PRINCIPAL. Section 2.3 addresses
> >the Kerberos principal type KRB5_NT_SRV_HST. I see no section
> >that addresses the Kerberos principal type KRB5_NT_UNKNOWN. (The
> >most common use of KRB5_NT_UNKNOWN is as a parameter to
> >krb5_sname_to_principal() indicating the host name is not to be
> >canonicalized.)
> >
> >Since GSS/Kerberos names can be commonly expressed in three
> >Kerberos principal forms (KRB5_NT_PRINCIPAL, KRB5_NT_SRV_HST, and
> >KRB5_NT_UNKNOWN) then why not specify only those three forms? The
> >remaining forms such as UID translation can be provided in OS
> >specific libraries.
>
> If there's a need to add a type corresponding to
> KRB5_NT_UNKNOWN, this can be done. Note, per intro to
> sec. 2, that no requirement is imposed for all
> implementations to support all listed name types, and
> expectation that list will extend over time. Local forms
> (which I expect are likely to receive wide use by
> application integrators) could be handled via
> separate, OS-specific libraries; is there strong
> sentiment that they should not be documented as
> alternate name types? Given the fact that the conversion
> procedures those libraries would perform can be (and
> are, in these cases) specific to Kerberos, it seems
> natural to me for GSS-API routines to be able to accept and
> output these forms directly.
>
The motivation to support KRB5_NT_UNKNOWN is a principal's instance
isn't canonicalized. For example, fw.ocsg.com (fire wall) is a DNS
CNAME for kerby.ocsg.com. If DNS is your network name resolution
authority then calling gethostbyname() passing fw.ocsg.com as an
argument returns kerby.ocsg.com. This may not be the desired effect.
Using host aliases is a very good method of managing services in
large distributed networks. If services are forced to use canonical
names then the benefits are less realized. I believe KRB5_NT_UNKNOWN
should be a supported name type.
I agree alternate name types should be documented however many of
those types may be site or OS specific. Those types should be
documented in a "recommended" appendix. Otherwise, a GSS
implementation on DOS can't ever be RFC compliant -- DOS doesn't
support UIDs.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22430;
10 May 94 17:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22418;
10 May 94 17:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21287;
10 May 94 17:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22404;
10 May 94 17:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22355;
10 May 94 17:03 EDT
Received: from uga.cc.uga.edu by CNRI.Reston.VA.US id aa21216;
10 May 94 17:03 EDT
Received: from UWF.CC.UWF.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
with BSMTP id 5298; Tue, 10 May 94 17:04:13 EDT
Received: from UWF (NJE origin STANKULI at UWF) by UWF.CC.UWF.EDU (LMail
V1.1d/1.7f) with BSMTP id 3110; Tue, 10 May 1994 15:21:19 -0500
Date: Tue, 10 May 94 15:20:22 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stan kulikowski ii <STANKULI%UWF.BITNET at uga.cc.uga.edu>
Subject: history ? : terminal characteristics
To: ietf at CNRI.Reston.VA.US
Message-ID: <9405101703.aa21216 at CNRI.Reston.VA.US>
A Historical Descendency of Major Terminal I/O Characteristics
teletype
before CRT
....................scrolling text
TTY
/ .................cursor movement
/ VT100 screen regions
/ \ \
TN3270 / \ \ ............color
/ \ \ bitmap graphic mode
TEKTONICS ANSI DOS VT220
GUI .................object-based event cycles
/ \ \
/ MAC WINDOWS ........standard sound resources
X-WINDOWS
/\
MOTIF OPENLOOK
i have just finished teaching the first trial of an introductory course
for programmers on the human-computer interface. during this pedagogical
experience, i more-or-less coined the above path of technical evolution
to explain how the major terminal characteristics came about. if this is
familiar territory to any of you, i would appreciate comments or any
references. is there a published source of something like this?
have i left out any major computer CRT interface that ought to be
mentioned in this line of development? i know there are various
euroteletexts, NAPLPS, and prodigy-style mixes of text and graphics, but
somehow i feel those belong in another developmental line of
interfacing... so do the laser print markups (r, TeX, LaTeX, PostScript,
EPS, SGML, TEI). and i wonder if these separate lines of development
might have some parallelisms to explain or coordinate them. certainly the
mac gui interface (from xerox alto) was linked to the success of
PostScript since it was laserprint desktop publishing which made that
machine on the market.
please share this internet request for information with other discussion
groups that might have a perspective on technical matters pertaining to
computer interfacing. i would be happy for reply from anyone,
stan
. stankuli at UWF.bitnet
=== the love the laughing lady gives you
is not the kind you can keep
--- -- neal young
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04758;
11 May 94 10:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04754;
11 May 94 10:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09256;
11 May 94 10:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04743;
11 May 94 10:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04739;
11 May 94 10:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09251;
11 May 94 10:19 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04734;
11 May 94 10:19 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ids at merit.edu
Cc: The Internet Engineering Steering Group <IESG at CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: A Revised Catalog of Available X.500
Implementations to Informational
Date: Wed, 11 May 94 10:19:27 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405111019.aa04734 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "A Revised Catalog of Available
X.500 Implementations" <draft-ietf-ids-catalog-02.txt> and recommends
that it be published by the RFC Editor as an Informational RFC. This
document is the product of the Integrated Directory Services Working
Group. The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06957;
11 May 94 11:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06941;
11 May 94 11:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11699;
11 May 94 11:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06924;
11 May 94 11:54 EDT
Received: from ninet.research.att.com by IETF.CNRI.Reston.VA.US id aa06818;
11 May 94 11:51 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: smb at research.att.com
Received: by gryphon; Wed May 11 11:45:35 EDT 1994
To: ietf at IETF.CNRI.Reston.VA.US
Subject: trademarks and the DNS
Date: Wed, 11 May 94 11:45:34 EDT
Message-ID: <9405111151.aa06818 at IETF.CNRI.Reston.VA.US>
The question has come up of what relationship trademarks have to DNS
names. A court may be about to look at the question. Enclosed below
is an article from misc.legal.moderated, reposted with permission.
--Steve Bellovin
In article <2qpjdf$eeu at panix.com>, adam at mtv.com (Adam Curry) writes:
> MTV Sues Curry
> **************
>
>
>
> Last update: May 10 1994
>
> New Jersey, May 10 1994
>
> I had planned to keep the following quiet until more information was available, but since several
> journalists have already caught wind of it, I decided to get it out into the open so my side of the
> story is heard as well.
>
> The domain I maintain and operate on the Internet, mtv.com was founded approximately one year
> ago. At that time I registered mtv.com with the InterNIC, purely because it was a cool address to
> have, and it was available. What a great "vanity plate"!
>
> The site quickly became a frequently accessed "hangout" on the net, with an average of 35000
> accesses daily from Mosaic clients alone. During the start up months I had many conversations
> with executives at MTV Networks about my endeavours, which btw, were all financed out of my
> own pocket, and vps from MTV Programming as well as Viacom New Media were aware of what I
> was doing on the internet, and although they stated "MTV has no interest in the internet" they gave
> me their blessing and supported my efforts.
>
> This was enforced when I set up several email accounts on mtv.com for use in MTV's on-air
> programming. Ever sionce the summer of '93, popquiz at mtv.com was used for trivia quiz
> questions, that were then aired on MTV's "Most Wanted" a program I hosted at the time.
> Solicitations were made on the air, and the address was shown on the screen. For MTV's annual
> Valentines video dedications, viewers were offered the choice of calling in their dedications, or
> sending them via email to elove at mtv.com.
>
> I never charged MTV Networks for this service, I purely saw it as a cool feature to introduce to
> MTV's programming, spreading the "gospel", so to speak.
>
> Then I started to get a lot of press about mtv.com, and some people started to wake up at 1515
> Broadway (MTV's HQ in New York City). And I was served with a "Cease and desist" on the use of
> mtv.com. MTV's attourneys claimed that there could be "confusion" for users of the internet, when
> connecting to *anything* that had the letters mtv in the adress, and then receiving music and
> entertainment information. I was obviously hurt by this move, but did see what point they were
> driving at, an asked if we could settle this matter amicably.
>
> The situation cooled down for a couple of months, but when I resigned on-air from my job as a VJ,
> which MTV chose not to air btw, things started to get ugly.
>
> Long story short, MTV Networks has filed a lawsuit against me, for copyright infringement of their
> "trademark", that being their "MTV" call letters, as well as having information onlie that was MTVN
> "property". In this case they are refferring to several press releases I put up on mtv.com, such a an
> announcement about Beavis and Butthead's "experience" cd release. Understand that MTVN sent
> me these releases over their own internal computer network for this very purpose!
> Again, I was only doing this to promote the channel, not for my own personal gain..after
> all...mtv.com is free access for all, no charge.
>
> Throughout all of this I have offered to maintain the site specifically for mtv, but again they said
> "we're not interested". Ofcourse I have no problem whatsoever removing all refrences to MTV
> Networks and it's projects from mtv.com, no that I don't work there anymore gives me even more
> reason to want to do this, but the kicker is they are moving for an injunction to make me stop using
> the internet address mtv.com!
>
> This is ofcourse totally unacceptable, I registered the domain name, and I don't plan on giving it
> up. Sure MTV and their parent company Viacom have a vast legal team, but david also nailed
> goliath, so I have faith. In the long run, everyone knows that the only *true* winners will be the
> lawyers.
>
> There are many different viewpoints on this situation, but I feel that the use of mtv in an addressing
> scheme can't be seen as an infringement of intellectulal propert laws, and a search of the InterNIC
> database shows at least 15 domain names registered with mtv in the address. Irony is that I
> incorporated a company called ON RAMP, Inc (tm) and onramp.com was already registered to
> someone else, but I'm not suing them :)
>
> It appears to me that MTV has their mind set on the address mtv.com, maybe not for now, but
> posibly for future use, and I feel extremely used, in that I built up quite an audience for that
> address, and they are basically saying "thank you very much, you may go".
>
> A pre-motion hearing is scheduled for this thursday morning at 11am, wit the honourable Judge
> McKenna presiding, in an attemp to get an injunction to make me stop using the address
> mtv.com. I will update the situation as it unfolds.
>
> Adam Curry, adam at mtv.com
>
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12058;
11 May 94 15:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19050;
11 May 94 15:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12044;
11 May 94 15:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11984;
11 May 94 15:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18986;
11 May 94 15:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11977;
11 May 94 15:43 EDT
To: IETF-Announce: ;
Subject: Toronto IETF: PRELIMINARY Message
Date: Wed, 11 May 94 15:43:28 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Steve Coya <scoya at CNRI.Reston.VA.US>
Message-ID: <9405111543.aa11977 at IETF.CNRI.Reston.VA.US>
This is a preliminary mailing of the At-A-Glance for the 30th IETF
Meeting to be held in Toronto, Ontario, Canada: July 25-29, 1994. The
first formal logistics announcement (including rsvp form) will be sent
out on May 31st.
Please note that we will NOT BEGIN REGISTERING folks UNTIL May 31st.
ANY rsvp forms RECEIVED PRIOR TO TUESDAY, May 31st WILL, without
exception, BE DELETED.
30th INTERNET ENGINEERING TASK FORCE Mailing Date : 5/11/94
AT-A-GLANCE Mailing Number:
DATES: July 25-29, 1994 HOST(S):
Warren Jackson
University of Toronto
HOTEL/MEETING SITE: Sheraton Centre Toronto
123 Queen Street West
Toronto, Ontario CANADA M5H 2M9
Phone: (800) 325-3535 {fax: (416) 947-4874}
Phone: 1 (416) 361-1000 (international callers)
CI 16:00; CO 12:00
300 Rooms reserved until Friday, July 1, 1994
$130.00 (Canadian)/single; $130.00 (Canadian)/double
(please add 12% tax). Additional taxes may be charged in
accordance with Federal or Provincial direction. Certain
taxes are rebatable to internationl travelers.
Specify: 30th IETF/Engineering
ALTERNATE ACCOM: TBD
NEWCOMER'S Sunday, July 24, 1994
ORIENTATION: 16:30 - 17:30
Room: Essex Ballroom
PRE-REGISTRATION: Sunday, July 24, 1994
18:00 - 20:00 (registration & reception)
Sheraton Centre Toronto
Room: Essex Ballroom
REGISTRATION: Monday, July 25, 1994
08:00 - 18:00
Tuesday, July 26 - Thursday, July 28, 1994
08:30 - 18:00
Friday, July 29, 1994
08:30 - 12:00
Sheraton Centre Toronto
Room: Outside Civic Ballroom
TERMINAL ROOM: Dufferin/Simcoe
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
$130.00 if registered BY July 1, 1994
$150.00 if registered AFTER July 1, 1994
AIRLINE: United Airlines (special rate roundtrip only)
1 (800) 521-4041 Meeting ID: 541YU (IETF)
We regret that discounted fares are not
available for international flights
Delta Airlines
1 (800) 241-6760 Meeting ID: P1014
AIRPORT: Lester Pearson International Airport (Toronto Intnt'l)
PARKING: Valet Parking $20.00 (Canadian) currently
Adjacent Municipal Lot $14.00 (Canadian) currently
SHUTTLE: Gray Coach Lines operates every 20 minutes.
$10.75 (Canadian) each way, currently.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12196;
11 May 94 15:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12192;
11 May 94 15:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19137;
11 May 94 15:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12179;
11 May 94 15:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12173;
11 May 94 15:50 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa19130;
11 May 94 15:50 EDT
Received: by ginger.lcs.mit.edu
id AA08777; Wed, 11 May 94 15:50:16 -0400
Date: Wed, 11 May 94 15:50:16 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9405111950.AA08777 at ginger.lcs.mit.edu>
To: iesg at CNRI.Reston.VA.US
Subject: Re: AREA ACTION: Service Applications Area to Close
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
The Service Applications Area of the IETF has closed down.
I believe this is unfortunate. I think that this technical field (tools for
building distributed applications, transaction processing, etc) is a very
important one for the future of the Internet, and it is not getting anything
like as much attention in the IETF as my guess is it deserves. Perhaps the
IESG has some plan on how to attack this, but this announcement gives no
details. If there is such a plan, you can ignore the rest of this message.
I have a hard time believing that this critical field (which includes a very
wide range of stuff, including things the IETF doesn't think of a lot) will
get the same attention without someone who sees this as their principal
responsibility. It's a fact of life that when someone has several things to
look after, and a few more they aren't attached to get dished on their plate,
the new things will get the least attention. (That was certainly the case with
me when I got some transport stuff thrown into Internet at one point; those
WG's did not get the same attention.) The natural (and healthy, in fact)
temptation is to keep your eye on a few things and make them happen.
While I'm aware that an AD can't make things happen if nobody wants to work on
them, an energetic AD can make a difference. At the very least, they can make
contact with people outside the IETF, and try and bring them in to work in
this forum. Etc, etc, etc.
It's not a quiescent field in general; I think there is a lot of stuff out
there, it's just happening in places we don't have a lot of visibility into.
This leaves the IETF with a number of choices, of which the following is not
intended to be an exhaustive enumeration:
- We can ignore the situation totally, and hope some other standards group
comes up with the right thing, and the market sorts things out.
- We can form some sort of liaision or delegation connection to some other
group, and let them sort out this part of the protocol tree.
- We can basically ignore things, and, from the available standards, pick
one as the IETF standard. (I know, I know, we may not be able to come to
an IETF consensus, but at least we could enter the contenders into the
IETF documentation process, etc.)
- A variant of the above, in which we pick on as a good starting place, and
try and make it better within the IETF context (same caveat).
- We try and "roll our own" from scratch.
Etc, etc, etc. I'm not really sure which strategy is the optimal one, I'm
simply not in close enough touch with all the stuff being done in this field.
I think there is an argument to be made that we should tend toward the latter
end of the list, since such protocols will need to fit into our overall
architecture as it develops with respect to thinks like security, resource
allocation, etc. I also think this community tends to have a technical focus
on larger and more homogeneous networks than any other protocol design
community.
I'd heard from quite a few people that this whole field is a very important
one. It's necessary to go outside the usual IETF crew, and talk to people in
other networking areas, to find out about some of this. Transaction
processing, for instance, is not a big priority with the IETF crowd.
In view of all this, it seems reasonable to me to think that this deserves the
kind of attention that an AD made responsible for just this field could bring
to it.
I do think the IETF ought to at least think hard about what to do here. At the
moment, we seem to be tending to default to the first solution above; ignore
the problem and hope somebody else does it. I dunno, maybe this is the right
thing to do, but I'd like to make sure we've thought about it before we take
that path.
Remember, WorldNet is going to have to have all this stuff, and if we expect
the Internet to be WorldNet we have to pay attention to all this stuff.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16565;
11 May 94 20:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16554;
11 May 94 20:17 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa24917;
11 May 94 20:17 EDT
Received: by bitsy.MIT.EDU
id AA26589; Wed, 11 May 94 19:59:37 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy with SMTP
id AA26581; Wed, 11 May 94 19:59:35 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA22323; Wed, 11 May 94 19:59:32 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id QAA10827; Wed, 11 May 1994 16:58:53 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA19431; Wed, 11 May 94 16:57:42 -0700
Date: Wed, 11 May 94 16:57:42 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405112357.AA19431 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: John Linn <linn at cam.ov.com>
Subject: Comment regarding GSS/Kerberos byte ordering
Cc: cat-ietf at mit.edu, gssapi at ocsg.com
Reply-To: dpg at ocsg.com
John:
The Kerberos GSS-API Mechanism Draft RFC (Section 1.1, page 5 for
example) states that integers will be formatted in little-endian
order.
Most Unix systems have system functions (usually macros) that
transpose short and long integers between network and host endian
order. The functions ntohl() and htonl() transpose a long integer
between network and host endian order and are used by the Beta 3 GSS
code. By using those functions the developer does not need to know
the host's ordering. Little-endian ordering will require GSS
implementations to empirically determine host ordering and make
adjustments.
Why the change to little-endian order?
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17046;
11 May 94 21:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17034;
11 May 94 21:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25674;
11 May 94 21:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17018;
11 May 94 21:14 EDT
Received: from quern.epilogue.com by IETF.CNRI.Reston.VA.US id aa16984;
11 May 94 21:11 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rob Austein <sra at epilogue.com>
X-Orig-Sender: sra at epilogue.com
To: Steve Bellovin <smb at research.att.com>
CC: ietf at IETF.CNRI.Reston.VA.US
In-reply-to: smb at research.att.com's message of Wed, 11 May 94 11:45:34 EDT <9405111151.aa06818 at IETF.CNRI.Reston.VA.US>
Subject: Re: trademarks and the DNS
Date: Wed, 11 May 94 21:11:06 -0400
Message-ID: <9405112111.aa21654 at quern.epilogue.com>
Steve,
Thanks for reposting the MTV.COM article. Reading it reminded me of a
famous tombstone inscription:
"I expected this, but not so soon."
--Rob Austein <sra at epilogue.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17469;
11 May 94 21:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17457;
11 May 94 21:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26291;
11 May 94 21:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17444;
11 May 94 21:51 EDT
Received: from giskard.holonet.net by IETF.CNRI.Reston.VA.US id aa17416;
11 May 94 21:49 EDT
Received: from localhost (ebear at localhost) by holonet.net (Eric Bear Albrecht)
id SAA05717; Wed, 11 May 1994 18:49:32 -0700
Message-Id: <199405120149.SAA05717 at holonet.net>
Subject: Lawyers
To: sob at harvard.edu
Date: Wed, 11 May 94 18:49:30 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eric Bear Albrecht <ebear at presto.com>
Cc: ietf at isoc.org, harmon at tenet.edu, network at world.std.com
to: Scott Bradner
cc: ietf, since there is no imtf (internet manners task force)
Network World
This is about the smug lawyers who blasted the net with ads
as reported in Network World 5/2/94
Let's take this one step at a time.
Are we going to tolerate it? Kiss the internet culture goodbye.<-----
If no, then we have to do something about it. |
Not doing something about it is tolerating it, by definition. |
If we don't do something about it, go back three spaces --------------
Doing something about it might include:
E-mail to their service provider demanding termination of their access;
Filing a class-action suit for the resources they used up;
Complaints to American Bar Association regarding unethical behaviour
(and to their state association and courts).
Picketing their office.
And don't withhold their names; we have to know who these people are in
order to deal with them. There's no "rights of the accused" at work here.
I don't get any usenet stuff since I'm long distance from _everything_
so I don't qualify as a member of the class for a suit, but I sure as
hell will complain to the ABA if I know who to complain about.
"Hadn't done anything wrong", ha!.
Only if we sit on our butts will it be so.
Eric K. Albrecht ....
ebear at presto.com ....
Presto Computers ....
Taos, New Mexico ....
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05629;
12 May 94 10:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05621;
12 May 94 10:23 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa07952;
12 May 94 10:23 EDT
Received: by bitsy.MIT.EDU
id AA01331; Thu, 12 May 94 10:03:02 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA01323; Thu, 12 May 94 10:02:57 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA20503; Thu, 12 May 94 10:02:50 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA05171; Thu, 12 May 94 06:55:55 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA10000; Thu, 12 May 94 09:54:54 -0400
Message-Id: <9405121354.AA10000 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Thu, 12 May 94 09:54:55 EDT
Date: Thu, 12 May 94 09:54:55 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 12-May-1994 0911" <wray at tuxedo.enet.dec.com>
To: dpg at ocsg.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, dpg at ocsg.com
Subject: RE: Comment regarding GSS/Kerberos byte ordering
>Most Unix systems have system functions (usually macros) that
>transpose short and long integers between network and host endian
>order. The functions ntohl() and htonl() transpose a long integer
>between network and host endian order and are used by the Beta 3 GSS
>code. By using those functions the developer does not need to know
>the host's ordering. Little-endian ordering will require GSS
>implementations to empirically determine host ordering and make
>adjustments.
>
>Why the change to little-endian order?
You don't need to know the host's byte-order in order to do something like
this:
packet_header[offset] = uint32 | 0xff;
packet_header[offset+1] = (uint32 | 0xff00) >> 8;
packet_header[offset+2] = (uint32 | 0xff0000) >> 16;
packet_header[offset+3] = (uint32 | 0xff000000) >> 24;
You also end up with code that's portable to environments without htonl() &
ntohl(), as well as supporting whatever base datatype has been chosen to
represent OM_uint32 (not necessarily long).
Any byte ordering would be OK. It's not a _change_ to little-endian; it was
always specified that way. From my point of view, the main reason this is
important is mostly because we're already shipping code to customers that
matches the current spec, so there's an incentive to resist any change that
doesn't fix a specific problem. However, that aside, the use of little-endian
byte-order also serves to keep the Kerberos GSSAPI protocol very close to the
DCE GSSAPI protocol. If we were to change this to big-endian for the Kerberos
mechanism, any dual-mechanism implementation that supports both Kerberos & DCE
security (as Digital's GSSAPI implementation does) would have to use different
byte-orderings for the different mechanisms. Currently, the only difference
between the two mechanisms (other than a different OID at the front of the
header) is the use made of the auth_info field within the Kerberos ticket
(along with some implicit trust assumptions that DCE brings for inter-realm
authentication).
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07090;
12 May 94 11:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07049;
12 May 94 11:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09627;
12 May 94 11:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07025;
12 May 94 11:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06849;
12 May 94 11:20 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa09374;
12 May 94 11:18 EDT
Received: from sanson.dit.upm.es by venera.isi.edu (5.65c/5.61+local-14)
id <AA04042>; Thu, 12 May 1994 08:09:35 -0700
Received: from yeti.dit.upm.es by sanson.dit.upm.es (5.65c/1.6.33) Thu, 12 May 1994 16:46:12 +0200
Received: by yeti.dit.upm.es (5.65c/1.6.33) Thu, 12 May 1994 16:46:10 +0200
Date: Thu, 12 May 1994 16:46:10 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Juan Quemada Vives <quemada at dit.upm.es>
Message-Id: <199405121446.AA15555 at yeti.dit.upm.es>
To: frers at bernie.zfe.siemens.de, frimout at it.et.tudelft.nl,
fritz.seytter at zfe.siemens.de, frocha at ci.ua.pt, frz at informatik.uni-ulm.de,
ftd at barco.be, fubpos4 at itcaspur.caspur.it, fuyung at ralvm29.vnet.ibm.com,
g.kalbeitzel at rcs.sel.de, gagnaire at res.enst.fr, galand at vnet.ibm.com,
galassi at settimo.italtel.it, gbcu1b65 at ibmmail.com,
georg.strasser at eurokom.ie, gerard.auvray at ansf.alcatel.fr,
gerard.segarra at eurokom.ie, gerry_mcmahon_eolas at eurokom.ie,
gfeller at tech.ascom.ch, etnomi!giannir at isi.edu, gigante at dassault.at.fr,
gigante at dassault_at.fr, gilbert.buty at sp1.y-net.fr, glax at fc.um.es,
glax at fc.um.es, glella at sarin.it, gnarcisco at gti.upm.es, godefroy at teaser.com,
godlewski at res.enst.fr, gonxa at softbase.es, gonza at softbase.es,
gonzalo.abente at higeia.isciii.es, gonzalo at islero.cedex.es,
greg at ektor.ntua.gr, greg at xtp.wpd.sgi.com, gue at maz-hh.de,
gueguen at eurecom.fr, guerin at watson.ibm.com, guillemi at lannion.cnet.fr,
guillemo at ccett.fr, guillemot at ccett.fr, guillermina.gavaldon at ens.es,
gun at vnet.ibm.com, haas at boole.att.com, gurcan at ee.bilkent.edu.tr,
gusrodri at cica.es, guven at atri.curtin.edu.au, gvazquez at plb.isdefe.es,
h_froeschle at iao.fhg.de, h_tobiet at eurocom.ie, h_tobiet at eurokom.ie,
haghiri at lep.lep-philips.fr, hakan at heiab.hasselblad.se,
hamberg at prl.philips.nl, hamlet-prj at hhi.de, hans.mahlein at zfe.siemens.de,
hans at gaes.usc.es, harald.pettersen at nta.no, harald_bobel at eurokom.ie,
hariri at cat.syr.edu, hbakker at rcs.sel.de, he at teles.de, hector at ttools.es,
helbig at informatik.uni-stuttgart.de, helmut.rackl at zfe.siemens.de,
helmut at stack.zfe.siemens.de, henri at cwi.nl, heras at dec.ciemat.es,
herbie_rijndorp at inmarsat.org, herranzma at inta.es, heuer at fz.telekom.de,
hherbrig at rcs.sel.de, hill_a_m at bt-web.bt.co.uk, hofmann at irt.de,
horlait at masi.ibp.fr, hp at cscn.ncsu.edu, hrb at sesa.es, hubaux at tcom.epfl.ch,
hueser at darmstadt.gmd.de, huish_p_w at bt-web.bt.co.uk, humberto at unimur.um.es,
ian.corden at eurokom.ie, ib_toftkjaer_jtas at eurokom.ie, ibrahim at ece.upm.my,
ic-esteban at fib.upc.es, ic_esteban at fib.upc.es, icad-request at santafe.edu,
icad at santafe.edu, idarz at leon.nrcps.ariadne-t.gr, idirene at imag.fr,
ietf-request at IETF.CNRI.Reston.VA.US, ietf at isi.edu, iinfd at ccuab1.uab.es,
imi04 at cc.uib.es, ina at fokus.gmd.de, info-faecad at dec.ciemat.es,
intelmann at deteberkom.detecon.d400.de, intersis at dcfgep.das.net,
ir-l at uccvma.bitnet, ired at gapd.es, ired at gapd.es, iris-mania at rediris.es,
quemada at dit.upm.es
Subject: Summer School on Advanced Braodband Communication
Please find attached the program of the Second International Summer
School on "Advanced Broadband Communication" to be held in Madrid and
Aveiro. I would appreciate If you forward it to potentially interested
persons.
Juan Quemada
==============================================================================
Second International Summer School on
Advanced Broadband Communications
ATM Enabling the 21st Century Organisation.
Madrid, Aveiro, July 11-15, 1994
==============================================================================
The RACE project BRAIN is pleased to announce its "Second International Summer
School on Advanced Broadband Communications (ABC)".
Following the success of the last year's first distributed Summer School on
ABC, this edition will feature new advances in subject matter and use of ATM
technologies in a distance education network. This year, participants will
explore the contribution of broadband technologies to the world of enterprise
and corporate communications.
Examining broadband communication requirements with strong emphasis in
o Broadband technologies
o Telecommunications/IT technologies
o System integration aspects
o The range of decision making factors
o Potential applications
this Summer School will allow its participants to gain the knowledge required
to assist the migration of organisations towards broadband networking
platforms.
Each day proposes a coherent theme relating to aspects of business user views
of advanced communications leading to a team-based problem-solving "syndicate"
sessions using CSCW. The Summer School will provide perspectives of these
networking technologies from both the large corporate user to the small and
medium-sized enterprise.
The syndicate sessions will be based on realistic case studies such as:
airline reservation systems; residential business user access to travel
information; LAN interconnection for banking; transnational brodband services
provision; network for aerospace industry supporting all aspects of design,
training, financial,...
In addition the Summer School will provide demonstrations of project
results. This includes: RACE projects, such as EUROBRIDGE, EXPLOIT, CIO, IBER,
PREPARE, CATALYST, RAMA,..; PLANBA projects such as EDUBA, RAL-ATM, etc.
==============================================================================
LOCATIONS AND INTERCONNECTION
At least four sites will be united in Summer School '94 using a European
Community sponsored ISABEL-IBER 34 Mbit/s ATM advanced network
o ETSI Telecomunicacion, Madrid-Spain (Central Site)
o University of Aveiro, Aveiro-Portugal
o CET, Aveiro-Portugal
o TIDSA, Madrid-Spain
A Multimedia Computer Supported Cooperative Work (CSCW) tele-education
application will join lecture rooms at different physical sites into a unified
virtual lecture room where lecturers and participants join together in a
unique, interactive educational experience.
Although more sites will join to SS'94, open registration will only exist at
the ETSI Telecomunicacion of the Technical University of Madrid in Spain and
at the Universidade de Aveiro in Portugal.
In addition to ISABEL-IBER interconnecting RIA of Telecom Portugal and RECIBA
of Telefonica, it will be used the CIBELES (Telefonica) infrastructure and the
PLANBA ATM LAN at the ETSI Telecomunicacion in Madrid, as well as the
campus-wide ROBL broadband network of the University of Aveiro.
Additional feasibility studies are underway with RACE projects CATALYST,
EXPLOIT, BETEUS and the Spanish National tele-education satellite project
ETSIT to broadcast SS'94 to sites in Spain, France, Switzerland, Germany and
possibly other European countries.
==============================================================================
OBJECTIVES
Business Communication - either for large corporations or small and medium
enterprises (SMEs) - is considered as the main driving force for the short
term introduction of IBC (Integrated Broadband Communications). These
requirements will have a strong impact in the strategy of most PNOs, equipment
suppliers, users, ...
This year the Summer School (SS'94) is targeted at training public operators
and suppliers for their new role in competitive business with major
responsabilities in meeting user needs within SMEs and corporate
communications. The Summer School also aims at assisting user organisations
to frame the relevant issues for the potential development of broadband
communications applications and be in a position to address implementation
issues & supplier relationships.
==============================================================================
WHO SHOULD ATTEND
The 1994 Summer School is targeted at any person requiring a comprehensive
overview of Advanced Broadband Communications focussed on corporate needs and
SMEs. In particular:
o Telecommunications/IT managers of medium/large enterprises.
o Telecommunication engineers of public operators.
o Senior communications/IT staff.
o Telecommunication consultants.
o Software suppliers of communication applications.
o Researchers interested in the field of broadband communications.
==============================================================================
PROGRAMME
To achieve SS'94 goals each day will present a coherent theme related to the
business user's view of advanced communications for corporate needs and SMEs.
MONDAY - 11th July: Framing the School & User Requirements
The fist day will initiate the logical progression of themes starting with
an introduction covering business user needs for advanced networks and
services for improving the enterprise effectiveness.
SESSIONS:
WELCOME by the rectors from the University of Madrid & Aveiro.
A1 [09.30-10.30] - Presentation of SS'94
Vasco Lagarto CET, Juan Quemada, UPM;
John Dobson, Univ. Newcastle;
A2 [11.00-12.30] - Enterprise Network & Corporate Communications
Jeff Gould, Datastrategies; Jerome Camus, Theseus
A3 [14.00-15.30] - Advanced Networks & Services Road Map
David Fisher, FORT Communications
A4 [15.45-17.15] - Requirements Determination
John Dobson, University of Newcastle
S1 [17.15-18.00] - Syndicate Session I
TUESDAY - 12th July: Communications and Technologies
Day 2 addresses the relevant technological issues and base
technologies. It will cover cell base technologies (ATM, SMDS,..)
access networks (wire, fiber and wireless) or current and future
trends in LANs and LANs interconnection.
SESSIONS:
B1 [09.00-10.30] - Cell-based Technology
Jeff Gould, Datastrategies; Jerome Camus, THESEUS
B2 [11.00-12.30] - Technological trends in the Access Loop
Niels Anderson, NKT; Manuel de Oliveira Duarte,
Univ. Aveiro; Silvia Ruiz, Tech. Univ. Barcelona
B3 [14.00-15.30] - An Evolutionary Approach to LANs & LANs Interconnection
Thierry Boissier, Metropolitan Fiber Systems
B4 [15.30-17.00] - Data Communications.& Distributed Computing
Chris Mayers - ANSA Team Cambridge
S2 [17.30-19.00] - Syndicate Session II
WEDNESDAY - 13th July: System Integration
Following the main technological components, Day 3 builds on this
knowledge by examining enterprise and corporate network systems
integration, management problems and provides a systems
engineering view.
SESSIONS:
C1 [09.00-10.30] - Communications Management
George Williamson, BT; William Donnelly, Broadcom
C2 [11.00-12.30] - Management & Dependability
George Williamson, BT; Jeff Gould, Datastrategies;
Jerome Camus, Theseus
S3 [14.00-16.00] - Syndicate Session III
C3 [16.15-17.30] - System Engineering
Darrel Ince, Open University, UK
C4 [17.30-18.30] - Messaging and Distributed Services
Jose Manas, Tech. Univ. Madrid; Pedro Ramalho, INESC
THURSDAY - 14th July: Key factors for Decision Making
This sequence leads logically to Day 4 sessions focussed on
business user decision making. "Make or buy" - users must choose
among options ranging from leased dark-fiber transmission to more
sophisticated public operations, such as Virtual Private Networks
(VPN) and advanced Intelligent Networks Services (IN) that may
bundle sophisticated management and switched services.
SESSIONS:
D1 [09.00-10.30] - Telecommunication Systems: The Boundaries of the
Public Service
Otto Baireuther, EURESCOM
D2 [11.00-12.30] - Cost Modelling for Advanced Networks
Andre Socard, SAT; Manuel de Oliveira Duarte,
Univ. Aveiro; Jeff Gould, Datastrategies
D3 [14.00-15.30] - Corporate Effectiveness & Virtual Private Networks
Mario Campolargo, RCO-DG XIII; Wulf Bauerfeld,
DeTeBerkom; William Donnelly, Broadcom
D4 [15.45-17.30] - Advanced CPE
Jean Clovis Tichon, Alcatel; David Drury, FORE;
Jos de Klein, Synoptics;
S4 [17.30-19.00] - Syndicate Session IV
FRIDAY - 15th July: Corporate Communications and the Future
The final day is devoted to advanced applications and IBC services,
including demonstrations of projects (RACE, PLANBA,..), advanced
multimedia applications, virtual reality, .. After a key note
speaker presenting the EC initiatives on advanced networking, a
panel on the future evolution of broadband communications at the
corporate side will close the Summer School, bringing together
experts from different perspectives (users, suppliers, PNOs,
academia, ...).
SESSIONS:
E1 [09.00-10.30] - Advanced Multimedia Applications & Interfaces
Jose Encarnacao - Frauenhofer Institut.
E2 [11.00-12.30] - The Orlando Time Warner & Silicon Graphics project,
Javier Castellar, Silicon Graphic.
- Advanced Experiments on the Information Superhighways,
Jorge Warren, SUN-Microsystems.
- RAMA: Remote Access to Museum Archives,
Guillermo Cisneros, Tech. Univ. Madrid
- EDUBA: Distance Education over Broadband Networks
David Fernandez, Tech. Univ. Madrid
S5 [14.00-14.45] - Presentation of Syndicate Work
E3 [14.45-15.15] - EC Initiatives in Advanced Broadband Communications
Augusto de Albuquerque, European Commission DG XIII-B
E4 [15.15-16.45] - PANEL: Future Corporate Networks.
Jeff Gould, Datastrategies; Jerome Camus (Moderators)
Augusto de Albuquerque, DG XIII-B;
Antonio Golderos, Telefonica;
Juan Martinez Fernandez-Villamil, Ericsson;
Paulo Nordeste, Telecom Portugal/CET;
Manuel de Oliveira Duarte, Univ. of Aveiro;
Francisco Padinha, Telecom Portugal;
Martin Potts, ASCOM;
Juan Riera, Tech. Univ. of Madrid;
George Williamson, BT.
==============================================================================
HONORARY COMMITTEE
Roland Huber (Chair), European Commission, Director DGXIII-B, Belgium
Javier Dominguez, Director Telefonica-Tecnologia, Spain
Manuel Fernandes Thomas, Secretary of Science and Technology, Portugal
Julio Linares, Director Telefonica I+D, Spain
Javier Nadal, Director General de Telecomunicaciones - MOPTMA, Spain
Paulo Nordeste, Director of the Central Directorate for R&D of
Telecom Portugal/CET, Portugal
Francisco Padinha, Board of Administration of Telecom Portugal, Portugal
Julio Pedrosa de Jesus, Reitor da Universidade de Aveiro, Portugal
Rafael Portaencasa, Rector Universidad Politecnica de Madrid, Spain
==============================================================================
ORGANIZING COMMITTEE
Rui Aguiar, University of Aveiro, Portugal
Anatolio Alonso, DGTel - MOPTMA, Spain
Arturo Azcorra, Technical University of Madrid, Spain
Joao Bastos, CET, Portugal
Jerome Camus, Institut Theseus, France
Pedro Chas, Telefonica I+D, Spain
Pierre Courtois, AIB, Belgium
John Dobson, University of Newcastle, United Kingdom
Jose Domingues, CET, Portugal (BRAIN Project Manager)
Manuel de Oliveira Duarte, Univ. of Aveiro, Portugal (Aveiro Site Manager)
Klaus Franke, Technical University of Chemnitz, Germany
Luis Gonzalez Souto, CDTI - MINER, Spain
Vasco Lagarto, CET, Portugal
Pierre Lagasse, University of Gent, Belgium
Vicente Marana, TELEFONICA, Spain
Hans Melchior, Swiss Federal Institut of Technology, Switzerland
Tomas de Miguel, Technical University of Madrid, Spain
John O'Reilly, University College North Wales, United Kingdom
Santiago Pavon, Technical University of Madrid, Spain
Steven Plagemann, SHP Systems Services, Ireland (BRAIN Technical Manager)
Juan Quemada, Technical Univ. of Madrid, Spain (Summer School Manager)
Michel Roy, European Commission DGXIII-B, Belgium
Silvia Ruiz, Technical University of Catalunya, Spain
Joaquin Salvachua, Technical University of Madrid, Spain
Eric Scharf, Queen Mary Westfield College, United Kingdom
Amaro de Sousa, Universidade de Aveiro, Portugal
Reg Teesdale, SESTEL, France
I Venieris, National Technical University of Athens, Greece
Robert Vinckier, SHP Systems Services, Belgium
George Williamson, British Telecom, United Kingdom
==============================================================================
MADRID
Madrid, the lively and beautiful capital of Spain, is located in the heart of
the country and offers plenty of exciting choices to the visitor. On the one
hand, the city has plenty of worldwide known museums, monuments and a restless
cultural life. On the other hand, night life is also a strong point of Madrid,
especially in July when holidays are starting and hundreds of outdoor pubs and
restaurants offer their delights along the so-called "Madrilenian coast" till
deep into the night. Historical sites such as Toledo, Segovia, Avila,
Aranjuez, ... can be reached within 1 hour from Madrid. Even Sevilla
or Cordoba can be reached in less than 2h30min with the new high speed train.
==============================================================================
AVEIRO
Aveiro is a charming University Town located on the Portuguese coast 70km
south of Oporto. It is easily reached from all European capitals by frequent
air services to Oporto and Lisbon and has good train/autoroute connections to
both cities. Aveiro is the center of the beautiful "Rota da Luz", literally
the "Light Route". A region full of contrasts, where land and water merge
together, thanks to the waters of the inlet called "Ria", a vast space ideally
suited to nautic activities. At the same time the town enjoys an exciting
night atmosphere, proper of a university population.....
==============================================================================
For further information, contact Secretariats:
Dept Ing. Telematica (SS'94) Dept. Electronica e Telecomunicacoes
ETSI Telecomunicacion Universidade de Aveiro (SS'94)
E-28040 Madrid, Spain 3800 AVEIRO, Portugal
tel: +34 1 3367332, fax: ..333 Tel: +351.34.391937, fax: ..941
email: SS94 at dit.upm.es
==============================================================================
S U M M E R S C H O O L ' 94
R E G I S T R A T I O N
11-15 July 1994, Madrid, SPAIN
==============================================================================
The central site will be located at ETSIT-UPM in Madrid where the main
auditorium will be put up. For registration at the Madrid site at
ETSIT-UPM, complete this form and return it to :
Fundacion Universidad Empresa (Summer School 94)
Serrano Jover 5 - planta 7 tf: +34 1 5419600, 5419003
28015, Madrid fax: +34 1 5470652
SPAIN e-mail: SS94 at dit.upm.es
All amounts in Spanish Pesetas (Pta). We do recommend early registration
as the summer school has a limited number of places.
____________________________________________________________________________
Registration Fees: Early Registration Late Registration
(Before June 6th)
Reduced fee (*) : [ ] 48.000 Pta [ ] 63.000 Pta
Regular fee : [ ] 69.000 Pta [ ] 84.000 Pta
Student fee : [ ] 38.000 Pta [ ] 53.000 Pta
Conference Dinner (Extra ticket): [ ] 7.000 Pta
(*) Reduced fee applies to : RACE or other CEC funded project members and
PLANBA funded project members. Proof of Student or Reduced fee status
must be attached.
Reduced or Regular fee covers: welcome reception, conference, proceedings,
meals and conference dinner.
Student fee covers: welcome reception, conference and proceedings.
==============================================================================
REGISTRATION FORM
CEC R&D Project: ____________________
Participant First Name: ____________________ Surname:_______________________
Company: _____________ Address: ____________________________________________
Post Code:_________________ Country:________________________________________
Telephone:_________________ Fax :____________________ Email:________________
Payment (tick one): Credit Card[ ] Check[ ] Bank Transfer(Pesetas)[ ]
Credit Card type: VISA [ ], Master Card [ ], Servired [ ].
Credit Card number: Expiration date:
Surname: Signature:
Make Check payable to "Fundacion Universidad Empresa" and enclose it with
the registration form.
Make Transfer to account: c/c 9700, Barclays Bank, Ag. 11
C/ Marques de Urquijo,11 28008-Madrid, SPAIN. USE REFERENCE: SS94 .
Please fill in these questions about your profesional profile in order to
facilitate the organisation of the syndicate sessions :
Present/Past work and responsabilities________________________________________
University degree and year____________________________________________________
Interest in ABC_______________________________________________________________
==============================================================================
S U M M E R S C H O O L ' 94
H O T E L R E S E R V A T I O N
11-15 July 1994, Madrid, SPAIN
==============================================================================
For Hotel reservations at the Madrid site near the Telecommunication
Engineering School or in Hotels where transportation will be provided by the
organizers, complete this form and return it to:
Ms. Victoria Alarcon tf: +34 1 4313550
Viajes ECO S.A. (Summer School 94). fax: +34 1 5752646
D. Ramon de la Cruz, 36 Telex: 22503
28001, Madrid
SPAIN
LODGING - Please order your three first lodging preferences ( 1 as first
choice, 2 as second). Prices are in Spanish Pesetas and include breakfast.
Only the students residence will be within a walking distance from the
Conference location (15min). A bus service will be set for the hotels. TRYP
hotels are placed in the Gran Via of Madrid, a commercial and entertainment
avenue which crosses the city center. H. Conde Duque is situated in a
picturesque quarter (San Bernardo) of the genuine Madrid. H. Palace is very
well located in the monumental and historical heart of the city very near to
many interesting places of Madrid, such as Castellana, El Prado, Centro de
Arte Reina Sofia, Thyssen, etc.
==============================================================================
LODGING RESERVATION FORM
Single Double
Students residence ( 4.500 Pta) _______ ( 6.000 Pta) _______
TRYP hotels ( 8.000 Pta) _______ (10.000 Pta) _______
H. Conde Duque (11.000 Pta) _______ (14.000 Pta) _______
H. Palace (19.200 Pta) _______ (23.000 Pta) _______
CEC R&D Project: ____________________
Participant First Name: ____________________ Surname:_______________________
Company: _____________ Address: ____________________________________________
Post Code:_________________ Country:________________________________________
Telephone:_________________ Fax :____________________ Email:________________
Number of Nights: Total Amount:
Arrival: Departure:
Payment (tick one): Credit Card[ ] Check[ ] Bank Transfer(Pesetas)[ ]
Credit Card type: VISA [ ], American Express [ ], Diners [ ], Eurocard [ ].
Credit Card number: Expiration date:
Surname: Signature:
Make Check payable to: "Viajes ECO S.A." and enclose it with this form.
Make Transfer to account:
"Viajes ECO S.A." c/c 60/07644-93, Banco Popular, Sucursal 14,
C/Ortega y Gasset 23, 28001-Madrid, SPAIN. USE REFERENCE: SS94 .
Viajes ECO can also provide special arrangements, such as excursions, visits,
trip extensions,... which should be negotiated directly with Viajes ECO.
==============================================================================
S U M M E R S C H O O L ' 94
R E G I S T R A T I O N
11-15 July 1994, Aveiro, PORTUGAL
==============================================================================
The site located at the University of Aveiro will be open open to registration
but will have a smaller auditorium. For registration at the Aveiro site,
complete this form (block capitals please) and return it to:
Summer School 94 Secretariat Tel: +351.34.391937
Universidade de Aveiro Fax: +351.34.391941
Dept. Electro'nica e Telecomunicac,o~es
3800 AVEIRO
Portugal
REGISTRATION DETAILS
--------------------
All amounts in Portuguese Escudos (PTE). We do recommend early registration
as the summer school has a limited number of places.
____________________________________________________________________________
Registration Fees: Early Registration Late Registration
(Before June 6th)
Reduced fee (*) : [ ] 55.000 PTE [ ] 70.000 PTE
Regular fee : [ ] 70.000 PTE [ ] 95.000 PTE
Student fee : [ ] 45.000 PTE [ ] 60.000 PTE
Conference Dinner (Extra ticket): [ ] 7.000 PTE
(*) Reduced fee applies to : RACE or other CEC funded project members.
Proof of Student or Reduced fee status must be attached.
Reduced or Regular fee covers: welcome reception, conference, proceedings,
meals and conference dinner.
Student fee covers: welcome reception, conference, meals and proceedings.
Cancellations must be received in writing before the 30th of June 1994 and
will be subject to an administration fee of 10,000 PTEs. Substitutions may be
made at any time until 10th June.
Payment may be made by Eurocheque (in Portuguese Escudos), a bank cheque drawn
on a Portuguese bank, or by credit card. Registration payment must be made at
the time of registration. No advanced payment is needed for accomodation. To
register, please send this Registration Form , or a copy, to the above address
with the appropriate registration fee.
==============================================================================
REGISTRATION FORM
CEC R&D Project: ____________________
Participant First Name: ____________________ Surname:_______________________
Company: _____________ Address: ____________________________________________
Post Code:_________________ Country:________________________________________
Telephone:_________________ Fax :____________________ Email:________________
Please fill in these questions about your profesional profile in order to
facilitate the organisation of the syndicate sessions :
Present/Past work and responsabilities________________________________________
University degree and year____________________________________________________
Interest in ABC_______________________________________________________________
LODGING - Please order your three first lodging preferences ( 1 as first
choice, 2 as second). The organization will try to accomodate your first
choice, but we can not assure it. Prices include breakfast. Please note that
July is high season in Aveiro, and block reservations have been already made
for Summer School participants; early registration will assure your
accomodation choice. All choices are in walking distance (15min) from the
University of Aveiro.
Arrival at ___/07/94 Departure at ___/07/94
Single Double
Hotel Imperial. (10 500 PTE) _______ (13 100 PTE) _______
Hotel D. Afonso V ( 9 850 PTE) _______ (13 150 PTE) _______
Residencial do Alboi ( 6 700 PTE) _______ ( 9 000 PTE) _______
If you have any special dietary or lodging requirements please list below.
----------------------------------------------------------------------------
[ ] I enclose Eurocheque number _________________ payable to Fundagco Joco
Jacinto de Magalhces / Universidade de Aveiro.
[ ] I enclose cheque number _________________ drawn on Portuguese Bank _____
payable to Fundagco Joco Jacinto de Magalhces / Universidade de Aveiro.
[ ] Please charge my credit card on the amount of ________________ as
payment of my registration fee.
Visa ___ Diners Club ___ Mastercard ___
Expiry Date: ________ Credit Card Number ____ ____ ____ ____
Name (as it appears on card) ______________________________________________
Participants signature: _________________________________________
Date ___/___/1994
==============================================================================
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07931;
12 May 94 12:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11020;
12 May 94 12:09 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07919;
12 May 94 12:09 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07806;
12 May 94 12:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tnfs at wdl1.wdl.loral.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-tnfs-spec-04.txt
Date: Thu, 12 May 94 12:04:13 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405121204.aa07806 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Trusted Network File Systems
Working Group of the IETF.
Title : A Specification of Trusted NFS (TNFS)
Protocol Extensions
Author(s) : Fred Glover
Filename : draft-ietf-tnfs-spec-04.txt
Pages : 28
Date : 05/11/1994
Additional functionality has been developed for UNIXr systems to address
the TCSEC requirements for trusted systems. New requirements are driving
efforts to develop interoperable, networked solutions for trusted UNIX
environments. A specific approach for addressing TCSEC MLS requirements
is identified in the CMW requirements document. Developing support for
network interoperability among MLS classified systems is a primary goal of
the trusted UNIX community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tnfs-spec-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tnfs-spec-04.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940511144412.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-tnfs-spec-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tnfs-spec-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940511144412.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08597;
12 May 94 13:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12441;
12 May 94 13:05 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08582;
12 May 94 13:05 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07743;
12 May 94 12:03 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-iab-mou2jtc1-02.txt
Date: Thu, 12 May 94 12:03:11 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405121203.aa07743 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Architecture Board.
Title : Draft Memorandum of Understanding Between
the Internet Society and ISO/IEC JTC-1/SC6
Author(s) : C. Huitema
Filename : draft-iab-mou2jtc1-02.txt
Pages : 4
Date : 05/11/1994
The IAB has been working toward establishing a liaison relationship between
the Internet Society and ISO/JTC-1. A liaison with ISO/IEC JTC1/SC6 has
been offered, and there have been indications that liaisons with any of the
other SCs will be granted without problems as needed.
Further progress is subject to the preparation and approval of a
"memorandum of understanding" (MOU) between the two organizations.
The present document is a prototype of an MOU. It stresses the main points
of agreement: mutual recognition of standards, information on work programs,
information sharing and possible collaborative efforts.
In line with JTC1 decisions, this draft MOU covers liaison with SC6.
The Internet Society looks forward to establishing similar liaisons with
other appropriate JTC1 subcommittees in the near future and expects to
use the same MOU for all such liaisons.
This version is a draft. It will have to be reviewed by the members of
the Internet community and discussed with ISO/IEC JTC1.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-iab-mou2jtc1-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-iab-mou2jtc1-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940511100722.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-iab-mou2jtc1-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-iab-mou2jtc1-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940511100722.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14813;
12 May 94 18:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14800;
12 May 94 18:34 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa21533;
12 May 94 18:34 EDT
Received: by bitsy.MIT.EDU
id AA09419; Thu, 12 May 94 18:24:20 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA09411; Thu, 12 May 94 18:24:19 EDT
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA02186; Thu, 12 May 94 18:24:14 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA26180; Thu, 12 May 94 18:23:59 EDT
Date: Thu, 12 May 94 18:23:59 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9405122223.AA26180 at tsx-11.MIT.EDU>
To: dpg at ocsg.com
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu, gssapi at ocsg.com
In-Reply-To: Dennis Glatting's message of Tue, 10 May 94 13:30:14 -0700,
<9405102030.AA16759 at war04.ocsg.com>
Subject: Re: Questions regarding GGS/Kerberos names
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Tue, 10 May 94 13:30:14 -0700
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
A Kerberos principal is a complex data structure released using
krb5_free_principal(). Strings are released using free(). How is
that information passed to gss_release_buffer()?
I made the assumption there is reason data encapsulated in GSS
buffers and passed to gss_import_name() would be kept around.
It's been said before, but it bears repeating, because I think people
are confused. gss_import_name() *only* takes character strings as
input. In the mechanism draft, where it says krb5_principal, what it
should say is "a character string in the format which could be parsed
by krb5_parse to turn it intop a valid krb5_principal". In point of
fact, that's what an implementation of gss_import_name() will likely be
end up doing --- it'll just pass the character string into krb5_parse(0.
I can't speak for NT but DOS and Mac do not have UIDs. Network
technologies for DOS and Mac platforms do have UID concepts but are
as varied as vendors implementations.
I believe the potential for GSS on DOS and Mac platforms is greater
than UNIX. Consequently, I think the UID name types removed from the
draft RFC. Translation of a UID to something suitable for GSS import
should be a local matter.
The motivation to support KRB5_NT_UNKNOWN is a principal's instance
isn't canonicalized. For example, fw.ocsg.com (fire wall) is a DNS
CNAME for kerby.ocsg.com. If DNS is your network name resolution
authority then calling gethostbyname() passing fw.ocsg.com as an
argument returns kerby.ocsg.com. This may not be the desired effect.
Again: types don't matter!!!! If you want a specific krb5 principal
name, just call gss_import_name() and with name type set to the OID for
krb5, and the input name will be passed into krb5_parse(), and no
canocalization will ever happen.
The canonclization only happens if you are using
krb5_sname_to_principal(), which will only happen if you call
gss_import_name() with the name type set to null, and in that case, the
input name is of the form "service:host";. This allows for a client to
specify the target authentication entity in a mechanism specific way.
But that's the only place where that might be happening if you are using
the krb5 GSSAPI mechanism.
- Ted
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17545;
12 May 94 19:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23705;
12 May 94 19:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17533;
12 May 94 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17491;
12 May 94 19:23 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa23638;
12 May 94 19:23 EDT
Received: from venera.isi.edu by venera.isi.edu (5.65c/5.61+local-14)
id <AA20311>; Thu, 12 May 1994 14:53:53 -0700
Message-Id: <199405122153.AA20311 at venera.isi.edu>
To: Internet-Research-Group: ;
Cc: IETF-Announce: ;
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Subject: April Internet Monthly Report Availability via FTP and Email
Reply-To: cooper at isi.edu
Date: Thu, 12 May 94 14:53:52 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
--NextPart
Internet Monthly Report Availability via FTP and EMAIL
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
IMR Retrieval using RFC-INFO Service
------------------------------------
The EMail retrieval system "RFC-Info" will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, 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_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from VENERA.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where "yymm" refers to the date of
the IMR. For example IMR9207.TXT is the report for July 1992). Login
with FTP username "anonymous" and password "ftp".
Requests to be added or deleted from the Internet Monthly Report list
should be sent to "imr-request at isi.edu".
Requests to be added or deleted from the IETF list should be sent to
"ietf-request at cnri.reston.va.us".
. . .
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the ASCII version
of the IMRs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9404
--OtherAccess
Content-Type: Message/External-body;
name="imr9404.txt";
site="venera.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17644;
12 May 94 19:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17632;
12 May 94 19:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23753;
12 May 94 19:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17621;
12 May 94 19:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17580;
12 May 94 19:27 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa23643;
12 May 94 19:24 EDT
Received: from venera.isi.edu by venera.isi.edu (5.65c/5.61+local-14)
id <AA20351>; Thu, 12 May 1994 14:55:30 -0700
Message-Id: <199405122155.AA20351 at venera.isi.edu>
To: Internet-Research-Group: ;
Cc: ietf at CNRI.Reston.VA.US
Subject: Internet Monthly Report - April 1994
Reply-To: cooper at isi.edu
Date: Thu, 12 May 94 14:55:26 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ann Cooper <cooper at isi.edu>
April 1994
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
This report is for Internet information purposes only, and is not
to be quoted in other publications without permission from the
submitter.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to:
Ann Westine Cooper (Cooper at ISI.EDU)
NSF Regional reports - To obtain the procedure describing how to
submit information for the Internet Monthly Report, send an email
message to mailserv at is.internic.net and put "send imr-procedure" in
the body of the message (add only that one line; do not put a
signature).
Requests to be added or deleted from the Internet Monthly report list
should be sent to "imr-request at isi.edu".
Details on obtaining the current IMR, or back issues, 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_imrs". For
example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
Cooper [Page 1]
Internet Monthly Report April 1994
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 3
Internet Projects
ANSNET/NSFNET BACKBONE ENGINEERING . . . . . . . . . . . page 8
DANTE. . . . . . . . . . . . . . . . . . . . . . . . . . page 11
INTERNIC. . . . . . . . . . . . . . . . . . . . . . . . . page 14
ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 18
MERIT/MICHNET . . . . . . . . . . . . . . . . . . . . . . page 24
MERIT/NSFNET ENGINEERING. . . . . . . . . . . . . . . . . page 26
NEARNET . . . . . . . . . . . . . . . . . . . . . . . . . page 28
NORTHWESTNET . . . . . . . . . . . . . . . . . . . . . . page 31
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 32
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 33
Rare List of Meetings . . . . . . . . . . . . . . . . . . page 36
Cooper [Page 2]
Internet Monthly Report April 1994
INTERNET ENGINEERING REPORTS
----------------------------
1. The next meeting of the IETF will be held in Toronto, Canada
from July 25 through July 29, 1994. This meeting is being hosted
by The University of Toronto.
Following the July 1994 meeting, IETF will meet in San Jose from
December 5-9, with the newcomer's orientation and registration
reception on Sunday, December 4th. Remember that information on
future IETF meetings can be always be found in the file
0mtg-sites.txt which is located on the IETF shadow directories.
2. At the IETF meeting in Seattle last month, new members of the
IESG were announced. The current members of the IESG are:
Paul Mockapetris Chair of the IETF/IESG
Scott Bradner Operational Requirements
A. Lyman Chapin Standards
Joel Halpern Routing
Erik Huizer Applications
John Klensin Applications
Stev Knowles Internet
Allison Mankin Transport Services
Mike O'Dell Operational Requirements
Joyce K. Reynolds User Services
Marshall T. Rose Network Management
Jeff Schiller Security
Claudio Topolcic Internet
3. The IESG issued five Last Calls to the IETF during the month of
April, 1994:
o Definitions of Managed Objects for the Ethernet-like
Interface Types <draft-ietf-ifmib-ethmib-smiv1-00> for
consideration as an Internet Standard.
o SMTP Service Extension for 8bit-MIMEtransport
<draft-ietf-smtpext-8bitmime-00> for consideration as a Draft
Standard.
o SMTP Service Extension for Message Size Declaration
<draft-ietf-smtpext-size-00> for consideration as a Draft
Standard.
Cooper [Page 3]
Internet Monthly Report April 1994
o SMTP Service Extensions <draft-ietf-smtpext-extensions-00>
for consideration as a Draft Standard.
o Post Office Protocol - Version 3 <draft-rose-pop3-again-01>
for consideration as a Draft Standard.
4. Two Working Groups were concluded during this period:
Network OSI Operations (noop)
Network Joint Management (njm)
5. A total of 61 Internet-Draft actions were taken during the month
of April, 1994:
(Revised draft (o), New Draft (+) )
(bgp) o A Border Gateway Protocol 4 (BGP-4)
<draft-ietf-bgp-bgp4-09.txt>
(bgp) o Application of the Border Gateway Protocol in the
Internet <draft-ietf-bgp-application-04.txt>
(none) o IP and ARP on Fibre Channel (FC)
<draft-rekhter-fibre-channel-03.txt>
(ospf) o OSPF Version 2 Management Information Base
<draft-ietf-ospf-mib-03.txt>
(x400ops) o Using the Internet DNS to distribute RFC1327 Address
Mapping Tables
<draft-ietf-x400ops-dnsx400maps-05.txt>
(pppext) o PPP in Frame Relay
<draft-ietf-pppext-frame-relay-03.txt>
(none) o Randomness Requirements for Security
<draft-ietf-security-randomness-01.txt>
(sipp) o SIPP Program Interfaces for BSD Systems
<draft-ietf-sipp-bsd-api-02.txt>
(uri) o Uniform Resource Locators (URL) A Syntax for the
Expression of Access Information of Objects on the
Network <draft-ietf-uri-url-03.txt, .ps>
(tn3270e) o TN3270 Enhancements
<draft-ietf-tn3270e-enhancements-04.txt>
(pppext) o The PPP Multilink Protocol (MP)
<draft-ietf-pppext-multilink-08.txt>
(none) o Selecting an Indirect Provider
<draft-rekhter-select-providers-02.txt>
(ids) o A Revised Catalog of Available X.500 Implementations
<draft-ietf-ids-catalog-02.txt>
(smtpext) + SMTP Service Extension for Command Pipelining
<draft-ietf-smtpext-pipeline-00.txt>
(none) o Selecting a Direct Provider
<draft-rekhter-direct-provider-01.txt>
Cooper [Page 4]
Internet Monthly Report April 1994
(none) o Post Office Protocol - Version 3
<draft-rose-pop3-again-01.txt>
(rreq) o Requirements for IP Routers
<draft-ietf-rreq-iprouters-require-01.txt>
(sipp) o SIPP Security Architecture
<draft-ietf-sipp-sa-02.txt>
(sipp) o SIPP Authentication Header
<draft-ietf-sipp-ap-03.txt>
(sipp) o SIPP Encapsulating Security Payload (ESP)
<draft-ietf-sipp-esp-02.txt>
(pppext) o PPP LCP Option for Data Encapsulation Selection
<draft-ietf-pppext-dataencap-02.txt>
(rdbmsmib) o RDBMS-MIB <draft-ietf-rdbmsmib-mib-03.txt>
(none) o A Mail-Safe Transformation Format of Unicode
<draft-goldsmith-mime-utf7-03.txt, .ps>
(ospf) o IP Forwarding Table MIB
<draft-ietf-ospf-cidr-route-mib-02.txt>
(none) o Computation of the Internet Checksum via Incremental
Update <draft-anil-incremental-checksum-01.txt>
(none) + A Unifying Syntax for the Expression of Names and
Addresses of Objects on the Network as used in the
World-Wide Web <draft-bernerslee-www-uri-00.txt,
.ps>
(pppext) o PPP in HDLC-like Framing
<draft-ietf-pppext-hdlc-fs-01.txt>
(pppext) o The Point-to-Point Protocol (PPP)
<draft-ietf-pppext-lcp-fs-01.txt>
(mobileip) o IP Mobility Support
<draft-ietf-mobileip-protocol-01.txt>
(none) + Procedures for Formalization, Evolution, and
Maintenance of the Internet X.500 Directory Schema
<draft-howes-x500-schema-00.txt>
(none) + Modeling and Simulation Requirements for IPng
<draft-symington-ipng-model-00.txt>
(none) + Market Viability as a IPng Criteria
<draft-curran-ipng-viability-00.txt>
(none) + Maintaining Presentation Guidelines on MIME Messages
<draft-pritchett-mime-guidelines-00.txt>
(isn) o Acceptable Use Policy Definition
<draft-ietf-isn-aup-01.txt>
(nasreq) + Remote Authentication Dial In User Service (RADIUS)
<draft-ietf-nasreq-radius-00.txt>
(iab) + Draft Memorandum of Understanding Between the
Internet Society and ISO/IEC JTC-1/SC6
<draft-iab-mou2jtc1-00.txt>
(none) + ISO/IEC 10747 Protocol for the Exchange of
Inter-Domain Routing Information among Intermediate
Systems to Support Forwarding of ISO 8473 PDUs
Cooper [Page 5]
Internet Monthly Report April 1994
<draft-kunzinger-idrp-ISO10747-00.txt>
(dns) + DNS Support for Load Balancing
<draft-ietf-dns-lb-00.txt>
(none) + TCP Embedded Trailer Checksum
<draft-bridges-tcp-checksum-00.txt>
(ifmib) + Definitions of Managed Objects for the Ethernet-like
Interface Types
<draft-ietf-ifmib-ethmib-smiv1-00.txt>
(smtpext) + SMTP Service Extensions
<draft-ietf-smtpext-extensions-00.txt>
(smtpext) + SMTP Service Extension for 8bit-MIMEtransport
<draft-ietf-smtpext-8bitmime-00.txt>
(smtpext) + SMTP Service Extension for Message Size Declaration
<draft-ietf-smtpext-size-00.txt>
(wg-msg) o Bombs series: Behaviour of Mail Based Servers Part
1: C-bombs Classification of Breeds of Mail Based
Servers <draft-rare-msg-c-bombs-01.txt>
(ifmib) + Definitions of Managed Objects for the Ethernet-like
Interface Types
<draft-ietf-ifmib-ethmib-smiv2-00.txt>
(wnils) + Architecture of the WHOIS++ service
<draft-ietf-wnils-whois-arch-00.txt>
(atm) + ATM Signaling Support for IP over ATM
<draft-ietf-atm-sig-00.txt>
(none) + TACTICAL RADIO FREQUENCY COMMUNICATION REQUIREMENTS
FOR NEXT GENERATION INTERNET PROTOCOLS
<draft-adamson-ipng-radio-req-00.txt>
(pppext) + Proposal for Callback Control Protocol (CBCP).
<draft-ietf-pppext-callback-cp-00.txt>
(none) + Accounting Requirements for IPng
<draft-brownlee-ipng-acct-req-00.txt>
(uri) + Specification of Uniform Resource Characteristics
<draft-ietf-uri-urc-00.txt>
(none) + IP Router Alert Option
<draft-katz-router-alert-00.txt>
(none) + A cellular industry view of IPng
<draft-taylor-ipng-cdpd-viewpt-00.txt>
(uri) + URN to URC resolution scenario
<draft-ietf-uri-urn2urc-00.txt>
(none) + HPN Working Group Input to the IPng Requirements
Solicitation <draft-green-ipng-navy-hpn-00.txt>
(none) + TUBA as IPng: A White Paper
<draft-ford-ipng-tuba-whitepaper-00.txt>
(none) + Electric Power Research Institute Response to RFC
1550 <draft-skelton-ipng-epri-00.txt>
(none) + CATNIP: Common Architecture for the Internet
<draft-mcgovern-ipng-catnip-wpaper-00.txt>
Cooper [Page 6]
Internet Monthly Report April 1994
(poised) + Procedure to Select and Confirm Individuals Serving
on the IAB and IESG
<draft-ietf-poised-nomcomm-00.txt>
(none) + A Chemical Primary MIME Type.
<draft-rzepa-chemical-mime-type-00.txt>
(wg-msg) + Bombs series: Behaviour of Mail Based Servers Part
2: A-bombs Answering servers
<draft-rare-msg-a-bombs-00.txt>
6. There were three RFC's published during the month of April, 1994
(all on April first):
RFC St WG Title
------- -- -------- -------------------------------------
RFC1605 I (none) SONET to Sonnet Translation
RFC1606 I (none) A Historical Perspective On The Usage Of
IP Version 9
RFC1607 I (none) A VIEW FROM THE 21ST CENTURY
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( E) Experimental
( I) Informational
Steve Coya (scoya at nri.reston.va.us)
Cooper [Page 7]
Internet Monthly Report April 1994
INTERNET PROJECTS
-----------------
ANSNET/NSFNET BACKBONE ENGINEERING
----------------------------------
Network Status Summary
======================
ANSnet total packet traffic grew by over 5% in April '94. The
process of CIDR aggregation continued in April. A decrease in the
ANSnet forwarding table growth was observed (1.72%) for the month
due to the withdrawal of 2,954 class based destinations.
April Backbone Traffic Statistics
=================================
The total inbound packet count for the ANSnet (measured using SNMP
interface counters) was 58,015,017,839 on T3 ENSS interfaces, up
2.03% from March. The total packet count into the network
including all ENSS serial interfaces was 68,132,330,845 up 4.99%
from March.
Router Forwarding Table Statistics
==================================
The maximum number of destinations announced to the ANSnet during
April was 19,721 up 1.72% from March. This decrease in the monthly
forwarding table growth rate is attributed to CIDR aggregation.
The number of network destinations configured for announcement to
the ANSnet but were never announced (silent nets) during April was
10,558.
BGP-4/CIDR Deployment Status
===========================
The following autonomous systems are currently exchanging routing
information with ANSnet via the BGP-4 protocol:
3 MIT
22 NOSC
86 SURANet
101 NorthWestNet
114 SESQUINet
185 MERIT-OFFNET
195 SDSC
200 BARRNet
Cooper [Page 8]
Internet Monthly Report April 1994
204 PSCNet
237 MichNet
266 CICNet
267 CICNet
279 SURANet
293 ESNet
297 NASA
372 NASA
560 NEARNet
577 CA*Net
600 OARNet
685 NorthWestNet
701 AlterNet
771 NASA
1133 Dante
1206 PSCNet
1225 CICNet
1240 ICMNet
1263 NASA (test)
1321 ANS (San Francisco)
1322 ANS (Los Angeles)
1323 ANS (Chicago)
1324 ANS (New York)
1325 ANS (Cleveland)
1326 ANS (Hartford)
1327 ANS (Washington DC)
1328 ANS (Houston)
1329 ANS (Greensboro)
1330 ANS (St. Louis)
1331 ANS (Seattle)
1332 ANS (Denver)
1333 ANS (Atlanta)
1670 ANS (test)
1674 Dante
1681 ANS (Ann Arbor)
1740 CERFNet
1800 ICMNet
1838 CERFNet
1879 EUROPE-RS
1957 ANS-CIX
2002 IBM Packet Video
2149 PSINet
2548 Digital Express
2551 Netcom
2882 COREN-ONE
3354 THENet
9010 ANS (test)
Cooper [Page 9]
Internet Monthly Report April 1994
As of early May '94, we have observed the withdrawal of 2,954 class
based destinations from the ANSnet router forwarding tables that
are now represented by 435 configured aggregates. Among these 37
configured aggregates:
398 of these are top-level aggregates (not nested in another
aggregate).
184 of these are actively announced to ANSnet.
162 of these have at least one subnet configured (the other 22
may be saving the Internet future subnet announcements).
142 of these have resulted in the withdrawal of at least one
configured more specific route.
136 of these have resulted in the withdrawal of 50% of their
configured more specific routes.
116 of these have resulted in the withdrawal of most (80%+) of
their more specific routes.
For further details on these CIDR aggregates, see
merit.edu:pub/nsfnet/cidr/nestings.announced for full listings.
Other gated software changes will be deployed over the next couple
of months to improve policy processing (required to support some
advanced forms of proxy aggregation).
Routing Stability Measured on the T3 Network
============================================
The three different routing stability measurements that have been
reported on over the past year were based on rcp_routed log file
entries. Gated software was deployed at the end of February to
replace rcp_routed. These routing stability reports have not yet
been converted to use gated logging. No data is available for the
month of April. Data collection is expected to resume shortly.
Notable Outages for April '94
=============================
E134 (Boston) suffered an extended outage due to hardware problems
on 04/02.
E136 (College Park) suffered an extended outage due to software
problems on 04/04.
Cooper [Page 10]
Internet Monthly Report April 1994
E137 (Princeton) was unreachable via T3 due to hardware problems on
04/06.
E172 (Phillips Labs) suffered an extended outage due to power
problems on 04/12.
E181 (WLN) was down for an extended time due to site move on 04/13.
E137 (Princeton) was unreachable via T3 due to hardware problems on
04/17.
UNAM suffered an extended circuit outage on 04/24.
E173 (ITESM) and UNAM suffered extended circuit outages on 04/28.
Jordan Becker, ANS (becker at ans.net)
DANTE
-----
__________________________________________________________________
* * A bi-monthly electronic news bulletin
* * reporting on the activities of DANTE,
* the company that provides international
* telecommunications services for the
THE WORKS OF D A N T E European research community.
No.3, April 1994 Editor: Josefien Bersee
__________________________________________________________________
* DANTE SHAREHOLDING EXPANDED *
On 25 March 1994, the DANTE Shareholders meeting took place in
Amsterdam. At the meeting the ownership of the company was formally
transferred from RARE to the Shareholders. RARE had been the legal
owner and only shareholder of DANTE in the first year of its
existence. During the meeting RARE was formally discharged of all
responsibility for the company, with the new Shareholders
acknowledging RARE's important role in setting it up. The chairman
thanked RARE for its support.
When issuing the Shareholder Certificates to the organisations
which had signed the final Shareholders Agreement the company
secretary, Boudewijn Nederkoorn from SURFnet, said: "This is an
historic occasion which marks a major step forward in pan-European
service provision for the research community".
Cooper [Page 11]
Internet Monthly Report April 1994
The following persons were appointed on the new Board of Directors:
Klaus Ullmann (DFN, DE) as a Director for a period of three years
and as Chairman of the Board; Boudewijn Nederkoorn (SURFnet, NL)
and Fernando Liello (CNUCE, IT) as Directors for a period of three
years, and Juergen Harms (SWITCH, CH) as a Director for a period of
two years. The new Board will make a proposal for a fifth Director,
who is to be approved by the Shareholders. The Operational Unit
Steering Committee, which was originally set up by potential
shareholders of DANTE to manage the creation of the company, will
be wound up as it has now completed its task.
The organisations which had signed the Shareholders Agreement at
the time of the meeting were: SWITCH (Switzerland), DFN (Germany),
HUNGARNET (Hungary), CNUCE (Italy), SURFnet (Netherlands), NORDUnet
(Nordic countries), FCCN (Portugal), ARNES (Slovenia), HEFC(E) (on
behalf of the UK). Organisations from other countries, including
Belgium, Spain and Greece, which had been unable to sign the
Agreement before the meeting, are still expected to do so.
* EuropaNET: THE LATEST DEVELOPMENTS *
In co-operation with CEENet, the Central and Eastern European
Networking Association set up in January 1994, DANTE has prepared a
plan for the development of international connectivity in Central
and Eastern Europe. The plan takes account of the financial and
other support that is likely to be available from ACOnet, NORDUnet
and the CEC's PHARE Programme. Implementation of the plan, which
outlines general principles as well as details for individual
countries, would represent a significant step forwards. DANTE has
offered to set up all the interconnections which include EuropaNET
if the plan goes ahead. The document is available from the DANTE
gopher server (EuropaNET directory).
The 2 Mbps line between Amsterdam and Washington (finally) came
into operation on 17 March 1994. Dai Davies, DANTE general manager,
commented: "This was an unusually challenging activity and the
effort required from DANTE to do so is a sad reflection on the
difficulties that still exist in getting international line
providers to organise simple things." The line was ordered in
November 1993 and was originally planned to be operational by
January 1994.
Since the beginning of April, EuropaNET is capable of exchanging
routing information with its peers on the basis of the new version
of the Border-Gateway-Protocol (BGP-4). Version 3 of the protocol
does not support Classless Interdomain Routing (CIDR), which offers
routers the possibility to aggregate routing entries. As routing
tables in the Internet were becoming too big to be handled within a
Cooper [Page 12]
Internet Monthly Report April 1994
router, there was an urgent need to migrate to BGP-4.
* CALL FOR TENDER MailFLOW *
An open Call for Tender for the provision MHS-Coordination,
MailFLOW, has been issued by DANTE. MailFLOW is currently provided
on behalf of DANTE by SWITCH, the Swiss research network. The
purpose of the tender is twofold: on the one hand to give other
providers a chance to step forward and on the other hand to
introduce a competitive element in the Service provision.
Tender requirements are available from the DANTE gopher server, in
the MailFLOW directory (under Applications Services). The deadline
for submitting proposals is 30 June 1994.
* HIGH SPEED PROGRESS *
As reported in the previous "Works", in January DANTE secured
approval in principle from the EuroCAIRN (European Co-operation for
Academic and Industrial Research Networking, a EUREKA Project)
Project Board for a proposal to produce a study report, the target
of which is to specify information and requirements necessary to
support funding proposals and the formal procurement of a high-
speed backbone.
EuroCAIRN now has enough financial commitments to pay for the
proposed study report. Preliminary contract negotiations have
already started with the CEC. DANTE is prepared to start work
immediately following the next EuroCAIRN meeting if a contract is
approved.
* DISCUS, NEW NAME FOR A FAMILIAR SERVICE *
Last month CONCISE, the information server set up as part of the
COSINE project, was renamed DISCUS. A new name has been introduced
to mark the beginning of a new period: in 1994 Level-7 will be
providing the service on behalf of DANTE.
The main issue in the Information Services area is to define which
role DANTE should play in offering pan-European information
services which are not yet available from other sources (and which
would be commercially viable). In parallel, the future
possibilities of DISCUS will be addressed.
* DANTE GOPHER INSTALLED *
A first set of information on the company, staff and services is
now electronically available from the DANTE gopher server
Cooper [Page 13]
Internet Monthly Report April 1994
<gopher.dante.net>, see "Information on DANTE and its activities".
An important future aim of the information server is to present on
a regular basis a range of relevant statistics relating to
EuropaNET. DANTE is currently looking into the definition and
production of such statistics.
* EuropaNET POSTER AVAILABLE FROM DANTE *
A full-colour poster of the EuropaNET network is now available and
can be obtained by sending a message to DANTE (dante at dante.org.uk).
__________________________________________________________________
DANTE - Lockton House - Clarendon Road - Cambridge - CB2 2BH - UK
tel +44 223 302992 fax +44 223 303005 e-mail dante at dante.org.uk
__________________________________________________________________
Josefien Bersee <j.bersee at dante.org.uk>
DANTE Publicity Manager
INTERNIC
--------
INFORMATION SERVICES
Contact Information:
Reference Desk Information
Toll-free hotline +1 800 444-4345
email info at internic.net
Fax +1 619 455-4640
InterNIC Suggestions or Complaints
Suggestions suggestions at internic.net
Complaints complaints at internic.net
NICLink Information
info at is.internic.net
NSF Network News
newsletter subscriptions newsletter-request at internic.net
newsletter comments newsletter-comments at internic.net
InterNIC Seminar Series
seminars at internic.net or +1 800 444-4345
Cooper [Page 14]
Internet Monthly Report April 1994
Listserv lists
net-happenings listserv at internic.net
net-resources listserv at is.internic.net
nics listserv at is.internic.net
InfoGuide
Host Name is.internic.net
Host Address 192.153.156.15
Postal address
InterNIC Information Services
General Atomics
P.O. BOX 85608
San Diego, CA 92186-9784
NICLINK
The introductory issue of NICLink has arrived! NICLink is InterNIC
Information Services' multiplatform CD-ROM periodical which
contains information about the Internet, its resources and tools,
and how to use it. NICLink runs on Macintosh, PC DOS and Windows,
and a variety of different UNIX platforms. It also features full-
text search-and-retrieval capability for powerful searches on the
information contained on the disk. An annual subscription offers 4
disks, each with up-to-date information from our online information
server. For more information about NICLink, including ordering
information, send email to info at internic.net or gopher to
is.internic.net under /About InterNIC Information Services.
NSF NETWORK NEWS
The _NSF Network News_ Vol. 1, No. 1 (Mar/Apr 1994) has been
published and is being distributed to over 5,000 subscribers in 44
different countries and the United States. Total distribution
includes members of Internet organizations such as FARNET and the
Internet Society, national, regional and midlevel service
providers, network information centers, and national supercomputer
centers as well as a wide variety of individual subscribers from
the Internet community.
Articles in the Mar/Apr issue include a feature article on the
Global Schoolhouse Project, a news brief on the new NSFNET
architecture rebid results, an update on the Asia-Pacific Network
Information Center, a first peek at InterNIC Information Services'
new InfoGuide, and much, much more. The _NSF Network News_ is also
available on the WorldWideWeb at
http://www.internic.net/newsletter. Be sure to check it out!
Cooper [Page 15]
Internet Monthly Report April 1994
The May/June issue is in preproduction and will feature an
interview with the new Executive Director of the Internet Society,
Tony Rutkowski. This upcoming issue will also include a full-
length article explaining the new NSFNET architecture; a Regional
NIC Report from NorthWestNet on their work with the Internet and
health care; a news brief on current and pending National
Information Infrastructure (NII) legislation; and a feature story
on Maven, a new Internet communications tool. It will also include
permanent features of the _NSF Network News_ such as the InterNIC
Event Calendar and new connectivity maps. If you are interested in
contributing to the _NSF Network News_, please contact the
Publications department at newsletter-comments at internic.net.
The newsletter is available on a subscription basis in ASCII or
hardcopy as well as the WorldWideWeb. To subscribe, send email to
newsletter-request at internic.net. Please include your postal address
if you want hardcopy.
REFERENCE DESK
The following table gives a summary of Reference Desk contacts
for April:
Method Contacts % of Total
------- -------- ---------
Email 85 2.5
Phone 2755 81.9
Fax 119 3.5
US Mail 11 <1
Other 394 11.7
------- -------- ---------
Total 3364 100.0
by Karen D. Frazer <kfrazer at is.internic.net>
DIRECTORY AND DATABASE SERVICES
The Directory and Database Services WorldWideWeb server provides
access to our RFC collection through an HTTP interface. To use
this interface, select "InterNIC Directory and Database Services",
"Internet Documentation", and then "IETF Request for Comment
Documents" from our home page (http://ds.internic.net/).
The index has been broken up into groups of 500 RFCs to make the
individual sections somewhat more managable for those with slow
connections to the Internet. The index entries contain HTTP
pointers to the RFC itself (with a separate pointer to the
PostScript version if any). In the case of RFCs that have been
Cooper [Page 16]
Internet Monthly Report April 1994
made obsolete by a more recent RFC, there is also an HTTP pointer
to the newer RFC.
A recent addition to the public databases available through our WWW
server is a hypertext document providing information about Z39.50
resources. Z39.50 is the official name of the protocol used by
WAIS and other text search systems. The document gives information
on the different versions of Z39.50 that are available and gives
pointers to additional information. To access this document,
select "InterNIC Directory and Database Services", "InterNIC
Database Services (Public Databases)", and "Information about
Z39.50" from our home page.
A reminder - if you would like to help the Internet community find
a resource that you offer, send mail to admin at ds.internic.net and
we will send information about listing your resource in the
Directory of Directories.
by Rick Huber <rvh at ds.internic.net>
REGISTRATION SERVICES
Significant Events
---------------------
InterNIC Registration Services assigned over 10,264 network
addresses and registered 1,376 new top and second level domains.
Top-level domains for Bahrain (BH), Moldova (MD) and Zambia (ZM)
were registered this month. One (1) class A address and A block of
sixteen class B addresses were reserved for and issued to the IANA
in response to a request for network address space in support of
RFC1597 - "Address Allocation for Private Internets".
I. Registration Statistics
March April
Hostmaster Email 4,695 3,520
Postal/Fax Applications 295 264
Telephone Calls 2,622 1,962
Domain Registered 1,376 1,079
Inverse Addresses 739 471
Class C's Assigned 10,180 5,832
Class B's Assigned 84 56
ASN Assigned 56 56
Cooper [Page 17]
Internet Monthly Report April 1994
March April
Connections Retrievals Connections Retrievals
Gopher Sessions 60,840 24,893 57,405 24,393
Wais Sessions 26,505 42,759 23,871 31,779
Ftp Sessions 8,527 38,026 7,885 33,698
Telnet 58,767 55,167
Mailserver 1,325 1,240
Whois Queries Client Server
200,822 816,535
Scott Williamson <scottw at internic.net>
ISI
---
Netstation
----------
The objective of the Netstation project is to demonstrate that both
I/O and peripheral device control can be effectively accomplished
by substituting a gigabit LAN for the system bus. To that end we
shall bitmap display and camera, and control them via remote
procedure calls (RPCs).
High Performance RPC
Because a network dedicated device has direct access to its own
network output buffer memory, it can create a stencil of the
packets that it sends within that memory and be assured that this
stencil will not overwritten.
The task of sending successive RPC messages for the display process
consists of changing only those locations in the stencil that are
altered from call to call. These are:
(1) Destination addresses, in LAN and IP headers
(2) Source and destination UDP ports in the UDP header
(3) Packet lengths, in LAN and IP headers
(4) Checksums, in LAN and IP header
(5) Procedure and program indexes, in the RPC header
and finally,
(6) Supply procedure arguments at the end of the stencil
We showed at the end of March that the techniques developed for
high- performance RPC based upon this technique produced a level of
performance at least ten times greater that that offered by the
standard UNIX stack in a SPARCstation-10.
Cooper [Page 18]
Internet Monthly Report April 1994
We expect that performance obtained in the specialized display and
camera devices that we are building will perform at least as well,
and probably, substantially better.
A question arises. At what level does the interface to a 'remote'
display belong? This project postulates that the coming advances
in VLSI, when combined with gigabit LAN performance, allow that
interface to be made very low. We are replacing the system bus
with a gigabit network. Thus we should interface to the display
much lower than the level used in the X-windows interface.
An approach which is being considered seriously is to rewrite the
device dependent portion of the X-windows server code. In
particular, to rewrite the Pixblit code, so that its rasterop
procedure calls are transformed into RPCs that are sent across the
ATOMIC network to the display device for execution.
In this approach, no windowing system assumed by the network
display device whatsoever. The display is only required to
implement a battery of RPCs. The virtual interface presented to
the network will initially be a very simple one.
Subsequent to this, experimentation with multiple JPEG streams will
occur. JPEG data may not use an RPC model for data delivery. This
remains to be determined.
At a later stage it will be necessary to implement security and
access restrictions to the display device.
Display Network Virtual Device
Bruce Parham, an EE formerly with Jet Propulsion Laboratory, was
hired to design the display and camera network virtual devices.
The broad design outlines are to develop a display that allows two
JPEG streams plus device and raster graphics commands to arrive
over an ATOMIC gigabit LAN port. The display should be capable of
rendering two NTSC video windows in real-time. To achieve this the
display will include a LANai gigabit network interface, a graphics
DSP, and JPEG chips.
The design of a 1280x1024 24-bit color CRT display is held hostage
by the pixel rate. Modern computer CRT displays are progressively
scanned. Human factors engineering decrees that refresh rate must
be at least 60 frame/sec. Currently, a rate somewhat higher, in
the low 70s, is favored to eliminate all trace of image flicker. A
rate of 72 frame/sec results in a pixel rate of approximately 90
Mpels/sec, or 11 ns/pel.
Cooper [Page 19]
Internet Monthly Report April 1994
The principal design problem is therefore one of memory
organization. If it is desired to allow the frame buffer to be
updated by real-time video sources, the frame buffer memory
bandwidth must approximate twice that required by refresh. An
analysis of available memory parts and organizations is underway to
determine what the most cost effective current engineering solution
to this is.
Previously, a good choice for the video DSP would have been the TMS
32040 from Texas Instruments, which contained a video/VRAM refresh
controller and a graphics-oriented CPU. Unfortunately, within the
last month it has been withdrawn from support.
Its replacement is the TMS320C8x. This is a multi-DSP 2 GOPs
processing chip that is designed to carry out JPEG or MPEG-II
decode in real-time. At $1500/part and not yet truly available, it
is tantalizing, but inappropriate. This is primarily because it
does not come with publicly available JPEG/MPEG. The programming
resources required to embed those algorithms is outside the current
scope of the NAAAN contract.
This is an issue that deserves some consideration at a higher
level. If this is indeed a appropriately powerful, fixing on a
standard DSP/video chip, and making publicly available a standard
suite of JPEG/MPEG software for it, could speed the spread of HDS
hardware development and so its applications.
We have decided to replace the TMS 34020 with two chips: A TMS
320C40 (which is a similarly numbered chip - but quite different
internally) and a graphics controller chip that is yet to be
determined. The 320C40 is a super-scalar DSP with dual-bus
support. It promises to be endlessly fascinating to program, that
is, if we can ever figure out why we need to use parallel
multiply/add/index instructions.
Seriously though, its dual-bus support provides a Harvard
architecture, allowing dedication of one bus to data transfer.
That bus will be used largely to transfer network packets in/out of
320C40 memory, provide compressed JPEG input to the CL560 chip
FIFOs, and to perform frame-buffer rasterop update.
Details of the display design will be made available in subsequent
reports.
Greg Finn <finn at isi.edu>
Cooper [Page 20]
Internet Monthly Report April 1994
Infrastructure
--------------
Joyce Reynolds was the opening Keynote speaker at UCTLIG '94 at the
University of Aberdeen, King's College, Aberdeen, Scotland
presentation topic "Internetworking in the United States: Past,
Present, and Future Endeavors". Joyce Rynolds was the invited
speaker at the University of Newcastle upon Tyne, Newcastle,
England, presenting talk on "Internetworking in the United States:
Past, Present, and Future Endeavors". Joe Touch attended Interop
94 for "Telecommuting BOF" Greenbelt, MD - NASA conference to
present research paper. Joyce Reynolds attended the IESG meetings
in Reston,VAm April 24-27.
Jon Postel, Walt Prue and Joe Touch attended the Networld Interop,
May 3-6, 1994 in Las Vegas. Greg Finn presented paper at
Interop'94, in Las Vegas, NV, May 3-6, 1994.
Three RFCs were published this month.
RFC 1605: Shakespeare, W., "SONET to Sonnet Translation",
Globe Communications, April 1994.
RFC 1606: Onions, J., "A Historical Perspective on the Usage
of IP Version 9", Nexor Ltd., April 1994.
RFC 1607: Cerf, V., "A View from the 21st Century", Internet
Society, April 1994.
US DOMAIN ADMINISTRATIVE INFORMATION
------------------------------------
EMAIL/FAX 387
PHONE 52
----------------------------
Total Contacts 439
DELEGATIONS 38
DIRECT REGISTRATIONS: 34
OTHER US DOMAIN MSGS: 367
---------------------------
Total 439
OTHER US DOMAIN MESSAGES INCLUDE: modifications, application
requests, discussion and clarification of the requests, questions
about names, referrals to other subdomains or to/from the InterNic,
resolving technical problems with zone files and name servers, and
Cooper [Page 21]
Internet Monthly Report April 1994
whois listings.
Third Level US Domain Delegations this month
--------------------------------------------
CC.AZ.US Arizona Community Colleges
SIERRA-VISTA.AZ.US Sierra Vista, Arizona, locality
STATE.CO.US Colorado, State Gov't Agencies
MUS.CO.US Colorado musuems
GEN.CO.US Colorado general branch
LONGMONT.CO.US Longmont, Colorado, locality
MORRISON.CO.US Morrison, Colorado, locality
BRECKENRIDGE.CO.US Breckenridge, Colorado, locality
MUS.FL.US Florida Museums
GEN.FL.US Florida, General branch
FT.WAYNE.IN.US Ft. Wayne, Indiana, city gov't agencies
K12.ME.US Maine K12 Schools
TEC.MN.US Minnesota State Gov't
TEC.ND.US North Dakoa Technical schools
CC.ND.US North Dakoa Community Colleges
MUS.ND.US North Dakoa Museums
GEN.ND.US North Dakoa General Branch
LIB.ND.US North Dakota Libraries
CC.NY.US New York Community Colleges
STATE.SD.US South Dakota State Gov't
WESTERVILLE.OH.US Westerville, Ohio
ROGERS.OH.US Rogers, Ohio, locality
LAWEWOOD, OH Lakewood, Ohio, Locality
CLV.PROB.FED.US. US probation Office, Cleveland
OTAN.DNI.US Outreach & Technical Assistance Network
Other US Domain Delegations this month
--------------------------------------
CI.SLC.UT.US Salt Lake City, City Gov't Agencies
CO.VENTURA.CA.US Ventura CA, County Gov't Agenciies
CO.SANTA-CLARA.CA.US Santa Clara, County Gov't Agencies
HIGHWAY.SLC.UT.US Utah Information Highway Co., SLC
DODGE-CITY.CC.KS.US Dodge City Community College, Kansas
CAMBRIDGE.LIB.MA.US Cambridge Public Library
CPS.K12.TN.US Chattanooga Public Schools
VANNET.K12.WA.US Vancouver School District, Vancouver, WA
GUPPY.MORRISTON.NY.US Nathaniel Borrenstein, Morriston, NY
MEDNET.BURLINGTON.VT.US Medical Center Hospital of Vermont
TNET.STATE.TN.US State of TN Office of Information Resources
DELO.NYC.NY.US. Select Technology, INC.
WATER.CI.DETROIN.MI.US Detroit Water and Sewerage Dept.
Cooper [Page 22]
Internet Monthly Report April 1994
TABLE OF DELEGATED DOMAINS BY STATE
K12 CC TEC STATE LIB MUS GEN
-----------------------------------------------------------
AK
AL X
AR X
AZ X X X X X X
-----------------------------------------------------------
CA X X X X
CO X X X X X X X
CT
DC X
-----------------------------------------------------------
DE X
FL X X X X X
GA X X X X
HI
-----------------------------------------------------------
IA X X X X
ID X X X X X X X
IL X X X X
IN X X X X
-----------------------------------------------------------
KS X
KY X X X X X X X
LA X X X X X
MA
-----------------------------------------------------------
ME X X
MI X X X X X
MN X X X X X X X
MO X X X X X
-----------------------------------------------------------
MS X X
MT X
NC X X X X X
ND X X X X X X X
-----------------------------------------------------------
NE X X X X
NH X X
NJ X
NM X X X
-----------------------------------------------------------
NV
NY X X X X
OH X X X X X X X
OK
Cooper [Page 23]
Internet Monthly Report April 1994
K12 CC TEC STATE LIB MUS GEN
-----------------------------------------------------------
OR X X X X X X X
PA X
RI X X X
SC X X X X X
-----------------------------------------------------------
SD X X
TN
TX X X X X
UT X X X X
-----------------------------------------------------------
VA X X X X
VI
VT X X
WA
-----------------------------------------------------------
WI X X X
WV X X X X X X X
WY X
===========================================================
For more information about the US Domain please request an
application via the RFC-INFO service. Send a message to RFC-
INFO at ISI.EDU with the contents "Help: us_domain_application". For
example:
To: RFC-INFO at ISI.EDU
Subject: US Domain Application
help: us_domain_application
Ann Westine Cooper (Cooper at ISI.EDU)
MERIT/MICHNET
-------------
New MichNet affiliates include Lake Superior State University,
Adrian College, Lansing Community College, Macomb Community
College, West Shore Community College, Northland Library
Cooperative, Library Cooperative of Macomb, Caledonia Community
Schools, the Lenawee Intermediate School District, Wayne County
RESA, the Michigan Department of State, Detroit Water and Sewerage
Department, the Observer & Eccentric Newspapers, the National Board
for Professional Teaching Standards and MERRA. MichNet affiliate
organizations now number 85, in addition to the 11 member
universities.
Cooper [Page 24]
Internet Monthly Report April 1994
Merit Network's MichNet Seminar, enthusiastically received by
member and affiliate organizations at its introduction in Ann Arbor
in late February, will be offered on the campus of Central Michigan
University in Mt. Pleasant on 19 May. Designed primarily with new
affiliate needs in mind, topics include an overview of the
Internet; MichNet and Merit Services; Merit's Cruise of the
Internet; and Internet tools, including FTP, Gopher and WWW.
Merit held a series of Internet Briefings and Open Houses for
Michigan's K-12 communities in March and April. The eight, day-
long Internet Briefings hosted throughout the state by MichNet
member and affiliate institutions, were planned to familiarize
teachers and administrators with the benefits of direct Internet
access and to provide details on new funding opportunities. With
the settlement of the "Michigan Bell Rebate Case," more than $26
million is available for educational telecommunications projects.
The governor-appointed Michigan Council on Telecommunications
Services for Public Education issued a "Request for Pre-Proposal,"
inviting proposals for allocating approximately $9 million of the
total funds, and encouraging collaborative efforts between groups
of organizations. Merit's increased K-12 outreach initiatives were
designed to help schools respond to the "Request for Pre-Proposal,"
enhancing the opportunity to expand programs already developed in
partnership with the Michigan schools.
Merit is working with the Society of Manufacturing Engineers (SME)
on the Cooperative Network for Dual Use Information Technologies
(CoNDUIT) project. Funded by a $24.3 million Technology
Reinvestment Program grant, the new program aims to provide small
manufacturing businesses with training using network
infrastructure. CoNDUIT will develop a network that will allow
full implementation of teleconferencing, remote library access, and
daily communication among business and educational facilities. A
central resource for the network will be an Industry NIC (I-NIC),
providing business with human and online support systems for
understanding and using network technologies. Multi-media training
will be a significant I-NIC offering. Merit is also participating
in the Michigan Industrial Extension Partnership, a 1993 TRP award
made to Michigan State University to provide network services to
industrial extension agents in the state.
Jo Ann Ward (jaw at merit.edu)
Merit Network, Inc. Information Services
Cooper [Page 25]
Internet Monthly Report April 1994
MERIT/NSFNET ENGINEERING
------------------------
The report summarizes recent activities of Merit's NSFNET Project
Internet Engineering and Network Management groups.
Routing Registry
----------------
Merit is happy to announce the Merit Routing Registry. Whereas
Merit designed and manages the PRDB (Policy Routing Data Base) for
the NSFNET service, RIPE pioneered a policy routing registry for
the European community. The RIPE Routing Registry is based on the
document, RIPE-81. With RIPE's collaboration, Merit installed
RIPE-81 software and then extended the policy descriptions in order
to realize more complex policies. The Merit Routing Registry will
be a companion registry to the RIPE Routing Registry and is
intended to serve the community that is not served by RIPE.
This is a new service and we consider ourselves still in the beta
phase. Registrations may be basic policy descriptions defined in
RIPE-81 or complex routing policy descriptions defined in the
Extended Policy Syntax document by Chen, Gerich, Joncheray, and Yu.
The Extended Policy Syntax document may be found on
rrdb.merit.edu:pub/meritrr/policy_syntax.txt. Documentation for
using the MeritRR can be found on rrdb.merit.edu:pub/meritrr.
Merit and RIPE anticipate that the combined registries will provide
a more comprehensive picture of the routing interactions in the
Internet. We are working together to allow the two registries to
appear like one virtual registry to the various tools that are
developed. We welcome your comments on all aspects of this
project. For more information, please respond to
rradmin at rrdb.merit.edu.
Several new tools are also available for anonymous ftp from
rrdb.merit.edu:/pub/meritrr and include:
-astrace.tar.Z: The new prtraceroute to use with the NARR registry
-aggrwalk.tar.Z: A tool to expand aggregates into sub components
-alc.tar.Z: The Routing Policy Server code
Policy Routing Data Base
------------------------
Several enhancements have been made to the Policy Routing Data Base
(PRDB). These include:
Cooper [Page 26]
Internet Monthly Report April 1994
- "Fake ASs" are no longer required for peers which need attach to
AS690 in more than one place. A new syntax "metric:AS(NSS)" has
been created to support this, for use in the PRDB AS-metric
lists. All PRDB reports (including whois and ftpable reports)
will soon include this syntax; it will soon be accepted on
NACRs as well.
- A new "NOCONFIG" option has been added. This option allows nets
to be registered in the PRDB without passing knowledge of those
specific nets on to the Gated config files and the backbone
routers. The initial use of this feature has been to suppress
the configuration of more-specific-subnets of announced
aggregates.
- The "whois -h prdb.merit.edu 'aggchk <aggregate>'" command has
been modified to include information about whether the
aggregates and their more-specific subnets are being announced.
Flags in the left of the report mark currently-announced nets
with "+", never-announced nets with " ", and nets that have been
withdrawn N days ago with a the number N. Nets which have had
the "NOCONFIGURE" option are marked with the flag "U"; Proxy
nets are marked with "P".
- Two new temporary reports are available on
merit.edu:pub/nsfnet/cidr. "nestings.announced" lists all
aggregates registered in the PRDB, along with their more-
specific-subnets and their offnet status (see above).
"cidr_savings" gives a summary of the same information by
aggregate.
- Proxy aggregation at a single ENSS is currently supported in the
PRDB; final testing of the feature is awaiting deployment of
GateD Proxy code.
- A new "flags" field has been added to the output of "whois -h
prdb.merit.edu <net>". This "flags" field shows the status of
the "NOCONFIG" and "Proxy" flags, and will hold future flag
values.
CIDR Progress
-------------
IE staff are working with the remaining non-CIDR compatible NSFNET
regional networks to upgrade to BGP4, to begin announcing CIDR
aggregates, and to withdraw specific routes covered by those
aggregates. The approximately 18,450 routes currently announced
include 276 aggregates and 3,275 more specific routes have been
withdrawn from routing announcement. Merit's offnet reports
Cooper [Page 27]
Internet Monthly Report April 1994
provide a historical data series that since April includes the
impact of specific network announcement withdrawals. The data is
available for anonymous ftp from merit.edu:~ftp/pub/nsfnet/offnet/
with postscript files of the charted data have names in the format:
Month1.ps, Month2.ps, and two files with cumulative table data
named "r_tab" and "path."
IDRP Project
------------
Continued development and testing have followed release of version
1.0 of the IDRP software. Merit's Inter-Domain Routing Policy
Project for the US-FAA is an implementation of OSI-IDRP for gated.
A generic PATRICIA trie implementation supports multiple
independent tries of several critical data structures including
RDIs.
The software is available for anonymous ftp from:
merit.edu:pub/iso/idrp/faa/gated-idrp.0.9.6.tar.Z
K-12 Domain Count
-----------------
An analysis was performed for NSF on the number of K-12 names in
the US domain. The listing of was prepared by walking the US DNS
tree and is available for anonymous ftp from
twain.merit.edu:pub/k12.uniq.Z
Kenneth T. Latta, II (klatta at merit.edu)
NEARNET
-------
NEARNET'S MEMBERSHIP EXPANDS
As of April 30, 1994, NEARNET has grown to a total of 313 member
organizations.
NEARNET would like to welcome the following new members who have
joined NEARNET during the month of April:
Southeast Regional Education Service Center (SERESC) of Derry, NH
EMC Corporation of Hopkinton, MA
Bay State Medical Center of Springfield, MA
NERAC, Inc. of Tolland, CT
Steinbrecher Associates of Burlington, MA
Aavid Engineering of Laconia, NH
Security Dynamics of Cambridge, MA
Cooper [Page 28]
Internet Monthly Report April 1994
NEARNET 1994 MINI-SEMINARS UPDATE
"A Mini-Seminar Focuses on NEARNET Security Services"
A second NEARNET Mini-Seminar entitled "An Introduction to NEARNET
Security Services" was held on April 13, 1994 also in BBN's Newman
Auditorium.
Focusing on Internet security issues, this seminar included an
overview of NEARNET's improved security services, including the
design of security packet filters and firewalls. Also included was
an update on Kerberos and Privacy Enhanced Mail (PEM) by Jeffrey
Schiller of MIT, and an overview of the Computer Emergency Response
Team (CERT) by Ed DeHart, Technical Coordinator at CERT.
"Business and the Internet on May 25"
The third NEARNET Mini-Seminar for 1994, entitled "Business and the
Internet" will be held on May 25, 1994 from 9:00 AM to 12:30 PM at
BBN's Newman Auditorium, 70 Fawcett Street, Cambridge, MA.
This seminar will address how and why organizations are
increasingly using the Internet to offer business services. It
will be presented in a panel format and will include the following
presenters: John Curran, NEARNET product manager; Daniel Dern,
Internet analyst and author of "The Internet Guide for New Users";
Laura Fillmore, president of Editorial Inc. and the Online
Bookstore, Michael Strangelove, editor of the "Internet Business
Journal", and author of the soon-to-be published book, "How to
Advertise on the Internet".
NEARNET members who wish to attend any of the NEARNET Mini-Seminars
should send mail to: nearnet-seminars at near.net. Additional
information on future mini-seminars for 1994 will be announced
shortly.
NEARNET TRAINING PROGRAM UPDATE
The Spring set of NEARNET Training Courses is scheduled for May 11,
12 and 13 from 9:00 a.m. to 4:00 p.m. at the BBN Newman Auditorium.
The three full-day set of courses include: (Day 1) An Introduction
to Resources on the Internet; (Day 2) An Orientation for New
NEARNET Liaisons; and (Day 3) An Introduction to Internet
Technology.
All three days of training are available free of charge to new
Standard Installation sites. The Internet Resources and Internet
Cooper [Page 29]
Internet Monthly Report April 1994
Technology courses are available for existing sites and non-members
for a $250.00 fee (per day/per attendee). The NEARNET Orientation
is free to all NEARNET sites.
For more information, please contact the NEARNET Client Services
Staff at nearnet-us at near.net or call 617-873-8730.
NEARNET COSPONSORS INTERNET SEMINAR FOR EDUCATORS
NEARNET and Cisco Systems, Inc. cosponsored a one-day seminar
organized by Editorial Inc. and the Online BookStore (OBS). The
seminar, entitled "An Educator's Introduction and Guide to the
Internet:Catching the Internet Wave," was held April 7, 1994 at
BBN's Newman Auditorium in Cambridge, MA.
Seminar leaders included Laura Fillmore, President of Editorial
Inc. and OBS in Rockport, MA. Tracy LaQuey Parker, author of the
bestselling book "The Internet Companion: A Beginner's Guide to
Global Networking" and Education Development Manager at Cisco
Systems, Inc.; and Daniel Fleming, a high school and middle school
principal in Rockport and an avid proponent of the use of
technology in schools.
Also participating in the seminar were Juliette Avots, a teacher at
Wellesley High School in Wellesley, MA; James Warner, Manager of
Prospect Innovation Network; and Martin Huntley of the Educational
Technologies Department at Bolt Beranek and Newman Inc. The
closing remarks were delivered by Dr. Richard Rowe of the
Massachusetts' State Board of Education, who also leads the State
Task Force on Education Reform.
Each of the seminar participants received a complimentary copy of
"The Internet Companion" as part of the seminar proceedings.
NEARNET members can borrow videotapes of the seminar by sending an
email request to nearnet-us at near.net. NEARNET also maintains an
interest-group mailing list for K-12 activities. To be added to
the nearnet-k12 at near.net list, send a message to nearnet-
us at near.net.
NEARNET USER SERVICES STEERING COMMITTEE UPDATE
The NEARNET User Services Steering Committee (USSC) provides
guidance to NEARNET's User Services staff. The USSC also advises
the NEARNET Steering Committee on user-service related areas,
including: policy, information services, packages, training and
seminars. The USSC is made up of 20 people from NEARNET member
organizations. The fourth USSC meeting was held on April 25. The
next meeting will be held on June 13.
Cooper [Page 30]
Internet Monthly Report April 1994
The April USSC meeting focused on the continued improvement of
NEARNET online information services.
by NEARNET Client Services <nearnet-us at nic.near.net>
NORTHWESTNET
------------
In mid-April, the User Services group provided three Internet
classes for 8 staff members from the King County Library System.
They will take the information they have learned in these classes
and apply it to the development of Internet services within their
organization. The King County Library System serves over 40 sites
in the Puget Sound region.
This was also a busy month for the User Services Committee. On
April 21, Jan Eveleth (director of User Services at NorthWestNet)
moderated the monthly teleconference discussion, "Exploring Legal
Issues on the Internet." As always, this topic produced spirited
discussion. The following week, regional committee meetings were
held at the Oregon Historical Society in Portland, Oregon and at
The Evergreen State College in Olympia, Washington. The discussion
topic, "Coping with Diversity," and agenda were duplicated at each
meeting. Participants highlighted many areas in which diversity
affects their work in supporting the Internet. Where diversity has
created challenges, the group shared their ideas and experiences.
Upcoming:
The NorthWestNet training facility will open its doors for the
first in a series of scheduled Internet classes in May and June.
These for-fee classes are open to the public as well as
NorthWestNet member organizations. Each three hour class will
combine lecture, demonstration, and hands-on lessons exploring the
Internet and accessing online resources and services. Subjects
include introduction to the Internet, electronic mail, FTP, Telnet,
and Gopher. For more information, send mail to training at nwnet.net
or call our offices at (206) 562-3000.
On May 17th, NorthWestNet is cosponsoring with Cisco Systems and
the Northwest Regional Education Laboratory a one-day seminar on
K-12 and the Internet. This seminar will be held at the Oregon
Center for Advanced Technology Education in Beaverton, Oregon. For
more information, contact our offices at (206) 562-3000.
NorthWestNet E-mail: info at nwnet.net
15400 SE 30th Place, Suite 202 Phone: (206) 562-3000
Bellevue, WA 98007 Fax: (206) 562-4822
Cooper [Page 31]
Internet Monthly Report April 1994
Dr. Eric S. Hood, Executive Director
Jan Eveleth, Director of User Services
Dan L. Jordt, Director of Technical Services
Anthony Naughtin, Director of Member Relations
NorthWestNet serves the six state region of Alaska, Idaho, Montana,
North Dakota, Oregon, and Washington.
UCL
----
Replacement of the (10-30% lossy) Ethernet at ULCC by a Hub means
that our International Internet Access is radically improved,
especially for Mbone events.
We helped Cambridge University to setup the mbone casting of their
weekly saeminar series.
Crowcroft proposed a modest modification to IP to meet the current
IPng requirements, called I PING, that permits mutual use of
routers by IP and IPng. It was proposed as a trivial strawman to
measure and burn other proposals against, rather than a serious
candidate.
UCL Hosted the SIGCOMM 94 Program Committee meeting, whose
deliberations will be forthcoming around now.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
Cooper [Page 32]
Internet Monthly Report April 1994
CALENDAR
--------
Last update: 4/20/94
The information below has been submitted to the IETF Secretariat
as a means of notifying readers of future events. Readers are
requested to send in dates of events that are appropriate for this
calendar section. Please send submissions, corrections, etc., to:
<meeting-planning at cnri.reston.va.us>
1994
------------
Apr. 18-20 European Exhb. HP Comp/Ntwk Munich, Germany
Apr. 18-22 IEEE POSIX
Apr. 18-22 '94 TCP/IP Windows Sockets
and PPP Bake-Off
Apr. 23-24 DIAC-94 Developing an Equitable
and Open Info. Infrastructure Cambridge, MA
Apr. 25-29 Africa Telecom 94 Forum Cairo, Egypt
May 2-6 NetWorld+Interop Las Vegas, NV
May 4-6 IFIP '94 Hamburg, Germany
May 9-12 IEEE P802.11 Interim Oshawa, Ontario
May 9-13 X3T5-OSI Upper Layers Rockville, MD
May 10-13 ATM Forum Munich, Germany
May 16-18 RIPE Amsterdam, NL
May 19-20 RARE Council of Admn. Darmstadt
May 30-31 IFIP WG 6.5 Tutorials Barcelona, Spain
Jun. 1-3 IFIP WG 6.5 Conference Barcelona, Spain
Jun. 6-8 Digital World Los Angeles, CA
Jun. 8-10 Seybold Paris
Jun. 6-10 USENIX Hynes CC, Boston, MA
Jun. 6-10 NetWorld+Interop Berlin
Jun. 12 RARE Technical Committee Prague
Jun. 13-17 INET94/JENC Prague
Jun. 13-17 OIW
Jun. 20-Jul. 1 ISO/IEC JTC1/SC6 Helsinki
Jun. 27-Jul. 1 High Performance Ntwg-HPN '94 Grenoble, France
Jun. 27-Jul. 1 Home-oriented informatics Copenhagen, Denmark
Jul. 6-7 X3T5 Gaithersburg, MD
Jul. 11-15 8th ACM Intntl Supercomputing Manchester, England
Jul. 11-15 IEEE P802.11 Plenary Orlando, FL
Jul. 13-14 Intntl W/S Community Networking
Integrated Multimedia Svs. Santa Clara, CA
Cooper [Page 33]
Internet Monthly Report April 1994
Jul. 25-29 30th IETF Toronto, Canada
Jul. 25-29 Sigraph 94 Orlando, FL
Jul. 25-29 NetWorld+Interop Tokyo, JP
Aug. (mid) SNOWMASS
Aug. 1-2 USENIX Berkeley, CA
Aug. 7-12 SHARE (IBM) Boston, MA
Aug. 10-12 IFIP Protocols Vancouver, BC
Aug. 22-26 6th Joint EPS-APS Phyicics Lugano, Switzerland
Aug. 28-Sep 2 IFIP World Congress Hamburg, Germany
Aug. 29-Sep 2 SIGCOMM 94 London, England
Sep. IEEE P802.11 Interim TBD
Sep. 7-9 Windows Solutions San Francisco, CA.
Sep. 12-16 NetWorld+Interop Atlanta, GA
Sep. 12-16 OIW
Sep. 13-16 Seybold San Francisco, CA
Sep. 14-16 4th Int'l CCHP Vienna, Austria
Sep. 26-28 2nd IWACA Heidelberg, Germany
Oct. 2-5 IEEE Leading Edge Comp. Ntwg Minneapolis, MN
Oct. 6-8 Parallel & Dist. Compt. Sys Las Vegas, NV
Oct. 15-20 ACM Conference on Multimedia San Francisco, CA
Oct. 16-20 ACM SIGUCCS
Oct. 24-28 NetWorld+Interop '94 Paris, France
October/November Windows Solutions Germany
Oct. 31-Nov. 1 1st Intntl ACM/SIGCAPH Conf.
Assistive Technolgies (ASSETS) Marina del Rey, CA
Oct. 31-Nov. 3 EDUCOM
Nov. 2-4 Gigabit testbed jamboree Reston, VA
Nov. 7-11 IEEE P802.11 Plenary Incline Village, NV
Nov. 11-14 ICCCN '94 San Francisco, CA
Nov. 14-15 CEC Cist 237 M-media Vienna, Austria
Nov. 14-18 Supercomputing '94 Washington, DC
Nov. 14-18 USENIX/ACM SIGOPS Monterey, CA
Nov. 28-30 Ntwk. Svs. Conf. (NSC'94) London, UK
Nov. 28-Dec. 2 Email World Boston, MA
Nov. 29-Dec. 2 ATM Forum Kyoto, Japan
Nov. 29-Dec. 2 Cause
Dec. 5-7 Australian Telecom Networks and
Applications Conf. ATNAC 94 Melbourne, AU
Dec. 5-9 31st IETF (Definite) San Jose, CA
Dec. 5-9 ANSI X3T11
Dec. 5-9 10th Comp. Sec. Applications Orlando, FL
Dec. 7-9 Windows Solutions Tokyo, JP
Dec. 7-9 IEEE R/T Systems Symposium San Juan, Puerto Rico
Dec. 12-16 OIW
Cooper [Page 34]
Internet Monthly Report April 1994
1995
---------
Jan. 16-20 USENIX New Orleans, LA
Feb. 16-17 PSRG - ISOC Symposium
Feb. 20-24 UniForum Dallas CC, Dallas, TX
Feb. 26-Mar. 3 SHARE (IBM) Los Angeles, CA
Mar. 6-10 IEEE 802 Plenary (Tentative)
Mar. 13-17 OIW
Mar. 13-17 Email World (Probable) Santa Clara, CA
Mar. 13-24 ISO/IEC JTC1/SC6 Tokyo, JP
Mar. 20-24 32nd IETF (Tentative)
Mar. 27-31 Email World Chicago, IL
(likely to be replaced by Mar 13-17 dates)
Mar. 27-31 NetWorld+Interop Las Vegas, NV
April 19-21 5th Network & Operating System
Support (NOSSADV) Workshop Boston, MA
May 15-19 Joint European Ntwkg Conf. Tel Aviv, Israel
May 18-19 RARE Council of Admin. Tel Aviv, Israel
Jun. ISOC Wkshop for Tech.
Emerging Countries
Jun. 12-16 INET '95 (tentative) Singapore
Jun. 12-16 OIW
Jun. 19-22 USENIX San Francisco, CA
Jun. INET95
Jul. 4 Independence Day
Jul. 10-14 IEEE 802 Plenary (Tentative)
JULY 14 BASTILLE DAY
Jul. 17-21 33rd IETF (Tentative) Sweden
Jul. 31 - Aug. 4 33rd IETF (Tentative) Sweden
Sep. 11-15 OIW
Oct. 3-11 Telecom '95 Geneva, Switzerland
Oct. 9-13 Email World San Jose, CA
(likely to be replaced by Nov. 27-Dec. 1 dates)
Nov. 6-10 IEEE 802 Plenary (Tentative)
Nov. 13-17 34th IETF (Tentative)
Nov. 27-Dec. 1 Email World (Probable) Boston, MA
Dec. 4-8 OIW
Dec. 4-8 34th IETF (Tentative)
Dec. 4-8 ANSI X3T11 (Possible)
Dec. 4-8 Supercomputing '95 (Possible)
Cooper [Page 35]
Internet Monthly Report April 1994
1996
-----------
Mar. 11-14 UniForum San Francisco, CA
Mar. 18-22 OIW
Jun. 10-14 OIW
Sep. 2-6 14th IFIP Conf. Canberra, AU
Sep. 9-13 OIW
Dec. 9-13 OIW
1997
-----------
Mar. 10-13 UniForum San Francisco, CA
----
Via ftp: /ietf/1events.calendar.imr.txt on ietf shadow directories
Via gopher: "Internet Society / IETF / IETF Meetings /
Scheduling Calendar" on ietf.cnri.reston.va.us
=====================================================================
RARE LIST OF MEETINGS
may 94 edition
---------------------
Ref. RSec(94)001-ac
This list of meetings is provided for information. Many of the
meetings are closed or by invitation; if in doubt, please contact the
chair of the meeting or the RARE Secretariat. If you have
additions/corrections/comments, please mail Anne Cozanet (e.mail
address: cozanet at rare.nl).
**********************************************************************
MEETING/DATE LOCATION
============ ========
RARE Executive Committee
------------------------
17 June afternoon
(Joint meeting with EARN-EXEC) Prague
30 June Amsterdam (RARE Secretariat)
1 September Amsterdam (RARE Secretariat)
2 September
(Joint meeting with EARN-EXEC) Amsterdam (RARE Secretariat)
Cooper [Page 36]
Internet Monthly Report April 1994
RARE Council of Administration
------------------------------
19/20 May 1994 Darmstadt
(19 May joint with EARN BOD)
27/28 October 1994 TBC
18/19 May 1995 Tel Aviv
RARE Technical Committee / WG Convenors
---------------------------------------
12 June afternoon Prague
RARE'S INVOLVEMENT IN THE IVth FRAMEWORK - Open Plenary
-------------------------------------------------------
14 June afternoon Prague
RARE Working Groups
-------------------
ATM (closed group)
13 June afternoon Prague
WG-CHAR
14 June morning Prague
WG-IMM
14 June morning Prague
WG-ISUS
13/14 June Prague
WG-LLT
14 June morning Prague
WG-MSG
13 June afternoon Prague
WG-NAP
13 June Prague
WG-NOP
14 June morning Prague
WG-SEC
13 June morning Prague
JOINT WORKING GROUP MEETING
1-2 December London (after NSC'94)
Cooper [Page 37]
Internet Monthly Report April 1994
RIPE
----
16-18 May Amsterdam (NIKHEF)
September (tbc) Lisboa
VARIOUS
-------
EBONE
Consortium of Contributing Organisations
23 June Amsterdam
EBONE Management Committee
16 May Amsterdam (RARE Secretariat)
June (tbc) Prague
EAT (Ebone Action Team) + EOT (Ebone Operations Team)
2-3 May Vienna (ACOnet)
EARN
Board of Directors
18-19 May Darmstadt
(19 May joint with RARE CoA)
30 November - 2 December London
DANTE Shareholders
20 September TBC
Euro-CCIRN
CCIRN
20/21 June Amsterdam
INTERNET SOCIETY Board of Trustees
13/14 June Prague
IETF
25-29 July Toronto
5-9 December San Jose, California
Summer 1995 Stockholm, Sweden
EWOS
----
Technical Assembly
17-18 May Brussels
13-14 September Brussels
Cooper [Page 38]
Internet Monthly Report April 1994
22-23 November Brussels
Steering Committee
7 June Brussels
27 September Brussels
6 December Brussels
Workshops
27 June - 1 July Brussels
10-14 October Brussels
ETSI
----
General Assembly
22/23 November Nice, France
Technical Assembly
18-20 October Nice, France
INET'94/JENC5 Track Leaders
INET'94/JENC5 Conference Committee
9 May telephone meeting
*******************************************************************
INET'94/ 5th Joint European Networking Conference (JENC5)
13 -> 17 June 1994 Prague, Czech Republic
The annual conference of the Internet Society held in conjunction
with the 5th Joint European Networking Conference.
To be added to the conference email distribution list, send a
message to <inet-jenc-request at rare.nl>. For information, email
<inet-jenc-sec at rare.nl>.
*******************************************************************
OTHER CONFERENCES
(nb. For some of the following events, full text information is
available from the RARE Document Store under the directory
calendar, in which case the file name is specified under the
information presented below. The files may be retrieved via:
anonymous FTP: ftp.rare.nl
Email : server at rare.nl
Gopher : gopher.rare.nl)
Cooper [Page 39]
Internet Monthly Report April 1994
MediaActive 94 - "Harnessing Multimedia for Higher Education"
-------------------------------------------------------------
from 4 till 6 May 1994 in Liverpool, England
Email <MedAct94 at livjm.ac.uk>
15TH INTERDISCIPLINARY WORKSHOP ON INFORMATICS AND PSYCHOLOGY
-------------------------------------------------------------
organised by the Computer Science Department of the Johannes
Kepler University Linz, Austria, in cooperation with the
European Association for Cognitive Ergonomics (EACE)
from 24 till 26 May 1994 in Schaerding, Austria
For further information, contact Michel Tauber
<tauber at uni-paderborn.de>.
FIRST INTERNATIONAL CONFERENCE ON THE WORLDWIDE WEB
---------------------------------------------------
The conference will include tutorials, topical workshops,
panels, presentation of formal papers on WWW technology
and theory, user and provider experiences plus a series
of special sessions for delegates from business and non-
academic organisations.
from 25 till 27 May 1994 at CERN, Geneva, Switzerland
For information, email <cailliau at www1.cern.ch>
NORDUnet 94
-----------
from 31 May to 2 June 1994
in Umea, Sweden
for information, email <nordunet94 at umdac.umu.se>
ULPAA'94
--------
from 30 May till 3 June 1994
(tutorials on 30/31 May; conference from 1st till 3rd June)
hosted by Universidat Politecnica de Catalunya, Spain.
IFIP 6.5 International Working Conference on Upper Layer
Protocols, Architectures and Applications.
*CALL FOR PARTICIPATION*
more information by anonymous ftp.ac.upc.es in the
/pub/conferences/ifip6.5 directory.
INTERNET SOCIETY WORKSHOP ON NETWORK TECHNOLOGY
-----------------------------------------------
from 5 till 11 June 1994
at the Czech Technical University in Prague
Email <workshop-apply at nyu.edu>
Cooper [Page 40]
Internet Monthly Report April 1994
ELECTRONIC COMMUNICATION TECHNOLOGY - ECT 94
--------------------------------------------
4th International Russian Forum
organised by the Academy of National Economy of Moscow,
Russia; the International Centre for Scientific and
Technical Information; and the Russian-American JV
"Ecotrends".
from 27 June till 2 July
For further information, contact Juri Gornostaev or Juri Andrianov
Email <enir at ccic.icsti.msk.su>
First INTERNATIONAL CONFERENCE ON DISTANCE EDUCATION in Russia
--------------------------------------------------------------
Distance Learning and New Technologies in Education, and the
exhibition BUILDING AN EDUCATIONAL ENVIRONMENT
organised by the State Committee for Higher Education of the
Russian Federation, Informationa Systems Research Institute of
Russia, Russian Academy of Administration and VIRTUS Institute,
USA.
from 5 till 8 July 1994 in Moscow
*CALL FOR PAPERS*
For further information, email <DE_RUSSIA_1994 at AIE.MSK.SU>.
SECOND INTERNATIONAL SUMMER SCHOOL ON
ADVANCED BROADBAND COMMUNICATIONS
---------------------------------
from 11 till 15 July 1994
as part of the RACE project BRAIN.
the school will be distributed to at least four different
sites in Spain.
for further information, please email <ss94 at dit.upm.es>
8th ACM INTERNATIONAL CONFERENCE ON SUPERCOMPUTING
--------------------------------------------------
from 11 till 15 July 1994 in Manchester, England
Email <jalby at irisa.fr)
6th JOINT EPS-APS INTERNATIONAL CONFERENCE ON PHYSICS COMPUTING
---------------------------------------------------------------
from 22 till 26 August 1994 in Lugano, Switzerland
Email <pc94 at cscs.ch>
13TH WORLD COMPUTER CONGRESS - IFIP CONGRESS 94
-----------------------------------------------
from 28 August till 2 September 1994, in Hamburg, Germany
Tel. +49 40 3569 2242 - Fax. +49 40 3569 2343
Cooper [Page 41]
Internet Monthly Report April 1994
ACM SIGCOMM'94
--------------
Communications Architectures, Protocols and Applications
organised by University College London
from 31 August till 2 September
(Tutorials and Workshops on 30 August)
For further information, contact <J.Crowcroft at cs.ucl.ac.uk>
THIRD INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS
-----------------------------------------------------------------------
(ICCCN'94)
from 11-14 September 1994, San Fransisco, U.S.A.
Conference Chairman: Prof. T. Suda <suda at ics.uci.edu>
OPENNET'94 - German Society of Internet Users (DIGI e.V.)
---------------------------------------------------------
from 8-11 November in Munich
For further information contact the DIGI board
via email: vorstand at digi.de
CEN/CENELEC/ETSI CONFERENCE 1994
--------------------------------
on 15 and 16 November 1994
in the European Parliament, Brussels.
Information from Kristien Van Ingelgem, fax.+32 2 519 6819
NETWORK SERVICES CONFERENCE 94
------------------------------
from 28 to 30 November 1994
in London (UK)
*CALL FOR PAPERS* deadline 1 July 1994.
For further information contact David Sitman
(PC Vice Chairman) via email: A79 at TAUNIVM.bitnet
Paper submissions to: NSC94 at EARNCC.EARN.NET
IS&T/SPIE SYMPOSIUM ON ELECTRONIC IMAGING
-----------------------------------------
from 5 till 11 February 1995
San Jose Convention Center, San Jose, California USA
*CALL FOR PAPERS*
-> Multimedia Computing and Networking 1995
-> Digital Video Compression: Algorithms & Technologies 1995
deadline 11 July 1994
Tel.(206)676 3290 - Fax.(206)647 1445
Cooper [Page 42]
Internet Monthly Report April 1994
EEMA MEETINGS
-------------
Pre-conference Tutorial
& EEMA subcommittees
14 June Stockholm
8th Annual General Assembly
14 June Stockholm
7th Annual EEMA Conference
Global Messaging '94
15-17 June Stockholm
Autumn Conference
September (tbc) Madrid
Winter Conference
November (tbc) Luxembourg
----------------------------------------------------------------------
29/4/94
Cooper [Page 43]
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18655;
12 May 94 21:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18647;
12 May 94 21:22 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa25407;
12 May 94 21:22 EDT
Received: by bitsy.MIT.EDU
id AA11754; Thu, 12 May 94 21:10:05 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA11746; Thu, 12 May 94 21:10:03 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA10557; Thu, 12 May 94 21:09:56 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id SAA06911; Thu, 12 May 1994 18:06:38 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA21204; Thu, 12 May 94 18:00:26 -0700
Date: Thu, 12 May 94 18:00:26 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405130100.AA21204 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: "John Wray, Digital DPE,\
(508) 486-5210 12-May-1994 0911" <wray at tuxedo.enet.dec.com>
Subject: Re: Comment regarding GSS/Kerberos byte ordering
Cc: cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
> Any byte ordering would be OK. It's not a _change_ to
> little-endian; it was always specified that way.
I do not recall seeing a byte-ordering specification before the Draft
Kerberos V GSS RFC. What have I missed?
> From my
> point of view, the main reason this is important is mostly
> because we're already shipping code to customers that
> matches the current spec, so there's an incentive to
> resist any change that doesn't fix a specific problem.
>
Isn't the Kerberos GSS spec a draft?
> However, that aside, the use of little-endian
> byte-order also serves to keep the Kerberos GSSAPI
> protocol very close to the DCE GSSAPI protocol.
>
I haven't seen a DCE GSS spec. Where can I find it?
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18737;
12 May 94 21:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18725;
12 May 94 21:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25473;
12 May 94 21:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18709;
12 May 94 21:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18661;
12 May 94 21:22 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa25420; 12 May 94 21:22 EDT
Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA09321 for ietf at cnri.reston.va.us; Thu, 12 May 94 21:21:46 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id SAA04580; Thu, 12 May 1994 18:19:46 -0700
Message-Id: <199405130119.SAA04580 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: SIGCOMM '94 Advance Program
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 12 May 94 18:19:45 -0700
X-Orig-Sender: craig at aland.bbn.com
I thought a number of IETFers might find this of interest. In particular
these items:
* a tutorial by Van Jacobson on his MBONE work ( Van only teaches once
every 4 years or so, so here's your chance :-)).
* a tutorial by Dave Clark on protocol performance
* papers on the various proposed ATM flow control schemes currently
being considered by ATM FORUM
* papers expanding on our understanding of self-similar traffic
* a paper on PIM
Note the conference is in London, which may require additional signatures
from US companies to get travel approval, although the airfare to London is
typically the same as the airfare across the US -- United quoted me $860
non-stop from San Francisco and $660 non-stop from New York for a 6 day
round-trip including a Saturday night. And if you're willing to live cheaply,
there are some nice B&B's in Bloomsbury (where University College London,
the conference site, is located) that charge as little as $55 USD a night for
a single.
Also, for FYI for graduate students, we've got funding to send 8 US graduate
students to the conference -- details on how to apply for a travel grant will
be sent to this list late next week.
Craig
**********************
From: dowd at acsu.buffalo.edu (Patrick Dowd)
Subject: SIGCOMM'94 Advance Program
Followup-To: dowd at eng.buffalo.edu
Reply-To: dowd at eng.buffalo.edu
Organization: State University of New York at Buffalo
Date: Thu, 12 May 1994 12:53:47 GMT
Advance Programme
ACM SIGCOMM'94 CONFERENCE
Communications Architectures, Protocols and Applications
University College London
London, UK
August 31 to September 2, 1994
(Tutorials and Workshop, August 29-30)
Sponsored by
The ACM Special Interest Group of Data Communication
This conference provides an international forum for the presentation
and discussion of communication network applications and technologies,
architectures, protocols, algorithms, and performance models. The
conference and tutorials will be conducted on the University College
London, London England.
----------------------------------
T E C H N I C A L P R O G R A M
----------------------------------
Monday 29 August 1994
* 7:30AM - 5:00PM
Tutorial and Conference Registration
UCL CS Department, Pearson Building
* 9:00AM - 5:00PM, Tutorial T1
"Personal Communication Services and Networks"
Zygmunt Haas (AT&T Bell Labs)
UCL CS Department, Pearson Building
* 9:00AM - 5:00PM, Tutorial T2
"Protocol Performance"
David D. Clark (MIT)
UCL CS Department, Pearson Building
Tuesday 30 August 1994
* 7:30AM to 5:00PM
Tutorial and Conference Registration
Edward Lewis Lecture Theatre, Windeyer Building
* 9:00AM - 5:00PM, Workshop W1
"Topics in High Performance Networking Support of
Distributed Systems"
Derek McAuley (University of Cambridge)
UCL CS Department, Pearson Building
* 9:00AM - 5:00PM, Tutorial T3
"Fiber Optic Networks"
Paul E. Green, Jr. (IBM Corporation)
UCL CS Department, Pearson Building
* 9:00AM - 5:00PM, Tutorial T4
"Multimedia Conferencing on the Internet"
Van Jacobson (Lawrence Berkeley Laboratories)
Edward Lewis Lecture Theatre, Windeyer Building
* 9:00AM - 5:00PM, Tutorial T5
"Asynchronous Transfer Mode"
Rainer Handel (Siemens Munich)
UCL CS Department, Pearson Building
* 5:30PM - 8:30PM
Welcoming Reception
The Quad at University College London
Wednesday 31 August 1994
* 7:30AM to 5:00PM
Conference Registration
Edward Lewis Lecture Theatre, Windeyer Building
* 9:00AM - 10:00AM
Session 1: Keynote Address
(1994 ACM SIGCOMM Award Winner)
Edward Lewis Lecture Theatre, Windeyer Building
* 10:30AM-12:30PM
Session 2: Protocol Performance
Experiences with a High-Speed Network
Adaptor: A Software Perspective (Best Student Paper)
P. Druschel (University of Arizona), L.L. Peterson (University of
Arizona), & B.S. Davie (Bellcore)
User-space Protocols Deliver High Performance to Applications on a
Low-Cost Gb/s LAN
A. Edwards, G. Watson, J. Lumley, D. Banks,
C. Calamvokis, & C. Dalton (Hewlett-Packard Labs, Bristol)
TCP Vegas: New Techniques for Congestion Detection and Avoidance
L.S. Brakmo, L.L. Peterson, & S.W. O'Malley (University of Arizona)
A Structured TCP in Standard ML
E. Biagioni (Carnegie Mellon University)
* 12:30PM - 2:00PM
Lunch
* 2:00PM-3:30PM
Session 3: Congestion Management
Making Greed Work in Networks: A Game-Theoretic Analysis of
Switch Service Disciplines
S. Shenker (Xerox PARC)
Scalable Feedback Control for Multicast Video Distribution in the Internet
J. Bolot (INRIA), T. Turletti (INRIA) & I. Wakeman
(University College, London)
Statistical Analysis of Generalized Processor
Sharing Scheduling Discipline
Z.-L. Zhang, D. Towsley, & J. Kurose (University of Massachusetts)
* 4:00PM-5:30PM
Session 4: ATM Flow Control
The Dynamics of TCP Traffic over ATM Networks
A. Romanow (Sun Microsystems) & S. Floyd (Lawrence Berkeley Labs)
Reliable and Efficient Hop-by-Hop Flow Control
C. Ozveren (DEC, Littleton), R. Simcoe (DEC, Littleton) &
G. Varghese (Washington University, St. Louis)
Credit Update Protocol for Flow-Controlled ATM
Networks: Statistical Multiplexing and Adaptive Credit Allocation
H.T. Kung (Harvard University), T. Blackwell (Harvard
University), & A. Chapman (BNR)
* 7:30PM - 10:00PM
SIGCOMM Social: Reception and Dinner
The Dinosaur Room, Natural History Museum
(Tickets Required)
Thursday 1 September 1994
* 7:30AM to 5:00PM
Conference Registration
Edward Lewis Lecture Theatre, Windeyer Building
* 8:30AM - 10:00 AM
Session 5: Internet Routing
Flexible Routing and Addressing for a Next Generation IP
P. Francis (NTT Software Labs) & R. Govindan (Bellcore)
An Architecture for Wide-Area Multicast Routing
S. Deering(Xerox PARC), D. Estrin (University of Southern
California), D. Farinacci (Cisco Systems), V. Jacobson
(Lawrence Berkeley Labs), C.-G. Liu (University of Southern
California) & L. Wei (University of Southern California)
Distributed Routing Based on Link-State Vectors
J. Behrens & J.J. Garcia-Luna-Aceves (University of
California at Santa Cruz)
* 10:30AM-12:00PM
Session 6: ATM Switching and Signalling
Signaling and Operating System Support for
Native-Mode ATM Applications
R. Sharma & S. Keshav (AT&T Bell Labs)
Experiences of Building ATM Switches for the Local Area
D.R. McAuley, R.J. Black & I.M. Leslie (University of Cambridge)
Controlling Alternate Routing in General-Mesh
Packet Flow Networks
S. Sibal (RPI) & A. DeSimone (AT&T Bell Labs)
* 12:00PM - 1:30PM
Lunch
* 1:30PM-3:00PM
Session 7: Nueral and Optical Networks
On Optimization of Polling Policy Represented
by Neural Network
Y. Matumoto (I.T.S., Inc., Japan)
An Optical Deflection Network
J. Feehrer (University of Colorado, Boulder), L. Ramfelt
(University of Colorado, Boulder/Royal Institute of Technology,
Stockholm), & J. Sauer (University of Colorado, Boulder)
Conflict-Free Channel Assignment for an Optical
Cluster-Based Shuffle Network Configuration
K.A. Aly (University of Central Florida)
* 3:30PM-5:30PM
Session 8: Selected Topics
MACAW: A Media Access Protocol for Wireless LANs
V. Bharghavan (UC Berkeley), A. Demers (Xerox PARC),
S. Shenker (Xerox PARC) & L. Zhang (Xerox PARC)
Asymptotic Resource Consumption in Multicast
Reservation Styles
D.J. Mitzel (University of Southern California) & S. Shenker
(Xerox PARC)
Highly Dynamic Destination-Sequenced Distance-
Vector Routing (DSDV) for Mobile Computers
C.E. Perkins & P. Bhagwat (IBM, Watson Research Center)
A Methodology for Designing Communication Protocols
G. Singh (Kansas State University)
* 5:30PM - 6:30PM
SIGCOMM Business Meeting
Friday 2 September 1994
* 8:30AM - 10:00AM
Session 9: Traffic Models
Wide-Area Traffic: The Failure of Poisson Modeling
V. Paxson & S. Floyd (Lawrence Berkeley Labs)
Analysis, Modeling and Generation of Self-Similar
VBR Video Traffic
M.W. Garrett & W. Willinger (Bellcore)
An Algorithm for Lossless Smoothing of MPEG Video
S.S. Lam, S. Chow, & D. Yau (University of Texas, Austin)
* 10:30AM-12:00PM
Session 10: Host Software
USC: A Universal Stub Compiler
S.W. O'Malley, T. Proebsting, & A. Montz (University of Arizona)
An Object-based Approach to Protocol Software Implementation
C.-S. Liu (Chung Yuan Christian University, Taiwan)
Improved Algorithms for Synchronizing Computer Network Clocks
D.L. Mills (University of Delaware)
* 12:00PM - 12:15PM
Closing Session
Note: Program subject to change.
-----------------
T U T O R I A L S
-----------------
Tutorial T1
- -----------
Zygmunt Haas, AT&T Bell Labs
"Personal Communication Services and Networks"
The recent explosion of interest in wireless and mobile networks,
stimulated by the effort of Personal Communication Services and
Networks (PCS & PCN) to be deployed at the beginning of the next
century, suggests the enormous technological, scientific, and
commercial potential in this field. The subject of wireless and mobile
communication integrates the large body of knowledge accumulated
through the traditional radio research, the large networking
experience accumulated through the proliferation of LANs and WANs, and
the vision of ubiquitous connectivity anywhere, at anytime, with
anyone, and in any format.
The tutorial exposes both the theoretical and the practical
aspects of mobile networking, from a networking and application
perspective. We will present the concept, architecture, and
functionality of Personal Communications Services and Networks (PCS &
PCN) and Universal Personal Telecommunications (UPT) and we will
describe the most common platform for mobile communications: the
wireless systems. In particular, systems such as cellular, cordless,
and satellite will be discussed. Existing and in-progress standards
are also outlined.
Finally, an abundance of examples of the wireless and mobile
networks will be described, giving realism to the presented material.
TOPICS:
* Elements of Wireless Mobile Communications
* Wireless Services and Applications
* The Cellular Concept
* The Cordless Concept
* Digital Communication Networks
* Local-Area Wireless Data Access
* Wide-area Wireless Data Access
* Mobile Satellite Communications
* Standardization of Wireless Networks
* PCS/PCN and UPT
* Summary: Where we have started and where are going .
Zygmunt Haas received his B.Sc. in EE in 1979 and M.Sc. in EE in 1985,
both with Summa Cum Laude. From 1979 till 1985 he worked for the
Government of Israel. In 1988, he earned his Ph.D. from Stanford
University researching fast packet-switched networks, and subsequently
joined AT&T Bell Laboratories in Holmdel NJ, where he is now a Member
of Technical Staff in the Wireless Networks Department. Dr. Haas is
an author of numerous technical papers and holds several patents in
the field of high-speed networking, wireless networks, and optical
switching. He has organized several workshops and served as a guest
editor for JSAC issues. Dr. Haas is a Senior Member of IEEE and his
interests include: mobile and wireless communication networks,
personal communication services, high-speed communication protocols,
and optical switching.
Tutorial T2
- -----------
David D. Clark, MIT
"Protocol Performance"
Getting proper performance from a network or protocol is often a
difficult task. This tutorial uses examples from the Internet (TCP/IP)
protocol suite to illustrate critical performance issues. The focus is
on providing real-world advice on how to design and implement
protocols in ways that avoid performance problems. The presentation
will include examples of various performance problems and how to
detect and recognize them.
Topics
* Performance issues (reliability, throughput and delay)
* Implementation bottlenecks
* Specifications and their limitations
* Heterogeneity and its impact on implementation
* Network dynamics
* Visualizing protocol performance
* Limits of protocol performance
Dr. David Clark is a senior research scientist at MIT Laboratory for
Computer Science and a recipient of the ACM SIGCOMM Award. He has
worked on TCP/IP since the mid-1970s and from 1981 to 1989 was
chairman of the Internet Activities Board. He is widely known for his
insight into protocol design and performance and for his skill in
identifying and eliminating myths about protocol implementation and
performance. His current areas of research include high-performance
networks, the evolution of the Internet, ATM and information
networking. He received his doctorate from MIT in 1973.
Tutorial T3
- -----------
Paul E. Green, Jr., IBM
"Fiber Optic Networks"
Fiber optic technology has completely transformed the internal
operation of the world's telephone networks and is beginning to impact
local computer networks. Compared to the voice grade phone line
technology, which defined most of the network architectures that we
are still living with today, fiber offers ten orders of magnitude
better bandwidth and an equal improvement in achievable bit error
rate. By use of WDM and circuit switching, the additional benefits of
protocol transparency can be achieved.
There is a widespread feeling that the generation of network
that will follow today's ATM and upgraded Internet structures might
very well be based on techniques that directly unlock this
revolutionary improvement at the physical level.
The course is devoted to the new class of "all-optical"
networks that attempt to do this. The lecturer will cover the
optoelectronic components involved and will also treat some of the
network architectural consequences, the regulatory and economic
picture, and review some systems already implemented.
TOPICS
* Motivating fiber optic networks
* Fibers, couplers and taps
* Optical resonant structures
* Laser diodes and amplifiers
* Optical receivers
* System considerations
* Network topologies and link budgets
* Protocols, layers and network control
* Some implemented systems
* Status and prospects
Paul E. Green, Jr, is Manager of Advanced Optical Networking Member at
IBM Research in Hawthorne, NY. He received the ScD degree from M.I.T.
in 1953, and after some years at M.I.T. Lincoln Laboratory, where he
made pioneering contributions to spread spectrum, adaptive receivers,
radar astronomy and seismic data processing, he joined IBM Research in
1969. At IBM he has held a variety of management and Corporate
Technical Staff positions. His technical interests have centered on
computer network architecture, and he has received several IBM
Outstanding Innovation Awards for his role in the initial formulation
and promotion of Advanced Peer to Peer Networking, now the basis for
further evolution of IBM's System Network Architecture. He is a member
of the National Academy of Engineering, in 1983 was named
Distinguished Engineering Alumnus by North Carolina State University,
and received the IEEE's Simon Ramo Medal in 1991. He is the author of
many technical papers, has edited several books on computer
communications, and is the author of the textbook Fiber Optic
Networks, published by Prentice Hall in June,1992. He has been
President of both the IEEE Communication Information Theory Society
and the Communication Society.
Tutorial T4
- -----------
Van Jacobson, LBL
"Multimedia Conferencing on the Internet"
An architectural overview and detailed walk-through of the protocols
and applications that provide real-time, multiparty, audio, video and
shared workspace conferencing on today's Internet.
Experiments and demonstrations over the Internet MBONE and the
DARTNET testbed have shown that multimedia and conferencing
applications can indeed work over IP internets. Playback algorithms
that adapt to variations in network delay (such as VAT) and
information distribution algorithms designed to facilitate shared
workspaces (such as those used in the shared whiteboard) have made
these sorts of applications possible. This tutorial describes these
algorithms and the applications that use them.
Topics
* IP as a real-time infrastructure: multicasting and queueing
* Adaptive Playback: VAT
* Managing Sessions: SD
* Managing Shared Workspaces: Shared Whiteboard
* Implications for the future of IP
Van Jacobson is a senior researcher at Lawrence Berkeley Laboratories,
where he works on real-time system performance, protocol and operating
system performance. He is widely known for his groundbreaking work on
TCP/IP performance, TCP/IP congestion control, and support for
multimedia applications on the Internet. He is the recipient of a
number of awards and teaches periodically at U.C. Berkeley and
Stanford University.
Tutorial T5
- -----------
Rainer Handel, Siemens Munich
"Asynchronous Transfer Mode"
The tutorial will provide a comprehensive introduction to the
Asynchronous Transfer Mode (ATM). Both technical and marketing aspects
of ATM will be addressed. ATM specification is not yet complete but in
a state that allows implementations which are basically compliant with
a worldwide agreed, unique standard supporting data, voice, image and
multimedia applications.
The presentation of the concept of ATM networking will include
the ATM protocol reference model, the architecture of ATM networks,
interfaces and procotols, traffic control and resource management,
signalling, operational aspects, ATM evolution and internetworking
aspects, and of course a detailed description of the ATM layer and ATM
adaptation layer functions. An overview of how ATM cells are switched
and transmitted will also be given. The possible use of ATM in a
business and residential environment and its market acceptance
depending on product availability, cost and feature offerings will be
clarified.
TOPICS:
* High speed networks
* ATM concept
* ATM protocols
* ATM interfaces
* interworking and evolvability
* market aspects
* switching and transmission products
* network implementations and service offerings
Rainer Handel has been with Siemens (Public Communications Networks
Group) since 1978 doing system design and software development for
switching systems, ATM conceptual and standardization work, ATM
network and product planning, and currently long-term telecom market
and technology trend evaluation. For several years he was active in
the standards bodies CCITT, ETSI and T1, and is the author of several
papers and a book on ATM.
Workshop W1
- ----------
Derek McAuley, University of Cambridge
"Topics in High Performance Networking Support of Distributed Systems"
This one day workshop will present the experiences of the speakers in
building various components of distributed systems which aim to
effectively utilise modern high performance networks. This workshop
consists of 4 talks. Each talk will be 60 minutes with 15 minutes for
discussion.
1. The CHORUS Communication Architecture, Marc Rozier
The communication service is a key component of the CHORUS
micro-kernel architecture. First, it provides the basic framework
allowing efficient modular operating system implementations. By
dramatically reducing the overhead of local communications, it is key
to the success of such serverized implementations, which are now able
to compete with monolithic implementations. Second, it provides
efficient, network-transparent, communication services, well adapted
to the distribution of the operating system servers. In particular,
it makes possible the implementation of UNIX systems on massively
parallel architectures, offering a single system image to their users.
This tutorial will address the various aspects of this communication
architecture, from the definition of the communication services, to
some aspects of its implementation. Emphasis will be placed on
insights from previous versions of this service.
2. The Organization of Networks in Plan 9, Rob Pike
In a distributed system networks are of paramount importance. This
tutorial describes the implementation, design philosophy and
organization of network support in Plan 9. Topics include network
requirements for distributed systems, our kernel implementation,
network naming, user interfaces and performance. We also observe that
much of this organization is relevant to current systems.
3. Mixed media applications, David Tennenhouse
WWW is a rapidly growing phenomena which highlights the interesting
applications possible with mixed media types. From experience with the
WWW this tutorial will address the issues raised in supporting these
mixed media types and the problems in building systems which support
media with time constraints.
4. What can you do with ATM today?, Derek McAuley
ATM must now be officially a bandwagon. Some will tell you it solves
all the world's problems because it was designed to, while others will
say it's good for nothing. The reality and hype are hard to
distinguish. This talk will address what ATM can be used for today and
highlight those features for which it is rightly criticised not least
of which is end-system integration. The talk could be subtitled,
"Difficult questions to ask your ATM salesman''.
Marc Rozier is the head of the Micro-Kernel Department within Chorus
systemes. He graduated from Ecole Nationale Superieure Informatique et
de Mathematiques Applique'es de Grenoble (ENSIMAG) before earning a
doctor's degree in Computer Science from Institut National
Polytechnique de Grenoble (INPG). In 1981-82, he was involved in the
CESAR project at IMAG (Grenoble), working on the Validation of
Distributed Systems. He gained experience in programming languages for
distributed applications and distributed systems. He joined INRIA in
1982 as a researcher in the CHORUS distributed operating system
project. In 1987, he became one of the founders of Chorus systemes. He
is one of the main designers of the CHORUS-v3 Micro-Kernel technology.
He is the author of several publications in international journals and
conferences.
Rob Pike is well known for his appearances on "Late Night with David
Letterman", is also a Member of Technical Staff at AT&T Bell
Laboratories in Murray Hill, New Jersey, where he has been since 1980,
the same year he won the Olympic silver medal in Archery. In 1981 he
wrote the first bitmap window system for Unix systems, and has since
written ten more. With Bart Locanthi he designed the Blit terminal;
with Brian Kernighan he wrote The Unix Program- ming Environment. A
shuttle mission nearly launched a gamma-ray telescope he designed. He
is a Canadian citizen and has never written a program that uses cursor
addressing.
David Tennenhouse is an Assistant Professor of Computer Science and
Electrical Engineering at MIT's Laboratory for Computer Science. He is
leader of the Telemedia, Networks and Systems Group, which is
addressing systems issues arising at the confluence of three
intertwined technologies: broadband networks, high definition video
and distributed computing. David studied electrical engineering at
the University of Toronto, where he received his B.A.Sc. and M.A.Sc.
degrees. In 1989 he completed his Ph.D. at the Computer Laboratory of
the University of Cambridge. His Ph.D. research focused on ATM-based
site interconnection issues. This work, which was conducted within the
Unison Project, led to the early implementation of an ATM-based wide
area testbed.
Derek McAuley is a Lecturer in the Computer Laboratory at the
University of Cambridge. His research interests include networking,
distributed systems and operating systems. Recent work has
concentrated on the support of time dependent mixed media types in
both networks and operating systems. He has failed to leave Cambridge
since arriving in 1979 to read Mathematics. In 1989 he completed his
Ph.D. on ATM internetworking. He has had a hand in de-commissioning 4
ATM networks, including Tennenhouse's carefully constructed Unison
platform.
---------------
L o c a t i o n
---------------
The conference will be held in the Edward Lewis Lecture Theatre which
is located in the Windeyer Building on the UCL campus. This building
is located on the corner of Cleveland Street and Howland Street, with
the entrance on Cleveland Street. Tutorials are all in UCL Computer
Science Department in the Pearson Building, except T4 (Van Jacobson)
on the Tuesday which is held in the Edward Lewis Lecture Theatre.
The main entrance of UCL is located at the north end of Gower Street,
close to Euston Square, Warren Street, or Euston tube stations. The
UCL Computer Science Department is located in the basement of the
Pearson Building. Location
---------------------------
T r a n s p o r t a t i o n
---------------------------
* Getting to London
There are four airports in and around London. Here is some
information that might help you to plan your journey. Please consult
your travel agency or the airports directly for further information.
LONDON Heathrow Airport: 24 km west of London
Telephone: +44-81-745-6156
LONDON Gatwick Airport: 46 km south of London
Telephone: +44-293-535-353
STANsted Airport: 55 km north east of London
Telephone: +44-279-680-500
* Getting to UCL and Hotels
UCL is located in central London, and is served by Warren St, Euston
and Euston Square Underground (tube) stations, as well as several main
bus routes. The department of computer science is right by the
entrance to the main quadrangles, on Gower Street.
>From Heathrow: Best by tube with Victoria Line to Euston Station
(about #3, 50 minutes). Alternatives are via Bus with London Transport
A1 Airbus to Victoria Station (45 minutes).
For local hotels it is probably best to go to Euston Station and get a
taxi from there unless you have a street map already and know the
nearest tube station. A free tube map may be obtained at any ticket
office.
>From Gatwick: Best by train, BR Gatwick Express to London Victoria
Station every 15 minutes (about #8.60, 30 minutes).
Unless you plan to sightsee outside London a car is probably a waste
of time. Tube fares are based on a zone system. After 9:30AM you can
get One Day Travel cards which allow you unlimited travel within given
zones for the rest of the day - that includes train and bus services
within that zone too. Zones 1,2 & 3 #2.30 pounds. Zones 1-5 #2.60
pounds.
-------------------------
A c c o m o d a t i o n s
-------------------------
The following hotels are walking distance from the conference meeting
room on the UCL campus. Contact the hotel directly to place
reservations.It is highly recommended that reservations are made as
early as possible. Refer to SIGCOMM'94 when making the reservation.
* Hotel Ibis Euston
3 Cardington Street, NW1
Telephone: +44-71-388-7777, Fax: +44-71-388-0001
Total Rooms: 300
Single Room #49.50, Double Room #49.50
Near UCL, about 10 minute walk from main Conference Hall.
* St. George's Hotel
Langham Place, W1N
Telephone: +44-71-580-0111, Fax: +44-71-436-7997
Total Rooms: 86
Single Room: #80.00, Double Room: #100.00
(Includes Continental Breakfast)
Situated near Oxford Circus, about 10 minute walk from main venue.
* RAMSAY HALL
20 Maple Street, W1P
Total Rooms: 400
Telephone: +44-71-387-4537, Fax: +44-71-383-0843
Single Room: #19.50, Double Room: not available.
(Includes Continental Breakfast)
Student residence used as hotel during summer break, 5 minute walk
from main conference venue.
* Hotel Russell
Russell Square, WC1
Telephone: +44-71-837-6470, Fax: +44-71-837-2857
Total Rooms: 328
Single Room: #70.00, Double Room: #90.00
(Includes Continental Breakfast)
Old Victorian Style Hotel. About 15 minute walk from Conference
venues. Russel Square Station is on the Picadilly line which
reaches to Heathrow Airport. Airport Bus stop nearby as well.
* Forte Crest Bloomsbury
Coram Street, WC1
Telephone: +44-71-837-1200
Fax: +44-71-837-5374
Total Rooms: 230
Single Room: #69.00, Double Room: #79.00
(Includes Continental Breakfast)
Modern hotel near Hotel Russell.
There are a large number of hotels near the conference. Almost any
hotel in the WC1 area of London is within 15 minutes walking distance.
A list of more hotels may be found via www
(http://www.cs.ucl.ac.uk/sigcomm94) or anonymous ftp
(norman.eng.buffalo.edu:/pub/SIGCOMM94). The list also includes nearby
lower cost housing and youth hostels.
------------------------------------------------
R E G I S T R A T I O N I N F O R M A T I O N
------------------------------------------------
Full conference registration includes breaks, lunch, Tuesday evening
reception, one ticket to dinner in the Dinosaur Room of the Natural
History Museum on Wednesday, and a copy of the conference proceedings.
Student registration includes breaks, lunch and proceedings but does
not include the dinner/museum event. On site registration will begin
Monday August 29, 1994 from 7:30AM - 5:00PM, and every day of the con-
ference starting at 7:30 am.
ACM and SIGcomm Membership
- --------------------------
If you are not an ACM or a SIGCOMM member at this time, you may join
now to take full advantage of ACM/SIGcomm Member or Student rates for
SIGCOMM94:
- - ACM Associate Member Dues $82/#52
- - Add SIGCOMM to ACM Membership $22/#15
- - ACM Student Dues $25/#17
- - Add SIGCOMM to ACM Student Membership $15/#10
- - SIGCOMM Membership only (non-ACM) $50/#32
Total Membership Fees $/# _________
(Note: $ indicates U.S. dollars, and # British Pounds Sterling)
To advance the sciences and arts of information processing; to promote
the free interchange of information about the sciences and arts of
information processing both among specialists and among the public;
and to develop and maintain the integrity and competence of
individuals engaged in the practice of information processing. I
hereby affirm that I subscribe to the purpose of ACM and understand
that my membership is not transferable.
Signature _________________________________________ Date ____________
Tutorials
- ---------
Check each tutorial attending. The tutorial registration fee includes
one copy of the tutorial notes and lunch. Tutorials are on a first
come first serve basis.
- - T1 Personal Communication Services & Networks (Monday)
- - T2 Protocol Performance (Monday)
- - T3 Fiber Optic Networks (Tuesday)
- - T4 Multimedia Conferencing on the Internet (Tuesday)
- - T5 Asynchronous Transfer Mode (Tuesday)
- - W1 Workshop on Distributed Systems (Tuesday)
Tutorial Rates
Postmarked by Postmarked
aug/1/1994 after aug/1/1994
ACM/SIG Member _____@ $275/#172 _____@ $325/#205
Non-Member _____@ $350/#220 _____@ $400/#250
Student _____@ $138/#87 _____@ $175/#110
Total Tutorial Fees _____$/# _____$/#
Special Needs
- -------------
Vegetarian Meals: - Yes - No
Conference Registration
- -----------------------
Please complete and send registration form, with check, credit card
information or money orders (no purchase orders) to the address below.
Registrations accepted via postal mail, fax or email (with credit
card) only.
Postmarked by Postmarked
Aug/1/1994 after Aug/1/1994
ACM/SIG Member _____@ $315/#200 _____@ $365/#230
Non-Member _____@ $397/#252 _____@ $440/#275
Student _____@ $100/#63 _____@ $130/#82
Total Registration Fees $/# _____ $/# _____
Extra Dinner/Museum Ticket _____@ $55/#35
TOTAL ENCLOSED $/# _____ (ACM/SIGCOMM Membership, tutorials,
conference registration)
NAME _________________________________________________________________
AFFILIATION __________________________________________________________
ADDRESS ______________________________________________________________
______________________________________________________________________
PHONE _____________________________ FAX ______________________________
Email ADDRESS ________________________________________________________
SIGCOMM Member? - YES - NO
ACM/SIGCOMM Member Number ____________________________________________
CREDIT CARD PAYMENT - VISA - MASTERCARD - euroCARD
CARD HOLDER NAME _____________________________________________________
CARD NUMBER ______________________________________ EXP. DATE _________
SIGNATURE ____________________________________________________________
Please send this form and a check, credit card information or money
orders (no purchase orders) to SIGCOMM'94. Registrations accepted via
postal mail, fax or email only.
Send U.S. or Send Pound Sterling
Credit Card Payments to:
Patrick McCarren Soren-Aksel Sorensen
ACM - 17th Floor Dept. of Computer Science
1515 Broadway University College London
New York, NY 10036 London WC1E 6BT
USA United Kingdom
phone: +1 212/626/0611 phone: +44 71 380 7269
fax: +1 212/302-5826 fax +44 71 387 1397
mccarren at acm.org
Email registrations can only be made by a credit card during the
pre-registration period ending 1 August 1994 and must use credit card
payment. A registration confirmation letter will be sent to each
participant upon receipt of the completed registration form and
accompanying payment. Registration fee will be refunded, less a
$30/#19 administration fee, if cancelation notification is received
prior to 15 August 1994. Substitution for a paid attendee is
acceptable.
----------------------------------------------
C o n f e r e n c e O r g a n i z a t i o n
----------------------------------------------
General Chair: Jon Crowcroft, University College London
Program Chairs: Stephen Pink, Swedish Institute of Computer Science
Craig Partridge, BBN (Program Co-Chair for North America)
Ian F. Akyildiz, Georgia Institute of Technology, USA
Lillian N. Cassel, Villanova Univ., USA
Vinton Cerf, MCI, USA
Lyman Chapin, BBN, USA
Jon Crowcroft, Univ. College London, UK
Andre Danthine, Univ. of Liege, Belgium
Gary Delp, IBM, USA
Patrick W. Dowd, SUNY/Buffalo, USA
Deborah Estrin, Univ. Southern California, USA
David Feldmeier, Bellcore, USA
Sally Floyd, Lawrence Berkeley Laboratory, USA
David Greaves, ORL Cambridge, UK
Per Gunningberg, Swedish Institute of Computer Science, Sweden
Christian Huitema, INRIA, France
David Hutchison, Lancaster Univ., UK
Raj Jain, Ohio State University, USA
Jim Kurose, Univ. of Massachusetts, USA
Ian Leslie, Univ. of Cambridge, UK
David Oran, Digital Equipment Corp, USA
Gerard Parr, University of Ulster, Northern Ireland
Guru Parulkar, Washington Univ. St Louis, USA
Krzysztof Pawlikowski, Univ. of Canterbury, New Zealand
Bernhard Plattner, ETH Zurich, Switzerland
Scott Shenker, XEROX PARC, USA
Deepinder Sidhu, Univ. of Maryland-BC, USA
Jonathan M. Smith, Univ. Pennsylvania, USA
Khosrow Sohraby, Univ. of Missouri - Kansas City, USA
James Sterbenz, IBM Research, USA
Greg Watson, Hewlett Packard Labs, UK
Greg Wetzel, AT&T Bell Laboratories, USA
Lixia Zhang, XEROX PARC, USA
---------------------------------------------------
F O R A D D I T I O N A L I N F O R M A T I O N
---------------------------------------------------
Additional information may be found/requested from:
www: http://www.cs.ucl.ac.uk/sigcomm94
anonymous ftp: norman.eng.buffalo.edu:/pub/sigcomm94
email: sigcomm94 at eng.buffalo.edu
fax: +1 716.645.3656
phone: +1 716.645.2406
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18795;
12 May 94 21:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18787;
12 May 94 21:36 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa25621;
12 May 94 21:36 EDT
Received: by bitsy.MIT.EDU
id AA12028; Thu, 12 May 94 21:24:56 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA12020; Thu, 12 May 94 21:24:54 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA11229; Thu, 12 May 94 21:24:50 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id SAA07169; Thu, 12 May 1994 18:23:55 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA21235; Thu, 12 May 94 18:23:10 -0700
Date: Thu, 12 May 94 18:23:10 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405130123.AA21235 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Theodore Ts'o <tytso at mit.edu>
Subject: Re: Questions regarding GGS/Kerberos names
Cc: John Linn <linn at cam.ov.com>, cat-ietf at mit.edu, gssapi at ocsg.com
Reply-To: dpg at ocsg.com
> A Kerberos principal is a complex data structure released using
> krb5_free_principal(). Strings are released using free(). How
> is that information passed to gss_release_buffer()?
>
> I made the assumption there is reason data encapsulated in GSS
> buffers and passed to gss_import_name() would be kept around.
>
> It's been said before, but it bears repeating, because I
> think people are confused. gss_import_name() *only*
> takes character strings as input. In the mechanism
> draft, where it says krb5_principal, what it should say
> is "a character string in the format which could be parsed
> by krb5_parse to turn it into a valid krb5_principal".
> In point of fact, that's what an implementation of
> gss_import_name() will likely be end up doing --- it'll
> just pass the character string into krb5_parse().
>
Beta 3 GSS has facilities to import a Kerberos principal. It is done
in krb5/import_name.c, lines 82 to 97 -- to add to the confusion. :)
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02953;
13 May 94 9:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02949;
13 May 94 9:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05338;
13 May 94 9:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02930;
13 May 94 9:06 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02926;
13 May 94 9:06 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: if-mib at thumper.bellcore.com
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Definitions of Managed Objects for the
Ethernet-like Interface Types to Standard
Date: Fri, 13 May 94 09:05:57 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405130906.aa02926 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Definitions of Managed
Objects for the Ethernet-like Interface Types"
<draft-ietf-ifmib-ethmib-smiv1-00.txt> as a Standard. This document is
the product of the Interfaces MIB Working Group. The IESG contact
person is Marshall T. Rose.
Technical Summary
This memo defines managed objects for ethernet-like interface types.
It is a revision of RFC 1398 based on implementation and deployment
experience.
Working Group Summary
There were no contentious issues in the WG.
Protocol Quality
There are multiple implementations of this MIB module.
Notes to the RFC editor (upon publication)
1. Please publish
draft-ietf-ifmib-ethmib-smiv2-00.txt
as an Informational RFC at the same time you publish
draft-ietf-ifmib-ethmib-smiv1-00.txt
as a Standard. Both memos are semantically equivalent; however,
the second Internet-Draft (smiv2) is written using the SNMPv2 SMI.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03005;
13 May 94 9:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03001;
13 May 94 9:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05362;
13 May 94 9:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02982;
13 May 94 9:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02975;
13 May 94 9:07 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ip-atm at hpl.hp.com
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Default IP MTU for use over ATM AAL5 to Proposed
Standard
Date: Fri, 13 May 94 09:07:39 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405130907.aa02975 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Default IP MTU for use over
ATM AAL5" <draft-ietf-atm-mtu-07.txt> as a Proposed Standard. This
document is the product of the IP Over Asynchronous Transfer Mode
Working Group. The IESG contact person is Stev Knowles.
Technical Summary
This is a very short, easy to understand reference for developers
intending to run IP over ATM. It goes into some detail to describe the
motivation for the value chosen, and seems complete and reasonable.
Working Group Summary
There does not appear to have been any working group concern over this
draft.
Protocol Quality
The protocol was reviewed by Stev Knowles, one of the Internet Area
Directors. There seems to be widespread community support for this
document, and the Last Call generated no negative comments.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03069;
13 May 94 9:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03064;
13 May 94 9:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05395;
13 May 94 9:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03046;
13 May 94 9:09 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03040;
13 May 94 9:09 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-ppp at merit.edu
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: PPP Bridging Control Protocol (BCP) to Proposed
Standard
Date: Fri, 13 May 94 09:09:51 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405130909.aa03040 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "PPP Bridging Control Protocol
(BCP)" <draft-ietf-pppext-for-bridging-04.txt> as a Proposed Standard.
This document is the product of the Point-to-Point Protocol Extensions
Working Group. The IESG contact persons is Stev Knowles.
Technical Summary
The protocol defined in this document allows for vendors to
provide bridging technologies across point-to-point links using PPP.
The protocol as defined allows for the exchange of necessary information
for this activity to occur.
Working Group Summary
The PPP working group has expended some effort in helping the
authors of this document bring it to a finely crafted sheen.
Protocol Quality
This document, while not short, is an extremely readable explanation of
the considered technologies and goes into some detail about how various
actions will effect the stability of one's network as a whole. The I-D
takes the time to explain to the reader bridging technologies, which
the reviewing AD feels is an appropriate matter, since one cannot
assume that IP centric readers will be as familiar with bridging as one
needs to be to implement bridging between two PPP endpoints. The I-D
avoids the religious pitfalls one may expect to find in a document
about a subject which most knowledgeable readers will have very strong
opinions about. There seem to be multiple implementations of this
document.
This review was done by Stev Knowles, one of the Internet Area
Directors, for the IESG.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03238;
13 May 94 9:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03234;
13 May 94 9:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05486;
13 May 94 9:15 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03216;
13 May 94 9:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03212;
13 May 94 9:14 EDT
Received: from excelsior.cnri.reston.va.us by CNRI.Reston.VA.US id aa05479;
13 May 94 9:14 EDT
Received: from CNRI.Reston.Va.US (localhost) by excelsior.CNRI.Reston.Va.US (5.0/SMI-SVR4)
id AA05008; Fri, 13 May 1994 09:14:49 +0500
Message-Id: <9405131314.AA05008 at excelsior.CNRI.Reston.Va.US>
To: IETF-Announce: ;, LOCAL at excelsior.cnri.reston.va.us
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: Internet Architecture Board <iab at isi.edu>,
Internet Engineering Steering Group <iesg at CNRI.Reston.VA.US>,
i2i at sophia.inria.fr
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Reply-To: i2i at sophia.inria.fr
Subject: Last Call for Draft MOU Between ISOC and ISO/IEC JTC-1/SC6
Date: Fri, 13 May 1994 09:14:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
content-length: 665
The IAB is trying to confirm community consensus on the "Draft
Memorandum of Understanding Between the Internet Society and
ISO/IEC JTC-1/SC6" <draft-iab-mou2jtc1-02.txt> document. This
document is what the IAB will present to JTC-1/SC6. They will
take it as input, fill in their part, and come back with the
completed document. This final document will be subject to a
review by the IAB, and to a community Last Call, before being
handed to the Internet Society for approval by the Board of
Trustees.
This Last Call is intended to verify community consensus on
the content of the MOU.
Please send comments to the i2i at sophia.inria.fr list.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04016;
13 May 94 9:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04011;
13 May 94 9:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06242;
13 May 94 9:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03990;
13 May 94 9:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03984;
13 May 94 9:42 EDT
Received: from excelsior.cnri.reston.va.us by CNRI.Reston.VA.US id aa06224;
13 May 94 9:42 EDT
Received: from CNRI.Reston.Va.US (localhost) by excelsior.CNRI.Reston.Va.US (5.0/SMI-SVR4)
id AA05130; Fri, 13 May 1994 09:42:03 +0500
Message-Id: <9405131342.AA05130 at excelsior.CNRI.Reston.Va.US>
To: IETF-Announce: ;, LOCAL at excelsior.cnri.reston.va.us
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: Internet Engineering Steering Group <iesg at CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Mockapetris <pvm at isi.edu>
Subject: Moritorium Lifted on OSI-related WG Activity
Date: Fri, 13 May 1994 09:42:02 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
content-length: 1067
In September 1993, the IESG issued a policy statement entitled
IESG Statement on ISOC/ISO liaison and OSI-related WG activity
This policy instituted a moratorium on the establishment of new IETF
working groups dealing with OSI technology, applied above and beyond
the normal policy of evaluating each proposed WG on the basis of its
individual merits and relationship to other IETF work. It was
intended to minimize conflict during the process of establishing
liaison relationships between the Internet Society and various bodies
within the International Organization for Standardization. As stated
in the memo, this policy would be re-evaluated after a six month
period. Accordingly, the IESG has re-evaluated its policy.
The IESG feels that the process of establishing a liaison has reached
the point where conflict can be minimized. As such, the moratorium is
now lifted. It must be emphasized that this action in no way affords
OSI technology any special privileges with respect to the formation of
working groups.
Paul Mockapetris
IETF/IESG Chair
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07041;
13 May 94 11:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11463;
13 May 94 11:57 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06979;
13 May 94 11:57 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06809;
13 May 94 11:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-anil-incremental-checksum-02.txt
Date: Fri, 13 May 94 11:55:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405131155.aa06809 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Computation of the Internet Checksum
via Incremental Update
Author(s) : A. Rijsinghani
Filename : draft-anil-incremental-checksum-02.txt
Pages : 9
Date : 05/12/1994
This memo describes an updated technique for incremental computation of the
standard Internet checksum. It updates the method described in RFC 1141.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-anil-incremental-checksum-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-anil-incremental-checksum-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940512142728.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-anil-incremental-checksum-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-anil-incremental-checksum-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940512142728.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07045;
13 May 94 11:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07040;
13 May 94 11:57 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa11465;
13 May 94 11:57 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08649; Fri, 13 May 94 11:53:58 EDT
Received: from [132.151.1.35] by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08)
id AA08645; Fri, 13 May 94 11:53:57 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05415;
13 May 94 10:48 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce. at CNRI.Reston.VA.US, %cnri.reston.va.us at dimacs.rutgers.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Cc: ietf-smtp at dimacs.rutgers.edu
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-smtpext-extensions-01.txt
Date: Fri, 13 May 94 10:48:33 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9405131048.aa05415 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Mail Extensions
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : SMTP Service Extensions
Author(s) : J. Klensin, N. Freed, M. Rose,
E. Stefferud, D. Crocker
Filename : draft-ietf-smtpext-extensions-01.txt
Pages : 9
Date : 05/12/1994
This memo defines a framework for extending the SMTP service by defining a
means whereby a server SMTP can inform a client SMTP as to the service
extensions it supports. Standard extensions to the SMTP service are
registered with the IANA. This framework does not require modification of
existing SMTP clients or servers unless the features of the service
extensions are to be requested or provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-smtpext-extensions-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-smtpext-extensions-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940512094739.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-smtpext-extensions-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smtpext-extensions-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940512094739.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07764;
13 May 94 12:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07760;
13 May 94 12:26 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12337;
13 May 94 12:26 EDT
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by thumper.bellcore.com (8.6.7/8.6.6) with SMTP id MAA20405 for <snanaumib at thumper.bellcore.com>; Fri, 13 May 1994 12:23:49 -0400
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06255;
13 May 94 11:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: snanaumib at thumper.bellcore.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-snanau-snamib-04.txt
Date: Fri, 13 May 94 11:28:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405131128.aa06255 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNA NAU Services MIB Working
Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : Definitions of Managed Objects for SNA NAUs
Author(s) : Z. Kielczewski, D. Kostick, K. Shih
Filename : draft-ietf-snanau-snamib-04.txt
Pages : 78
Date : 05/12/1994
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for managing the configuration, monitoring
and control of Physical Units (PUs) and Logical Units (LUs) in an SNA
environment. PUs and LUs are two types of Network Addressable Units (NAUs)
in the logical structure of an SNA network. NAUs are the origination or
destination points for SNA data streams. This memo identifies managed
objects for PU Type 1.0, 2.0 and Type 2.1 and LU Type 0, 1, 2, 3, 4, 7.
The generic objects defined here can also be used to manage LU 6.2 and any
LU-LU session. The SNA terms and overall architecture are documented in
Systems Network Architecture Technical Overview.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-snanau-snamib-04.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snanau-snamib-04.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940512143332.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-snanau-snamib-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snanau-snamib-04.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940512143332.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04553;
13 May 94 10:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04545;
13 May 94 10:10 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa07540; 13 May 94 10:10 EDT
Received: from hpdmd48.boi.hp.com by hp.com with SMTP
(1.36.108.7/15.5+IOS 3.13) id AA03185; Fri, 13 May 1994 07:10:51 -0700
Received: from hpbs911.boi.hp.com by hpdmd48.boi.hp.com with SMTP
(1.37.109.4/15.5+IOS 3.21+OM) id AA25921; Fri, 13 May 94 08:10:41 -0600
Received: by hpbs907.boi.hp.com
(16.6/15.5+IOS 3.12) id AA14328; Fri, 13 May 94 08:01:45 -0600
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joel Gyllenskog <jgyllens at hpdmd48.boi.hp.com>
Message-Id: <9405131401.AA14328 at hpbs907.boi.hp.com>
Subject: May meeting agenda
To: pmi at hpbs907.boi.hp.com
Date: Fri, 13 May 94 8:01:44 MDT
Cc: ietf-announce-post at CNRI.Reston.VA.US
Mailer: Elm [revision: 66.25]
The next meeting of the Printer MIB Working Group and the Printer MIF
Working Group will be held on Tuesday, May 24 and Wednesday, May 25.
Meetings will be held from 8:00 AM to 5:00 PM on both days at a
conference room at Carnegie-Mellon University in Pittsburgh, PA.
A block of rooms has been reserved at the Holiday Inn University Center.
The $86 daily rate is available by requesting reservations through Donna
Donovan at CMU. Her e-mail address is <dd2m+ at andrew.cmu.edu>.
Send her a message requesting reservations and she will make them
for you with the hotel. She will then send you a reservation
number which she received from the hotel. You can then call the
hotel and guarantee your reservations. The Hotel's telephone
number is (412) 682-6200. Holiday Inn has a toll-free reservation
number of 1-800-HOLIDAY.
Agenda:
Discussion of IETF concerns about Printer MIB Working Group. This
will include a discussion of the schedule and liklihood of producing
a spec in the required timeframe.
Review proposal to remove finishers from the printer MIB and leave
their definition to a subsequent working group.
Review of strings used within the Printer MIB. Should they be
DisplayStrings, octets, or something else.
Review of the use of community strings as a means of steering requests
to the appropriate device when more than one device uses the same IP
address. Should this be defined or should we leave it to individual
providers to handle the problem?
Review of other open items. Participants are invited to submit items
for inclusion on the agenda.
Joel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07863;
13 May 94 12:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07859;
13 May 94 12:31 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa12428; 13 May 94 12:31 EDT
Received: from hpdmd48.boi.hp.com by hp.com with SMTP
(1.36.108.7/15.5+IOS 3.13) id AA10842; Fri, 13 May 1994 09:31:27 -0700
Received: from hpbs907.boi.hp.com by hpdmd48.boi.hp.com with SMTP
(1.37.109.4/15.5+IOS 3.21+OM) id AA05999; Fri, 13 May 94 10:31:20 -0600
Received: from hp.com by hpbs907.boi.hp.com with SMTP
(16.6/15.5+IOS 3.12) id AA15444; Fri, 13 May 94 10:23:26 -0600
Received: from ftp.std.com by hp.com with SMTP
(1.36.108.7/15.5+IOS 3.13) id AA10620; Fri, 13 May 1994 09:29:30 -0700
Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0)
id MAA24700; Fri, 13 May 1994 12:26:59 -0400
Received: by world.std.com (5.65c/Spike-2.0)
id AA25737; Fri, 13 May 1994 12:26:57 -0400
Date: Fri, 13 May 1994 12:26:57 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike Bloom <dpi at world.std.com>
Message-Id: <199405131626.AA25737 at world.std.com>
To: jgyllens at hpdmd48.boi.hp.com, pmi at hpbs907.boi.hp.com
Subject: Re: May meeting agenda
Cc: ietf-announce-post at CNRI.Reston.VA.US
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07905;
13 May 94 12:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07901;
13 May 94 12:36 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa12536; 13 May 94 12:36 EDT
Received: from hpdmd48.boi.hp.com by hp.com with SMTP
(1.36.108.7/15.5+IOS 3.13) id AA11473; Fri, 13 May 1994 09:36:26 -0700
Received: from hpbs907.boi.hp.com by hpdmd48.boi.hp.com with SMTP
(1.37.109.4/15.5+IOS 3.21+OM) id AA06469; Fri, 13 May 94 10:36:05 -0600
Received: from relay.hp.com by hpbs907.boi.hp.com with SMTP
(16.6/15.5+IOS 3.12) id AA15504; Fri, 13 May 94 10:28:31 -0600
Received: from ftp.std.com by relay.hp.com with SMTP
(1.37.109.8/15.5+ECS 3.3) id AA23647; Fri, 13 May 1994 09:34:34 -0700
Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0)
id MAA24989; Fri, 13 May 1994 12:32:03 -0400
Received: by world.std.com (5.65c/Spike-2.0)
id AA28519; Fri, 13 May 1994 12:32:01 -0400
Date: Fri, 13 May 1994 12:32:01 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike Bloom <dpi at world.std.com>
Message-Id: <199405131632.AA28519 at world.std.com>
To: jgyllens at hpdmd48.boi.hp.com, pmi at hpbs907.boi.hp.com
Subject: Re: May meeting agenda
Cc: ietf-announce-post at CNRI.Reston.VA.US
I suggest that community names topic include consideration of applicability to internal print servers (physically within the printer) as well as external devices driving multiple printers. Initial idea that these have HostRes MIBs> I wouldlike comment?BW
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08700;
13 May 94 13:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13713;
13 May 94 13:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08664;
13 May 94 13:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08589;
13 May 94 13:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rmonmib at jarthur.claremont.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-rmonmib-rmonmib-01.txt
Date: Fri, 13 May 94 13:25:59 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405131326.aa08589 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Remote LAN Monitoring Working
Group of the IETF.
Title : Remote Network Monitoring Management Information Base
Author(s) : S. Waldbusser
Filename : draft-ietf-rmonmib-rmonmib-01.txt
Pages : 101
Date : 05/12/1994
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing remote network
monitoring devices.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-rmonmib-rmonmib-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rmonmib-rmonmib-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940512090038.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-rmonmib-rmonmib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmonmib-rmonmib-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940512090038.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08826;
13 May 94 13:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08812;
13 May 94 13:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13836;
13 May 94 13:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08799;
13 May 94 13:32 EDT
Received: from darpa.mil by IETF.CNRI.Reston.VA.US id aa08763;
13 May 94 13:31 EDT
Received: from next24.darpa.mil (next24.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5)
id <AA20464>; Fri, 13 May 1994 13:31:30 -0400
Received: by next24.darpa.mil (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
id AA00763; Fri, 13 May 94 13:28:05 EDT
Date: Fri, 13 May 1994 13:28:04 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: BLeiner at arpa.mil
Subject: ARPA BAA 94-28 - NIE
To: ietf at isoc.org
Message-Id: <940513132804.449AABmT.bleiner at next24>
Mime-Version: 1.0 (Generated by Eloquent)
Content-Type: text/plain; charset=US-ASCII
X-Mailer: Eloquent [1.01c]; Eloquent is a Trademark of Take Three
I thought some of you might find this of interest.
Barry
--------------
THIS IS NOT THE OFFICIAL COPY. THAT APPEARS IN THE CBD.
Appeared 10 May 94
NATIONAL-SCALE INFORMATION ENTERPRISES (NIE) SOL BAA94-28 DUE
082294 POC
Randy H. Katz, Barry M. Leiner, ARPA/CSTO, FAX: (703)522-2668.
The Advanced
Research Projects Agency (ARPA) is soliciting proposals
for its
National-scale Information Enterprises (NIE) Program. The goal
of the NIE
Program is to develop revolutionary new computing systems'
technology to
enable applications developers to demonstrate prototype
solutions to
National Challenge problems. The technology is based on those
developed for
High Performance Computing and Communications (HPCC) but
exhibits more
extensive capabilities for ubiquitous information access, dynamic
discovery
of and adaptation to new resources, linkage of objects
and their
dissemination and distribution over internetworked distributed
systems, and
trusted system operation on behalf of users and applications. To
drive the
development of these technologies, the program supports
integrated systems
technology demonstration projects for selected National
Challenge
applications. In particular, the program will develop the
underlying
technology base for the fundamental enabling applications
of Digital
Libraries and Electronic Commerce. This BAA focuses on research
interests
in the following three technical areas: 1) Information
Infrastructure
Services: These are the bitway-enabled technologies that
provide a
ubiquitously available, network-aware, adaptive interface
upon which to
construct complex applications. These include, but are not
limited to,
universal information infrastructure access points, dynamic
partitioning of
applications logic among heterogeneous nodes, mechanisms for
applications
to negotiate for and adapt to the available quality of
service, and
mechanisms for a common authentication, authorization,
accounting/banking,
usage metering, and charging infrastructure for networks. 2)
Information
Infrastructure Software Development Tools: Innovative
mechanisms and
development tools are needed to support the rapid
development of new
services and services-enabled applications composed from
modular building
blocks. Techniques of interest include, but are not
limited to,
self-describing service interfaces and modules that can negotiate
with each
other to reach a common communications protocol, new
methods for
encapsulating existing services for more dynamic and
adaptive use, and
mechanisms such as advanced Yellow Page services for resource
registration
and discovery of available services and service building
blocks in a
complex, internetworked environment. 3) Information
Infrastructure
Applications Demonstrations: The program will demonstrate
technology for
applications like Digital Libraries and Electronic Commerce
which enable
larger scale applications requiring capabilities for large
repositories of
network-linked objects, adaptation to a changing resource
environment,
usage metering, accounting, and payment, and privacy-enhanced,
secure, and
trusted processing on behalf of users and programs. The
purpose is to
validate developed technologies through use by modest-
sized user
communities to drive the evolution of services. Proposals
will be
considered in independent areas as well as across multiple areas.
Technical
Points of Contact: Randy H. Katz, Barry M. Leiner. The
focus of this
solicitation is on revolutionary prototype information
infrastructure
services and their pilot demonstration. It is expected that
these services
will form the foundation for a generation beyond that which
is already
envisioned to exist within the next three years.
Nevertheless,
collaborative university/industry research and development is
desirable to
ensure technology transfer. Teaming arrangements and cost
sharing are
encouraged where appropriate, especially when coupling
services
developments to applications demonstrations. However,
teaming is not
essential in all of the technical areas of research. Further
details on
individual topic areas are available in the BAA 94-28 Proposer
Information
Pamphlet. PROGRAM SCOPE: Proposals for individual efforts should
not exceed
three years in length. Technologies which have a broad impact
will be given
highest priority. Contract awards are expected to be made during
the first
half of fiscal year 1995. Total funding is expected to be
approximately
$30,000,000 over three years. Multiple awards will be made.
Collaborative
efforts and teaming are encouraged where appropriate. GENERAL
INFORMATION:
In order to minimize unnecessary effort in proposal preparation
and review,
proposers are strongly encouraged to submit brief proposal
abstracts in
advance of full proposals. An original and four (4) copies of
the proposal
abstract must be submitted to ARPA/CSTO, 3701 North
Fairfax Drive,
Arlington, VA 22203-1714, (ATTN: BAA 94-28) on or before 4:00
PM, June 17,
1994. Proposal abstracts received after this date may not be
reviewed. Upon
review, ARPA will provide written feedback on the likelihood
of a full
proposal being selected. Proposers must submit an original
and four (4)
copies of full proposals by 4:00 PM, August 22, 1994, in
order to be
considered. Proposers must obtain a pamphlet, BAA 94-28
Proposer
Information, which provides further information on areas of
interest, the
submission, evaluation, funding processes, proposal and
proposal abstract
formats. This pamphlet may be obtained by fax, electronic
mail, or mail
request to the administrative contact address given below.
Proposals not
meeting the format described in the pamphlet may not be
reviewed. This
notice, in conjunction with the pamphlet BAA 94-28 Proposer
Information,
constitutes the total BAA. No additional information is
available, nor will
a formal RFP or other solicitation regarding this announcement
be issued.
Requests for same will be disregarded. The Government reserves
the right to
select for award all, some, or none of the proposals
received. All
responsible sources capable of satisfying the Government's needs
may submit
a proposal which shall be considered by ARPA. Historically
Black Colleges
and Universities (HBCU) and Minority Institutions (MI) are
encouraged to
submit proposals and join others in submitting proposals,
however, no
portion of this BAA will be set aside for HBCU and MI
participation due to
the impracticality of reserving discrete or severable areas of
research in
NIE. Evaluation of proposals will be accomplished through a
technical
review of each proposal using the following criteria, which are
listed in
descending order of relative importance: (1) overall
scientific and
technical merit, (2) potential contribution and relevance to
ARPA mission,
(3) plans and capability to accomplish technology transition, (4)
offeror's
capabilities and related experience, and (5) cost realism.
Note: Cost
realism will only be significant in proposals which have
significantly
under or over estimated the cost to complete their
effort. All
administrative correspondence and questions on this solicitation,
including
requests for information on how to submit a proposal abstract
or proposal
to this BAA, should be directed to one of the administrative
addresses
below, e-mail or fax is preferred. ARPA intends to use
electronic mail and
fax for correspondence regarding BAA 94-28. Proposals and
proposal
abstracts may not submitted by fax, any so sent will be
disregarded. The
administrative addresses for this BAA are: Fax: 703-522-2668
Addressed to:
ARPA/CSTO, BAA 94-28, Electronic Mail: BAA9428 at arpa.mil Mail:
ARPA/CSTO,
ATTN: BAA 94-28, 3701 N. Fairfax Drive, Arlington, VA 22203-1714
(0126)
SPONSOR: Advanced Research Projects Agency (ARPA), Contracts
Management
Office (CMO), 3701 North Fairfax Drive, Arlington, VA
22203-1714
SUBFILE: PSE (U.S. GOVERNMENT PROCUREMENTS, SERVICES)
SECTION HEADING: A Research and Development
PUBLICATION DATE: MAY 10, 1994
ISSUE: PSA-1092
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12582;
13 May 94 16:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12569;
13 May 94 16:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18646;
13 May 94 16:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12546;
13 May 94 16:30 EDT
Received: from darpa.mil by IETF.CNRI.Reston.VA.US id aa12442;
13 May 94 16:27 EDT
Received: from next24.darpa.mil (next24.darpa.mil) by vax.darpa.mil (5.65c/5.61+local-5)
id <AA24910>; Fri, 13 May 1994 16:27:07 -0400
Received: by next24.darpa.mil (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
id AA00984; Fri, 13 May 94 16:24:56 EDT
Date: Fri, 13 May 1994 16:24:55 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: BLeiner at arpa.mil
Subject: ARPA BAA 94-28 - NIE (reformatted)
To: ietf at isoc.org
Message-Id: <940513162455.449AABme.bleiner at next24>
Mime-Version: 1.0 (Generated by Eloquent)
Content-Type: text/plain; charset=US-ASCII
X-Mailer: Eloquent [1.01c]; Eloquent is a Trademark of Take Three
Sorry for the bad format. Hope this is better. and I hope you
find
it of interest.
Barry
-------------
Due to the possibility of transcription errors, the official CBD
announcement takes precedence over this transcription in any
disagreement between the two. The transcription is provided for
your
convenience only.
Appeared in CBD 10 May 1994
NATIONAL-SCALE INFORMATION ENTERPRISES (NIE) SOL BAA94-28 DUE
082294 POC Randy H. Katz, Barry M. Leiner, ARPA/CSTO, FAX:
(703)522-2668. The Advanced Research Projects Agency (ARPA) is
soliciting proposals for its National-scale Information
Enterprises (NIE) Program. The goal of the NIE Program is to
develop revolutionary new computing systems' technology to enable
applications developers to demonstrate prototype solutions to
National Challenge problems. The technology is based on those
developed for High Performance Computing and Communications
(HPCC) but exhibits more extensive capabilities for ubiquitous
information access, dynamic discovery of and adaptation to new
resources, linkage of objects and their dissemination and
distribution over internetworked distributed systems, and trusted
system operation on behalf of users and applications. To drive
the development of these technologies, the program supports
integrated systems technology demonstration projects for selected
National Challenge applications. In particular, the program will
develop the underlying technology base for the fundamental
enabling applications of Digital Libraries and Electronic
Commerce. This BAA focuses on research interests in the following
three technical areas: 1) Information Infrastructure Services:
These are the bitway-enabled technologies that provide a
ubiquitously available, network-aware, adaptive interface upon
which to construct complex applications. These include, but are
not limited to, universal information infrastructure access
points, dynamic partitioning of applications logic among
heterogeneous nodes, mechanisms for applications to negotiate for
and adapt to the available quality of service, and mechanisms for
a common authentication, authorization, accounting/banking, usage
metering, and charging infrastructure for networks. 2)
Information Infrastructure Software Development Tools: Innovative
mechanisms and development tools are needed to support the rapid
development of new services and services-enabled applications
composed from modular building blocks. Techniques of interest
include, but are not limited to, self-describing service
interfaces and modules that can negotiate with each other to
reach a common communications protocol, new methods for
encapsulating existing services for more dynamic and adaptive
use, and mechanisms such as advanced Yellow Page services for
resource registration and discovery of available services and
service building blocks in a complex, internetworked environment.
3) Information Infrastructure Applications Demonstrations: The
program will demonstrate technology for applications like Digital
Libraries and Electronic Commerce which enable larger scale
applications requiring capabilities for large repositories of
network-linked objects, adaptation to a changing resource
environment, usage metering, accounting, and payment, and
privacy-enhanced, secure, and trusted processing on behalf of
users and programs. The purpose is to validate developed
technologies through use by modest-sized user communities to
drive the evolution of services. Proposals will be considered in
independent areas as well as across multiple areas. Technical
Points of Contact: Randy H. Katz, Barry M. Leiner. The focus of
this solicitation is on revolutionary prototype information
infrastructure services and their pilot demonstration. It is
expected that these services will form the foundation for a
generation beyond that which is already envisioned to exist
within the next three years. Nevertheless, collaborative
university/industry research and development is desirable to
ensure technology transfer. Teaming arrangements and cost sharing
are encouraged where appropriate, especially when coupling
services developments to applications demonstrations. However,
teaming is not essential in all of the technical areas of
research. Further details on individual topic areas are available
in the BAA 94-28 Proposer Information Pamphlet. PROGRAM SCOPE:
Proposals for individual efforts should not exceed three years in
length. Technologies which have a broad impact will be given
highest priority. Contract awards are expected to be made during
the first half of fiscal year 1995. Total funding is expected to
be approximately $30,000,000 over three years. Multiple awards
will be made. Collaborative efforts and teaming are encouraged
where appropriate. GENERAL INFORMATION: In order to minimize
unnecessary effort in proposal preparation and review, proposers
are strongly encouraged to submit brief proposal abstracts in
advance of full proposals. An original and four (4) copies of the
proposal abstract must be submitted to ARPA/CSTO, 3701 North
Fairfax Drive, Arlington, VA 22203-1714, (ATTN: BAA 94-28) on or
before 4:00 PM, June 17, 1994. Proposal abstracts received after
this date may not be reviewed. Upon review, ARPA will provide
written feedback on the likelihood of a full proposal being
selected. Proposers must submit an original and four (4) copies
of full proposals by 4:00 PM, August 22, 1994, in order to be
considered. Proposers must obtain a pamphlet, BAA 94-28 Proposer
Information, which provides further information on areas of
interest, the submission, evaluation, funding processes, proposal
and proposal abstract formats. This pamphlet may be obtained by
fax, electronic mail, or mail request to the administrative
contact address given below. Proposals not meeting the format
described in the pamphlet may not be reviewed. This notice, in
conjunction with the pamphlet BAA 94-28 Proposer Information,
constitutes the total BAA. No additional information is
available, nor will a formal RFP or other solicitation regarding
this announcement be issued. Requests for same will be
disregarded. The Government reserves the right to select for
award all, some, or none of the proposals received. All
responsible sources capable of satisfying the Government's needs
may submit a proposal which shall be considered by ARPA.
Historically Black Colleges and Universities (HBCU) and Minority
Institutions (MI) are encouraged to submit proposals and join
others in submitting proposals, however, no portion of this BAA
will be set aside for HBCU and MI participation due to the
impracticality of reserving discrete or severable areas of
research in NIE. Evaluation of proposals will be accomplished
through a technical review of each proposal using the following
criteria, which are listed in descending order of relative
importance: (1) overall scientific and technical merit, (2)
potential contribution and relevance to ARPA mission, (3) plans
and capability to accomplish technology transition, (4) offeror's
capabilities and related experience, and (5) cost realism. Note:
Cost realism will only be significant in proposals which have
significantly under or over estimated the cost to complete their
effort. All administrative correspondence and questions on this
solicitation, including requests for information on how to submit
a proposal abstract or proposal to this BAA, should be directed
to one of the administrative addresses below, e-mail or fax is
preferred. ARPA intends to use electronic mail and fax for
correspondence regarding BAA 94-28. Proposals and proposal
abstracts may not submitted by fax, any so sent will be
disregarded. The administrative addresses for this BAA are: Fax:
703-522-2668 Addressed to: ARPA/CSTO, BAA 94-28, Electronic Mail:
BAA9428 at arpa.mil Mail: ARPA/CSTO, ATTN: BAA 94-28, 3701 N.
Fairfax Drive, Arlington, VA 22203-1714 (0126)
SPONSOR: Advanced Research Projects Agency (ARPA),
Contracts Management Office (CMO)
3701 North Fairfax Drive
Arlington, VA 22203-1714
SUBFILE: PSE (U.S. GOVERNMENT PROCUREMENTS, SERVICES)
SECTION HEADING: A Research and Development
PUBLICATION DATE: MAY 10, 1994
ISSUE: PSA-1092
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12737;
13 May 94 16:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12729;
13 May 94 16:37 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa18811;
13 May 94 16:37 EDT
Received: by bitsy.MIT.EDU
id AA28756; Fri, 13 May 94 16:22:35 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA28748; Fri, 13 May 94 16:22:33 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA06322; Fri, 13 May 94 16:22:22 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA17335 at pad-thai.aktis.com>; Fri, 13 May 1994 16:21:43 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA06274; Fri, 13 May 94 16:21:34 EDT
Message-Id: <9405132021.AA06274 at winkl.aktis.com>
To: dpg at ocsg.com
Cc: Theodore Ts'o <tytso at mit.edu>, John Linn <linn at cam.ov.com>,
cat-ietf at mit.edu, gssapi at ocsg.com, linn at cam.ov.com
Subject: Re: Questions regarding GGS/Kerberos names
In-Reply-To: Your message of "Thu, 12 May 1994 18:23:10 PDT."
<9405130123.AA21235 at war04.ocsg.com>
Date: Fri, 13 May 1994 16:21:33 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
I can't at the moment jump into all the questions that have recently been
raised, but would like to make a few comments:
(1) As noted, it is true that the implementation in Beta 3 is capable
of importing a principal object in addition to being able to accept a
printable principal name. This is an extra feature, convenient for
some applications although not what was contemplated when 1508 was
written; while the function of GSS_Display_name() clearly implies that
it should produce only a printable output form, a goal of flexible use
by applications suggests that it might be helpful to accept other
forms of input to GSS_Import_name() in addition. If there's support
for this, we should consider rewording the text describing importable
names when the RFCs are next revised, to broaden the definition. If
the group sentiment is against it, the principal name type can be
removed from the KV5 I-D.
>My concern is two fold. First, to support native name forms may
>encourage application programmers to seek service in mechanism's
>libraries possibly circumventing security. My second concern is the
>utility of native name forms.
I don't think that the set of name types a GSS-API implementation
supports will govern the set of non-GSS-API interfaces which an
application uses and from which it may receive names or other objects.
>Suppose for a moment native name forms are stricken from the GSS
>specification. What is left? I believe, native name forms
>presented as strings.
It is, of course, possible to accomplish the same function by
requiring the application to call a translation routine itself. It's
not clear to me why this approach, which could certainly force an
application to call a mechanism-specific routine, is intrinsically
preferable in terms of minimizing the degree to which (per prior
quoted paragraph) applications deal directly with mechanisms.
(2) The intro text to the name type section specifically states: "It
is understood that not all implementations of the Kerberos V5 GSS-API
mechanism need support all name types in this list, and that
additional name forms will likely be added to this list over time."
Support for the entire set isn't a conformance requirement.
--jl
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15528;
13 May 94 19:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22562;
13 May 94 19:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15483;
13 May 94 19:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15406;
13 May 94 19:51 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22500;
13 May 94 19:51 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA26985>; Fri, 13 May 1994 16:51:19 -0700
Message-Id: <199405132351.AA26985 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1613 on X.25 Over TCP (XOT)
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 13 May 94 16:51:33 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1613:
Title: cisco Systems X.25 over TCP (XOT)
Author: J. Forster, G. Satz, G. Glick & R. Day
Mailbox: forster at cisco.com, satz at cisco.com,
gglick at cisco.com, R.Day at jnt.ac.uk
Pages: 13
Characters: 29,267
Updates/Obsoletes: none
It is sometimes desirable to transport X.25 over IP internets. The
X.25 Packet Level requires a reliable link level below it and
normally uses LAPB. This memo documents a method of sending X.25
packets over IP internets by encapsulating the X.25 Packet Level in
TCP packets.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940513164731.RFC at ISI.EDU>
SEND /rfc/rfc1613.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1613.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940513164731.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15635;
13 May 94 19:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22645;
13 May 94 19:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15624;
13 May 94 19:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15576;
13 May 94 19:57 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22601;
13 May 94 19:57 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA27060>; Fri, 13 May 1994 16:56:56 -0700
Message-Id: <199405132356.AA27060 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1618 on PPP over ISDN
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 13 May 94 16:57:10 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1618:
Title: PPP over ISDN
Author: W. Simpson
Mailbox: Bill.Simpson at um.cc.umich.edu
Pages: 8
Characters: 14,896
Updates/Obsoletes: none
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. This
document describes the use of PPP over Integrated Services Digital
Network (ISDN) switched circuits. This document is the product of the
Point-to-Point Protocol Extensions Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940513165214.RFC at ISI.EDU>
SEND /rfc/rfc1618.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1618.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940513165214.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15786;
13 May 94 20:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22709;
13 May 94 20:03 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15756;
13 May 94 20:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15663;
13 May 94 20:01 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22691;
13 May 94 20:01 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA27130>; Fri, 13 May 1994 17:01:28 -0700
Message-Id: <199405140001.AA27130 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1619 on PPP over SONET/SDH
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 13 May 94 17:01:42 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1619:
Title: PPP over SONET/SDH
Author: W. Simpson
Mailbox: Bill.Simpson at um.cc.umich.edu
Pages: 6
Characters: 8,893
Updates/Obsoletes: none
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. This
document describes the use of PPP over Synchronous Optical Network
(SONET) and Synchronous Digital Heirarchy (SDH) circuits. This
document is the product of the Point-to-Point Protocol Extensions
Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940513165842.RFC at ISI.EDU>
SEND /rfc/rfc1619.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1619.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940513165842.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20092;
13 May 94 22:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20080;
13 May 94 22:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25289;
13 May 94 22:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20067;
13 May 94 22:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18504;
13 May 94 22:52 EDT
Received: from nic.cerf.net by CNRI.Reston.VA.US id aa25235; 13 May 94 22:52 EDT
Received: from sunburst (solsource.com [134.24.1.241]) by nic.cerf.net (8.6.7/8.6.6) with SMTP id TAA09088; Fri, 13 May 1994 19:51:02 -0700
Received: from supernova.sunburst by sunburst (4.1/SMI-4.1)
id AA29177; Fri, 13 May 94 19:50:34 PDT
Received: by supernova.sunburst (4.1/SMI-4.1)
id AA01190; Fri, 13 May 94 19:50:15 PDT
Date: Fri, 13 May 94 19:50:15 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Dan O. Nadir" <dano at solsource.com>
Message-Id: <9405140250.AA01190 at supernova.sunburst>
To: sob at harvard.edu, ebear at presto.com
Subject: Re: Lawyers
Cc: ietf at isoc.org, harmon at tenet.edu, network at world.std.com
I think we've all got the wrong idea here...
Like it or not, there are those out there who
are going to do whatever they can to make a buck,
screw the rest of us.
I've got a solution so simple I'm amazed that I never
thought of it before!
Don't waste time complaining to their provider, etc.
SEND A REPLY DIRECTLY TO THEM ASKING FOR MORE INFORMATION.
CALL THEIR 800 NUMBER, FAX THEM, E-MAIL THEM.
When these brilliant marketing wizards get thousands of
replies, they will be overwhelmed, they won't be able
to accurately determine who, if anyone, REALLY is interested
in the crap they are pushing. Let them spend lots of $$
to send us ALL their glossy datasheets (which I'll promptly
toss). After about the first 10,000, they will realize that
marketing like this is a complete waste of time. Let's
turn the lure of thousands of readers AGAINST THEM!
If you think this is a good idea, pass it along. If you don't,
sorry for wasting bandwidth!
Dan
> From ietf-request at ietf.nri.reston.va.us Wed May 11 19:23:36 1994
> Subject: Lawyers
> To: sob at harvard.edu
> Date: Wed, 11 May 94 18:49:30 PDT
> Sender: ietf-request at IETF.CNRI.Reston.VA.US
> From: Eric Bear Albrecht <ebear at presto.com>
> Cc: ietf at isoc.org, harmon at tenet.edu, network at world.std.com
> Content-Length: 1384
>
> to: Scott Bradner
> cc: ietf, since there is no imtf (internet manners task force)
> Network World
>
> This is about the smug lawyers who blasted the net with ads
> as reported in Network World 5/2/94
>
> Let's take this one step at a time.
>
> Are we going to tolerate it? Kiss the internet culture goodbye.<-----
> If no, then we have to do something about it. |
> Not doing something about it is tolerating it, by definition. |
> If we don't do something about it, go back three spaces --------------
>
> Doing something about it might include:
> E-mail to their service provider demanding termination of their access;
> Filing a class-action suit for the resources they used up;
> Complaints to American Bar Association regarding unethical behaviour
> (and to their state association and courts).
> Picketing their office.
>
> And don't withhold their names; we have to know who these people are in
> order to deal with them. There's no "rights of the accused" at work here.
>
> I don't get any usenet stuff since I'm long distance from _everything_
> so I don't qualify as a member of the class for a suit, but I sure as
> hell will complain to the ABA if I know who to complain about.
>
> "Hadn't done anything wrong", ha!.
> Only if we sit on our butts will it be so.
>
>
> Eric K. Albrecht ....
> ebear at presto.com ....
> Presto Computers ....
> Taos, New Mexico ....
>
>
Dan Nadir
Solsource Computers
dano at solsource.com
619-929-7800 x308 voice 5928 Pascal Ct. Suite 201
619-929-7810 fax Carlsbad, CA 92008
*You could say I've lost my faith in the politicians...
They all seem like game show hosts to me...* Sting
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20181;
13 May 94 23:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20169;
13 May 94 23:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25380;
13 May 94 23:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20158;
13 May 94 23:01 EDT
Received: from hsdndev.harvard.edu by IETF.CNRI.Reston.VA.US id aa20121;
13 May 94 22:59 EDT
Date: Fri, 13 May 94 22:59:39 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Scott Bradner <sob at hsdndev.harvard.edu>
Message-Id: <9405140259.AA18802 at hsdndev.harvard.edu>
To: dano at solsource.com, ebear at presto.com, sob at harvard.edu
Subject: Re: Lawyers
Cc: harmon at tenet.edu, ietf at isoc.org, network at world.std.com
> SEND A REPLY DIRECTLY TO THEM ASKING FOR MORE INFORMATION.
CALL THEIR 800 NUMBER, FAX THEM, E-MAIL THEM.
I don't think this scales over the long term, I think we need
some sort of general stick. Could be along the lines of tyhe
anti junk-fax rules.
Scott
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03239;
15 May 94 15:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03235;
15 May 94 15:14 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa08648; 15 May 94 15:14 EDT
Received: from hpdmd48.boi.hp.com by hp.com with SMTP
(1.36.108.7/15.5+IOS 3.13) id AA25790; Sun, 15 May 1994 12:14:56 -0700
Received: from hpbs907.boi.hp.com by hpdmd48.boi.hp.com with SMTP
(1.37.109.4/15.5+IOS 3.21+OM) id AA20499; Sun, 15 May 94 12:58:00 -0600
Received: from relay.hp.com by hpbs907.boi.hp.com with SMTP
(16.6/15.5+IOS 3.12) id AA20608; Sun, 15 May 94 12:31:29 -0600
Received: from gatekeeper.imagen.com by relay.hp.com with SMTP
(1.37.109.8/15.5+ECS 3.3) id AA17110; Sun, 15 May 1994 11:37:21 -0700
Received: from imagen.sclara.qms.com (imagen.imagen.com) by gatekeeper.imagen.com (4.1/SMI-4.1)
id AA24250; Sun, 15 May 94 11:34:38 PDT
Received: from sun470.rd.qms.com (sun470-t1) by imagen.sclara.qms.com (4.1/SMI-4.1)
id AA28771; Sun, 15 May 94 11:34:37 PDT
Received: from jrtipc.rd.qms.com.rd.qms.com by sun470.rd.qms.com (4.1/SMI-4.1)
id AA09882; Sun, 15 May 94 13:22:27 CDT
Received: by jrtipc.rd.qms.com.rd.qms.com (4.1) id AA04004; Sun, 15 May 94 13:23:36 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Randy Turner <rturner at sun470.rd.qms.com>
Message-Id: <9405151323.ZM4002 at jrtipc.rd.qms.com>
Date: Sun, 15 May 1994 13:23:35 -0500
In-Reply-To: dpi at world.std.com (Mike Bloom)
"Re: May meeting agenda" (May 13, 12:32pm)
References: <199405131632.AA28519 at world.std.com>
X-Mailer: Z-Mail (3.0.0 15dec93)
To: Mike Bloom <dpi at world.std.com>, pmi at hpbs907.boi.hp.com
Subject: Re: May meeting agenda (Community names)
Cc: ietf-announce-post at CNRI.Reston.VA.US
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
On May 13, 12:32pm, Mike Bloom wrote:
> Subject: Re: May meeting agenda
> I suggest that community names topic include consideration of applicability
to internal print servers (physically within the printer) as well as external
devices driving multiple printers. Initial idea that these have HostRes MIBs> I
wouldlike comment?BW
>-- End of excerpt from Mike Bloom
The problem with using community names for anything but a physical printer
SNMP agent, is that the community name is a global access identifier to
any MIB that the agent has access to. It would be difficult to implement
the proposal that I made at the last meeting to cover something like
a Windows/NT server whose SNMP agent also has access to the printer
MIB. If the NT agent uses community names for secure access to the MIB(s),
then it would depend where in the agent code the check for community
name is made.
It really depends on how the agent is implemented. If it is a "distributed"
agent, the "core" agent only does some small amount of protocol processing
before passing the remainder of the packet off to some other "sub-agent"
capable of satisfying the request ( kinda like proxy SNMPD capability). If
this is the case, then the printer MIB handler might not ever see the
community name string and therefore cannot index the appropriate logical
printer database.
This problem goes back to the original sticking point in
using community names to address logical printers; in that we are
"overloading" the original intended use of community names and therefore
stepping outside our administrative domain of specification.
R.
--
/* Rt */
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04473;
16 May 94 10:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04469;
16 May 94 10:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07841;
16 May 94 10:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04458;
16 May 94 10:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04454;
16 May 94 10:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07836;
16 May 94 10:12 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04449;
16 May 94 10:12 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: snanaumib at thumper.bellcore.com
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Definitions of Managed Objects for SNA NAUs to Proposed
Standard
Date: Mon, 16 May 94 10:12:45 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405161012.aa04449 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the SNA NAU Services MIB
Working Group to consider "Definitions of Managed Objects for SNA
NAUs" <draft-ietf-snanau-snamib-04.txt> for the status of Proposed
Standard.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any comments
to the iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing
lists by 30 May.
Note: This is the second Last Call for this document. An earlier
version (snamib-03) was reviewed by the NM Area Directorate and
approved by the IESG. Prior to RFC publication, the working group
found an error in one of the table indexes, and this new draft
(snamib-04) was completed.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04942;
16 May 94 10:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04938;
16 May 94 10:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08258;
16 May 94 10:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04927;
16 May 94 10:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04922;
16 May 94 10:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08252;
16 May 94 10:29 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04917;
16 May 94 10:29 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: if-mib at thumper.bellcore.com
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Definitions of Managed Objects for the Ethernet-like
Interface Types to Standard
Date: Mon, 16 May 94 10:29:41 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405161029.aa04917 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Interfaces MIB Working Group
to consider "Definitions of Managed Objects for the Ethernet-like
Interface Types" <draft-ietf-ifmib-ethmib-smiv2-00.txt> for the status
of Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
30 May.
Note: This is the same MIB module as
draft-ietf-ifmib-ethmib-smiv1-00.txt, but is written using the SNMPv2
SMI. The SNMPv1 version of this MIB was approved by the IESG for
publication as an Internet Standard.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07059;
16 May 94 11:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10402;
16 May 94 11:38 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07048;
16 May 94 11:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06924;
16 May 94 11:34 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-magnalink-01.txt
Date: Mon, 16 May 94 11:34:19 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405161134.aa06924 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP Magnalink Variable Resource Compression
Author(s) : D. Schremp, J. Black, J. Weiss
Filename : draft-ietf-pppext-magnalink-01.txt
Pages : 6
Date : 05/13/1994
The Point-to-Point Protocol (PPP) provides a standard method of
encapsulating multiple protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method for negotiating
data compression over PPP links.
The Magnalink Variable Resource Compression Algorithm (MVRCA) allows
a wide range of interoperable compression implementations whose performance
characteristics are a function of available CPU and memory resources.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-magnalink-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-magnalink-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940513105929.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pppext-magnalink-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-magnalink-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940513105929.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07892;
16 May 94 12:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11123;
16 May 94 12:07 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07872;
16 May 94 12:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07716;
16 May 94 12:05 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-estrin-ipng-unified-routing-00.txt
Date: Mon, 16 May 94 12:05:26 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405161205.aa07716 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Unified Routing Requirements for IPng
Author(s) : D. Estrin, T. Li, Y. Rekhter
Filename : draft-estrin-ipng-unified-routing-00.txt
Pages : 2
Date : 05/13/1994
This document was submitted to the IETF IPng area in response to RFC 1550.
Publication of this document does not imply acceptance by the IPng area of
any ideas expressed within. Comments should be submitted to the
big-internet at munnari.oz.au mailing list.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-estrin-ipng-unified-routing-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-estrin-ipng-unified-routing-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940513143436.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-estrin-ipng-unified-routing-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-estrin-ipng-unified-routing-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940513143436.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10020;
16 May 94 13:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10012;
16 May 94 13:40 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa13179;
16 May 94 13:40 EDT
Received: by bitsy.MIT.EDU
id AA00940; Mon, 16 May 94 13:27:56 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA00932; Mon, 16 May 94 13:27:51 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA24010; Mon, 16 May 94 13:27:30 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA17556; Mon, 16 May 94 10:06:29 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA00844; Mon, 16 May 94 13:05:38 -0400
Message-Id: <9405161705.AA00844 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Mon, 16 May 94 13:05:42 EDT
Date: Mon, 16 May 94 13:05:42 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 16-May-1994 0947" <wray at tuxedo.enet.dec.com>
To: linn at cam.ov.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Questions regarding GGS/Kerberos names
>(2) The intro text to the name type section specifically states: "It
>is understood that not all implementations of the Kerberos V5 GSS-API
>mechanism need support all name types in this list, and that
>additional name forms will likely be added to this list over time."
>Support for the entire set isn't a conformance requirement.
This has always bothered me. What benefits are gained from including
"optional" features in an API spec? If an application implementor wants his
application to be portable, he can't use any features flagged as "optional", so
why should they appear in the ID, rather than supplementary documentation for a
given implementation? I would prefer to see the ID contain a small set of
name-types that all implementations must support, and leave it up to individual
implementations to add additional types if they want.
>(1) As noted, it is true that the implementation in Beta 3 is capable
>of importing a principal object in addition to being able to accept a
>printable principal name. This is an extra feature, convenient for
>some applications although not what was contemplated when 1508 was
>written; while the function of GSS_Display_name() clearly implies that
>it should produce only a printable output form, a goal of flexible use
>by applications suggests that it might be helpful to accept other
>forms of input to GSS_Import_name() in addition. If there's support
>for this, we should consider rewording the text describing importable
>names when the RFCs are next revised, to broaden the definition. If
>the group sentiment is against it, the principal name type can be
>removed from the KV5 I-D.
I think that this function should be provided by an implementation-specific
extension routine (eg import_kerberos_principal()), rather than overloading a
gssapi routine.
It certainly seems wrong to pass a krb5_principal object to a routine using a
gss_buffer_t, anyway. The gss_buffer_t datatype is explicitly designed for
passing contiguous byte arrays, not structured data.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10156;
16 May 94 13:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10152;
16 May 94 13:48 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa13374;
16 May 94 13:48 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.8.1/1.2)
id LAA00292; Mon, 16 May 1994 11:47:26 -0600
Received: by noc-gw.lanl.gov (8.6.8.1/SMI-4.1)
id LAA17809; Mon, 16 May 1994 11:46:31 -0600
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.8.1/SMI-4.1)
id LAA17806; Mon, 16 May 1994 11:46:30 -0600
Received: from IETF.nri.reston.VA.US by mailhost.lanl.gov (8.6.8.1/1.2)
id LAA00204; Mon, 16 May 1994 11:46:31 -0600
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10081;
16 May 94 13:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, CNRI.Reston.VA.US at noc-gw.lanl.gov
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
cc: tuba at lanl.gov
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-tuba-inlsp-00.txt
Date: Mon, 16 May 94 13:44:14 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405161344.aa10081 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the TCP/UDP Over CLNP-Addressed
Networks Working Group of the IETF.
Title : Integrated Network Layer Security Protocol For TUBA
Author(s) : K. Robert Glenn
Filename : draft-ietf-tuba-inlsp-00.txt
Pages : 25
Date : 05/13/1994
This Internet Draft specifies a protocol that may be used by End Systems
(ESs) and Intermediate Systems (ISs) in order to provide security services
in support of TUBA. The TUBA deployment and transition plan relies on a
dual-stack (i.e., CLNP and IPv4) approach to evolving the Internet to IPng.
Thus, to provide secure operation in an TUBA environment this Internet
Draft defines a simple Integrated Network Layer Security Protocol (I-NLSP)
that provides confidentiality and integrity services for both CLNP and
IPv4. TUBA systems supporting I-NLSP will be capable of secure operations
with: (1) other TUBA/I-NLSP systems using either CLNP or IP, and or (2)
existing IPv4 operating behind TUBA/I-NLSP capable secure ISs.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tuba-inlsp-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tuba-inlsp-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940513155324.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-tuba-inlsp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tuba-inlsp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940513155324.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11702;
16 May 94 14:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15832;
16 May 94 14:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11668;
16 May 94 14:59 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11534;
16 May 94 14:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-smtp at dimacs.rutgers.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-smtpext-size-01.txt
Date: Mon, 16 May 94 14:55:47 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405161455.aa11534 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Mail Extensions
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : SMTP Service Extension for Message Size Declaration
Author(s) : J. Klensin, N. Freed, K. Moore
Filename : draft-ietf-smtpext-size-01.txt
Pages : 8
Date : 05/13/1994
This memo defines an extension to the SMTP service whereby an SMTP client
and server may interact to give the server an opportunity to decline to
accept a message (perhaps temporarily) based on the client's estimate of
the message size.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-smtpext-size-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-smtpext-size-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940513142110.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-smtpext-size-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smtpext-size-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940513142110.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11705;
16 May 94 14:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15835;
16 May 94 14:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11674;
16 May 94 14:59 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11577;
16 May 94 14:56 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-smtp at dimacs.rutgers.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-smtpext-8bitmime-01.txt
Date: Mon, 16 May 94 14:56:00 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405161456.aa11577 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Mail Extensions
Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : SMTP Service Extension for 8bit-MIMEtransport
Author(s) : J. Klensin, N. Freed, M. Rose,
E. Stefferud, D. Crocker
Filename : draft-ietf-smtpext-8bitmime-01.txt
Pages : 7
Date : 05/13/1994
This memo defines an extension to the SMTP service whereby an SMTP content
body consisting of text containing octets outside of the US ASCII octet
range (hex 00-7F) may be relayed using SMTP.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-smtpext-8bitmime-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-smtpext-8bitmime-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940513140201.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-smtpext-8bitmime-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smtpext-8bitmime-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940513140201.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11708;
16 May 94 14:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15833;
16 May 94 14:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11670;
16 May 94 14:59 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11548;
16 May 94 14:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-smtp at dimacs.rutgers.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-smtpext-pipeline-01.txt
Date: Mon, 16 May 94 14:55:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405161455.aa11548 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Mail Extensions
Working Group of the IETF.
Title : SMTP Service Extension for Command Pipelining
Author(s) : J. Klensin, N. Freed
Filename : draft-ietf-smtpext-pipeline-01.txt
Pages : 9
Date : 05/13/1994
This memo defines an extension to the SMTP service whereby a server can
indicate the extent of its ability to accept multiple commands in a single
TCP send operation. Using a single TCP send operation for multiple commands
can improve SMTP performance significantly.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-smtpext-pipeline-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-smtpext-pipeline-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940513141544.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-smtpext-pipeline-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smtpext-pipeline-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940513141544.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13206;
16 May 94 16:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13201;
16 May 94 16:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17594;
16 May 94 16:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13184;
16 May 94 16:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13180;
16 May 94 16:01 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: iafa at cc.mcgill.ca
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: How to Use Anonymous FTP to Informational
Date: Mon, 16 May 94 16:01:50 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405161601.aa13180 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "How to Use Anonymous FTP"
<draft-ietf-iafa-howftp-01.txt> and recommends that it be published by
the RFC Editor as an Informational RFC. This document is the product of
the Internet Anonymous FTP Archives Working Group. The IESG contact
person is Joyce K. Reynolds.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13255;
16 May 94 16:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13250;
16 May 94 16:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17687;
16 May 94 16:03 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13232;
16 May 94 16:03 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13228;
16 May 94 16:03 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: nir at mailbase.ac.uk
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: A Status Report on Networked Information
Retrieval: Tools and Groups to Informational
Date: Mon, 16 May 94 16:03:20 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405161603.aa13228 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "A Status Report on Networked
Information Retrieval: Tools and Groups"
<draft-ietf-nir-status-report-03.txt> and recommends that it be published
by the RFC Editor as an Informational RFC. This document is the product
of the Networked Information Retrieval Working Group. The IESG contact
person is Joyce K. Reynolds.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15906;
16 May 94 18:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15902;
16 May 94 18:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21631;
16 May 94 18:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15889;
16 May 94 18:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15743;
16 May 94 18:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21470;
16 May 94 18:25 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15733;
16 May 94 18:25 EDT
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
To: IETF-Announce: ;
cc: iesg at CNRI.Reston.VA.US
Subject: WG ACTION: Integrated Services Working Group (int-serv)
Date: Mon, 16 May 94 18:25:06 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405161825.aa15733 at IETF.CNRI.Reston.VA.US>
A new working group has been chartered in the Transport Services
Area of the IETF. For more information, contact the working
group chairs and/or the area director.
IESG Secretary
Integrated Services (intserv)
-----------------------------
Charter
Chair(s):
Craig Partridge <craig at bbn.com>
Dave Clark <ddc at lcs.mit.edu>
Scott Shenker <shenker at parc.xerox.com>
John Wroclawski <jtw at lcs.mit.edu>
Transport Area Director(s)
Allison Mankin <mankin at cmf.nrl.navy.mil>
Mailing lists:
General Discussion:int-serv at isi.edu
To Subscribe: int-serv-request at isi.edu
Archive: ftp.isi.edu:int-serv/int-serv.mail
Description of Working Group:
Recent experiments demonstrate the capability of packet switching
protocols to support Integrated Services --- the transport of audio,
video, real-time, and classical data traffic within a single network
infrastructure. These experiments suggest that expanding the Internet
service model would better meet the needs of these diverse applications.
The purpose of this working group is to specify this enhanced service model
and then to define and standardize certain interfaces and requirements
necessary to implement the new service model.
The working group will focus on defining a minimal set of global
requirements which transition the Internet into a robust
integrated-service communications infrastructure. Enhancements to
individual protocols (e.g., adding additional routing information to
routing protocols, or choosing IP queueing disciplines for routers)
will be left to other working groups, except in those rare cases where
detailed definitions of behavior are critical to the success of the
enhanced architecture.
Extending the Internet service model raises a series of questions.
The working group will focus on the three problems listed below:
(1) Clearly defining the services to be provided. The first task faced
by this working group is to define and document the enhanced Internet
service model.
(2) Defining the application service, router scheduling and (general)
subnet interfaces. The working group must define at least three
high-level interfaces: that expressing the application's end-to-end
requirements, that defining what information is made available to
individual routers within the network, and the additional expectations
(if any) the enhanced service model has for subnet technologies. The
working group will define these abstract interfaces, and will coordinate
with and advise IP over "subnet" working groups (such as IP over ATM)
in this.
(3) Developing router validation requirements which can ensure that
the proper service is provided. We assume that the Internet will
continue to contain a heterogeneous set of routers, running different
routing protocols and using different forwarding algorithms. The
working group will seek to define a minimal set of additional router
requirements which ensure that the Internet can support the new
service model. Rather than presenting specific scheduling and admission
control algorithms which must be supported, these requirements will likely
take the form of behavioral tests which measure the capabilities of
routers in the integrated services environment. This approach is used
because no single algorithm seems likely to be appropriate in all
circumstances at this time. The working group will coordinate with
the Benchmarking Working Group (BMWG).
We expect to generate three RFCs as a product of performing these tasks.
An important aspect of this working group's charter is in coordination
with the development of IP Next Generation. The working group will
be reviewed in November 1995 to determine if it should be re-chartered
as is or modified to reflect IPng developments, in particular, but also
operational and commercial developments. The IESG deems the great
significance of this working group to merit this unusual review.
In addition, because many of the integrated services concepts are new,
the working group may produce Informational RFCs explaining specific
algorithms that may be appropriate in certain circumstances, and may host
some educational meetings to assist both IETF members and members of the
larger Internet community to understand the proposed enhancements to IP.
The working group proposes to hold regular meetings beyond those held at
the IETF meetings.
APPENDIX - Integrated Services Working Group Management Plan
The General Chair is Craig Partridge (BBN). The Co-Chairs are Dave Clark
(MIT), Scott Shenker(XEROX), and John Wroclawski (MIT).
The dual reasons for this management structure are:
(1) The working group will have do considerably more outreach into the
larger networking community than the typical IETF working group. For
instance, one of the important tasks is to convince the larger public
that IP is suitable for integrated services. So we need management
manpower to do outreach.
(2) The working group has a lot of work to do and swiftly. Even though
we plan to spin off working groups as fast as we can, a lot of key
architectural decisions will need to be made in one place (e.g., by
this working group) if the final architecture is to be sound. So we
need management manpower just to keep the working group moving.
So Craig has primary responsibility for keeping the working group moving,
and Dave, Scott, and John have primary responsibility for outreach to
different communities (and titles sufficient to show they can speak for
the working group).
Goals and Milestones:
Done Seattle IETF: First full meeting of working group. Discuss proposed
service model. Discuss strategy for addressing other issues.
Nov 94 Submit Informational RFC on service model. Discuss initial draft
documents describing router requirements and strategies for
behavioral testing. Hold coordination meeting with RSVP Working
Group (and perhaps others as well) to discuss Application
(end-to-end) PI.
Mar 95 Continue discussion of router requirements. Develop experimental
verification of behavioural testing approach. Continue discussion of
API and subnet models.
Nov 95 Submit router requirements document for publication as an RFC.
Nov 95 Submit API. Working group charter will be revised after a working
group review managed by the area director, then submitted via the
normal chartering process for approval.
Jun 96 Submit subnet document for publication as an RFC.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16300;
16 May 94 18:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16296;
16 May 94 18:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22201;
16 May 94 18:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16284;
16 May 94 18:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16280;
16 May 94 18:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22196;
16 May 94 18:59 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16274;
16 May 94 18:59 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: tn3270e at list.nih.gov
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: TN3270 Enhancements to Proposed Standard
Date: Mon, 16 May 94 18:59:08 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405161859.aa16274 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Telnet TN3270 Enhancements
Working Group to consider "TN3270 Enhancements"
<draft-ietf-tn3270e-enhancements-04.txt> for the status of Proposed
Standard, and "TN3270 Extensions for LUname and Printer Selection"
<draft-ietf-tn3270e-luname-print-02.txt> for publication as an
Informational RFC.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
30 May.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16824;
16 May 94 19:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22614;
16 May 94 19:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16806;
16 May 94 19:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16755;
16 May 94 19:20 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22584;
16 May 94 19:20 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10407>; Mon, 16 May 1994 16:20:43 -0700
Message-Id: <199405162320.AA10407 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1611 on DNS Server MIB Extensions
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 16 May 94 16:20:57 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1611:
Title: DNS Server MIB Extensions
Author: R. Austein & J. Saperia
Mailbox: sra at epilogue.com, saperia at zko.dec.com
Pages: 30
Characters: 58,700
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of extensions which instrument DNS
name server functions. This memo was produced by the Domain Name
System Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940516161644.RFC at ISI.EDU>
SEND /rfc/rfc1611.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1611.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940516161644.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16939;
16 May 94 19:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22780;
16 May 94 19:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16920;
16 May 94 19:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16872;
16 May 94 19:24 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22658;
16 May 94 19:24 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10495>; Mon, 16 May 1994 16:24:12 -0700
Message-Id: <199405162324.AA10495 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1612 on DNS Resolver MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 16 May 94 16:24:25 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1612:
Title: DNS Resolver MIB Extensions
Author: R. Austein & J. Saperia
Mailbox: sra at epilogue.com, saperia at zko.dec.com
Pages: 32
Characters: 61,382
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of extensions which instrument DNS
resolver functions. This memo was produced by the Domain Name System
Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940516162125.RFC at ISI.EDU>
SEND /rfc/rfc1612.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1612.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940516162125.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16969;
16 May 94 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16943;
16 May 94 19:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22778;
16 May 94 19:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16918;
16 May 94 19:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16866;
16 May 94 19:24 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22651;
16 May 94 19:24 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA10474>; Mon, 16 May 1994 16:24:04 -0700
Message-Id: <199405162324.AA10474 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1612 on DNS Resolver MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Mon, 16 May 94 16:24:18 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1612:
Title: DNS Resolver MIB Extensions
Author: R. Austein & J. Saperia
Mailbox: sra at epilogue.com, saperia at zko.dec.com
Pages: 32
Characters: 61,382
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of extensions which instrument DNS
resolver functions. This memo was produced by the Domain Name System
Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940516162125.RFC at ISI.EDU>
SEND /rfc/rfc1612.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1612.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940516162125.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03997;
17 May 94 10:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03985;
17 May 94 10:22 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa08081;
17 May 94 10:22 EDT
Received: by bitsy.MIT.EDU
id AA17201; Tue, 17 May 94 10:05:08 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA17187; Tue, 17 May 94 10:05:06 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA21379; Tue, 17 May 94 10:04:56 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA06685 at pad-thai.aktis.com>; Tue, 17 May 1994 10:05:38 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA07488; Tue, 17 May 94 10:05:37 EDT
Message-Id: <9405171405.AA07488 at winkl.aktis.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 16-May-1994 0947" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Questions regarding GGS/Kerberos names
In-Reply-To: Your message of "Mon, 16 May 1994 13:05:42 EDT."
<9405161705.AA00844 at us1rmc.bb.dec.com>
Date: Tue, 17 May 1994 10:05:37 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
John,
>>(2) The intro text to the name type section specifically states: "It
>>is understood that not all implementations of the Kerberos V5 GSS-API
>>mechanism need support all name types in this list, and that
>>additional name forms will likely be added to this list over time."
>>Support for the entire set isn't a conformance requirement.
>
>This has always bothered me. What benefits are gained from including
>"optional" features in an API spec? If an application implementor wants his
>application to be portable, he can't use any features flagged as "optional", so
>why should they appear in the ID, rather than supplementary documentation for a
>given implementation? I would prefer to see the ID contain a small set of
>name-types that all implementations must support, and leave it up to individual
>implementations to add additional types if they want.
I saw this as a trial balloon, to be refined as more implementations
emerge. If we can reach agreement on a core set of name types that
all implementations, present and future, would agree or be bound
to support, this would be a fine basis for portability. Let's discuss
whether a proper subset of the types in the current I-D could form
such a core set.
Beyond whatever we can agree on as a core set, I still see value in
recommending definitions for implementations to use if they elect
to support additional types, but would split these non-core, optional
types off into a separate section. Even if not all implementations
are committed to supporting a particular type, it still seems useful
to provide a vehicle so that the implementations which do support
that type will be able to do so in the same way. Effectively, it's
a place to document an implementor's agreement.
>>(1) As noted, it is true that the implementation in Beta 3 is capable
>>of importing a principal object in addition to being able to accept a
>>printable principal name. This is an extra feature, convenient for
>>some applications although not what was contemplated when 1508 was
>>written; while the function of GSS_Display_name() clearly implies that
>>it should produce only a printable output form, a goal of flexible use
>>by applications suggests that it might be helpful to accept other
>>forms of input to GSS_Import_name() in addition. If there's support
>>for this, we should consider rewording the text describing importable
>>names when the RFCs are next revised, to broaden the definition. If
>>the group sentiment is against it, the principal name type can be
>>removed from the KV5 I-D.
>
>I think that this function should be provided by an implementation-specific
>extension routine (eg import_kerberos_principal()), rather than overloading a
>gssapi routine.
This could be done. Paralleling my comment above, though, I think the
scope over which such a routine would likely be interesting is broader
than a specific implementation, instead spanning more than one (though
not necessarily all) of the GSS-API implementations built atop
Kerberos V5. This suggests to me that we should have at least an
implementor's agreement for how to do this, even if not all
implementors elect to support it; although we don't currently define
any mechanism-specific routines at the level of the KV5 mechanism I-D,
this spec could be a repository for such a definition.
>It certainly seems wrong to pass a krb5_principal object to a routine using a
>gss_buffer_t, anyway. The gss_buffer_t datatype is explicitly designed for
>passing contiguous byte arrays, not structured data.
This basically matters because gss_release_buffer() will be called
later to free the buffer, and needs to know if a particular
gss_buffer_desc points at something other than contiguous bytes in
order to do the right thing when freeing the storage. This can't be
the only case where this arises, though; how would we construct, e.g.,
a mechanism which wanted to support importation of an X.500 name as a
structured object rather than as a crunched-down contiguous ASCII byte
form? Perhaps we should generalize the idea of being able to import a
structured object, which the caller would be responsible for
allocating and freeing, rather than treating this Kerberos object
with a special-case, implementation-defined or mechanism-defined,
routine?
--jl
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05658;
17 May 94 11:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10635;
17 May 94 11:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05623;
17 May 94 11:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05419;
17 May 94 11:37 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-crocker-edi-01.txt, .ps
Date: Tue, 17 May 94 11:37:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405171137.aa05419 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : MIME Encapsulation of EDI Objects
Author(s) : D. Crocker
Filename : draft-crocker-edi-01.txt, .ps
Pages : 4
Date : 05/16/1994
This is a preliminary draft document, intended for eventual submission
to the IETF working group process. At this stage, the document should be
viewed strictly as a think-piece, with comments, corrections, etc. eagerly
sought.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-crocker-edi-01.txt".
Or
"get draft-crocker-edi-01.ps".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-crocker-edi-01.txt".
Or
"FILE /internet-drafts/draft-crocker-edi-01.ps".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940516172705.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-crocker-edi-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-crocker-edi-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940516172705.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05813;
17 May 94 11:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05809;
17 May 94 11:58 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa10742;
17 May 94 11:58 EDT
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (8.6.8.1/1.2)
id JAA22197; Tue, 17 May 1994 09:58:21 -0600
Received: by noc-gw.lanl.gov (8.6.8.1/SMI-4.1)
id JAA26614; Tue, 17 May 1994 09:58:06 -0600
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (8.6.8.1/SMI-4.1)
id JAA26611; Tue, 17 May 1994 09:58:05 -0600
Received: from IETF.nri.reston.VA.US by mailhost.lanl.gov (8.6.8.1/1.2)
id JAA22148; Tue, 17 May 1994 09:58:03 -0600
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05715;
17 May 94 11:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, CNRI.Reston.VA.US at noc-gw.lanl.gov
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
cc: tuba at lanl.gov
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-tuba-mobility-00.txt
Date: Tue, 17 May 94 11:55:37 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405171155.aa05715 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the TCP/UDP Over CLNP-Addressed
Networks Working Group of the IETF.
Title : TUBA Mobility Support
Author(s) : Y. Rekhter, R. Colella
Filename : draft-ietf-tuba-mobility-00.txt
Pages : 27
Date : 05/16/1994
This document specifies protocol enhancements that allow transparent
routing of CLNP datagrams to Mobile Nodes in the Internet. The Mobile Node
is always identified by its Home-Address, regardless of its current point
of attachment to the Internet. While situated away from its home, a Mobile
Node is also associated with a Care-Of-Address, which provides information
about its current point of attachment to the Internet. The protocol
provides for registering the Care-Of-Address with the Home Agent. The Home
Agent tunnels traffic destined for the Mobile Node to the Care-Of-Address.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tuba-mobility-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tuba-mobility-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940516154659.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-tuba-mobility-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tuba-mobility-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940516154659.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06104;
17 May 94 12:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06096;
17 May 94 12:12 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa11058;
17 May 94 12:12 EDT
Received: by bitsy.MIT.EDU
id AA18720; Tue, 17 May 94 11:49:01 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA18712; Tue, 17 May 94 11:48:59 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA29762; Tue, 17 May 94 11:48:32 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA15953; Tue, 17 May 94 08:35:33 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA22543; Tue, 17 May 94 11:35:11 -0400
Message-Id: <9405171535.AA22543 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Tue, 17 May 94 11:35:11 EDT
Date: Tue, 17 May 94 11:35:11 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 17-May-1994 1014" <wray at tuxedo.enet.dec.com>
To: linn at cam.ov.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: Questions regarding GGS/Kerberos names
John,
>If we can reach agreement on a core set of name types that
>all implementations, present and future, would agree or be bound
>to support, this would be a fine basis for portability. Let's discuss
>whether a proper subset of the types in the current I-D could form
>such a core set.
I'd recommend that the mandatory set be simply a printable Kerberos V5
principal name. In addition, the SERVICE:<svc>@<host> printable form should be
documented as a variant of this printable format, suitable for input to
gss_import_name(), although a name of this form will never be emitted by
gss_display_name(). The SERVICE: form probably doesn't need its own name-type,
as it can be syntactically distinguished from a regular principal name.
>Beyond whatever we can agree on as a core set, I still see value in
>recommending definitions for implementations to use if they elect
>to support additional types, but would split these non-core, optional
>types off into a separate section. Even if not all implementations
>are committed to supporting a particular type, it still seems useful
>to provide a vehicle so that the implementations which do support
>that type will be able to do so in the same way. Effectively, it's
>a place to document an implementor's agreement.
I think it's only worth documenting additional optional name-types if:
i) They have widespread applicability
ii) They're not easily converted into another supported name-form by an
existing system function
iii) They can be specified completely enough in this document to be useful to
application developers.
I'd suggest that a local O/S username satisfies these criteria: All multi-user
O/S provide some way of naming individual users, the O/S itself probably can't
convert local names into global authentication names, and simply referring to
the native O/S username ought to be sufficient to describe what's meant on any
given platform.
O/Ss that don't support usernames (eg DOS) won't be able to support this
nametype, unless they're operating in an environment (e.g. a NOS) that has a
concept of usernames.
I don't think that GSSAPI should directly support numeric alternatives for
local names, since if the O/S does have numeric synonyms for usernames, then
the O/S will provide a function to translate from one form to another. I can't
imagine an application making use of numeric-format names if it wanted to be
portable across O/S platforms.
>>I think that this function should be provided by an implementation-specific
>>extension routine (eg import_kerberos_principal()), rather than overloading a
>>gssapi routine.
>
>This could be done. Paralleling my comment above, though, I think the
>scope over which such a routine would likely be interesting is broader
>than a specific implementation, instead spanning more than one (though
>not necessarily all) of the GSS-API implementations built atop
>Kerberos V5. This suggests to me that we should have at least an
>implementor's agreement for how to do this, even if not all
>implementors elect to support it; although we don't currently define
>any mechanism-specific routines at the level of the KV5 mechanism I-D,
>this spec could be a repository for such a definition.
If GSSAPI-using applications are likely to want to deal in krb5_principal
objects, then I'd recommend that we define mechanism-specific functions to
convert between gss_name_t objects and krb5_principals in each direction.
Going just in the direction krb5_principal->gss_name_t doesn't seem enough.
However, I still question the need. If an application wants to use the
krb5_principal name-type, then it knows it's dealing with Kerberos. If it's
willing to hard-code such a dependency, why wouldn't it use the native Kerberos
API, rather than the GSSAPI? Presumably it is already calling the Kerberos
native API, since otherwise it wouldn't have a krb5_principal object.
>>It certainly seems wrong to pass a krb5_principal object to a routine using a
>>gss_buffer_t, anyway. The gss_buffer_t datatype is explicitly designed for
>>passing contiguous byte arrays, not structured data.
>
>This basically matters because gss_release_buffer() will be called
>later to free the buffer, and needs to know if a particular
>gss_buffer_desc points at something other than contiguous bytes in
>order to do the right thing when freeing the storage. This can't be
>the only case where this arises, though; how would we construct, e.g.,
>a mechanism which wanted to support importation of an X.500 name as a
>structured object rather than as a crunched-down contiguous ASCII byte
>form? Perhaps we should generalize the idea of being able to import a
>structured object, which the caller would be responsible for
>allocating and freeing, rather than treating this Kerberos object
>with a special-case, implementation-defined or mechanism-defined,
>routine?
I don't think that structured names should be supported by gss_import_name() &
gss_display_name(). If GSSAPI implementations are likely to want to support
structured names (and I believe that they may), perhaps there should be
additional GSSAPI routines specifically designed to support those name-types
(for example, gss_import_structured_name() and gss_export_structured_name()).
That way, an implementation can define the set of structured name-forms it
supports, and specify what environment-provided routines should be used to free
such names. For example, krb5_principal objects created by
gss_export_structured_name() should be passed to the krb5_free_principal()
routine (or whatever it's called). If the implementation supports, for
example, X.500 names using the XDS representation, then the XDS spec can be
referenced by the implementation documentation, along with the name of the
routine that deletes such things (om_delete()?).
If we were to do this, then the Kerberos mechanism spec could define
krb5_principal as a recommended structured name-type for support via these
routines.
Use of the structured_name routines is a clear indication that the application
isn't likely to be portable to GSSAPI implementations over other mechanisms,
and may well not be portable to a GSSAPI implementation on another platforms
using the same mechanism. Also, not all names may be convertible to a given
structured name-form, if the GSSAPI implementation supports multiple
mechanisms, and the desired structured name-form is specific to a given
mechanism.
Note that support of the krb5_principal name-type can't be made mandatory,
since the krb5_principal definition isn't part of the Kerberos spec, just the
MIT implementation of that spec (Kerberos is specified only as a protocol, not
an API), so not all implementations of Kerberos may use it.
John
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07312;
17 May 94 13:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12569;
17 May 94 13:31 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07300;
17 May 94 13:31 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07224;
17 May 94 13:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-manning-dns-nsap-05.txt
Date: Tue, 17 May 94 13:28:21 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405171328.aa07224 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : DNS NSAP Resource Records
Author(s) : B. Manning, R. Colella
Filename : draft-manning-dns-nsap-05.txt
Pages : 10
Date : 05/16/1994
The Internet is moving towards the deployment of an OSI lower layers
infrastructure. This infrastructure comprises the connectionless network
protocol (CLNP) and supporting routing protocols. Also required as part of
this infrastructure is support in the Domain Name System (DNS) for mapping
between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for the
DNS for domain name-to-NSAP mapping. The RR may be used with any NSAP
address format. This document supercedes RFC 1348.
NSAP-to-name translation is accomplished through use of the PTR RR
(see RFC 1035 for a description of the PTR RR). This paper describes
how PTR RRs are used to support this translation.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-manning-dns-nsap-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-manning-dns-nsap-05.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940516144053.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-manning-dns-nsap-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-manning-dns-nsap-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940516144053.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12301;
17 May 94 17:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12289;
17 May 94 17:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19434;
17 May 94 17:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12272;
17 May 94 17:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12203;
17 May 94 17:14 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa19304;
17 May 94 17:13 EDT
Received: from SUVM.SYR.EDU (suvm.acs.syr.EDU) by venera.isi.edu (5.65c/5.61+local-14)
id <AA17441>; Tue, 17 May 1994 14:13:48 -0700
Message-Id: <199405172113.AA17441 at venera.isi.edu>
Received: from SUVM by SUVM.SYR.EDU (IBM VM SMTP V2R2) with BSMTP id 5003;
Tue, 17 May 94 17:13:29 LCL
Received: from SUADMIN.SYR.EDU (MJVANARN) by SUVM (Mailer R2.10 ptf000) with
BSMTP id 2538; Tue, 17 May 94 16:43:30 LCL
Date: Tue, 17 May 1994 16:40 ET
To: ietf at isi.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Margaret.Vanarnam" <MJVANARN%SUADMIN.BITNET at suvm.acs.syr.edu>
Subject: Final Version (May 16)
----------( Forwarded letter 1 follows )----------------------------------------
Received: from SUVM by SUVM (Mailer R2.10 ptf000) with BSMTP id 6544; Mon, 16
May 94 14:37:32 LCL
Received: from spica.npac.syr.edu by SUVM.SYR.EDU (IBM VM SMTP V2R2) with TCP;
Mon, 16 May 94 14:37:29 LCL
Received: from cat.syr.edu (mango.ece.syr.EDU) by spica.npac.syr.edu
(4.1/I-1.98K) id AA04477; Mon, 16 May 94 14:37:09 ED
Received: from localhost.syr.edu by cat.syr.edu (4.1/1.0-6/5/90)
id AA05139; Mon, 16 May 94 14:36:59 EDT
Message-Id: <9405161836.AA05139 at cat.syr.edu>
To: hpdc at npac.syr.edu
Cc: hariri at cat.syr.edu
Subject: Final Version (May 16)
Date: Mon, 16 May 94 14:36:58 -0400
From: hariri at cat.syr.edu
Please use this version for distribution. Also compare this against
the proff Janet has sent to us.
Thanks,
Salim
**************************************************************************
HPDC-3 CALL FOR PARTICIPATION
**************************************************************************
THIRD INTERNATIONAL SYMPOSIUM ON
HIGH PERFORMANCE DISTRIBUTED COMPUTING (HPDC-3)
Westin St. Francis Hotel, San Francisco, California
August 2-5, 1994
SPONSORS:
- IEEE Computer Society
- Northeast Parallel Architectures Center at Syracuse University
IN COOPERATION WITH:
- ACM SIGCOMM
- Rome Laboratory
The International Symposium on High Performance
Distributed Computing provides a forum for presenting the latest
research findings that unify parallel and distributed computing.
In HPDC environments, parallel or distributed computing techniques
are applied to the solution of computationally intensive applications
across networks of computers.
This symposium follows two successful earlier conferences
held in Syracuse, NY and Spokane, WA in 1992 and 1993, respectively.
=======================
Pre-Symposium Tutorials
=======================
Tuesday, August 2
8:30 AM -- 12 NOON Concurrent Sessions
Tutorial 1A: Software Systems and Tools for High Performance
Distributed Computing
Anand Tripathi, University of Minnesota
Tutorial 1B: Interfacing to High Speed Networks: Adapter Design
and Operating System Issues.
K. K. Ramakrishnan, Digital Equipment Corporation
2:00 PM -- 5:30 PM Concurrent Sessions
Tutorial 2A: Message Passing Using MPI: from Fundamentals to Applications
David W. Walker, Oak Ridge National Laboratory
Tutorial 2B: High Performance Distributed Computing
in a Supercomputing Environment:
Computational Services and Applications Issues
W. T. C. Kramer and Horst D. Simon, NASA Ames Research Center
======================================
Wednesday, August 3
======================================
8:00 AM - 10:00 AM Registration
8:30 AM - 10:00 AM Plenary Session
Keynote Speech
Robert E. Kahn, Corporation for Networking
Research Initiatives
10:30 AM - 12:00 NOON
SESSION 1: INVITED PAPERS
Chair: W. Johnston, NYNEX
Multimedia Supercomputing: The Use of Supercomputers to Drive
High-Performance Multimedia Systems and Virtual Environments
Rick Stevens, Argonne National Laboratory
Constructing Numerical Software Libraries for HPCC Environments
Jack Dongarra, University of Tennessee and Oak Ridge National Laboratory
Overview of RWC Massively Parallel Computer Project
Shuichi Sakai, Real World Computing Project, Japan
12:00 NOON - 1:30 PM LUNCH
sponsored by Kendall-Square Research
Speaker: TBA
1:30 PM - 3:00 PM Concurrent Sessions
SESSION 2A: SOFTWARE TOOLS AND ENVIRONMENTS I
Chair: M. Annaratone, Digital
"The Virtual Computing Environment"
P. Rouselle, P. Tymann, G. Fox, S. Hariri,
Syracuse University
"The Use of Frameworks for Scientific Computation in a Parallel
Distributed Environment"
R. Armstrong, Sandia National Laboratories
J. Macfarlane, Lawrence Berkeley Laboratory
"Falcon -- Toward Interactive Parallel Programs: The On-line Steering
of a Molecular Dynamics Application"
G. Eisenhauer, W. Gu, K. Schwan, N. Mallavarupu,
Georgia Institute of Technology
SESSION 2B: HIGH-SPEED NETWORKS AND APPLICATIONS
Chair: W. Dabbous, INRIA, France
"High-Performance TCP/IP and UDP/IP Networking in DEC OSF/1 Alpha AXP"
C-H. Chang, D. Flower, J. Forecast, H. Gray, B. Hawe,
A. Nadkarni, K. K. Ramakrishnan, U. Shikarpur, D. Ting, K. Wilde,
Digital Equipment Corporation
"Design and Implementation of Global Reduction Operations across ATM
Networks"
C. Huang, P. K. McKinley,
Michigan State University
"Traffic Monitoring for Capacity Allocation of Multimedia Traffic in
ATM Broadband Networks"
A. Burrell, D. Makrakis, P. Papantoni-Kazakos,
University of Ottawa
3:30 PM - 4:30 PM Concurrent Sessions
SESSION 3A: SOFTWARE TOOLS AND ENVIRONMENTS II
Chair: A. Skjellum, Mississippi State University
"WAVE Processing of Networks and Distributed Simulation"
P. M. Borst, University of Karlsruhe, Germany
M. Corbin, DRA, Farnborough, U.K.
P. S. Sapaty, University of Surrey, U.K.
"Providing High Performance Distributed Computing through Scalable
Computation Servers"
O. Kremien, Bar-Ilan University, Israel
J. Kramer, Imperial College, U.K.
SESSION 3B: HPDC APPLICATIONS I
Chair: D. McAuliffe, Rome Laboratory
"Running a Climate Model in a Heterogeneous Distributed Computer
Environment"
C. R. Mechoso, D. J. Farrara, J. A. Spahr,
University of California, Los Angeles
"Distributed Computation of Electromagnetic Scattering Problems Using
Finite-Difference Time-Domain Decompositions"
Sandy Nguyen, Brian Zook, Southwest Research Institute
Xiaodong Zhang, The University of Texas at San Antonio
======================================
Thursday, August 4
======================================
9:00 AM - 10:00 AM Keynote Speech: System Architectures for High Performance
Computing in the 1990's
Tilak Agerwala, IBM
10:30 AM - 12:00 NOON Concurrent Sessions
SESSION 4A: MAPPING AND SCHEDULING I
Chair: A. Grimshaw, University of Virginia
"Scheduling Large-Scale Parallel Computations on Networks of
Workstations"
R. D. Blumofe, D. S. Park,
Massachusetts Institute of Technology
"Scheduling a Metacomputer by an Implicit Voting System"
K. Kremer, University of Technology Aachen, Germany
F. Ramme, University of Paderborn, Germany
"A Decomposition Advisory System for Heterogeneous Data-Parallel
Processing"
P. E. Crandall, M. J. Quinn,
Oregon State University
SESSION 4B: DISTRIBUTED SHARED-MEMORY SYSTEMS
Chair: T. V. Lakshman, Bellcore
"Evaluating Weak Memories with Maya"
D. Agrawal, M. Choy, H. Va Leong, A. Singh
University of California, Santa Barbara
"Analysis and Transformation of Parallel Programs for Fast Data Sharing"
A. Li, University of Victoria, Canada
G Hermannsson, L. Wittie, State University of New York, Stony Brook
"An Experimental Active-Memory-Based Network Environment"
A. Asthana, M. Cravatts, P. Krzyzanowski,
AT&T Bell Laboratories
12:00 NOON - 1:30 PM LUNCH
1:30 PM - 3:00 PM Panel
GOVERNMENT STRATEGIES FOR HIGH-PERFORMANCE DISTRIBUTED COMPUTING
Panel Chair: J. A. Graniero, Rome Laboratory
Panelists: Hank Dardy, Naval Research Laboratory
Andrew White, Los Alamos
Richard Freund, Naval Research and Development Center
L/C John Toole, ARPA/CSTO
L/C Larry Davis, AFOSR/ST
Ray Kline, Sandia National Laboratories
3:30 PM - 5:00 PM Concurrent Sessions
SESSION 5A: PARTITIONING AND LOAD BALANCING
Chair: R. Perrot, Queens University, Belfast
"Network Partitioning of Data Parallel Programs"
J. B. Weissman, A. S. Grimshaw,
University of Virginia
"Exploiting Inter-Task Dependencies for Dynamic Load Balancing"
W. Becker, G. Waldmann,
University of Stuttgart, Germany
"Automatic Generation of Parallel Programs with Dynamic Load Balancing"
B. S. Siegell, P. Steenkiste,
Carnegie Mellon University
SESSION 5B: HPDC APPLICATIONS II
Chair: J. Patterson, Boeing
"Distributed Solutions to the Delay Fault Test Quality Evaluation
Problem"
I. Pramanick, A. K. Pramanick,
IBM
"Design and Implementation of Parallel Algorithms for Gene Finding"
J. J. Puthukattukran, S. Chalasani, University of Wisconsin-Madison
P. Senapathy, Genome International Corporation
"Solving Partial Differential Equations on a Network of Workstations"
C.-C. Hui, M. Hamdi, Ishfaq Ahmad,
Hong Kong University of Science and Technology
======================================
Friday, August 5
======================================
8:30 AM - 10:00 AM Concurrent Sessions
SESSION 6A: MAPPING AND SCHEDULING II
Chair: Ardsher Ahmed, UMASS Dartmouth
Parallel Computations on the CHARM Heterogeneous Workstation Cluster"
V. A. Saletore, J. Jacob, M. Padala,
Oregon State University
"Mapping Parallel Iterative Algorithms onto Workstations Networks"
A. Heddaya, K. Park,
Boston University
"A Task Graph Centroid"
C. Leangsuksun, J. Potter
Kent State University
SESSION 6B: FAULT-TOLERANCE AND I/O IN DISTRIBUTED SYSTEMS
Chair: I. Ahmad, Hong Kong University of Science & Technology
"Data Reshuffling in Support of Fast I/O for Distributed-Memory Machines"
C. Bornstein, P. Steenkiste
Carnegie Mellon University
"Process-Replication Technique for Fault-Tolerance and Performance
Improvement in Distributed Computing Systems"
J-F. Chiu, G-M. Chiu,
National Taiwan Institute of Technology
"Performance Evaluation of a Partial Dynamic Declustering Disk Array
System"
V. Catania, A. Puliafito, S. Riccobene, L. Vita,
University of Catania, Italy
10:30 AM - 12:00 NOON Concurrent Sessions
SESSION 7A: NETWORK PROTOCOLS AND INTERFACES
Chair: I. Akyildiz, Georgia Institute of Technology
"Large-Scale Group Communication Protocol on High-Speed Channel"
M. Takamura, M. Takizawa,
Tokyo Denki University
"Deciding Boundedness for Systems of Communicating Finite
State Machines"
A. Benslimane,
Universite de Franche-Comte, France
"Design of the Header Processor for the PSi Implementation of the
Logical Link Control Protocol in LANs"
F. A. Morales, H. Abu-Amara,
Texas A&M University
SESSION 7B: PERFORMANCE EVALUATION AND RESOURCE MANAGEMENT
Chair: J. J. Garcia-Luna, University of California, Santa Cruz
"PMT: A Tool to Monitor Performance in Distributed Systems"
V. Catania, O. Granato, A. Puliafito, L. Vita,
University of Catania, Italy
"Reducing Variations in Parallel Efficiency for Unstructured Grid
Computations"
B. Worner, G. Geunder, M. Hardtner, R. Zink,
University of Stuttgart, Germany
"Performance Prediction for Different Consistency Schemes in Distributed
Shared Memory Systems"
Z. G. Vranesic, S. Srbljic, University of Toronto
L. Budin, University of Zagreb, Croatia
______________________________________________________________
KEYNOTE SPEAKERS
Robert E. Kahn is President of the Corporation for National
Research Initiatives (CNRI), which he founded in 1986 after a 13-
year term at the Advanced Research Projects Agency (ARPA). Dr.
Kahn holds a Ph.D. from Princeton University. Prior to his service
at CNRI he held positions at Bell Laboratories, MIT and DARPA where
he became Director of DARPA's Information Processing Techniques
Office (IPTO) and initiated the United States government's billion
dollar Strategic Computing Program, the largest computer research
and development program ever undertaken by the federal government.
Dr. Kahn is a member of the National Academy of Engineering, a
Fellow of the IEEE, a Fellow of AAAI, a recipient of the AFIPS
Harry Goode Memorial Award, the Marconi Award, the ACM SIGCOMM
Award, the President's Award from the ACM, the IEEE Koji Kobayashi
Computer and Communications Award, the ACM Software Systems Award,
and the ASIS Special Award. He was twice the recipient of the
Secretary of Defense Meritorious Civilian Service Award.
Tilak Agerwala is Director of Architecture and System Design for
IBM's parallel computer products. He is responsible for future
product designs, performance analysis, and technical strategy.
Dr. Agerwala has held executive positions in the RISC System 6000
division, where he was responsible for future system technology
development, and at the T.J. Watson Research Center, where he
initiated and directed broad research programs in parallel processing,
artificial intelligence, and supercomputing. Dr. Agerwala is a
member of the IBM Academy of Technology and has served on the
Corporate Technical Committee. He was elected a Fellow of the IEEE
for his leadership in the development of very high performance computers.
**********************************************************************
DESCRIPTIONS OF TUTORIALS
---------------------------------------------------------------------------
Tutorial 1A
Software Systems and Tools for High Performance Distributed Computing
Anand Tripathi, University of Minnesota
The objective of this tutorial is to present an
overview of the mechanisms and software tools/systems that are
currently available for high-performance distributed programming
in local-area networks. A high performance distributed
programming environment needs mechanisms for specifying and
managing parallel computation structures of a distributed
application, transparent distribution of load in the network,
dynamic linking of components, error detection and recovery, and
transparency of the hardware/software heterogeneity in the
network. This tutorial will present an overview of the most
commonly used paradigms and models for distributed computing.
These are related to interprocess communication models such as
message passing and the remote procedure call (RPC),
heterogeneous computing, load balancing and scheduling of tasks,
and naming and protection of resources in the network.
Reliability related issues in implementing RPC will be discussed.
An overview the object model of computing will be presented in
the context of micro-kernel architectures for distributed
computing. The concept of group is a useful abstraction for
managing a collection of related activities. Primitives for
group management and broadcast communication will be presented.
A number of software tools and programming languages are
currently available for high performance distributed
programming. An overview of the salient features and
capabilities of Parallel Virtual Machine (PVM), Linda, Express,
P4, CODE/ROPE, Mentat, CC++, PCN, Jade, Orca, Concurrent C, SR
will be presented.
SPEAKER: Anand Tripathi is an Associate Professor in the Department
of Computer Science, University of Minnesota, Minneapolis. He
received the B.Tech degree from the Indian Institute of
Technology, Bombay, India, 1972, and the M.S. and Ph.D. degrees
from the University of Texas at Austin in 1978 and 1980,
respectively, in Electrical Engineering. From 1972 to 1975 he
worked as a research scientist at Bhabha Atomic Research Center,
Bombay, India. During 1981 to 1984 he worked as a Senior
Principal Research Scientist at Honeywell Computer Sciences
Center, Bloomington, MN. At the University of Minnesota he has
led the design and development of the Nexus distributed operating
system and its programming environment. His research interests
include parallel and distributed systems, object-oriented
programming, and fault-tolerant computing. In the past he has
presented tutorials on distributed computing systems at some of
the IEEE sponsored conferences and tutorial-weeks.
---------------------------------------------------------------------------
Tutorial 1B
Interfacing to High Speed Networks: Adapter Design and Operating System Issues
K. K. Ramakrishnan, Digital Equipment Corporation
Overview: We have seen significant increases in the bandwidth available
for computer communication networks in the recent past.
Commercially available Local Area
Networks operate at 100 Mbits/sec and research networks are running at greater
than 1 Gbit/sec. Host CPU processing speed has also increased relentlessly.
However, the anticipation that end-user applications can effectively use these
large communication link speeds has yet to be fulfilled to a large extent.
Network I/O at the end-system has often been perceived as the bottleneck for
distributed applications. This tutorial discusses
the important topics in the design of a high-speed network adapter,
including the memory-system architecture, buffer management,
support for Quality of Service (QoS) guarantees
and flow/congestion control, and host software issues.
Several case studies will be presented.
Speaker: K. K. Ramakrishnan is a Consulting Engineer
in the Distributed Systems Architecture and Performance group
at Digital Equipment Corporation.
He has been with Digital since 1983 after completing
his Ph.D. in Computer Science from the University of Maryland.
His group is involved in architecting Digital's efforts in the networking and
distributed systems area.
Dr. Ramakrishnan has worked and published papers in the areas of load
balancing, congestion control and avoidance, algorithms for FDDI, distributed
systems performance and issues relating to network I/O. Dr. Ramakrishnan
participates in the Internet Engineering Task Force and is a member of the
End-End Group, as part of the Internet Research Task Force. He is also
a technical editor for IEEE Network.
---------------------------------------------------------------------------
Tutorial 2A
Message Passing Using MPI: from Fundamentals to Applications
David W. Walker, Oak Ridge National Laboratory
This tutorial will describe the features of the MPI message passing
standard, and will show how to use MPI in applications. The tutorial is
intended to benefit researchers who have some experience with message passing,
and who wish to assess the advantages of MPI for their particular applications.
However, the tutorial will be structured to also be of use to novices.
The tutorial will be divided into three main parts. The first part will
give an overview of MPI, describe how it came about, and will discuss the
basic point-to-point and collective communication capabilities of MPI. The
second part will describe advanced features in MPI, in particular, the
management of groups and communication contexts. The third part will be
devoted to the presentation of application kernels and examples written
using MPI.
SPEAKER: David Walker is a Research Staff Member in the
Mathematical Sciences Section at Oak Ridge National Laboratory,
and an Adjunct Associate Professor in the
Department of Computer Science of the University of Tennessee, Knoxville.
He obtained his B.A. in Mathematics from Jesus College, Cambridge, in 1973,
his M.S. in Astrophysics in 1979, and his Ph.D. in Physics from the University
of London in 1983. From 1986-88. Dr. Walker was a member of the research staff
of the Concurrent Computation Project at the California Institute of
Technology, and from 1988-1990 was an Associate Professor in the Department of
Mathematics at the University of South Carolina. He was worked at ORNL since
1990, where he is mainly involved in the design of software libraries,
algorithms, and application for distributed memory concurrent computers.
Dr. Walker was instrumental in establishing the MPI Forum, which led to the
specification of the MPI standard and in which he played an active role.
---------------------------------------------------------------------------
Tutorial 2B
High Performance Distributed Computing in a Supercomputing Environment:
Computational Services and Applications Issues
W. T. C. Kramer and Horst D. Simon, NASA Ames Research Center
The focus of this tutorial will be a discussion of current
hardware and software trends for massively parallel supercomputers
from the perspective of applications. In case studies
the lessons learned at NASA Ames will be presented. The main thrust of
the tutorial will be a presentation of high performance computing topics
which will remain relevant for a long period of time, independent
of currently ``hot" machines. This requires a detailed investigation of
the issue of communication. From an applications perspective
the communication characteristics of various applications will be examined.
A new taxonomy of parallel application will be developed.
Similarly high-performance architectures will be investigated
with respect to their communications performance. The matching
of the applications taxonomy with the architectural characteristics
of a machine will form the basis for the understanding of high
performance computing. High performance distributed computing will thus
be evaluated as one possible alternative to both MPP and PVP systems.
Emphasis will be placed on an honest evaluation of the capabilities
and challenges that distributed computing faces in a production
environment. The tutorial utilizes the unique experience made
at the NAS facility at NASA Ames Research Center.
Over the last five years at NAS
massively parallel supercomputers such as the Connection Machines
CM-2 and CM-5 from Thinking Machines Corporation
and the iPSC/860 (Touchstone Gamma Machine) and Paragon Machines
from Intel were used in a production supercomputer center alongside
traditional vector supercomputers such as the Cray Y-MP and C90.
In addition to these resources, NAS has operated since 1993 a
distributed computing testbed (DCT), consisting of an environment
with 50 SGI and 40 SUN workstations.
Speakers: William Kramer is Chief of the NAS Computational
Service Branch, and is responsible for providing state-of-the-art support
and enhancement of a Cray YMP, two C-90s, CM-5, an Intel iPSC/860, an Intel
Paragon and several Convex systems, along with over 250 other systems and
workstations connected via Ultranet, FDDI and ethernet. These systems are
used by a nationwide network of over 1400 researchers in 100+ sites,
connected with the advanced NAS Aeronet and other networks. Bill was
responsible for the first production Cray-2 and YMP at NAS before
becoming Branch Chief. He is currently leading the NAS effort in
computing on loosely clustered workstations. He has authored or
presented papers sessions and seminars on a number of subjects,
including system management, computer graphics, security and supporting
advanced users at supercomputer centers.
He and his staff presented the highest rated Tutorial at Supercomputing 89,
"System Management in the UNIX Supercomputing Environment", which was presented
again by invitation at SC '90.
Horst D. Simon is with Computer Sciences Corporation at
the Applied Research Branch at the
NAS (National Aerodynamics Simulator) Systems Division
at NASA Ames Research Center in
Moffett Field, California. He is CSC department manager and
responsible for a group of researchers in the areas
of parallel algorithm development and scientific visualization,
who as contractor personnel collaborate with the NAS
staff. His research interests are in the development
of high performance algorithms for vector and
parallel machines. Particular areas of
interest are sparse matrix algorithms, algorithms for
large scale eigenvalue problems, and domain decomposition
algorithms for irregular domains for parallel processing.
Simon's algorithm research efforts were honored
with the 1988 Gordon Bell Award for parallel processing research.
Previously, until October 1989,
Dr. Simon was an employee of Boeing Computer Services, and
from October 1987 through October 1989, supported the NAS
project in a similar capacity.
>From 1982 to 1983 Dr. Simon was an assistant professor at the Department of
Applied Mathematics, SUNY Stony Brook, New York.
Dr. Simon holds a Ph.D. in mathematics from the University of
California (1982), Berkeley and a Diplom in Mathematik from the
TU Berlin, Germany (1978).
Dr. Simon has presented tutorials on high performance computing
at all previous Supercomputing conferences. His tutorials
have consistently been rated excellent or very good.
---------------------------------------------------------------------------
CONFERENCE LOCATION
HPDC-3 will be held at the Westin St. Francis Hotel
in downtown San Francisco, California. Just 30 minutes from the airport,
the Westin St. Francis is in the heart of the city
on Union Square surrounded by fine restaurants, shops and theaters. Cable cars
stop at the front door. The hotel is within walking
distance of San Francisco's Chinatown and an easy cable car ride
away from Ghiradelli Square and Fisherman's Wharf. Napa and Sonoma
Valleys, the heart of California wine country, are an hour's drive
away. If you have additional time before or after the symposium you may
want to explore Marin County's redwoods, the California Mission,
or drive scenic highway 101 to San Simeon.
Monterey, Carmel, Santa Cruz, Yosemite National Park and Lake
Tahoe are not far away.
Weather: San Francisco in August is typically very pleasant. Sunny
and warm (about 70F) during the day, and cool (about 50F) in the
evenings. Note that the evening fog often makes it feel a bit
colder and a lightweight jacket or all-weather coat is advised.
Transportation: The hotel is about 20 minutes away from San Francisco
International Airport. A taxi ride from the airport typically costs
about $25. Also, the SFO Airporter has direct service to the
hotel at 20-minute intervals. The fare is $10 one-way and $17
round-trip.
Rental Cars: HERTZ has been appointed as the car rental supplier for
HPDC-3. Special rates with unlimited mileage have been offered
to HPDC-3 attendees and are also available the week prior and the
week after the symposium. To make reservations call HERTZ
at 1-800-654-2240 (In Canada 1-800-263-0600) and identify yourself as
HPDC attendee (Meeting # 15329). Cars can be rented at most Bay-area
airports and also at the Westin St. Francis Hotel.
Social Event: An evening dinner-cruise on the San Francisco Bay is planned
for Wednesday, August 3. The cost of the cruise is included in
the registration fee. Additional tickets may be purchased at a price
of $55 each.
E-mail service will be available at the hotel to the attendees.
**************************************************************************
REGISTRATION INFORMATION
Advance registration is available using the form below through July
8th. E-mail registration is available only through July 27th, and must
use a credit card number. On-site registration at the Westin St. Francis
Hotel will be available starting Tuesday, August 2nd, and
every day of the conference starting at 8 AM.
---------------------------------------------------------------------------
HPDC-3
Registration Form
Please send this form and a check, credit card information,
or money order (no purchase orders) to the address below.
Make checks payable to SYRACUSE UNIVERSITY.
Registrations accepted via postal mail, FAX, or email only.
SU Conference Planning
HPDC-3 Conference
P.O. Box 4709
Syracuse, NY 13221-4709
Phone: (315) 443-3333
Fax: (315) 443-1168
e-mail: hpdc at nova.npac.syr.edu
-----------------------------------------------------------
Symposium Registration (select one):
Advance Registration Regular Registration
(Received by July 8, 1994) (Received after July 8, 1994)
--------------------- -------------------
IEEE/ACM SIGCOMM Member [ ] $325 [ ] $395
Non-Member [ ] $405 [ ] $485
Full-time student [ ] $180 [ ] $180
Symposium registration fee includes a copy of the proceedings,
sponsored lunches, coffee breaks, and the Bay cruise.
Student registration does not include proceedings or the Bay cruise.
Extra copies of the proceedings may be purchased on-site.
-----------------------------------------------------------
Extra Dinner/Cruise Tickets ___ @ $55 each
-----------------------------------------------------------
Tutorials (check the box for each tutorial attending)
Note: You may select at most one tutorial from the morning session
and one from the afternoon session.
_____
1A: Software Systems and Tools for High Performance | |
Distributed Computing...............................|___|
_____
1B: Interfacing to High Speed Networks..................| |
|___|
_____
2A: Message Passing Using MPI...........................| |
|___|
_____
2B: High Performance Distributed Computing | |
in a Supercomputing Environment.....................|___|
Enter total number of tutorials at the appropriate rate
(rates are per tutorial).
Advance Registration Regular Registration
(Received by July 8, 1994) (Received after July 8, 1994)
--------------------- -------------------
IEEE/ACM SIGCOMM Member ___ @ $165 ___ @ $195
Non-Member ___ @ $205 ___ @ $245
Total Tutorial Fee: $________US
Each Tutorial registration fee includes attendance at one
tutorial session, notes, and coffee breaks. There are no student fees
for the tutorials. Cancellations of tutorial registrations after
July 22 will be subject to the total fee.
We reserve the right to cancel the tutorials
due to insufficient participation or other unforeseeable problems,
in which case fees will be refunded.
-----------------------------------------------------------
Symposium Registration Fee $_________ + Extra cruise tickets $_______ +
Tutorial Fees $___________ = Total Amount enclosed: $________ US
-----------------------------------------------------------
Name: ____________________________________
Affiliation: _____________________________
Address: _________________________________
City/State/Zip/Postal Code/Country: ________________________________
Phone: ___________________________________
FAX: _____________________________________
E-mail Address: ___________________________
IEEE/ACM SIGCOMM Member #: ____________________________
(required for member rate)
Method of Payment
__ Visa __ Mastercard __check enclosed (payable to Syracuse University)
Card Holder Name: ________________________
(as it appears on card)
Card Number: _____________________________
Expiration Date: _________________________
Signature: _______________________________
You may register by e-mail using your credit card.
Send completed registration to hpdc at nova.npac.syr.edu
If you have a disability and may require accommodation in order ______
to fully participate in this activity, please check | |
here. You will be contacted to discuss your needs. |____|
Vegetarian Meals: ___ YES / ___ NO
Cancellation Policy: All requests for refunds must be received
in writing on or before July 22, 1994. No refunds will be made
on cancellations made after this date.
**************************************************************************
HOTEL REGISTRATION
Please contact the Westin St. Francis Hotel directly for
accommodations.
The Westin St. Francis
Union Square
335 Powell Street
San Francisco, CA 94102 USA
Phone: (415) 397-7000
Special conference rates have been arranged for attendees of
HPDC-3. The rates are as follows:
Type of Room Main Building Towers
Single Double Single Double
Standard $120 $120 - -
Medium $135 $135 - -
Deluxe $150 $150 $170 $170
Reservation cut-off date is Friday, July 1, 1994;
Reservations made after this date will be on a space-available basis only.
In order to receive our special rates you must identify
yourself as a participant in the HPDC-3 Conference.
**************************************************************************
CONFERENCE COMMITTEES
**************************************************************************
SYMPOSIUM GENERAL CHAIR: Geoffrey Fox, NPAC, Syracuse University
SYMPOSIUM STEERING COMMITTEE:
- Salim Hariri, Syracuse University (Chair)
- Tilak Agerwala, IBM
- Andrew Grimshaw, University of Virginia
- H. T. Kung, Harvard University
- T. V. Lakshman, Bell Communications Research
- Daniel McAuliffe, Rome Laboratory
- C. S. Raghavendra, Washington State University
PROGRAM CHAIR: Anujan Varma, University of California, Santa Cruz
PUBLICITY CHAIRS:
North America: T. V. Lakshman, Bell Communications Research
Europe: Walid Dabbous, INRIA, France
Asia: Makoto Takizawa, Tokyo Denki University, Japan
TUTORIALS CHAIR: Ian F. Akyildiz, Georgia Tech
EXHIBITS: C. S. Raghavendra, Washington State University
REGISTRATION AND LOCAL ARRANGEMENTS: Peggy Van Arnam, Syracuse University
PROGRAM COMMITTEE
- Dharma Agrawal, North Carolina State University
- Prathima Agrawal, AT&T Bell Labs
- Ian F. Akyildiz, Georgia Tech
- Marco Annaratone, DEC
- Ken Birman, Cornell University
- Suresh Chalasani, University of Wisconsin, Madison
- Monsong Chen, IBM Research
- Roger Chen, Syracuse University
- Abdelaziz Chihoub, Siemens Corporate Research
- Jon Crowcroft, University College London
- Walid Dabbous, INRIA, France
- Patrick Dowd, SUNY Buffalo
- Dennis Duke, SCRI/Florida State University
- Stuart Elby, NYNEX Science and Technology
- Richard Freund, NRaD
- J.J. Garcia-Luna, University of California, Santa Cruz
- Arif Ghafoor, Purdue University
- Andrew Grimshaw, University of Virginia
- Salim Hariri, Syracuse University
- S. H. Hosseini, University of Wisconsin, Milwaukee
- T. V. Lakshman, Bell Communications Research
- C. R. Mechoso, UCLA
- Paul Messina, Caltech
- Richard C. Metzger, Rome Laboratory
- Paul Mockapetris, USC/ISI
- John Morrison, Los Alamos National Laboratory
- John Nicholas, Battelle Pacific Northwest Lab
- James C. Patterson, Boeing Co.
- Ira Pramanick, IBM
- Michael Quinn, Oregon State University
- C. S. Raghavendra, Washington State University
- Paul Rupert, Lawrence Livermore National Laboratory
- Karsten Schwan, Georgia Institute of Technology
- Nita Sharma, Ncube Inc.
- Vaidy Sunderam, Emory University
- Makoto Takizawa, Tokyo Denki University, Japan
- Alexander Thomasian, IBM Research
- Satish Tripathi, University of Maryland
- Larry Wittie, SUNY Stony Brook
- Pen-Chung Yew, University of Illinois
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13948;
17 May 94 19:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13933;
17 May 94 19:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24251;
17 May 94 19:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13921;
17 May 94 19:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13895;
17 May 94 19:35 EDT
Received: from uucp6.netcom.com by CNRI.Reston.VA.US id aa24208;
17 May 94 19:35 EDT
Received: from localhost by netcomsv.netcom.com with UUCP (8.6.4/SMI-4.1)
id QAA07369; Tue, 17 May 1994 16:20:40 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: lynn at bli.com
Received: by bli.com (AIX 3.2/UCB 5.64/4.03)
id AA26734; Tue, 17 May 1994 16:04:59 -0700
Date: Tue, 17 May 1994 16:04:59 -0700
Message-Id: <9405172304.AA26734 at bli.com>
To: ietf at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: new experimental IETF RFC index
Reply-To: Lynn Wheeler <lynn at bli.com>
New experimental ietf rfc index at
ftp://ftp.network.com/IPSEC/rfcietf.html
The standards index information has 3-4 minor modifications as
indicated in that section of the html file.
The protocol index information attempts to merge the data found in the
Assigned Numbers tables (rfcxxxx) and Official Protocols tables
(rfcxxxx). In order to do that, there are about 30 or so manual
changes to the text strings that are loaded from the Assigned Numbers
tables (to correspond with the same text strings used in the Official
Protocols tabels).
The term index has been updated so that term definitions are self
selectable. The objective is to "checkpoint" the current position
so on return from checking on an RFC ... return is made to the
same position in the term index.
I've introduced the semantic relationship "HasPreferred" into
the database for the following authors:
"Case, J.D." HasPreferred "Case, J."
"Cerf, V.G." HasPreferred "Cerf, V."
"Chapin, A.L." HasPreferred "Chapin, L."
"Chapin, Lyman" HasPreferred "Chapin, L."
"Crispin, M.R." HasPreferred "Crispin, M."
"Hardcastle-Kille, S.E." HasPreferred "Hardcastle-Kille, S."
"Kastenholz, F.J." HasPreferred "Kastenholz, F."
"Kent, S.T." HasPreferred "Kent, S."
"Knopper, Mark" HasPreferred "Knopper, M."
"Malis, A.G." HasPreferred "Malis, A."
"Malkin, G.S." HasPreferred "Malkin, G."
"McLaughlin, L.J." HasPreferred "McLaughlin, L."
"Mills, D.L." HasPreferred "Mills, D."
"Postel, J.B." HasPreferred "Postel, J."
"Rekhter, J." HasPreferred "Rekhter, Y."
"Reynolds, J.K." HasPreferred "Reynolds, J."
"Rose, M.T." HasPreferred "Rose, M."
"Simpson, W.A." HasPreferred "Simpson, W."
and the author index then shows consolidated listing under the preferred
authors name.
I've so far only introduced the "HasPreferred" into the database for
some of the IETF terms, i.e.:
"Privacy enhancement for Internet electronic mail"
HasPreferred "Privacy Enhanced Mail"
Acronyms and non-preferred terms now both map to the standard
preferred term for the term index (with all rfc references appearing
under the common term).
I'm in the process of of defining "IsASenseOf" and "HasASense" that
are somewhat analogous to the traditional semantic network
relationships "IsA" and "HasInstance". The effect of "IsASenseOf" for
the term index will be somewhat analogous to "see also".
An example is "Kerberos" with "IsASenseOf" relationship to both
"authentication" and "encryption". "Kerberos" RFCs would then be
listed not only under "Kerberos" but also under "authentication" and
"encryption".
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06349;
18 May 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09535;
18 May 94 11:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06286;
18 May 94 11:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05890;
18 May 94 10:58 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iafa at cc.mcgill.ca
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iafa-publishing-01.txt
Date: Wed, 18 May 94 10:58:31 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405181058.aa05890 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Anonymous FTP
Archives Working Group of the IETF.
Title : Publishing Information on the Internet with Anonymous
FTP
Author(s) : P. Deutsch, A. Emtage
Filename : draft-ietf-iafa-publishing-01.txt
Pages : 28
Date : 05/17/1994
This document specifies a range of information that your site may wish to
make available on your Anonymous FTP Archive to the Internet user
community. Automatic archive indexing tools have been created that can
gather and index this information, thus making it easier for users to find
and access it. It also may be used by the general user community for
extracting information about the archive itself, or about material
contained on the archive.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iafa-publishing-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-iafa-publishing-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940517140402.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-iafa-publishing-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iafa-publishing-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940517140402.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06437;
18 May 94 11:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09573;
18 May 94 11:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06387;
18 May 94 11:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06264;
18 May 94 11:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-smtp at dimacs.rutgers.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-smtpext-pipeline-02.txt
Date: Wed, 18 May 94 11:12:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405181112.aa06264 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Mail Extensions
Working Group of the IETF.
Title : SMTP Service Extension for Command Pipelining
Author(s) : J. Klensin, N. Freed
Filename : draft-ietf-smtpext-pipeline-02.txt
Pages : 9
Date : 05/17/1994
This memo defines an extension to the SMTP service whereby a server can
indicate the extent of its ability to accept multiple commands in a single
TCP send operation. Using a single TCP send operation for multiple commands
can improve SMTP performance significantly.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-smtpext-pipeline-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-smtpext-pipeline-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940517135040.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-smtpext-pipeline-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-smtpext-pipeline-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940517135040.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08583;
18 May 94 13:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12505;
18 May 94 13:05 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08567;
18 May 94 13:05 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06805;
18 May 94 11:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-simpson-sipp-64-bit-plan-00.txt
Date: Wed, 18 May 94 11:31:54 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405181131.aa06805 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Administrative Allocation of the 64-bit Number Space
Author(s) : W. Simpson
Filename : draft-simpson-sipp-64-bit-plan-00.txt
Pages : 7
Date : 05/17/1994
SIPP uses a numbering space of 64 bits, to replace the 32 bit space used in
the current IP. This document specifies an administrative allocation plan.
Space is reserved for end-point identifier, metropolitan, and provider
assignment schemes to exist in parallel. Special consideration is given to
the interaction of these schemes with the inverse function of the domain
name service.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-simpson-sipp-64-bit-plan-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-simpson-sipp-64-bit-plan-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940517141445.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-simpson-sipp-64-bit-plan-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-simpson-sipp-64-bit-plan-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940517141445.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27112;
17 May 94 22:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27099;
17 May 94 22:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03732;
17 May 94 22:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26887;
17 May 94 22:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26422;
17 May 94 22:46 EDT
Received: from access2.digex.net by CNRI.Reston.VA.US id aa03351;
17 May 94 22:45 EDT
Received: by access2.digex.net id AA19062
(5.67b8/IDA-1.5 for IETF List <ietf at cnri.reston.va.us>); Tue, 17 May 1994 22:45:07 -0400
Newsgroups: tdr.paul.private.mail
Date: Tue, 17 May 1994 22:45:07 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Robinson <PAUL at tdr.com>
X-Orig-Sender: Paul Robinson <PAUL at tdr.com>
Reply-To: Paul Robinson <PAUL at tdr.com>
Subject: Who 'owns' the Internet?
To: emailman at vtvm1.cc.vt.edu
Message-Id: <01.1994May17.22h30m35s.PAUL-0100000 at TDR.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
From: Paul Robinson <PAUL at TDR.COM>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
A user on the EMailman list <EMAILMAN at VTVM1.CC.VT.EDU> posed the question
about hooking up to the internet and asked the question, "Who owns the
Internet?"
The answer which is least informative and closest to the truth is
"nobody" and "somebody", both and neither.
The actual answer is that a large number of independent organizations
agreed to use the same method of transfering data (the TCP/IP protocol)
and to connect their networks together using this method. A group of
networks connected together - any group of networks - is called an
"internet". The group of networks which communicates using TCP/IP
internationally on a cooperative basis is called the "Internet" (with a
capital I).
Each organization owns its own network. Some organizations use common
carrier facilities to connect to the Internet. But the Internet itself is
an example of probably the closest thing to an anarchy that has ever
existed. No individual group, organization or government or international
organization "owns" the Internet. There are no rules and no mandatory
requirements. It is only because it is in each party's interest to
cooperate with the standards that it works. Since failing to cooperate
with the standards makes one's network less valuable, these standards
have generally been "self enforcing".
An international communications system that operates without any mandatory
rules or government coercion, that enables people to get things done
using it, nobody owns it and yet it works because it appeals to people's own
self-interest to see that it does.
What a unique concept!
---
Paul Robinson - Paul at TDR.COM
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy at psg.com>
-----
The following Fortune Cookie was selected for this message:
"We're going to blast through the Internet like the Four Horsemen of
the Apocalypse!" - Sonny Harari, Tekwar "Tekjustice"
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11310;
18 May 94 15:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11302;
18 May 94 15:30 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa17236;
18 May 94 15:30 EDT
Received: from dun-dun-noodles.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA07189 at pad-thai.aktis.com>; Wed, 18 May 1994 14:51:51 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
Received: by dun-dun-noodles.aktis.com (4.1/4.7) id AA23951; Wed, 18 May 94 14:51:49 EDT
Date: Wed, 18 May 94 14:51:49 EDT
Message-Id: <9405181851.AA23951 at dun-dun-noodles.aktis.com>
To: cat-ietf at mit.edu
Subject: change of control of cat-ietf list from MIT to OpenVision
Starting in the next few days, OpenVision will be taking over from MIT
maintenance of the cat-ietf list. The address will not change;
cat-ietf at mit.edu will be changed to point at a mail server at
OpenVision. This message is sent to the old cat-ietf list, bcc'd to
the new cat-ietf list, both of which should be up to date right now.
You should receive two copies of this email (this should be the only
such test I have to do). If you only receive one, or if you know of
someone who wants to receive list email and isn't, please let
<cat-ietf-request at mit.edu> know, so I can figure out what is wrong,
and fix it. If you have any changes you want made, please also send
mail, so I can make those changes.
Thanks.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11760;
18 May 94 15:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11756;
18 May 94 15:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17700;
18 May 94 15:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11740;
18 May 94 15:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11732;
18 May 94 15:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17684;
18 May 94 15:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11723;
18 May 94 15:49 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: bgp at ans.net
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Border Gateway Protocol to Proposed Standard
Date: Wed, 18 May 94 15:49:21 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405181549.aa11723 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Border Gateway Protocol
Working Group to consider the following Internet-Drafts:
o "A Border Gateway Protocol 4 (BGP-4)"
<draft-ietf-bgp-bgp4-10.txt>
o "BGP-4 protocol document roadmap and implementation experience"
<draft-ietf-bgp-bgp4-implement-01.txt>
o "Definitions of Managed Objects for the Fourth Version of Border
Gateway Protocol (BGP-4)" <draft-ietf-bgp-mibv4-06.txt>
o "Application of the Border Gateway Protocol in the Internet"
<draft-ietf-bgp-application-04.txt>
for the status of Proposed Standard.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any comments
to the iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing
lists by 1 June.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14434;
18 May 94 17:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14420;
18 May 94 17:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20520;
18 May 94 17:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14389;
18 May 94 17:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14298;
18 May 94 17:42 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa20455; 18 May 94 17:42 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA13493 for ietf at cnri.reston.va.us; Wed, 18 May 94 17:41:48 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id OAA10171; Wed, 18 May 1994 14:39:40 -0700
Message-Id: <199405182139.OAA10171 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: student grants for SIGCOMM '94
Reply-To: Craig Partridge <craig at aland.bbn.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 18 May 94 14:39:38 -0700
X-Orig-Sender: craig at aland.bbn.com
*******************************************************************************
STUDENT GRANTS TO ATTEND ACM SIGCOMM '94
ACM SIGCOMM '94 has received funding from the US National Science
Foundation (NSF) and Advanced Research Projects Agency (ARPA) to fund
up to eight graduate students of US universities to attend ACM SIGCOMM '94
in London (August 31 to September 2nd, with tutorials August 29 and 30).
The grants are up to $1000 each and intended to cover trans-Atlantic airfare,
hotel accommodations, and meals. Students should note that the grant sizes
are fixed (any costs in excess of the grant will not be reimbursed).
SIGCOMM '94 will waive the conference fee for awardees. Note that
all flights must be on a US carrier and be between the US and England to
be reimbursed, and that while students need not be US citizens or permanent
residents to apply, they do need a US Social Security number (for accounting
reasons). Further note that SIGCOMM is only waiving conference fees, not
tutorial fees.
Applications for grants will be evaluated by a three person committee
of Prof. Ian Akyildiz (Georgia Tech - chair), Prof. Lillian Cassel (Villanova)
and Prof. Craig Partridge (Stanford/BBN). Grants will be awarded based
on the committee's estimate of how much attending the conference is likely
to benefit the student's graduate research, education and career prospects.
Some preference will be given to applicants from historically black colleges
and universities and minority institutions.
To apply for a grant, a student should send a letter to Prof. Akyildiz
explaining how they believe attending the conference will benefit them.
The letter should be accompanied by a quote of the lowest available airfare
from the student's location to London and a letter from the student's graduate
advisor which evaluates the quality of the student's graduate work to date.
E-mail applications (to ian at armani.gatech.edu) are encouraged. Applications
are due by June 10th. The committee decisions will be made by June 25th.
If the application cannot be e-mailed, send it via postal mail to:
Dr. Ian F. Akyildiz
Georgia Institute of Technology
School of Electrical and Computer Engineering
791 Atlantic Drive, NW
Atlanta, GA 30332-0269
*******************************************************************************
*******************************************************************************
[Note to students -- I am aware of some less expensive hotels (c. 32 English
pounds per night) near the conference area, and am in fact going to stay in
one myself. Contact me if you need recommendations -- Craig Partridge,
(craig at bbn.com). Keep in mind that you don't need to give us a budget when
you apply -- just a plane fare quotation].
Advance Programme
ACM SIGCOMM'94 CONFERENCE
Communications Architectures, Protocols and Applications
University College London
London, UK
August 31 to September 2, 1994
(Tutorials and Workshop, August 29-30)
Sponsored by
The ACM Special Interest Group of Data Communication
This conference provides an international forum for the presentation
and discussion of communication network applications and technologies,
architectures, protocols, algorithms, and performance models. The
conference and tutorials will be conducted on the University College
London, London England.
----------------------------------
T E C H N I C A L P R O G R A M
----------------------------------
Monday 29 August 1994
* 7:30AM - 5:00PM
Tutorial and Conference Registration
UCL CS Department, Pearson Building
* 9:00AM - 5:00PM, Tutorial T1
"Personal Communication Services and Networks"
Zygmunt Haas (AT&T Bell Labs)
UCL CS Department, Pearson Building
* 9:00AM - 5:00PM, Tutorial T2
"Protocol Performance"
David D. Clark (MIT)
UCL CS Department, Pearson Building
Tuesday 30 August 1994
* 7:30AM to 5:00PM
Tutorial and Conference Registration
Edward Lewis Lecture Theatre, Windeyer Building
* 9:00AM - 5:00PM, Workshop W1
"Topics in High Performance Networking Support of
Distributed Systems"
Derek McAuley (University of Cambridge)
UCL CS Department, Pearson Building
* 9:00AM - 5:00PM, Tutorial T3
"Fiber Optic Networks"
Paul E. Green, Jr. (IBM Corporation)
UCL CS Department, Pearson Building
* 9:00AM - 5:00PM, Tutorial T4
"Multimedia Conferencing on the Internet"
Van Jacobson (Lawrence Berkeley Laboratories)
Edward Lewis Lecture Theatre, Windeyer Building
* 9:00AM - 5:00PM, Tutorial T5
"Asynchronous Transfer Mode"
Rainer Handel (Siemens Munich)
UCL CS Department, Pearson Building
* 5:30PM - 8:30PM
Welcoming Reception
The Quad at University College London
Wednesday 31 August 1994
* 7:30AM to 5:00PM
Conference Registration
Edward Lewis Lecture Theatre, Windeyer Building
* 9:00AM - 10:00AM
Session 1: Keynote Address
(1994 ACM SIGCOMM Award Winner)
Edward Lewis Lecture Theatre, Windeyer Building
* 10:30AM-12:30PM
Session 2: Protocol Performance
Experiences with a High-Speed Network
Adaptor: A Software Perspective (Best Student Paper)
P. Druschel (University of Arizona), L.L. Peterson (University of
Arizona), & B.S. Davie (Bellcore)
User-space Protocols Deliver High Performance to Applications on a
Low-Cost Gb/s LAN
A. Edwards, G. Watson, J. Lumley, D. Banks,
C. Calamvokis, & C. Dalton (Hewlett-Packard Labs, Bristol)
TCP Vegas: New Techniques for Congestion Detection and Avoidance
L.S. Brakmo, L.L. Peterson, & S.W. O'Malley (University of Arizona)
A Structured TCP in Standard ML
E. Biagioni (Carnegie Mellon University)
* 12:30PM - 2:00PM
Lunch
* 2:00PM-3:30PM
Session 3: Congestion Management
Making Greed Work in Networks: A Game-Theoretic Analysis of
Switch Service Disciplines
S. Shenker (Xerox PARC)
Scalable Feedback Control for Multicast Video Distribution in the Internet
J. Bolot (INRIA), T. Turletti (INRIA) & I. Wakeman
(University College, London)
Statistical Analysis of Generalized Processor
Sharing Scheduling Discipline
Z.-L. Zhang, D. Towsley, & J. Kurose (University of Massachusetts)
* 4:00PM-5:30PM
Session 4: ATM Flow Control
The Dynamics of TCP Traffic over ATM Networks
A. Romanow (Sun Microsystems) & S. Floyd (Lawrence Berkeley Labs)
Reliable and Efficient Hop-by-Hop Flow Control
C. Ozveren (DEC, Littleton), R. Simcoe (DEC, Littleton) &
G. Varghese (Washington University, St. Louis)
Credit Update Protocol for Flow-Controlled ATM
Networks: Statistical Multiplexing and Adaptive Credit Allocation
H.T. Kung (Harvard University), T. Blackwell (Harvard
University), & A. Chapman (BNR)
* 7:30PM - 10:00PM
SIGCOMM Social: Reception and Dinner
The Dinosaur Room, Natural History Museum
(Tickets Required)
Thursday 1 September 1994
* 7:30AM to 5:00PM
Conference Registration
Edward Lewis Lecture Theatre, Windeyer Building
* 8:30AM - 10:00 AM
Session 5: Internet Routing
Flexible Routing and Addressing for a Next Generation IP
P. Francis (NTT Software Labs) & R. Govindan (Bellcore)
An Architecture for Wide-Area Multicast Routing
S. Deering(Xerox PARC), D. Estrin (University of Southern
California), D. Farinacci (Cisco Systems), V. Jacobson
(Lawrence Berkeley Labs), C.-G. Liu (University of Southern
California) & L. Wei (University of Southern California)
Distributed Routing Based on Link-State Vectors
J. Behrens & J.J. Garcia-Luna-Aceves (University of
California at Santa Cruz)
* 10:30AM-12:00PM
Session 6: ATM Switching and Signalling
Signaling and Operating System Support for
Native-Mode ATM Applications
R. Sharma & S. Keshav (AT&T Bell Labs)
Experiences of Building ATM Switches for the Local Area
D.R. McAuley, R.J. Black & I.M. Leslie (University of Cambridge)
Controlling Alternate Routing in General-Mesh
Packet Flow Networks
S. Sibal (RPI) & A. DeSimone (AT&T Bell Labs)
* 12:00PM - 1:30PM
Lunch
* 1:30PM-3:00PM
Session 7: Nueral and Optical Networks
On Optimization of Polling Policy Represented
by Neural Network
Y. Matumoto (I.T.S., Inc., Japan)
An Optical Deflection Network
J. Feehrer (University of Colorado, Boulder), L. Ramfelt
(University of Colorado, Boulder/Royal Institute of Technology,
Stockholm), & J. Sauer (University of Colorado, Boulder)
Conflict-Free Channel Assignment for an Optical
Cluster-Based Shuffle Network Configuration
K.A. Aly (University of Central Florida)
* 3:30PM-5:30PM
Session 8: Selected Topics
MACAW: A Media Access Protocol for Wireless LANs
V. Bharghavan (UC Berkeley), A. Demers (Xerox PARC),
S. Shenker (Xerox PARC) & L. Zhang (Xerox PARC)
Asymptotic Resource Consumption in Multicast
Reservation Styles
D.J. Mitzel (University of Southern California) & S. Shenker
(Xerox PARC)
Highly Dynamic Destination-Sequenced Distance-
Vector Routing (DSDV) for Mobile Computers
C.E. Perkins & P. Bhagwat (IBM, Watson Research Center)
A Methodology for Designing Communication Protocols
G. Singh (Kansas State University)
* 5:30PM - 6:30PM
SIGCOMM Business Meeting
Friday 2 September 1994
* 8:30AM - 10:00AM
Session 9: Traffic Models
Wide-Area Traffic: The Failure of Poisson Modeling
V. Paxson & S. Floyd (Lawrence Berkeley Labs)
Analysis, Modeling and Generation of Self-Similar
VBR Video Traffic
M.W. Garrett & W. Willinger (Bellcore)
An Algorithm for Lossless Smoothing of MPEG Video
S.S. Lam, S. Chow, & D. Yau (University of Texas, Austin)
* 10:30AM-12:00PM
Session 10: Host Software
USC: A Universal Stub Compiler
S.W. O'Malley, T. Proebsting, & A. Montz (University of Arizona)
An Object-based Approach to Protocol Software Implementation
C.-S. Liu (Chung Yuan Christian University, Taiwan)
Improved Algorithms for Synchronizing Computer Network Clocks
D.L. Mills (University of Delaware)
* 12:00PM - 12:15PM
Closing Session
Note: Program subject to change.
-----------------
T U T O R I A L S
-----------------
Tutorial T1
-----------
Zygmunt Haas, AT&T Bell Labs
"Personal Communication Services and Networks"
The recent explosion of interest in wireless and mobile networks,
stimulated by the effort of Personal Communication Services and
Networks (PCS & PCN) to be deployed at the beginning of the next
century, suggests the enormous technological, scientific, and
commercial potential in this field. The subject of wireless and mobile
communication integrates the large body of knowledge accumulated
through the traditional radio research, the large networking
experience accumulated through the proliferation of LANs and WANs, and
the vision of ubiquitous connectivity anywhere, at anytime, with
anyone, and in any format.
The tutorial exposes both the theoretical and the practical
aspects of mobile networking, from a networking and application
perspective. We will present the concept, architecture, and
functionality of Personal Communications Services and Networks (PCS &
PCN) and Universal Personal Telecommunications (UPT) and we will
describe the most common platform for mobile communications: the
wireless systems. In particular, systems such as cellular, cordless,
and satellite will be discussed. Existing and in-progress standards
are also outlined.
Finally, an abundance of examples of the wireless and mobile
networks will be described, giving realism to the presented material.
TOPICS:
* Elements of Wireless Mobile Communications
* Wireless Services and Applications
* The Cellular Concept
* The Cordless Concept
* Digital Communication Networks
* Local-Area Wireless Data Access
* Wide-area Wireless Data Access
* Mobile Satellite Communications
* Standardization of Wireless Networks
* PCS/PCN and UPT
* Summary: Where we have started and where are going .
Zygmunt Haas received his B.Sc. in EE in 1979 and M.Sc. in EE in 1985,
both with Summa Cum Laude. From 1979 till 1985 he worked for the
Government of Israel. In 1988, he earned his Ph.D. from Stanford
University researching fast packet-switched networks, and subsequently
joined AT&T Bell Laboratories in Holmdel NJ, where he is now a Member
of Technical Staff in the Wireless Networks Department. Dr. Haas is
an author of numerous technical papers and holds several patents in
the field of high-speed networking, wireless networks, and optical
switching. He has organized several workshops and served as a guest
editor for JSAC issues. Dr. Haas is a Senior Member of IEEE and his
interests include: mobile and wireless communication networks,
personal communication services, high-speed communication protocols,
and optical switching.
Tutorial T2
-----------
David D. Clark, MIT
"Protocol Performance"
Getting proper performance from a network or protocol is often a
difficult task. This tutorial uses examples from the Internet (TCP/IP)
protocol suite to illustrate critical performance issues. The focus is
on providing real-world advice on how to design and implement
protocols in ways that avoid performance problems. The presentation
will include examples of various performance problems and how to
detect and recognize them.
Topics
* Performance issues (reliability, throughput and delay)
* Implementation bottlenecks
* Specifications and their limitations
* Heterogeneity and its impact on implementation
* Network dynamics
* Visualizing protocol performance
* Limits of protocol performance
Dr. David Clark is a senior research scientist at MIT Laboratory for
Computer Science and a recipient of the ACM SIGCOMM Award. He has
worked on TCP/IP since the mid-1970s and from 1981 to 1989 was
chairman of the Internet Activities Board. He is widely known for his
insight into protocol design and performance and for his skill in
identifying and eliminating myths about protocol implementation and
performance. His current areas of research include high-performance
networks, the evolution of the Internet, ATM and information
networking. He received his doctorate from MIT in 1973.
Tutorial T3
-----------
Paul E. Green, Jr., IBM
"Fiber Optic Networks"
Fiber optic technology has completely transformed the internal
operation of the world's telephone networks and is beginning to impact
local computer networks. Compared to the voice grade phone line
technology, which defined most of the network architectures that we
are still living with today, fiber offers ten orders of magnitude
better bandwidth and an equal improvement in achievable bit error
rate. By use of WDM and circuit switching, the additional benefits of
protocol transparency can be achieved.
There is a widespread feeling that the generation of network
that will follow today's ATM and upgraded Internet structures might
very well be based on techniques that directly unlock this
revolutionary improvement at the physical level.
The course is devoted to the new class of "all-optical"
networks that attempt to do this. The lecturer will cover the
optoelectronic components involved and will also treat some of the
network architectural consequences, the regulatory and economic
picture, and review some systems already implemented.
TOPICS
* Motivating fiber optic networks
* Fibers, couplers and taps
* Optical resonant structures
* Laser diodes and amplifiers
* Optical receivers
* System considerations
* Network topologies and link budgets
* Protocols, layers and network control
* Some implemented systems
* Status and prospects
Paul E. Green, Jr, is Manager of Advanced Optical Networking Member at
IBM Research in Hawthorne, NY. He received the ScD degree from M.I.T.
in 1953, and after some years at M.I.T. Lincoln Laboratory, where he
made pioneering contributions to spread spectrum, adaptive receivers,
radar astronomy and seismic data processing, he joined IBM Research in
1969. At IBM he has held a variety of management and Corporate
Technical Staff positions. His technical interests have centered on
computer network architecture, and he has received several IBM
Outstanding Innovation Awards for his role in the initial formulation
and promotion of Advanced Peer to Peer Networking, now the basis for
further evolution of IBM's System Network Architecture. He is a member
of the National Academy of Engineering, in 1983 was named
Distinguished Engineering Alumnus by North Carolina State University,
and received the IEEE's Simon Ramo Medal in 1991. He is the author of
many technical papers, has edited several books on computer
communications, and is the author of the textbook Fiber Optic
Networks, published by Prentice Hall in June,1992. He has been
President of both the IEEE Communication Information Theory Society
and the Communication Society.
Tutorial T4
-----------
Van Jacobson, LBL
"Multimedia Conferencing on the Internet"
An architectural overview and detailed walk-through of the protocols
and applications that provide real-time, multiparty, audio, video and
shared workspace conferencing on today's Internet.
Experiments and demonstrations over the Internet MBONE and the
DARTNET testbed have shown that multimedia and conferencing
applications can indeed work over IP internets. Playback algorithms
that adapt to variations in network delay (such as VAT) and
information distribution algorithms designed to facilitate shared
workspaces (such as those used in the shared whiteboard) have made
these sorts of applications possible. This tutorial describes these
algorithms and the applications that use them.
Topics
* IP as a real-time infrastructure: multicasting and queueing
* Adaptive Playback: VAT
* Managing Sessions: SD
* Managing Shared Workspaces: Shared Whiteboard
* Implications for the future of IP
Van Jacobson is a senior researcher at Lawrence Berkeley Laboratories,
where he works on real-time system performance, protocol and operating
system performance. He is widely known for his groundbreaking work on
TCP/IP performance, TCP/IP congestion control, and support for
multimedia applications on the Internet. He is the recipient of a
number of awards and teaches periodically at U.C. Berkeley and
Stanford University.
Tutorial T5
-----------
Rainer Handel, Siemens Munich
"Asynchronous Transfer Mode"
The tutorial will provide a comprehensive introduction to the
Asynchronous Transfer Mode (ATM). Both technical and marketing aspects
of ATM will be addressed. ATM specification is not yet complete but in
a state that allows implementations which are basically compliant with
a worldwide agreed, unique standard supporting data, voice, image and
multimedia applications.
The presentation of the concept of ATM networking will include
the ATM protocol reference model, the architecture of ATM networks,
interfaces and procotols, traffic control and resource management,
signalling, operational aspects, ATM evolution and internetworking
aspects, and of course a detailed description of the ATM layer and ATM
adaptation layer functions. An overview of how ATM cells are switched
and transmitted will also be given. The possible use of ATM in a
business and residential environment and its market acceptance
depending on product availability, cost and feature offerings will be
clarified.
TOPICS:
* High speed networks
* ATM concept
* ATM protocols
* ATM interfaces
* interworking and evolvability
* market aspects
* switching and transmission products
* network implementations and service offerings
Rainer Handel has been with Siemens (Public Communications Networks
Group) since 1978 doing system design and software development for
switching systems, ATM conceptual and standardization work, ATM
network and product planning, and currently long-term telecom market
and technology trend evaluation. For several years he was active in
the standards bodies CCITT, ETSI and T1, and is the author of several
papers and a book on ATM.
Workshop W1
----------
Derek McAuley, University of Cambridge
"Topics in High Performance Networking Support of Distributed Systems"
This one day workshop will present the experiences of the speakers in
building various components of distributed systems which aim to
effectively utilise modern high performance networks. This workshop
consists of 4 talks. Each talk will be 60 minutes with 15 minutes for
discussion.
1. The CHORUS Communication Architecture, Marc Rozier
The communication service is a key component of the CHORUS
micro-kernel architecture. First, it provides the basic framework
allowing efficient modular operating system implementations. By
dramatically reducing the overhead of local communications, it is key
to the success of such serverized implementations, which are now able
to compete with monolithic implementations. Second, it provides
efficient, network-transparent, communication services, well adapted
to the distribution of the operating system servers. In particular,
it makes possible the implementation of UNIX systems on massively
parallel architectures, offering a single system image to their users.
This tutorial will address the various aspects of this communication
architecture, from the definition of the communication services, to
some aspects of its implementation. Emphasis will be placed on
insights from previous versions of this service.
2. The Organization of Networks in Plan 9, Rob Pike
In a distributed system networks are of paramount importance. This
tutorial describes the implementation, design philosophy and
organization of network support in Plan 9. Topics include network
requirements for distributed systems, our kernel implementation,
network naming, user interfaces and performance. We also observe that
much of this organization is relevant to current systems.
3. Mixed media applications, David Tennenhouse
WWW is a rapidly growing phenomena which highlights the interesting
applications possible with mixed media types. From experience with the
WWW this tutorial will address the issues raised in supporting these
mixed media types and the problems in building systems which support
media with time constraints.
4. What can you do with ATM today?, Derek McAuley
ATM must now be officially a bandwagon. Some will tell you it solves
all the world's problems because it was designed to, while others will
say it's good for nothing. The reality and hype are hard to
distinguish. This talk will address what ATM can be used for today and
highlight those features for which it is rightly criticised not least
of which is end-system integration. The talk could be subtitled,
"Difficult questions to ask your ATM salesman''.
Marc Rozier is the head of the Micro-Kernel Department within Chorus
systemes. He graduated from Ecole Nationale Superieure Informatique et
de Mathematiques Applique'es de Grenoble (ENSIMAG) before earning a
doctor's degree in Computer Science from Institut National
Polytechnique de Grenoble (INPG). In 1981-82, he was involved in the
CESAR project at IMAG (Grenoble), working on the Validation of
Distributed Systems. He gained experience in programming languages for
distributed applications and distributed systems. He joined INRIA in
1982 as a researcher in the CHORUS distributed operating system
project. In 1987, he became one of the founders of Chorus systemes. He
is one of the main designers of the CHORUS-v3 Micro-Kernel technology.
He is the author of several publications in international journals and
conferences.
Rob Pike is well known for his appearances on "Late Night with David
Letterman", is also a Member of Technical Staff at AT&T Bell
Laboratories in Murray Hill, New Jersey, where he has been since 1980,
the same year he won the Olympic silver medal in Archery. In 1981 he
wrote the first bitmap window system for Unix systems, and has since
written ten more. With Bart Locanthi he designed the Blit terminal;
with Brian Kernighan he wrote The Unix Program- ming Environment. A
shuttle mission nearly launched a gamma-ray telescope he designed. He
is a Canadian citizen and has never written a program that uses cursor
addressing.
David Tennenhouse is an Assistant Professor of Computer Science and
Electrical Engineering at MIT's Laboratory for Computer Science. He is
leader of the Telemedia, Networks and Systems Group, which is
addressing systems issues arising at the confluence of three
intertwined technologies: broadband networks, high definition video
and distributed computing. David studied electrical engineering at
the University of Toronto, where he received his B.A.Sc. and M.A.Sc.
degrees. In 1989 he completed his Ph.D. at the Computer Laboratory of
the University of Cambridge. His Ph.D. research focused on ATM-based
site interconnection issues. This work, which was conducted within the
Unison Project, led to the early implementation of an ATM-based wide
area testbed.
Derek McAuley is a Lecturer in the Computer Laboratory at the
University of Cambridge. His research interests include networking,
distributed systems and operating systems. Recent work has
concentrated on the support of time dependent mixed media types in
both networks and operating systems. He has failed to leave Cambridge
since arriving in 1979 to read Mathematics. In 1989 he completed his
Ph.D. on ATM internetworking. He has had a hand in de-commissioning 4
ATM networks, including Tennenhouse's carefully constructed Unison
platform.
---------------
L o c a t i o n
---------------
The conference will be held in the Edward Lewis Lecture Theatre which
is located in the Windeyer Building on the UCL campus. This building
is located on the corner of Cleveland Street and Howland Street, with
the entrance on Cleveland Street. Tutorials are all in UCL Computer
Science Department in the Pearson Building, except T4 (Van Jacobson)
on the Tuesday which is held in the Edward Lewis Lecture Theatre.
The main entrance of UCL is located at the north end of Gower Street,
close to Euston Square, Warren Street, or Euston tube stations. The
UCL Computer Science Department is located in the basement of the
Pearson Building. Location
---------------------------
T r a n s p o r t a t i o n
---------------------------
* Getting to London
There are four airports in and around London. Here is some
information that might help you to plan your journey. Please consult
your travel agency or the airports directly for further information.
LONDON Heathrow Airport: 24 km west of London
Telephone: +44-81-745-6156
LONDON Gatwick Airport: 46 km south of London
Telephone: +44-293-535-353
STANsted Airport: 55 km north east of London
Telephone: +44-279-680-500
* Getting to UCL and Hotels
UCL is located in central London, and is served by Warren St, Euston
and Euston Square Underground (tube) stations, as well as several main
bus routes. The department of computer science is right by the
entrance to the main quadrangles, on Gower Street.
>From Heathrow: Best by tube with Victoria Line to Euston Station
(about #3, 50 minutes). Alternatives are via Bus with London Transport
A1 Airbus to Victoria Station (45 minutes).
For local hotels it is probably best to go to Euston Station and get a
taxi from there unless you have a street map already and know the
nearest tube station. A free tube map may be obtained at any ticket
office.
>From Gatwick: Best by train, BR Gatwick Express to London Victoria
Station every 15 minutes (about #8.60, 30 minutes).
Unless you plan to sightsee outside London a car is probably a waste
of time. Tube fares are based on a zone system. After 9:30AM you can
get One Day Travel cards which allow you unlimited travel within given
zones for the rest of the day - that includes train and bus services
within that zone too. Zones 1,2 & 3 #2.30 pounds. Zones 1-5 #2.60
pounds.
-------------------------
A c c o m o d a t i o n s
-------------------------
The following hotels are walking distance from the conference meeting
room on the UCL campus. Contact the hotel directly to place
reservations.It is highly recommended that reservations are made as
early as possible. Refer to SIGCOMM'94 when making the reservation.
* Hotel Ibis Euston
3 Cardington Street, NW1
Telephone: +44-71-388-7777, Fax: +44-71-388-0001
Total Rooms: 300
Single Room #49.50, Double Room #49.50
Near UCL, about 10 minute walk from main Conference Hall.
* St. George's Hotel
Langham Place, W1N
Telephone: +44-71-580-0111, Fax: +44-71-436-7997
Total Rooms: 86
Single Room: #80.00, Double Room: #100.00
(Includes Continental Breakfast)
Situated near Oxford Circus, about 10 minute walk from main venue.
* RAMSAY HALL
20 Maple Street, W1P
Total Rooms: 400
Telephone: +44-71-387-4537, Fax: +44-71-383-0843
Single Room: #19.50, Double Room: not available.
(Includes Continental Breakfast)
Student residence used as hotel during summer break, 5 minute walk
from main conference venue.
* Hotel Russell
Russell Square, WC1
Telephone: +44-71-837-6470, Fax: +44-71-837-2857
Total Rooms: 328
Single Room: #70.00, Double Room: #90.00
(Includes Continental Breakfast)
Old Victorian Style Hotel. About 15 minute walk from Conference
venues. Russel Square Station is on the Picadilly line which
reaches to Heathrow Airport. Airport Bus stop nearby as well.
* Forte Crest Bloomsbury
Coram Street, WC1
Telephone: +44-71-837-1200
Fax: +44-71-837-5374
Total Rooms: 230
Single Room: #69.00, Double Room: #79.00
(Includes Continental Breakfast)
Modern hotel near Hotel Russell.
There are a large number of hotels near the conference. Almost any
hotel in the WC1 area of London is within 15 minutes walking distance.
A list of more hotels may be found via www
(http://www.cs.ucl.ac.uk/sigcomm94) or anonymous ftp
(norman.eng.buffalo.edu:/pub/SIGCOMM94). The list also includes nearby
lower cost housing and youth hostels.
------------------------------------------------
R E G I S T R A T I O N I N F O R M A T I O N
------------------------------------------------
Full conference registration includes breaks, lunch, Tuesday evening
reception, one ticket to dinner in the Dinosaur Room of the Natural
History Museum on Wednesday, and a copy of the conference proceedings.
Student registration includes breaks, lunch and proceedings but does
not include the dinner/museum event. On site registration will begin
Monday August 29, 1994 from 7:30AM - 5:00PM, and every day of the con-
ference starting at 7:30 am.
ACM and SIGcomm Membership
--------------------------
If you are not an ACM or a SIGCOMM member at this time, you may join
now to take full advantage of ACM/SIGcomm Member or Student rates for
SIGCOMM94:
- ACM Associate Member Dues $82/#52
- Add SIGCOMM to ACM Membership $22/#15
- ACM Student Dues $25/#17
- Add SIGCOMM to ACM Student Membership $15/#10
- SIGCOMM Membership only (non-ACM) $50/#32
Total Membership Fees $/# _________
(Note: $ indicates U.S. dollars, and # British Pounds Sterling)
To advance the sciences and arts of information processing; to promote
the free interchange of information about the sciences and arts of
information processing both among specialists and among the public;
and to develop and maintain the integrity and competence of
individuals engaged in the practice of information processing. I
hereby affirm that I subscribe to the purpose of ACM and understand
that my membership is not transferable.
Signature _________________________________________ Date ____________
Tutorials
---------
Check each tutorial attending. The tutorial registration fee includes
one copy of the tutorial notes and lunch. Tutorials are on a first
come first serve basis.
- T1 Personal Communication Services & Networks (Monday)
- T2 Protocol Performance (Monday)
- T3 Fiber Optic Networks (Tuesday)
- T4 Multimedia Conferencing on the Internet (Tuesday)
- T5 Asynchronous Transfer Mode (Tuesday)
- W1 Workshop on Distributed Systems (Tuesday)
Tutorial Rates
Postmarked by Postmarked
aug/1/1994 after aug/1/1994
ACM/SIG Member _____@ $275/#172 _____@ $325/#205
Non-Member _____@ $350/#220 _____@ $400/#250
Student _____@ $138/#87 _____@ $175/#110
Total Tutorial Fees _____$/# _____$/#
Special Needs
-------------
Vegetarian Meals: - Yes - No
Conference Registration
-----------------------
Please complete and send registration form, with check, credit card
information or money orders (no purchase orders) to the address below.
Registrations accepted via postal mail, fax or email (with credit
card) only.
Postmarked by Postmarked
Aug/1/1994 after Aug/1/1994
ACM/SIG Member _____@ $315/#200 _____@ $365/#230
Non-Member _____@ $397/#252 _____@ $440/#275
Student _____@ $100/#63 _____@ $130/#82
Total Registration Fees $/# _____ $/# _____
Extra Dinner/Museum Ticket _____@ $55/#35
TOTAL ENCLOSED $/# _____ (ACM/SIGCOMM Membership, tutorials,
conference registration)
NAME _________________________________________________________________
AFFILIATION __________________________________________________________
ADDRESS ______________________________________________________________
______________________________________________________________________
PHONE _____________________________ FAX ______________________________
Email ADDRESS ________________________________________________________
SIGCOMM Member? - YES - NO
ACM/SIGCOMM Member Number ____________________________________________
CREDIT CARD PAYMENT - VISA - MASTERCARD - euroCARD
CARD HOLDER NAME _____________________________________________________
CARD NUMBER ______________________________________ EXP. DATE _________
SIGNATURE ____________________________________________________________
Please send this form and a check, credit card information or money
orders (no purchase orders) to SIGCOMM'94. Registrations accepted via
postal mail, fax or email only.
Send U.S. or Send Pound Sterling
Credit Card Payments to:
Patrick McCarren Soren-Aksel Sorensen
ACM - 17th Floor Dept. of Computer Science
1515 Broadway University College London
New York, NY 10036 London WC1E 6BT
USA United Kingdom
phone: +1 212/626/0611 phone: +44 71 380 7269
fax: +1 212/302-5826 fax +44 71 387 1397
mccarren at acm.org
Email registrations can only be made by a credit card during the
pre-registration period ending 1 August 1994 and must use credit card
payment. A registration confirmation letter will be sent to each
participant upon receipt of the completed registration form and
accompanying payment. Registration fee will be refunded, less a
$30/#19 administration fee, if cancelation notification is received
prior to 15 August 1994. Substitution for a paid attendee is
acceptable.
----------------------------------------------
C o n f e r e n c e O r g a n i z a t i o n
----------------------------------------------
General Chair: Jon Crowcroft, University College London
Program Chairs: Stephen Pink, Swedish Institute of Computer Science
Craig Partridge, BBN (Program Co-Chair for North America)
Ian F. Akyildiz, Georgia Institute of Technology, USA
Lillian N. Cassel, Villanova Univ., USA
Vinton Cerf, MCI, USA
Lyman Chapin, BBN, USA
Jon Crowcroft, Univ. College London, UK
Andre Danthine, Univ. of Liege, Belgium
Gary Delp, IBM, USA
Patrick W. Dowd, SUNY/Buffalo, USA
Deborah Estrin, Univ. Southern California, USA
David Feldmeier, Bellcore, USA
Sally Floyd, Lawrence Berkeley Laboratory, USA
David Greaves, ORL Cambridge, UK
Per Gunningberg, Swedish Institute of Computer Science, Sweden
Christian Huitema, INRIA, France
David Hutchison, Lancaster Univ., UK
Raj Jain, Ohio State University, USA
Jim Kurose, Univ. of Massachusetts, USA
Ian Leslie, Univ. of Cambridge, UK
David Oran, Digital Equipment Corp, USA
Gerard Parr, University of Ulster, Northern Ireland
Guru Parulkar, Washington Univ. St Louis, USA
Krzysztof Pawlikowski, Univ. of Canterbury, New Zealand
Bernhard Plattner, ETH Zurich, Switzerland
Scott Shenker, XEROX PARC, USA
Deepinder Sidhu, Univ. of Maryland-BC, USA
Jonathan M. Smith, Univ. Pennsylvania, USA
Khosrow Sohraby, Univ. of Missouri - Kansas City, USA
James Sterbenz, IBM Research, USA
Greg Watson, Hewlett Packard Labs, UK
Greg Wetzel, AT&T Bell Laboratories, USA
Lixia Zhang, XEROX PARC, USA
---------------------------------------------------
F O R A D D I T I O N A L I N F O R M A T I O N
---------------------------------------------------
Additional information may be found/requested from:
www: http://www.cs.ucl.ac.uk/sigcomm94
anonymous ftp: norman.eng.buffalo.edu:/pub/sigcomm94
email: sigcomm94 at eng.buffalo.edu
fax: +1 716.645.3656
phone: +1 716.645.2406
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15739;
18 May 94 19:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22185;
18 May 94 19:34 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15728;
18 May 94 19:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15696;
18 May 94 19:31 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22136;
18 May 94 19:31 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA02555>; Wed, 18 May 1994 16:31:45 -0700
Message-Id: <199405182331.AA02555 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1626 on Default IP MTU for use over ATM AAL5
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 18 May 94 16:31:59 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1626:
Title: Default IP MTU for use over ATM AAL5
Author: R. Atkinson
Mailbox: atkinson at itd.nrl.navy.mil
Pages: 5
Characters: 11,841
Updates/Obsoletes: none
This RFC provides an easy to understand reference for developers
intending to run IP over ATM and describes the motivation for the
value chosen. This memo is a product of the IP Over Asynchronous
Transfer Mode Working Group of the IETF.
This is now a Proposed Standard Protcol.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940518162336.RFC at ISI.EDU>
SEND /rfc/rfc1626.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1626.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940518162336.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15820;
18 May 94 19:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22257;
18 May 94 19:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15808;
18 May 94 19:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15763;
18 May 94 19:35 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22220;
18 May 94 19:35 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA02626>; Wed, 18 May 1994 16:35:56 -0700
Message-Id: <199405182335.AA02626 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1628 on UPS MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 18 May 94 16:36:10 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1628:
Title: UPS Management Information Base
Author: J. Case, Editor
Mailbox: case at SNMP.COM
Pages: 45
Characters: 83,439
Updates/Obsoletes: none
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing uninterruptible power
supply (UPS) systems. This RFC is a product of the Uninterruptible
Power Supply Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940518163339.RFC at ISI.EDU>
SEND /rfc/rfc1628.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1628.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940518163339.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16584;
18 May 94 20:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23488;
18 May 94 20:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16571;
18 May 94 20:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16528;
18 May 94 20:56 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa23458;
18 May 94 20:56 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA02928>; Wed, 18 May 1994 16:56:19 -0700
Message-Id: <199405182356.AA02928 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1629 on NSAP Guidelines
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 18 May 94 16:56:34 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1629:
Title: Guidelines for OSI NSAP Allocation in the Internet
Author: R. Colella, R. Callon, E. Gardner & Y. Rekhter
Mailbox: colella at nist.gov, callon at wellfleet.com,
epg at gateway.mitre.org, yakov at watson.ibm.com
Pages: 52
Characters: 131,640
Obsoletes: 1237
CLNP is currently being deployed in the Internet. This is useful to
support OSI and DECnet traffic. In addition, CLNP has been
proposed as a possible IPng candidate, to provide a long-term solution
to IP address exhaustion. Required as part of the CLNP infrastructure
are guidelines for network service access point (NSAP) address
assignment. This paper provides guidelines for allocating NSAP
addresses in the Internet.
The guidelines provided in this paper have been the basis for initial
deployment of CLNP in the Internet, and have proven very valuable both
as an aid to scaling of CLNP routing, and for address administration.
This document is the product of the Assignment of OSI NSAP Addresses
Working Group of the IETF.
This is now a Draft 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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940518164428.RFC at ISI.EDU>
SEND /rfc/rfc1629.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1629.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940518164428.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05961;
19 May 94 11:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05952;
19 May 94 11:17 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa08684;
19 May 94 11:17 EDT
Received: by bitsy.MIT.EDU
id AA25636; Thu, 19 May 94 11:00:10 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA25622; Thu, 19 May 94 11:00:04 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA28057; Thu, 19 May 94 10:59:53 EDT
Received: from dun-dun-noodles.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <LAA26719 at pad-thai.aktis.com>; Thu, 19 May 1994 11:00:23 -0400
Received: by dun-dun-noodles.aktis.com (4.1/4.7) id AA26858; Thu, 19 May 94 11:00:21 EDT
Message-Id: <9405191500.AA26858 at dun-dun-noodles.aktis.com>
To: dpg at ocsg.com
Cc: Theodore Ts'o <tytso at mit.edu>, John Linn <linn at cam.ov.com>,
cat-ietf at mit.edu, gssapi at ocsg.com
Subject: Re: Questions regarding GGS/Kerberos names
In-Reply-To: Your message of "Thu, 12 May 1994 18:23:10 PDT."
<9405130123.AA21235 at war04.ocsg.com>
Date: Thu, 19 May 1994 11:00:20 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
I've been out of town for a while, so I'll reply to the things which I
think need to be replied to here.
dpg> * Sections 2.5 and 2.6 describe a GSS name in terms of a UID (user
dpg> ID). Those specifications seem tailored to a UNIX environment. My
dpg> questions regarding the forms described in Sections 2.5 and 2.6 are:
dpg>
dpg> * If the environment is DOS, NT, or a Mac then what is a UID?
When I implemented those name types, the intent was to provide
convenience functions for developers on unix platforms. Rather than
have every app writer who wants to use a name based on the local uid
write the necessary code himself, I provided these functions. If
these name types are to remain in the spec, they should probably be
moved to a section or appendix which is labelled as unix-specific, and
almost certainly made optional. Perhaps they should be removed from
the spec altogether.
dpg> * How is Kerberos realm information included in the UID forms?
It's not. "The gss_import_name() operation resolves this uid into a
username, which is then treated as the User Name Form." "An
implementation of gss_import_name() based on Kerberos V5 technology
can process names of [User Name Form] by postfixing an "@" sign and
the name of the local realm." In short, the local realm is used. As
I said, this is a convenience function. If you want to create a
principal as an ascii string in some application-specific manner,
using a different realm in some application-determined way, and import
it as a General Kerberos Name, you are free to do so.
dpg> To pass a Kerberos principal to gss_import_name() it must be
dpg> encapsulated in a gss_buffer. This raises the question: what is the
dpg> gss_buffer's length? Further, it implies the gss_buffer cannot be
dpg> deleted using gss_release_buffer().
wray> It certainly seems wrong to pass a krb5_principal object to a routine
wray> using a gss_buffer_t, anyway. The gss_buffer_t datatype is explicitly
wray> designed for passing contiguous byte arrays, not structured data.
According to the spec, this name type is illegal. I did not realize
that when I implemented this functionality. IMHO, the restriction
that gss_import_name() accept only printable representations is
unnecessary, and should be removed.
As a clarification, the contents of the buffer is the value of the
krb5_principal. This is a scalar value, which is easily represented
in a buffer as contiguous bytes. Someone (I don't remember who)
pointed out that there is no krb5 API standard, so this routine isn't
necessarily portable. This is a good point, and I'll have to think
about it some more.
WRT gss_release_buffer(), that function only applies to buffers which
are created by gssapi routines. The buffer containing the
krb5_principal value is created by the application, and therefore must
be freed by it.
This name type is distinct from the General Kerberos Name Form, which
imports a character-string representation of a principal.
wray> Any byte ordering would be OK. It's not a _change_ to
wray> little-endian; it was always specified that way.
dpg> I do not recall seeing a byte-ordering specification before the Draft
dpg> Kerberos V GSS RFC. What have I missed?
For the record, I agree with Dennis (OV has shipped code using
big-endian byte order), but I also don't care that much.
wray> I'd recommend that the mandatory set be simply a printable Kerberos V5
wray> principal name. In addition, the SERVICE:<svc>@<host> printable form
wray> should be documented as a variant of this printable format, suitable
wray> for input to gss_import_name(), although a name of this form will
wray> never be emitted by gss_display_name(). The SERVICE: form probably
wray> doesn't need its own name-type, as it can be syntactically
wray> distinguished from a regular principal name.
I disagree here. First, the Service Name form is intended to be a
mechanism-independent name type, hopefully supported by as many
mechanisms as possible. This alleviates the need for a gssapi
application to use mechanism-specific name types. Second, the service
form cannot be syntactically distinguished from a kerberos principal.
For example, "SERVICE:login at ATHENA.MIT.EDU" is a valid (although
currently non-existent) kerberos principal.
Going back to the I-D, I notice that John Linn has written:
The recommended symbolic name for this type is
"gss_krb5_nt_service_name".
[...]
The recommended symbolic name for this type is
"gss_krb5_nt_user_name".
I would rather have these symbolic names be "gss_nt_service_name" and
"gss_nt_user_name". These name types are not inherent to kerberos or
anything else. I believe that these name types are part of a core set
which is applicable to many underlying mechanisms, not just kerberos,
and can enable developers to write mechanism-independent applications
more easily. Same thing applies for the uid name types if these name
types remain in the spec.
wray> However, I still question the need. If an application wants to use
wray> the krb5_principal name-type, then it knows it's dealing with
wray> Kerberos. If it's willing to hard-code such a dependency, why
wray> wouldn't it use the native Kerberos API, rather than the GSSAPI?
wray> Presumably it is already calling the Kerberos native API, since
wray> otherwise it wouldn't have a krb5_principal object.
I have applications which use an RPC based on gssapi, but also perform
a krb5 AS-REQ on their own rather than using the existing ccache.
This must be done with the native krb5 API, since gssapi doesn't do
this sort of thing, but the RPC is used by other (more portable)
applications which do not do an AS-REQ on their own. Once I do the
AS-REQ, I've got a krb5_principal which I want to import into gssapi.
I could unparse this principal into a string and import that, but this
seemed wasteful, since the import function was just going to parse it
again. This is why I implemented the krb5_principal Form name type.
I think that's all I have for now :-)
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08859;
19 May 94 14:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08851;
19 May 94 14:13 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa15032;
19 May 94 14:13 EDT
Received: by bitsy.MIT.EDU
id AA28130; Thu, 19 May 94 14:01:41 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA28122; Thu, 19 May 94 14:01:39 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA12546; Thu, 19 May 94 14:01:38 EDT
Received: from dun-dun-noodles.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <OAA00919 at pad-thai.aktis.com>; Thu, 19 May 1994 14:02:13 -0400
Received: by dun-dun-noodles.aktis.com (4.1/4.7) id AA27607; Thu, 19 May 94 14:02:07 EDT
Message-Id: <9405191802.AA27607 at dun-dun-noodles.aktis.com>
To: dpg at ocsg.com
Cc: cat-ietf at mit.edu, gssapi at ocsg.com
Subject: Re: Questions regarding GGS/Kerberos names
In-Reply-To: Your message of "Thu, 19 May 1994 09:21:21 PDT."
<9405191621.AA15914 at war04.ocsg.com>
Date: Thu, 19 May 1994 14:02:05 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> I don't understand the issue. Why wouldn't you use the existing
>> credential cache?
Because the application is paranoid, and wants to force the user to
enter a password in certain cases. We've extended gssapi to allow the
server to verify that this is an as-req ticket (don't worry, I'm not
proposing this for standardization).
>> I don't think waste is an issue. There are many, many wasteful
>> things in the Kerberos libraries that dwarf the inefficiency of
>> unparsing a principal. For example, ASN.1 encoding and translation
>> is a pig.
Just because part of the code is wasteful, doesn't mean we should
follow suit. Also, the issue is not just efficiency, it's complexity,
too. If you have to unparse the principal, you have to free it.
Someone might forget to do this, and introduce a memory leak.
Simplifying the interface makes it harder to make mistakes, and
therefore easier to use, which is the whole point.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08900;
19 May 94 14:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08892;
19 May 94 14:15 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa15083;
19 May 94 14:15 EDT
Received: by bitsy.MIT.EDU
id AA27991; Thu, 19 May 94 13:56:02 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA27982; Thu, 19 May 94 13:55:51 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA12178; Thu, 19 May 94 13:55:40 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id KAA28299; Thu, 19 May 1994 10:42:13 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA15914; Thu, 19 May 94 09:21:21 -0700
Date: Thu, 19 May 94 09:21:21 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405191621.AA15914 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Marc Horowitz <marc at cam.ov.com>
Subject: Re: Questions regarding GGS/Kerberos names
Cc: cat-ietf at mit.edu, gssapi at ocsg.com
Reply-To: dpg at ocsg.com
> wray> However, I still question the need. If an application wants
> wray> to use the krb5_principal name-type, then it knows it's
> wray> dealing with Kerberos. If it's willing to hard-code such a
> wray> dependency, why wouldn't it use the native Kerberos API,
> wray> rather than the GSSAPI? Presumably it is already calling the
> wray> Kerberos native API, since otherwise it wouldn't have a
> wray> krb5_principal object.
>
> I have applications which use an RPC based on gssapi, but
> also perform a krb5 AS-REQ on their own rather than using
> the existing ccache. This must be done with the native
> krb5 API, since gssapi doesn't do this sort of thing, but
> the RPC is used by other (more portable) applications
> which do not do an AS-REQ on their own. Once I do the AS-REQ,
> I've got a krb5_principal which I want to import into
> gssapi. I could unparse this principal into a string and
> import that, but this seemed wasteful, since the import
> function was just going to parse it again. This is why I
> implemented the krb5_principal Form name type.
>
I don't understand the issue. Why wouldn't you use the existing
credential cache?
I don't think waste is an issue. There are many, many wasteful
things in the Kerberos libraries that dwarf the inefficiency of
unparsing a principal. For example, ASN.1 encoding and translation
is a pig.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09518;
19 May 94 14:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09510;
19 May 94 14:50 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa16022;
19 May 94 14:50 EDT
Received: by bitsy.MIT.EDU
id AA28684; Thu, 19 May 94 14:37:42 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA28675; Thu, 19 May 94 14:37:33 EDT
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA15274; Thu, 19 May 94 14:37:25 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id LAA12974; Thu, 19 May 1994 11:33:28 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA16002; Thu, 19 May 94 11:29:30 -0700
Date: Thu, 19 May 94 11:29:30 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405191829.AA16002 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: John Linn <linn at cam.ov.com>
Subject: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
Cc: cat-ietf at mit.edu, gssapi at ocsg.com
Reply-To: dpg at ocsg.com
A issue not covered in the draft RFC "The Kerberos Version 5 GSS-API
Mechanism" is context time.
What is the expiration time of a context? What is a context
expiration time in the presence of renewable tickets?
If either peer's ticket is not renewable, I believe the context
expiration time to be the minimum of the peers' "end time". If a
peer has a renewable ticket then the peer's "possible" expiration
time is the maximum of the ticket's end and renew times. However,
having a renewable ticket isn't a guarantee of renewal and renewing
tickets are subject to the ticket being renewed before its
expiration.
The initiator's end and renew times are encoded in a AP-REQ message.
Therefore, the acceptor has the end and renew times for both halves
of the context and can make a reasonable determination of the
context's expiration time. The initiator however, is at a
disadvantage.
The initiator cannot determine the acceptor's end and renew times in
singled ended authentication. In the presence of mutual
authentication those times are not returned in the AP-REP -- unless
the GSS/Kerberos token format is adjusted to include the acceptor's
end and renew times.
To determine a context's expiration time, the algorithm I use chooses
the minimum of the local end time against the maximum of the remote's
end and renew times. (A ticket's end time is updated when the ticket
is renewed.) The local representation of the peer's end and renew
times are preinitialized to KRB5_KDB_EXPIRATION (defined in
krb5/config.h as Thu Jan 1 00:00:00 2038 UTC). Arithmetically:
expiration time =
min( local end time,
max( remote end time, remote renew time))
If the GSS/Kerberos AP-REP token returned the acceptor's end and
renew times then context expiration would be more deterministic for
the initiator.
I believe the draft GSS/Kerberos RFC should address context
expiration and present an algorithm. Although I believe the
technique I use to be reasonable, it is by no means the best or most
appropriate.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05404;
17 May 94 11:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05400;
17 May 94 11:36 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa10185; 17 May 94 11:36 EDT
Received: from hpdmd48.boi.hp.com by hp.com with SMTP
(1.36.108.7/15.5+IOS 3.13) id AA08041; Tue, 17 May 1994 08:37:00 -0700
Received: from hpbs907.boi.hp.com by hpdmd48.boi.hp.com with SMTP
(1.37.109.4/15.5+IOS 3.21+OM) id AA26206; Tue, 17 May 94 09:36:49 -0600
Received: from hp.com by hpbs907.boi.hp.com with SMTP
(16.6/15.5+IOS 3.12) id AA25773; Tue, 17 May 94 09:28:52 -0600
Received: from ftp.std.com by hp.com with SMTP
(1.36.108.7/15.5+IOS 3.13) id AA07812; Tue, 17 May 1994 08:34:53 -0700
Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0)
id LAA28258; Tue, 17 May 1994 11:32:21 -0400
Received: by world.std.com (5.65c/Spike-2.0)
id AA01511; Tue, 17 May 1994 11:32:18 -0400
Date: Tue, 17 May 1994 11:32:18 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike Bloom <dpi at world.std.com>
Message-Id: <199405171532.AA01511 at world.std.com>
To: dpi at world.std.com, pmi at hpbs907.boi.hp.com, rturner at sun470.rd.qms.com
Subject: Re: May meeting agenda (Community names)
Cc: ietf-announce-post at CNRI.Reston.VA.US
Randy, I am confused. Are we backing off from the community names mechanism for handling multiple printers from one node? Did I miss the discussion I thought you indicated would be available Monday last? Bill Wagner (aka Mike Bloom)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12809;
19 May 94 17:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12797;
19 May 94 17:56 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa20374;
19 May 94 17:56 EDT
Received: by bitsy.MIT.EDU
id AA01423; Thu, 19 May 94 17:42:42 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA01414; Thu, 19 May 94 17:42:08 EDT
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA28469; Thu, 19 May 94 17:42:02 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA21723; Thu, 19 May 94 17:38:42 EDT
Date: Thu, 19 May 94 17:38:42 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9405192138.AA21723 at tsx-11.MIT.EDU>
To: Marc Horowitz <marc at cam.ov.com>
Cc: dpg at ocsg.com, cat-ietf at mit.edu, gssapi at ocsg.com
In-Reply-To: Marc Horowitz's message of Thu, 19 May 1994 14:02:05 -0400,
<9405191802.AA27607 at dun-dun-noodles.aktis.com>
Subject: Re: Questions regarding GGS/Kerberos names
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Thu, 19 May 1994 14:02:05 -0400
From: Marc Horowitz <marc at cam.ov.com>
>> I don't think waste is an issue. There are many, many wasteful
>> things in the Kerberos libraries that dwarf the inefficiency of
>> unparsing a principal. For example, ASN.1 encoding and translation
>> is a pig.
Just because part of the code is wasteful, doesn't mean we should
follow suit.
... and even if using ASN.1 is a mistake that we can't undo at this
point (us Kerberos developers don't need to feel bad, the SNMP people
fell into the same trap, and I hear they are also regretting it....),
we can still improve the efficiency greatly by ditching ISODE, and
replace it with hand-written coders and decoders.
Inefficiency in one part of the system should never be considered an
excuse for ineffiency in other parts of the system. :-)
That being said, importing the krb5 principal directly into the GSSAPI
certainly does impede portability, so I question whether it should go
into the draft. Most normal applications (especially those written with
an eye to being portable) should never need to use it anyway.
- Ted
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12948;
19 May 94 17:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20404;
19 May 94 17:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12865;
19 May 94 17:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12713;
19 May 94 17:51 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa20271;
19 May 94 17:51 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA17525>; Thu, 19 May 1994 14:51:25 -0700
Message-Id: <199405192151.AA17525 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1615, RTR9 on Migrating from X.400(84) to X.400(88)
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 May 94 14:51:40 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1615:
RTR 9:
Title: Migrating from X.400(84) to X.400(88)
Author: J. Houttuin & J. Craigie
Mailbox: houttuin at rare.nl, J.Craigie at jnt.ac.uk
Pages: 17
Characters: 39,693
Updates/Obsoletes: none
This document compares X.400(88) to X.400(84) and describes what
problems can be anticipated in the migration, especially considering
the migration from the existing X.400(84) infrastructure created by
the COSINE MHS project to an X.400(88) infrastructure. It not only
describes the technical complications, but also the effect the
transition will have on the end users, especially concerning
interworking between end users of the 84 and the 88 services.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940519144847.RFC at ISI.EDU>
SEND /rfc/rfc1615.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1615.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940519144847.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12946;
19 May 94 17:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20403;
19 May 94 17:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12866;
19 May 94 17:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12658;
19 May 94 17:48 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa20189;
19 May 94 17:48 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA17465>; Thu, 19 May 1994 14:48:11 -0700
Message-Id: <199405192148.AA17465 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1614, RTR8 on Network Access to Multimedia Information
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 May 94 14:48:25 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1614:
RTR 8:
Title: Network Access to Multimedia Information
Author: C. Adie
Mailbox: C.J.Adie at edinburgh.ac.uk
Pages: 79
Characters: 187,253
Updates/Obsoletes: none
This report summarises the requirements of research and academic
network users for network access to multimedia information. It does
this by investigating some of the projects planned or currently
underway in the community. Existing information systems such as
Gopher, WAIS and World-Wide Web are examined from the point of view of
multimedia support, and some interesting hypermedia systems emerging
from the research community are also studied. Relevant existing and
developing standards in this area are discussed. The report
identifies the gaps between the capabilities of currently deployed
systems and the user requirements, and proposes further work centered
on the World-Wide Web system to rectify this. The report is in some
places very detailed, so it is preceded by an extended summary, which
outlines the findings of the report.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940519144423.RFC at ISI.EDU>
SEND /rfc/rfc1614.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1614.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940519144423.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13059;
19 May 94 18:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20469;
19 May 94 18:00 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13050;
19 May 94 18:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12902;
19 May 94 17:57 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa20387;
19 May 94 17:57 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA17648>; Thu, 19 May 1994 14:57:42 -0700
Message-Id: <199405192157.AA17648 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1616, RTR10 on X.400(88) for European Academics and Research
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 May 94 14:57:56 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1616:
RTR 10:
Title: X.400(1988) for the Academic and Research
Community in Europe
Author: RARE WG-MSG Task Force 88
E. Huizer & J. Romaguera, Editors
Mailbox: huizer at surfnet.nl, romaguera at netconsult.ch
Pages: 44
Characters: 107,432
Updates/Obsoletes: none
The European research and development community, as represented by the
member research networks of RARE, has lead the deployment within the
global R&D community of X.400 electronic messaging services, as
specified in the international recommendations CCITT X.400(1984), for
more than five years. This report documents the results of a task
force on X.400(1988) deployment of the RARE Mails and Messaging Work
Group during the period from November 1992 until October 1993. Open
reviews of the report have occurred in the RARE Mail and Messaging
Work Group and within the IETF X.400ops Working Group.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940519145226.RFC at ISI.EDU>
SEND /rfc/rfc1616.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1616.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940519145226.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13141;
19 May 94 18:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20558;
19 May 94 18:06 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13130;
19 May 94 18:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13102;
19 May 94 18:03 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa20519;
19 May 94 18:03 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA17710>; Thu, 19 May 1994 15:03:37 -0700
Message-Id: <199405192203.AA17710 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1617, RTR11 on Naming and Structuring Guidelines for X.500
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 May 94 15:03:51 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1617:
RTR 11:
Title: Naming and Structuring Guidelines for X.500
Directory Pilots
Author: P. Barker, S. Kille & T. Lenggenhager
Mailbox: p.barker at cs.ucl.ac.uk, s.kille at isode.com,
lenggenhager at switch.ch
Pages: 28
Characters: 56,945
Obsoletes: 1384
Deployment of a Directory will benefit from following certain
guidelines. This document defines a number of naming and structuring
guidelines focused on White Pages usage. Alignment to these guidelines
is recommended for directory pilots.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940519145841.RFC at ISI.EDU>
SEND /rfc/rfc1617.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1617.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940519145841.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13196;
19 May 94 18:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13188;
19 May 94 18:12 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa20664;
19 May 94 18:12 EDT
Received: by bitsy.MIT.EDU
id AA29819; Thu, 19 May 94 15:56:17 EDT
Received: from SOUTH-STATION-ANNEX.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA29811; Thu, 19 May 94 15:56:12 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA20964; Thu, 19 May 94 15:56:09 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA04784; Thu, 19 May 94 12:49:52 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA04817; Thu, 19 May 94 15:49:21 -0400
Message-Id: <9405191949.AA04817 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Thu, 19 May 94 15:49:29 EDT
Date: Thu, 19 May 94 15:49:29 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 19-May-1994 1511" <wray at tuxedo.enet.dec.com>
To: dpg at ocsg.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, dpg at ocsg.com
Subject: RE: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
dpg writes:
>A issue not covered in the draft RFC "The Kerberos Version 5 GSS-API
>Mechanism" is context time.
>
>What is the expiration time of a context? What is a context
>expiration time in the presence of renewable tickets?
I don't see that the context lifetime needs to be tied to the lifetime of the
underlying service ticket or the TGT. The ticket(s) are used simply to
authenticate, and establish a session key; after that, they've done their work,
and can expire without affecting anything.
The only reasons I could see for wanting a context to time-out would be:
i) If you feel that the context's session key has been used for too long. At
this point, you should either re-authenticate to get a new session key from
Kerberos, or roll-over to a new session key, chained from the current one.
Neither of these options is supported by the current GSSAPI definition (except
by tearing down the context, and establishing a new one).
or ii) You want to make sure that the client or server's long-term keys haven't
been revoked by the KDC.
I'm not convinced that enforcing a context expiration time will be seen as
friendly behavior by the majority of applications - I think that having an
infinite lifetime is going to be better for most apps. Those apps that care
about (i) or (ii) can always enforce their own timeouts, along with whatever
synchronization is necessary to move their communications over to the new
context.
I'm not sure what the OpenVision implementation does; the Digital
implementation currently creates contexts with inifinite lifetimes.
John
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14606;
19 May 94 20:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22911;
19 May 94 20:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14594;
19 May 94 20:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14518;
19 May 94 20:40 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa22857;
19 May 94 20:40 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA20817>; Thu, 19 May 1994 17:40:49 -0700
Message-Id: <199405200040.AA20817 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1620 on Shared Media IP Architecture
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 19 May 94 17:41:04 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1620:
Title: Internet Architecture Extensions for Shared Media
Author: B. Braden, J. Postel & Y. Rekhter
Mailbox: Braden at ISI.EDU, Postel at ISI.EDU,
Yakov at WATSON.IBM.COM
Pages: 19
Characters: 44,999
Updates/Obsoletes: none
The original Internet architecture assumed that each network is
labeled with a single IP network number. This assumption may be
violated for shared media, including "large public data networks"
(LPDNs). The architecture still works if this assumption is violated,
but it does not have a means to prevent multiple host-router and
router-router hops through the shared medium. This memo discusses
alternative approaches to extending the Internet architecture to
eliminate some or all unnecessary hops.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940519173237.RFC at ISI.EDU>
SEND /rfc/rfc1620.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1620.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940519173237.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05373;
20 May 94 10:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05365;
20 May 94 10:11 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa07886;
20 May 94 10:11 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA19628 at pad-thai.aktis.com>; Fri, 20 May 1994 09:37:34 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA25939; Fri, 20 May 94 09:36:40 EDT
Received: from dun-dun-noodles.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA19624 at pad-thai.aktis.com>; Fri, 20 May 1994 09:37:22 -0400
Received: by dun-dun-noodles.aktis.com (4.1/4.7) id AA02222; Fri, 20 May 94 09:37:21 EDT
Message-Id: <9405201337.AA02222 at dun-dun-noodles.aktis.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 19-May-1994 1511" <wray at tuxedo.enet.dec.com>
Cc: dpg at ocsg.com, cat-ietf at mit.edu
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
Date: Fri, 20 May 1994 09:37:20 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> I'm not sure what the OpenVision implementation does; the Digital
>> implementation currently creates contexts with inifinite lifetimes.
The OpenVision implementation uses the ticket expiration time as the
expire time for initiating credentials, infinity as the expire time
for accepting credentials, and the initiating credential's expire time
as the expire time for a context.
>> I'm not convinced that enforcing a context expiration time will be
>> seen as friendly behavior by the majority of applications - I think
>> that having an infinite lifetime is going to be better for most apps.
>> Those apps that care about (i) or (ii) can always enforce their own
>> timeouts, along with whatever synchronization is necessary to move
>> their communications over to the new context.
Kerberos provides timeouts, and I believe we should support this
functionality. While some applications might see timeouts as
unfriendly, other applications might see ignoring timeouts as a
security hole.
I proposed several weeks ago that GSS_S_CREDENTIALS_EXPIRED and
GSS_S_CONTEXT_EXPIRED be made into supplementary info bits instead of
routine errors. The appropriate gssapi functions will be defined to
complete the act of context establishment/sign/seal/verify/unseal, but
to set the appropriate bits if something has expired. This way, the
application can decided to obey or ignore kerberos's ideas of
timeouts.
Marc
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05752;
20 May 94 10:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08212;
20 May 94 10:25 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05726;
20 May 94 10:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05242;
20 May 94 10:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07785;
20 May 94 10:06 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05237;
20 May 94 10:06 EDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
To: IETF-Announce: ;
Subject: POP3 Mailing List
Date: Fri, 20 May 94 10:06:08 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405201006.aa05237 at IETF.CNRI.Reston.VA.US>
There is a new mailing list for the Post Office Protocol version 3.
The list is being created to review and resolve some apparent
ambiguities in the most recent POP3 Internet-Draft before the IESG
considers it for standards track activity. People with an interest
in POP3 are urged to participate because different readings of the
current text may lead to non-interoperable implementations.
General Discussion
ietf-pop3 at andrew.cmu.edu
To Subscribe
ietf-pop3-request at andrew.cmu.edu
Archives
(1) Anonymous IMAP to cyrus.andrew.cmu.edu in archive.ietf-pop3
(2) Anonymous FTP to cnri.reston.va.us in ietf-mail-archives/pop3.
The current month is in "current", and previous months are in
files with the pattern YY-MM.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06033;
20 May 94 10:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06025;
20 May 94 10:35 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa08517;
20 May 94 10:35 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA20184 at pad-thai.aktis.com>; Fri, 20 May 1994 10:06:24 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA27773; Fri, 20 May 94 10:05:36 EDT
Received: from dun-dun-noodles.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA20178 at pad-thai.aktis.com>; Fri, 20 May 1994 10:06:19 -0400
Received: by dun-dun-noodles.aktis.com (4.1/4.7) id AA02252; Fri, 20 May 94 10:06:18 EDT
Message-Id: <9405201406.AA02252 at dun-dun-noodles.aktis.com>
To: cat-ietf at mit.edu
Subject: Re: change of control of cat-ietf list from MIT to OpenVision
In-Reply-To: Your message of "Wed, 18 May 1994 14:51:49 EDT."
<9405181851.AA23951 at dun-dun-noodles.aktis.com>
Date: Fri, 20 May 1994 10:06:17 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> Starting in the next few days, OpenVision will be taking over from MIT
>> maintenance of the cat-ietf list. The address will not change;
>> cat-ietf at mit.edu will be changed to point at a mail server at
>> OpenVision.
This changeover has occurred. If you notice any problems, please send
mail to <cat-ietf-request at mit.edu>. Thanks.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06678;
20 May 94 11:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06670;
20 May 94 11:08 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa09274;
20 May 94 11:08 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA20885 at pad-thai.aktis.com>; Fri, 20 May 1994 10:36:19 -0400
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA00214; Fri, 20 May 94 10:35:29 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA28327; Fri, 20 May 94 07:28:30 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA12455; Fri, 20 May 94 10:28:07 -0400
Message-Id: <9405201428.AA12455 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 20 May 94 10:28:07 EDT
Date: Fri, 20 May 94 10:28:07 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 20-May-1994 0946" <wray at tuxedo.enet.dec.com>
To: marc at cam.ov.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, marc at cam.ov.com
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
>>> I'm not sure what the OpenVision implementation does; the Digital
>>> implementation currently creates contexts with inifinite lifetimes.
>
>The OpenVision implementation uses the ticket expiration time as the
>expire time for initiating credentials, infinity as the expire time
>for accepting credentials, and the initiating credential's expire time
>as the expire time for a context.
That's the TGT expiration time for initiating credentials, isn't it? I guess
it must be, since a cred isn't associated with any particular peer, and
therefore can't be associated with any particular service ticket. That's what
the DCE implementation does, too, as far as credentials are concerned, but it
doesn't expire its contexts.
>>> I'm not convinced that enforcing a context expiration time will be
>>> seen as friendly behavior by the majority of applications - I think
>>> that having an infinite lifetime is going to be better for most apps.
>>> Those apps that care about (i) or (ii) can always enforce their own
>>> timeouts, along with whatever synchronization is necessary to move
>>> their communications over to the new context.
>
>Kerberos provides timeouts, and I believe we should support this
>functionality. While some applications might see timeouts as
>unfriendly, other applications might see ignoring timeouts as a
>security hole.
I agree that we should support Kerberos' timeout functionality for credentials.
I remain unconvinced about the need for context expiration.
>I proposed several weeks ago that GSS_S_CREDENTIALS_EXPIRED and
>GSS_S_CONTEXT_EXPIRED be made into supplementary info bits instead of
>routine errors. The appropriate gssapi functions will be defined to
>complete the act of context establishment/sign/seal/verify/unseal, but
>to set the appropriate bits if something has expired. This way, the
>application can decided to obey or ignore kerberos's ideas of
>timeouts.
I don't see how the Kerberos GSSAPI can complete a context initiation with an
expired credential, since that means that the TGT's no longer valid, and the
Kerberos KDC will (I assume) refuse to issue a service ticket against an
expired TGT. So I don't think that GSS_S_CREDENTIALS_EXPIRED can be just
informational, at least not for Kerberos. However, some mechanisms might be
willing to authenticate with expired credentials (and only give a warning).
So maybe we could make this an informational status, but always couple it with
GSS_S_FAILURE for Kerberos.
GSS_S_CONTEXT_EXPIRED could be made informational for the Kerberos GSSAPI, and
that might be a reasonable compromise; however, as I stated above, I'm not
convinced that the context lifetime needs to bear any relationship to the
credential lifetime. What's the argument in favor of linking them? What's the
argument for picking any particular time-out for contexts?
What does Kerberos itself do in this area? Does it really refuse to generate
or accept KRB_SAFE/KRB_SEAL messages after the TGT has expired? How does the
acceptor know what the expiration time of the original TGT was, since all it
gets to see is a service ticket, which may have a shorter lifetime than the
TGT?
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06947;
20 May 94 11:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06943;
20 May 94 11:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09724;
20 May 94 11:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06931;
20 May 94 11:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06926;
20 May 94 11:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09712;
20 May 94 11:16 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06910;
20 May 94 11:16 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-osi-x400ops at cs.wisc.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: X.400 Operations to Proposed Standard
Date: Fri, 20 May 94 11:16:49 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405201116.aa06910 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the X.400 Operations Working
Group to consider "Postmaster Convention for X.400 Operations"
<draft-ietf-x400ops-postmaster-05.txt> for the status of Proposed
Standard, and "Operational Requirements for X.400 Management
Domains in the GO-MHS Community"
<draft-ietf-x400ops-mgtdomains-ops-06.txt> for the status of
Informational.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any comments
to the iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing
lists by 3 June.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07259;
20 May 94 11:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07250;
20 May 94 11:23 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa09888;
20 May 94 11:23 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA21234 at pad-thai.aktis.com>; Fri, 20 May 1994 10:53:41 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA01698; Fri, 20 May 94 10:52:51 EDT
Received: from dun-dun-noodles.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <KAA21230 at pad-thai.aktis.com>; Fri, 20 May 1994 10:53:33 -0400
Received: by dun-dun-noodles.aktis.com (4.1/4.7) id AA02334; Fri, 20 May 94 10:53:32 EDT
Message-Id: <9405201453.AA02334 at dun-dun-noodles.aktis.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 20-May-1994 0946" <wray at tuxedo.enet.dec.com>
Cc: cat-ietf at mit.edu
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
In-Reply-To: Your message of "Fri, 20 May 1994 10:28:07 EDT."
<9405201428.AA12455 at us1rmc.bb.dec.com>
Date: Fri, 20 May 1994 10:53:31 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> That's the TGT expiration time for initiating credentials, isn't
>> it?
yes.
>> I don't see how the Kerberos GSSAPI can complete a context initiation
>> with an expired credential, since that means that the TGT's no longer
>> valid, and the Kerberos KDC will (I assume) refuse to issue a service
>> ticket against an expired TGT. So I don't think that
>> GSS_S_CREDENTIALS_EXPIRED can be just informational, at least not for
>> Kerberos.
You're right for gss_init_sec_context, but not for, say,
gss_inquire_context (when it gets added).
>> However, some mechanisms might be willing to authenticate with expired
>> credentials (and only give a warning). So maybe we could make this an
>> informational status, but always couple it with GSS_S_FAILURE for
>> Kerberos.
This seems reasonable to me.
>> however, as I stated above, I'm not convinced that the context
>> lifetime needs to bear any relationship to the credential lifetime.
>> What's the argument in favor of linking them? What's the argument for
>> picking any particular time-out for contexts?
I think this is an application-specific decision. Some applications
(like rlogin) will run forever, once the connection has been
established. Other applications, like AFS, will refuse to honor
requests after the service ticket expires, forcing the user to
reauthenticate. I think that the compromise of making the error codes
flags works here, because it lets the app decide what to do.
>> What does Kerberos itself do in this area?
Nothing. At least not according to a brief skim of rd_priv.c
>> How does the acceptor know what the expiration time of the original
>> TGT was, since all it gets to see is a service ticket, which may have
>> a shorter lifetime than the TGT?
Perhaps the context expire time should be the service ticket's expire
time. Both peers have access to this information, and it is
logically consistent.
Marc
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07553;
20 May 94 11:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10338;
20 May 94 11:38 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07524;
20 May 94 11:38 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07459;
20 May 94 11:35 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tuba at lanl.gov
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-tuba-host-clnp-multicas-01.txt
Date: Fri, 20 May 94 11:35:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405201135.aa07459 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the TCP/UDP Over CLNP-Addressed
Networks Working Group of the IETF.
Title : Host Group Extensions for CLNP Multicasting
Author(s) : D. Marlow
Filename : draft-ietf-tuba-host-clnp-multicas-01.txt
Pages : 42
Date : 05/19/1994
This draft provides a specification for multicast extensions to the CLNP
protocol similar to those provided to IP by RFC1112. These extensions are
intended to provide the mechanisms needed by a host for multicasting in a
CLNP based Internet. This draft covers addressing extensions to the CLNP
addressing structure, extensions to the CLNP protocol and extensions to the
ES-IS protocol. An appendix discusses the differences between IP multicast
and the CLNP multicast approach provided in this draft.
The multicast extensions to the CLNP addressing structure defines group
Network addresses which identify host groups. The multicast extensions to
CLNP provides a means for identifying a CLNP packet and provides scope
control mechanisms for CLNP multicast packets. The multicast extensions to
the ES-IS protocol provide the mechanisms needed for a host to exchange
control information with multicast capable routers. These extensions to
the ES-IS protocol provide for a host to "announce" which multicast packets
are of interest and for a multicast capable router to dynamically "map"
group Network addresses to subnetwork addresses.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tuba-host-clnp-multicas-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-tuba-host-clnp-multicas-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940519085229.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-tuba-host-clnp-multicas-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tuba-host-clnp-multicas-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940519085229.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08136;
20 May 94 12:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08129;
20 May 94 12:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11198;
20 May 94 12:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08115;
20 May 94 12:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08110;
20 May 94 12:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11193;
20 May 94 12:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08104;
20 May 94 12:08 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-smtp at dimacs.rutgers.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call2: SMTP Service Extensions to Draft Standard
Date: Fri, 20 May 94 12:08:03 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405201208.aa08104 at IETF.CNRI.Reston.VA.US>
Note: These documents have already been subjected to a Last Call,
but as a result of comments received and to editorial changes made
to the documents, another Last Call is being issued.
The IESG has received a request from the Internet Mail Extensions
Working Group to consider the following three documents for the
status of Draft Standard:
o SMTP Service Extensions
<draft-ietf-smtpext-extensions-01.txt>
o SMTP Service Extension for 8bit-MIMEtransport
<draft-ietf-smtpext-8bitmime-01.txt>
o SMTP Service Extension for Message Size Declaration
<draft-ietf-smtpext-size-01.txt>
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any comments
to the iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing
lists by 3 June.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08337;
20 May 94 12:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11375;
20 May 94 12:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08318;
20 May 94 12:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07373;
20 May 94 11:32 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-osi-x400ops at cs.wisc.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-x400ops-postmaster-05.txt
Date: Fri, 20 May 94 11:32:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405201132.aa07373 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the X.400 Operations Working
Group of the IETF.
Title : Postmaster Convention for X.400 Operations
Author(s) : C. A. Cargille
Filename : draft-ietf-x400ops-postmaster-05.txt
Pages : 5
Date : 05/19/1994
Both RFC822 and RFC1123 (Host Requirements) require that the email address
"postmaster" be supported at all hosts. This paper extends this concept to
X.400 mail domains which have registered RFC1327 mapping rules, and which
therefore appear to have normal RFC822-style addresses.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-x400ops-postmaster-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-x400ops-postmaster-05.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940519151309.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-x400ops-postmaster-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-x400ops-postmaster-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940519151309.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09266;
20 May 94 12:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09254;
20 May 94 12:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13177;
20 May 94 12:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09236;
20 May 94 12:53 EDT
Received: from hearn.nic.surfnet.nl by IETF.CNRI.Reston.VA.US id aa09171;
20 May 94 12:51 EDT
Received: from IRLEARN.UCD.IE by HEARN.nic.SURFnet.nl (IBM VM SMTP V2R2)
with BSMTP id 6367; Fri, 20 May 94 15:33:04 CET
Received: from IRLEARN.UCD.IE (NJE origin JENNINGS at IRLEARN) by IRLEARN.UCD.IE
(LMail V1.2a/1.8a) with BSMTP id 3570; Fri, 20 May 1994 14:05:11 +0100
Date: Fri, 20 May 94 14:03:01 WET
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Jennings <JENNINGS at irlearn.ucd.ie>
Subject: Call for Papers for Engineers Conference
To: ietf at IETF.CNRI.Reston.VA.US
cc: Emmanuelle Gille <egille at interop.com>
Message-ID: <9405201251.aa09171 at IETF.CNRI.Reston.VA.US>
Dear IETFers,
By kind permission of Paul Mokapetris, I circulate the attached Call for
Papers for your attention. My apologies for the short notice of the
deadlines - hopefully it is not too late.
Dennis
-----------------------------------------------------------------------
=====================
First Call for Papers
-------------------
Engineers Conference
at
NetWorld+Interop 94 Paris
---------------------------------------------------------------------
Interop Company is soliciting technical papers for an Engineers
Conference to be held as part of the upcoming NetWorld+Interop
94 Paris event, October 24 - 28, 1994, in Paris.
The Engineers Conference, which will be held on Thursday/Friday
October 27 - 28, is a two-day focused event offering approaches and
solutions to practical systems and software design for networking.
All participants in the conference will be able to attend the
NetWorld+Interop 94, Paris exhibition, which will run from
October 26 - 28.
FORMAT
The conference will feature the presentation of original papers
which will have been selected by a review committee. All accepted
papers will be published in Conference Proceedings. Accepted papers
must be presented by original authors during the 2-day conference.
Conference sessions typically will be 90 minutes long and will
present three papers of 20 to 30 minutes duration.
The Engineer's Conference will concentrate on engineering design
problems in three areas: High Speed Networking, Internetworking,
and Multimedia. This conference seeks to bring together research
scholars, engineers, and vendors to address pragmatic engineering
issues in the field of networking and distributed systems
interoperability. It is an excellent forum for Engineers and
Researchers to publish papers and to be brought up to date on
solutions to today's engineering related problems.
Papers are solicited in the following areas:
* High Speed Networking: ATM, Fast Ethernet, SDH, FDDI-II,
HIPPI, SMDS, Frame Relay, Broadband ISDN, etc.
* Internetworking: Addressing Schemes, Routing Protocols,
Support of Mobility, Design of Bridges, Routers, and
Multiprotocol Brouters, Application Gateways etc.
* Multimedia Networking: Multimedia technologies, Multimedia
inteoperability, Packet Video and voice, Multimedia Mail and
Conferencing, Tele-Presence, Virtual Reality, etc.
SUBMISSION GUIDELINES
Interested authors are invited to submit an abstract (up to 600
words) clearly describing the problem and the solution offered. All
abstracts will be reviewed and authors will be notified for acceptance
or rejection of the abstract. Authors of accepted abstracts must
submit the paper before the last date. These papers are reviewed by
a technical committee for technical merit of the paper before final
acceptance.
Please note the important dates for abstract and paper submission.
All abstracts must contain the authors name, address, telephone
number, Fax number and e-mail address (if available).
Please send your abstract to:
Interop Europe
14 Place Marie-Jeanne Bassot,
92593 Levallois Peret Cedex,
Paris, France
Attention: Engineer's Conference
or e-mail it (in ASCII or PostScript) to: Paris_Engineer at interop.com
** E-mail is preferred. **
===================
= Important Dates =
===================
Abstracts due: 3 Jun, 1994
Notification to authors: 24 Jun, 1994
Draft paper due: 22 Jul, 1994
Feedback to authors: 5 Aug, 1994
Camera ready copy due: 9 Sep, 1994
Final camera reader papers must not exceed 10 A4 pages.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09524;
20 May 94 13:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09516;
20 May 94 13:07 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa13438;
20 May 94 13:07 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA23236 at pad-thai.aktis.com>; Fri, 20 May 1994 12:30:00 -0400
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA09371; Fri, 20 May 94 12:28:55 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA07386; Fri, 20 May 94 09:23:12 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA19736; Fri, 20 May 94 12:22:51 -0400
Message-Id: <9405201622.AA19736 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Fri, 20 May 94 12:22:51 EDT
Date: Fri, 20 May 94 12:22:51 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 20-May-1994 1205" <wray at tuxedo.enet.dec.com>
To: dpg at ocsg.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, dpg at ocsg.com
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
>> The only reasons I could see for wanting a context to time-out
>> would be:
>>
>> i) If you feel that the context's session key has been used
>> for too long. At this point, you should either
>> re-authenticate to get a new session key from Kerberos,
>> or roll-over to a new session key, chained from the
>> current one. Neither of these options is supported by the
>> current GSSAPI definition (except by tearing down the
>> context, and establishing a new one).
>>
>> or ii) You want to make sure that the client or server's
>> long-term keys haven't been revoked by the KDC.
>
>
>or iii, to enforce the realm's security policy.
How does GSSAPI find out what the realm's security policy is? I've been
assuming that we're talking about the case where the client askes for an
infinite lifetime context - There's no dispute that, for cases where the client
asks for a shorter lifetime, then GSSAPI should honor that requested lifetime.
>From a security perspective, an infinite key lifetime should be
>avoided. The longer an application uses the same key the more
>susceptible it is to compromise.
I agree that you don't want to use a session key forever. But what's a good
expiration time for GSSAPI to pick (assuming the client hasn't specified one)?
>Telnet and FTP are two examples where context expiration is
>desirable.
I'd have thought that these applications are examples of ones where you _don't_
want GSSAPI to enforce context expiration. If I use secure telnet to connect
to a remote host, I'd be very unhappy if GSSAPI were to unilaterally tear down
my conection, just because I happened to have only a few minutes of time left
on my TGT at the time I opened my connection.
Maybe I'm misunderstanding the requirement here. Are you asking for an
enforced context timeout, calculated by GSSAPI, or are you asking just for
somewhere in the protocol for a GSSAPI implementation to put a context
expiration time, to support the case where there's some additional security
policy in place at one end?
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11375;
20 May 94 14:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11363;
20 May 94 14:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16012;
20 May 94 14:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11352;
20 May 94 14:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11308;
20 May 94 14:55 EDT
Received: from iraun1.ira.uka.de by CNRI.Reston.VA.US id aa15986;
20 May 94 14:55 EDT
Received: from walhalla.eiss.ira.uka.de (actually eiss_sun3.ira.uka.de)
by iraun1.ira.uka.de with SMTP (PP); Fri, 20 May 1994 20:55:03 +0200
Received: from deathstar.iaks.ira.uka.de
by walhalla.eiss.ira.uka.de (4.1/SMI-4.1) id AA26645;
Fri, 20 May 94 20:55:00 +0200
Received: from columbia.iaks.ira.uka.de
by deathstar.iaks.ira.uka.de (4.1/SMI-4.1) id AA15841;
Fri, 20 May 94 20:54:58 +0200
Date: Fri, 20 May 94 20:54:58 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Hadmut Danisch <danisch at ira.uka.de>
Message-Id: <9405201854.AA15841 at deathstar.iaks.ira.uka.de>
To: cypherpunks at toad.com, ietf at CNRI.Reston.VA.US
Subject: Secure RPC?
Hello,
where can I get specs and informations about
secure RPC?
Thanks
Hadmut
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12669;
20 May 94 16:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12661;
20 May 94 16:10 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa18340;
20 May 94 16:10 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA27337 at pad-thai.aktis.com>; Fri, 20 May 1994 15:36:07 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA23966; Fri, 20 May 94 15:35:21 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA28869; Fri, 20 May 94 15:35:19 EDT
Date: Fri, 20 May 94 15:35:19 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9405201935.AA28869 at tsx-11.MIT.EDU>
To: cat-ietf at mit.edu
Subject: GSSAPI OID assignments....
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
I've finally gotten around to making the OID assignments for the GSSAPI
assignments. My apolgies for taking so long on this! Anyway, here it is:
iso (1) member-body (2) United States (840) mit (113554) infosys (1) gssapi (2)
generic (1)
user_name (1)
machine_uid_name (2)
string_uid_name (3)
service_name (4)
krb5 (2)
krb5_name (1)
krb5_principal (2)
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13339;
20 May 94 16:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13331;
20 May 94 16:53 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa19478;
20 May 94 16:53 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA28279 at pad-thai.aktis.com>; Fri, 20 May 1994 16:16:51 -0400
Received: from darkstar.isi.edu by MIT.EDU with SMTP
id AA26894; Fri, 20 May 94 16:15:55 EDT
Received: by darkstar.isi.edu (5.65c/5.61+local-17)
id <AA03403>; Fri, 20 May 1994 13:15:51 -0700
Date: Fri, 20 May 1994 13:15:51 -0700
Message-Id: <199405202015.AA03403 at darkstar.isi.edu>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Clifford Neuman <bcn at isi.edu>
To: tytso at mit.edu
Cc: cat-ietf at mit.edu
In-Reply-To: Theodore Ts'o's message of Fri, 20 May 94 15:35:19 EDT <9405201935.AA28869 at tsx-11.MIT.EDU>
Subject: GSSAPI OID assignments....
Date: Fri, 20 May 94 15:35:19 EDT
From: tytso at MIT.EDU (Theodore Ts'o)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
I've finally gotten around to making the OID assignments for the GSSAPI
assignments. My apolgies for taking so long on this! Anyway, here it is:
iso (1) member-body (2) United States (840) mit (113554) infosys (1) gssapi (2)
generic (1)
user_name (1)
machine_uid_name (2)
string_uid_name (3)
service_name (4)
krb5 (2)
krb5_name (1)
krb5_principal (2)
Why is the second one different than the OID already assigned for
Kerberos in the Kerberos V5 Spec (RFC1510).
~ Cliff
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13680;
20 May 94 17:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13672;
20 May 94 17:22 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa20259;
20 May 94 17:22 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA28898 at pad-thai.aktis.com>; Fri, 20 May 1994 16:48:31 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA29082; Fri, 20 May 94 16:47:45 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA29974; Fri, 20 May 94 16:47:26 EDT
Date: Fri, 20 May 94 16:47:26 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9405202047.AA29974 at tsx-11.MIT.EDU>
To: Clifford Neuman <bcn at isi.edu>
Cc: cat-ietf at mit.edu
In-Reply-To: Clifford Neuman's message of Fri, 20 May 1994 13:15:51 -0700,
<199405202015.AA03403 at darkstar.isi.edu>
Subject: Re: GSSAPI OID assignments....
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Fri, 20 May 1994 13:15:51 -0700
From: Clifford Neuman <bcn at ISI.EDU>
Why is the second one different than the OID already assigned for
Kerberos in the Kerberos V5 Spec (RFC1510).
I've remembered some amount of confusion about whether or not that OID
would be appropriate for the Krb5 GSSAPI mechanism. In particular,
RFC1510 reads:
During authentication of an OSI client to and OSI server, the mutual
authentication of an OSI server to an OSI client, the transfer of
credentials from an OSI client to an OSI server, or during exchange of
private or integrity checked messages, Kerberos protocol messages may
be treated as opaque objects and the type of the authentication
mechanism will be:
iso (1), org(3), dod(5),internet(1), security(5), kerberosv5(2)
Since GSSAPI isn't related to OSI (thank goodness!), it wasn't clear
whether or not we wanted to use that OID or pick a new one. It also
wasn't clear whether or not who had the authority to assign OID's below
this arc, which was where I put the mechanism-specific name type.
That brings up another question. In the OID assignments that I
released, we used the following convention:
krb5 (2) (algorithm)
krb5_name (1) (nametype)
krb5_principal (2) (nametype)
One can make the argument that we should have done something like this:
gssapi (2)
algorithm (1)
krb5 (1)
nametype (1)
krb5_name (1)
krb5_principal (2)
or:
gssapi (2)
generic (1)
nametype (1)
...
krb5 (2) (algorithm)
nametype (1)
krb5_name (1)
krb5_principal (2)
I'm not particularily tied to one way of doing things over another; but
I'd rather not change them unless there's a really good reason why one
of the alternative hierarchical schemes.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14404;
20 May 94 18:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14392;
20 May 94 18:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21190;
20 May 94 18:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14380;
20 May 94 18:19 EDT
Received: from ftp.com by IETF.CNRI.Reston.VA.US id aa14348; 20 May 94 18:16 EDT
Received: from ftp.com by ftp.com ; Fri, 20 May 1994 18:16:35 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Fri, 20 May 1994 18:16:35 -0400
Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA29183; Fri, 20 May 94 18:15:09 EDT
Date: Fri, 20 May 94 18:15:09 EDT
Message-Id: <9405202215.AA29183 at mailserv-D.ftp.com>
To: smb at research.att.com
Subject: Re: trademarks and the DNS
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank T Solensky <solensky at ftp.com>
Cc: ietf at IETF.CNRI.Reston.VA.US
X-Orig-Sender: solensky at mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Fri May 20 18:15:06 1994]
Originating-Client: fenway.ftp.com
Content-Length: 3217
> From: smb at research.att.com
> Subject: trademarks and the DNS
> Date: Wed, 11 May 94 11:45:34 EDT
>
> The question has come up of what relationship trademarks have to DNS
> names. A court may be about to look at the question. Enclosed below
> is an article from misc.legal.moderated, reposted with permission.
>
> In article <2qpjdf$eeu at panix.com>, adam at mtv.com (Adam Curry) writes:
> >
> > MTV Sues Curry
> > **************
> >
> > I had planned to keep the following quiet until more information
> > was available, but since several journalists have already caught
> > wind of it, I decided to get it out into the open so my side of the
> > story is heard as well.
> >
> > The domain I maintain and operate on the Internet, mtv.com was
> > founded approximately one year ago....
Here's another viewpoint from one of those journalists (David Plotnikoff;
Knight-Ridder Service), reprinted without permission:
Until a few weeks ago, Adam Curry, the veteran video jock for the MTV
Network, would have appeared to have the best of both worlds.
By day, he was a globally recognized talking head. By night he
pursued a second career in cyberspace. As a not-for-profit
avocation, he ran a massively popular Internet site called mtv.com,
which featured music news, photos, celebrity interviews and other
goodies. He also ran the Cyber-sleaze Internet mail group, a very
catty five-day-a-week show-biz gossip rag transmitted by email.
Tes, the 29-year-old Curry had it all -- until a few weeks ago, when
something smapped. Curry was headed to work at the MTV studios in
New York City when he had an epiphany of sorts.
"It really wasn't anything premeditated," said Curry, when reached by
phone at his New York office. "I started thingking about how the
world around me has been changing. All of a sudden, I started asking
myself, 'Why cling to this pop icon of the '80s?' I was driving into
the city and it just hit me: I realized I'd intro'd 'Beavis and
Butt-head' one time too many."
Curry went through with the taping of the MTV Top 20 video countdown
-- until it came time to announce the No. 1 video. With the cameras
rolling, he announced he was leaving his six-year gig at MTV for "the
digital revolution."
Currently, his biggest project is OnRamp Inc., a 6-month-old
partnership with some advertising bigwigs that will build "virtual
storefronts" on the Internet for consumer firms. At the moment, the
mtv.com site is still running. (In the midst of the music goodies is
an incredible document titled "I-QUIT!")
Curry said he's received 10,000 pieces of congratulatory email since
his resignation. The reaction from the executive suite of MTV came
in the form of a lawsuit filed last week in New York. The suit seeks
to bar Curry from using MTV's name in any context. "This is a case
of Adam using MTV's trademark to market and sell his Internet
service," said Carol Robinson, senior vice president of press for the
network.
Naturally, Curry begs to differ. He claims to own the mtv.com
Internet address. "MTV always said, 'Go ahead, do whatever, we don't
care.'" he said. "Then when I started getting media afttention, they
started to get really difficult about it."
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14519;
20 May 94 18:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14507;
20 May 94 18:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21273;
20 May 94 18:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14496;
20 May 94 18:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14454;
20 May 94 18:21 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa21251; 20 May 94 18:21 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA20181 for ietf at cnri.reston.va.us; Fri, 20 May 94 18:21:14 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id PAA12914; Fri, 20 May 1994 15:19:12 -0700
Message-Id: <199405202219.PAA12914 at aland.bbn.com>
To: tccc at cs.umass.edu
Cc: ietf at CNRI.Reston.VA.US
Cc: comp.dcom.cell-relay at news-relay.indiana.edu
Subject: further info on SIGCOMM '94 student grant program
Reply-To: Craig Partridge <craig at aland.bbn.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Fri, 20 May 94 15:19:10 -0700
X-Orig-Sender: craig at aland.bbn.com
Hi folks:
There seems to be a rumor running around that the NSF/ARPA grants are
going preferentially to student paper authors -- that's not the case --
in fact, quite the reverse. The purpose of this grant is to help students
who otherwise would normally not be expected to attend. In our view is
student authors should be funded by their advisors and are normally
expected to be at the conference anyway.
Craig
E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14547;
20 May 94 18:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21294;
20 May 94 18:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14534;
20 May 94 18:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14434;
20 May 94 18:20 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21231;
20 May 94 18:20 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08299>; Fri, 20 May 1994 15:20:06 -0700
Message-Id: <199405202220.AA08299 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1621 on Pip Near-term Architecture
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 20 May 94 15:20:21 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1621:
Title: Pip Near-term Architecture
Author: P. Francis
Mailbox: francis at cactus.ntt.jp
Pages: 51
Characters: 128,905
Updates/Obsoletes: none
Pip is an internet protocol intended as the replacement for IP version
4. Pip is a general purpose internet protocol, designed to evolve to
all forseeable internet protocol requirements. This specification
describes the routing and addressing architecture for near-term Pip
deployment. We say near-term only because Pip is designed with
evolution in mind, so other architectures are expected in the future.
This document, however, makes no reference to such future
architectures.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940520104314.RFC at ISI.EDU>
SEND /rfc/rfc1621.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1621.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940520104314.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14617;
20 May 94 18:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21357;
20 May 94 18:25 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14593;
20 May 94 18:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14491;
20 May 94 18:23 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21263;
20 May 94 18:23 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08350>; Fri, 20 May 1994 15:22:57 -0700
Message-Id: <199405202222.AA08350 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1622 on Pip Header Processing
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 20 May 94 15:23:12 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1622:
Title: Pip Header Processing
Author: P. Francis
Mailbox: francis at cactus.ntt.jp
Pages: 16
Characters: 34,837
Updates/Obsoletes: none
Pip is an internet protocol intended as the replacement for IP version
4. Pip is a general purpose internet protocol, designed to handle all
forseeable internet protocol requirements. This specification defines
the Pip header processing for Routers and Hosts.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940520152108.RFC at ISI.EDU>
SEND /rfc/rfc1622.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1622.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940520152108.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14692;
20 May 94 18:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21428;
20 May 94 18:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14675;
20 May 94 18:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14641;
20 May 94 18:27 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21384;
20 May 94 18:27 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08395>; Fri, 20 May 1994 15:27:02 -0700
Message-Id: <199405202227.AA08395 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1631 on Network Address Translator
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 20 May 94 15:27:16 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1631:
Title: The IP Network Address Translator (NAT)
Author: K. Egevang & P. Francis
Mailbox: kbe at craycom.dk, francis at cactus.ntt.jp
Pages: 10
Characters: 22,714
Updates/Obsoletes: none
The two most compelling problems facing the IP Internet are IP address
depletion and scaling in routing. Long-term and short-term solutions
to these problems are being developed. The short-term solution is
CIDR (Classless InterDomain Routing). The long-term solutions consist
of various proposals for new internet protocols with larger addresses.
It is possible that CIDR will not be adequate to maintain the IP
Internet until the long-term solutions are in place. This memo
proposes another short-term solution, address reuse, that complements
CIDR or even makes it unnecessary.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940520152331.RFC at ISI.EDU>
SEND /rfc/rfc1631.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1631.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940520152331.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14772;
20 May 94 18:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21539;
20 May 94 18:35 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14754;
20 May 94 18:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14721;
20 May 94 18:33 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21494;
20 May 94 18:33 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08573>; Fri, 20 May 1994 15:33:09 -0700
Message-Id: <199405202233.AA08573 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1624 on Incremental Internet Checksum
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 20 May 94 15:33:23 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1624:
Title: Computation of the Internet Checksum
via Incremental Update
Author: A. Rijsinghani, Editor
Mailbox: anil at levers.enet.dec.com
Pages: 6
Characters: 9,836
Updates: 1141
This memo describes an updated technique for incremental
computation of the standard Internet checksum. It updates the
method described in RFC 1141.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940520152932.RFC at ISI.EDU>
SEND /rfc/rfc1624.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1624.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940520152932.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14878;
20 May 94 18:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21666;
20 May 94 18:40 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14868;
20 May 94 18:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14819;
20 May 94 18:38 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21595;
20 May 94 18:38 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA08725>; Fri, 20 May 1994 15:38:35 -0700
Message-Id: <199405202238.AA08725 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI11, RFC1632 on X.500 Catalog
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 20 May 94 15:38:44 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
FYI 11:
RFC 1632:
Title: A Revised Catalog of Available X.500
Implementations
Author: A. Getchell & S. Sataluri, Editors
Mailbox: getchell at es.net, sri at qsun.att.com
Pages: 94
Characters: 124,111
Obsoletes: 1292
This document is the result of a survey that gathered new or updated
descriptions of currently available implementations of X.500,
including commercial products and openly available offerings. This
document is a revision of FYI 11, RFC 1292. We contacted each
contributor in FYI 11, RFC 1292 and requested an update and published
the survey template in several mailing lists and obtained new product
descriptions. This document is a product of the Integrated Directory
Services Working Group of the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940520153402.RFC at ISI.EDU>
SEND /rfc/rfc1632.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1632.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940520153402.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24424;
21 May 94 0:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24412;
21 May 94 0:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00127;
21 May 94 0:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24401;
21 May 94 0:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24371;
21 May 94 0:29 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa29965;
21 May 94 0:29 EDT
Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0)
id VAA13888; Fri, 20 May 1994 21:28:52 -0700
Message-Id: <aa033d660e02101342c6 at [128.102.17.23]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 20 May 1994 21:28:55 -0700
To: Hadmut Danisch <danisch at ira.uka.de>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re:Secure RPC?
Cc: cypherpunks at toad.com, ietf at CNRI.Reston.VA.US
There is an IETF working group pursuing standardization of Sun's RPC/XDR.
There are some internet-drafts as the base (look for the string *onc*). To
subscribe to its mailing list, send a request to:
oncrpc-wg-request at sunroof.Eng.Sun.COM
The initial round of effort is to standardize 'classic' rpc. One of the
follow-on efforts is likely to be specification for use with Kerberos.
At 11:54 AM 5/20/94, Hadmut Danisch wrote:
>where can I get specs and informations about
>secure RPC?
Dave
+1 408 246 8253 (fax: +1 408 249 6205)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03000;
23 May 94 8:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02987;
23 May 94 8:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04301;
23 May 94 8:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02931;
23 May 94 8:24 EDT
Received: from [131.112.4.4] by IETF.CNRI.Reston.VA.US id aa02822;
23 May 94 8:13 EDT
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 23 May 94 21:06:57 +0859
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Return-Path: <mohta at necom830.cc.titech.ac.jp>
Message-Id: <9405231207.AA05816 at necom830.cc.titech.ac.jp>
Subject: Re: trademarks and the DNS
To: Frank T Solensky <solensky at ftp.com>
Date: Mon, 23 May 94 21:06:56 JST
Cc: smb at research.att.com, ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: <9405202215.AA29183 at mailserv-D.ftp.com>; from "Frank T Solensky" at May 20, 94 6:15 pm
X-Mailer: ELM [version 2.3 PL11]
> > The question has come up of what relationship trademarks have to DNS
> > names.
As far as I know, US trademark system is case sensitive while DNS is not.
Moreover, DNS (including "com" zone) is for worldwide while trademark
is for domestic.
So, I think US domestic trademark issue has nothing to do with DNS.
Of course, if someone advertises that "MTV.COM is for MTV" or "mtv.com
is for MTV", the latter use of the word: "for MTV", might violate
trademark related laws of some countries. But the issue has nothing to
do with the DNS names of "mtv.com", "MTV.COM", "MtV.Com", etc.
Masataka Ohta
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03663;
23 May 94 9:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03649;
23 May 94 9:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05361;
23 May 94 9:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03624;
23 May 94 9:09 EDT
Received: from reggae.concert.net by IETF.CNRI.Reston.VA.US id aa03596;
23 May 94 9:06 EDT
Received: from mento.oit.unc.edu by reggae.concert.net (5.65/tas-reggae/nov93)
id AA15817; Mon, 23 May 94 09:01:13 -0400
Received: by mento.oit.unc.edu (NeXT-1.0 (From Sendmail 5.52)/TAS/11-16-88)
id AA14746; Mon, 23 May 94 09:01:11 EDT
Date: Mon, 23 May 1994 09:01:10 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Jones <pjones at mento.oit.unc.edu>
Subject: Re: trademarks and the DNS
To: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Cc: Frank T Solensky <solensky at ftp.com>, smb at research.att.com,
ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: <9405231207.AA05816 at necom830.cc.titech.ac.jp>
Message-Id: <Pine.3.89.9405230849.A14733-0100000 at mento.oit.unc.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I get it! MTV = Maybe a Trademark Violation
- - -
==============================================
Paul Jones
Office FOR Information Technology
University of North Carolina
Chapel Hill, NC
Paul_Jones at unc.edu
Imagination is more important than knowledge - A. Einstein
<http://sunsite.unc.edu/pjones/pjones.html>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04305;
23 May 94 9:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04288;
23 May 94 9:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06852;
23 May 94 9:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04272;
23 May 94 9:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04170;
23 May 94 9:39 EDT
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa06787;
23 May 94 9:39 EDT
Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/21Mar94)
id AA06085; Mon, 23 May 94 06:32:20 -0700
Received: by skidrow.lkg.dec.com (5.65/MS-081993);
id AA00378; Mon, 23 May 1994 09:34:26 -0400
Message-Id: <9405231334.AA00378 at skidrow.lkg.dec.com>
To: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Cc: Internet Engineering Task Force <ietf at CNRI.Reston.VA.US>
Subject: Re: trademarks and the DNS
In-Reply-To: Your message of "Mon, 23 May 94 21:06:56 +0200."
<9405231207.AA05816 at necom830.cc.titech.ac.jp>
Date: Mon, 23 May 94 09:34:26 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Beast)" <dee at skidrow.lkg.dec.com>
X-Mts: smtp
Ohta-san,
From: Masataka Ohta <mohta at necom830.cc.titech.ac.jp>
Sender: ietf-request at IETF.CNRI.Reston.VA.US
To: Frank T Solensky <solensky at ftp.com>
Cc: smb at research.att.com, ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: <9405202215.AA29183 at mailserv-D.ftp.com>; from "Frank T Solensky" at May 20, 94 6:15 pm
X-Mailer: ELM [version 2.3 PL11]
>> > The question has come up of what relationship trademarks have to DNS
>> > names.
>
>As far as I know, US trademark system is case sensitive while DNS is not.
A trademark can be case sensitive or not or font sensitive or not or
color sensitive or not... It all depends. If it is not case
sensitive, then traditionally in the USA the trademark application,
etc., are written using a plain font and all capital letters.
But the basic test for trademark infringement in the US is whether you
are using a mark in such a way as to cause confusion between yourself
and the other owner. If no one can show confusion, then there is no
basis for a claim of infringement. Even if you can show confusion,
there are still questions of how likely a reasonable person is to be
confused, what rights you have acquired due to independent use,
possible complete or partial abandonment by other trademark owner, do
you put disclaimers on the products, different geographic markets,
etc. etc. Although perhaps the most important factor is who has the
most money to pay for lawyers.
KodaK and XeroX were both at least originally trademarked in a case
sensitive way with a leading and trailing capital letter but that does
not mean you can use "kodak" or "xerox" for anything you want.
>Moreover, DNS (including "com" zone) is for worldwide while trademark
>is for domestic.
A very good point.
>So, I think US domestic trademark issue has nothing to do with DNS.
>
>Of course, if someone advertises that "MTV.COM is for MTV" or "mtv.com
>is for MTV", the latter use of the word: "for MTV", might violate
>trademark related laws of some countries. But the issue has nothing to
>do with the DNS names of "mtv.com", "MTV.COM", "MtV.Com", etc.
>
> Masataka Ohta
Donald
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06043;
23 May 94 11:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09304;
23 May 94 11:30 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06026;
23 May 94 11:30 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05921;
23 May 94 11:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-multilink-09.txt
Date: Mon, 23 May 94 11:24:57 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405231124.aa05921 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The PPP Multilink Protocol (MP)
Author(s) : K. Sklower, B. Lloyd, G. McGregor, D. Carr
Filename : draft-ietf-pppext-multilink-09.txt
Pages : 20
Date : 05/20/1994
This document proposes a method for splitting, recombining and sequencing
datagrams across multiple logical data links. This work was originally
motivated by the desire to exploit multiple bearer channels in ISDN, but is
equally applicable to any situation in which multiple PPP links connect two
system, including async links. This is accomplished by means of new PPP
options and protocols.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-multilink-09.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-multilink-09.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940520111010.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pppext-multilink-09.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-multilink-09.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940520111010.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10330;
23 May 94 16:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10318;
23 May 94 16:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15575;
23 May 94 16:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10307;
23 May 94 16:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10260;
23 May 94 16:24 EDT
Received: from othello.admin.kth.se by CNRI.Reston.VA.US id aa15519;
23 May 94 16:24 EDT
Received: from mercutio.admin.kth.se by othello.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0b)
id AA02350; Mon, 23 May 94 22:24:40 +0200
Received: by mercutio.admin.kth.se (5.65+bind 1.8+ida 1.4.2/4.0)
id AA13051; Mon, 23 May 94 22:24:37 +0200
Date: Mon, 23 May 94 22:24:37 +0200
Message-Id: <9405232024.AA13051 at mercutio.admin.kth.se>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Olle Jarnefors <ojarnef at admin.kth.se>
To: wg-msg at rare.nl
Cc: ietf at CNRI.Reston.VA.US, Olle Jarnefors <ojarnef at admin.kth.se>
In-Reply-To: <Pine.3.89.9405220914.A15753-0100000 at ester> (Sun, 22 May 1994
09:07:45 +0200 (MET DST); From: Jacob Palme DSV <jpalme at dsv.su.se>)
Subject: Re: Identification of Internet standards
Jacob Palme writes (whole text included here):
> Erik Huizer writes:
>
> > Internet standards also retain their number. They are numbered:
> > STD-1 STD-2 etc.
> > Unfortunately most people refer to them by their publication number:
> > RFC-1234 etc.
>
> I had never heard of these STD-numbers before! I have looked at
> a copule of important Internet standards (RFC1036, RFC1123, RFC1341)
> to check the usage of numbering. I find that the RFC number is
> indicated on the first page and on the heading line of each
> page, but not STD number is shown. Also, stores of Internet
> Standards (so-called RFC depositories) store standards by
> RFC numbers only.
I suppose STD numbers are not included in RFC1036 and RFC1123
because the STD numbering didn't exist when they were published.
In newer standard RFCs STD numbers seem to be included in the
document header, see for example RFC1350.
That RFC1341 (MIME I) does not include an STD number is probably
because MIME is not an adopted Internet standard yet, it's still
on the second "maturity level", Draft Standard Protocol. (By the
way, RFC1341 has been replaced by RFC1521.)
It will be interesting to watch what happens to the meaning
of the phrase "Internet STD 11" when MIME is adopted as an
Internet Standard Protocol. Presently STD 11 includes two RFCs,
the well-known RFC822 and RFC1049, "Content Type Header Field".
RFC822 is not affected by MIME but RFC1049 will be obsoleted by
the MIME standard. Will "STD 11" then get a new meaning, or will
a new STD number be assigned to RFC822+MIME?
Another observation is that what is specified in one Internet
standard may be changed by another Internet standard. For
example: the syntax for a "date" in a RFC822 header field
according to STD 11 (RFC822) is changed in STD 3 (RFC1123,
section 5.2.14). I suppose the rule is that the standard RFC
with the highest number wins when two standard RFCs are in
conflict.
To my knowledge RFC1123 is the only standard RFC that changes
anything in RFC822. I have incorporated the RFC1123 changes in a
special version of RFC822 that is available by anonymous FTP
from othello.admin.kth.se
in the directory pub/misc/ojarnef/internet
as the file rfc0822r.txta
One way to make the STD numbers more known and thereby more
usable might be to assign a number already when an Internet
draft reaches the first maturity level, Proposed Standard
Protocol. The number would be preserved throughout the process
from Proposed via Draft to final Standard. Different prefixes
could be used: Internet PSTD 99, Internet DSTD 99, Internet STD
99. This would make the number more or less an Internet
standardization project number, and many numbers will probably
never reach the STD level, so the STD number series will contain
holes.
ISO uses the same number for the three stages Committee Draft
(CD) Draft International Standard (DIS) and adopted
Internantional Standard. E.g. ISO 10646, "Universal
Multiple-Octet Coded Character Set", went through the five
stages ISO CD 10646, ISO CD 10646.2, ISO DIS 10646, ISO DIS
10646.2, ISO 10646, and already from the first CD 1989 this
emerging standard could be referred to as "10646".
> To get the STD numbers used, the following actions would be needed:
>
> (a) Change the formatting requirements so that the STD number
> is given (together with the RFC number) on the heading of each
> page of the standard.
>
> (b) Modify all old RFC-s in the RFC archives to employ the
> STD numbering scheme.
>
> (b) Include an STD index, with STD number, title and references to
> corresponding RFC-numbers, in the beginning of the RFC-index file.
The most up-to-date list of STD documents is included in the latest
RFC with the title "INTERNET OFFICIAL PROTOCOL STANDARDS",
currently RFC1600. In the RFC archives at ds.internic.net there
is also a special index file for STDs, but it seems to be
severely out-of-date:
-r--r--r-- 1 101 30 9835 Nov 3 1992 std-index.txt
> (c) Preferably also provide an FTP and Gopher retrieval scheme
> where standards can be retrieved by their STD numbers.
>
> (d) Where one standard refers to another standard, it should
> refer to the STD number, and only include the RFC number
> when this is necessary because the reference for technical
> reasons must be to a particular version of a standard. In
> that case its name could be quoted as:
> "Internet Standard STD-17/version RFC-4711"
>
> If these measures were employed, then we might avoid the confusion
> which the RFC numbers create at present.
>
> P.S. How are amendments handled in the STD numbering scheme.
> If a standard amends a previous standard (such as when MIME
> amends RFC822), is this shown in the STD numbers?
>
> ------------------------------------------------------------------------
> Jacob Palme E-mail: jpalme at dsv.su.se
> Phone: +46-8-664 77 48 or +46-8-16 16 67
> Department of Computer and Fax: +46-8-664 77 48 between 9 am & 2 pm WET
> Systems Sciences (DSV) Postal address: Skeppargatan 73,
> Stockholm University S-11530 Stockholm, Sweden
--
Olle Jarnefors Internet: ojarnef at admin.kth.se
Information Management Services UUCP: ...!uunet!mcsun!sunic!kth!ojarnef
Royal Institute of Technology (KTH) BITNET: ojarnef at sekth Fax:+46 8 10 25 10
S-100 44 Stockholm, Sweden Phone: +46 8 790 71 26 (time zone +0200)
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12171;
23 May 94 18:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18015;
23 May 94 18:30 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12148;
23 May 94 18:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12069;
23 May 94 18:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17944;
23 May 94 18:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12062;
23 May 94 18:27 EDT
To: IETF-Announce: ;
Subject: WG ACTION: Electonic Data Interchange (edi)
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Date: Mon, 23 May 94 18:27:51 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9405231827.aa12062 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Applications Area
of the IETF. The responsible area director is John Klensin.
For more information, contact the working group chair or the
responsible area director.
IESG Secretary
Electronic Data Interchange (edi)
---------------------------------
Charter
Chair(s):
Dave Crocker <dcrocker at mordor.stanford.edu>
Applications Area Director(s)
John Klensin <Klensin at infoods.unu.edu>
Erik Huizer <Erik.Huizer at SURFnet.nl>
Area Advisor
John Klensin <Klensin at infoods.unu.edu>
Mailing lists:
General Discussion:ietf-edi at byu.edu
To Subscribe: listserv at byu.edu
In Body: sub ietf-edi <yourname>
Archive: ftp.sterling.com:edi/lists
Description of Working Group:
Electronic Data Interchange (EDI) is a set of protocols for conducting
highly structured inter-organization exchanges, such as for making
purchases. The working group will produce specifications for the use
of EDI standards over the Internet, with an initial focus on the
transport of EDI via Internet e-mail. The EDI community is large,
diverse and well-established. This working group effort is explicitly
NOT intending to specify or modify any of the details of EDI protocols
themselves. Instead, it will focus on the requirements for proper
carriage of EDI over the Internet, attending only to issues of
encapsulation, addressing, security and the like.
Initial efforts by the working group will focus on two deliverables:
specification for the carriage of various EDI content via MIME-based
e-mail, and a discussion document, considering issues in the use of
EDI over the Internet. The usage document will cover such issues as
addressing and security.
Goals and Milestones:
Done Submit specification for carriage of various EDI "interchange"
transactions via MIME-based e-mail as an Internet-Draft.
Jun 94 Submit "specification for carriage..." document (EDI transport) to
the IESG for consideration as a Proposed Standard.
Jul 94 Complete outline for usage document and include it in the minutes
from the Toronto IETF.
Aug 94 Submit first the draft of the usage document as an Internet-Draft.
Oct 94 Submit the finalized usage document for publication as an RFC.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14359;
23 May 94 22:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14355;
23 May 94 22:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21418;
23 May 94 22:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14343;
23 May 94 22:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14339;
23 May 94 22:08 EDT
Received: from hertz.njit.edu by CNRI.Reston.VA.US id aa21412;
23 May 94 22:08 EDT
Received: by hertz.njit.edu (5.57/Ultrix3.0-C)
id AA18699; Mon, 23 May 94 22:08:41 -0400
Date: Mon, 23 May 94 22:08:41 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: vincent birritteri ee stnt <vxb0543 at hertz.njit.edu>
Message-Id: <9405240208.AA18699 at hertz.njit.edu>
To: @ietf-announce:iesg-secretary at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: Last Call: Border Gateway Protocol to Proposed Standard
Cc: iesg at CNRI.Reston.VA.US
please remove my name from your mailing list.
thank you,
vince birritteri
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18167;
23 May 94 23:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18155;
23 May 94 23:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22553;
23 May 94 23:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18035;
23 May 94 23:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17803;
23 May 94 23:38 EDT
Received: from oit.gatech.edu by CNRI.Reston.VA.US id aa22520;
23 May 94 23:38 EDT
Received: by oit.gatech.edu (5.67a/OIT-4.2)
id AA07029; Mon, 23 May 1994 23:38:19 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Michael Mealling <ccoprmm at oit.gatech.edu>
Message-Id: <199405240338.AA07029 at oit.gatech.edu>
Subject: Internet Staff T-Shirt and Comdex?
To: ietf at CNRI.Reston.VA.US
Date: Mon, 23 May 1994 23:38:18 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 409
Should I wear my _Internet Staff_ T-Shirt from the Houston IETF to Comdex
tomorrow?
-MM
--
------------------------------------------------------------------------------
Michael Mealling ! Hypermedia WWW, WAIS, and gopher will be
Georgia Institute of Technology ! here soon via MIME. Your view of the
Michael.Mealling at oit.gatech.edu ! internet is about to change completely!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04586;
24 May 94 9:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04574;
24 May 94 9:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06255;
24 May 94 9:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04494;
24 May 94 9:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04275;
24 May 94 9:33 EDT
Received: from arcwelder.micro.umn.edu by CNRI.Reston.VA.US id aa05980;
24 May 94 9:33 EDT
Received: from phish.micro.umn.edu by arcwelder.micro.umn.edu (5.65c/Tony Tiger 1.34)
id AA27916; Tue, 24 May 1994 08:33:35 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Neophytos Iacovou <iacovou at arcwelder.micro.umn.edu>
Message-Id: <199405241333.AA27916 at arcwelder.micro.umn.edu>
Subject: Re: Internet Staff T-Shirt and Comdex?
To: Michael Mealling <ccoprmm at oit.gatech.edu>
Date: Tue, 24 May 1994 08:36:08 -0500 (CDT)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <199405240338.AA07029 at oit.gatech.edu> from "Michael Mealling" at May 23, 94 11:38:18 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 520
Michael Mealling writes:
>
> Should I wear my _Internet Staff_ T-Shirt from the Houston IETF to Comdex
> tomorrow?
I'm not sure. Let me form a WG and I'll get back to you on this. In the
mean time, go naked.
--------------------------------------------------------------------------------
Neophytos Iacovou Distributed Computing Services
University of Minnesota 100 Union St. SE
email: iacovou at boombox.micro.umn.edu Minneapolis, MN 55455 USA
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05063;
24 May 94 10:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05054;
24 May 94 10:16 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa06962;
24 May 94 10:16 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA21536 at pad-thai.aktis.com>; Tue, 24 May 1994 09:46:28 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA14811; Tue, 24 May 94 09:45:35 EDT
Received: from winkl.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <JAA21530 at pad-thai.aktis.com>; Tue, 24 May 1994 09:46:12 -0400
Received: by winkl.aktis.com (4.1/4.7) id AA10261; Tue, 24 May 94 09:46:11 EDT
Message-Id: <9405241346.AA10261 at winkl.aktis.com>
To: Theodore Ts'o <tytso at mit.edu>
Cc: Clifford Neuman <bcn at isi.edu>, cat-ietf at mit.edu, linn at cam.ov.com
Subject: Re: GSSAPI OID assignments....
In-Reply-To: Your message of "Fri, 20 May 1994 16:47:26 EDT."
<9405202047.AA29974 at tsx-11.MIT.EDU>
Date: Tue, 24 May 1994 09:46:10 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at cam.ov.com>
Ted,
Thanks for making the assignments.
> Date: Fri, 20 May 1994 13:15:51 -0700
> From: Clifford Neuman <bcn at ISI.EDU>
>
> Why is the second one different than the OID already assigned for
> Kerberos in the Kerberos V5 Spec (RFC1510).
>
>I've remembered some amount of confusion about whether or not that OID
>would be appropriate for the Krb5 GSSAPI mechanism. In particular,
>RFC1510 reads:
>
> During authentication of an OSI client to and OSI server, the mutual
> authentication of an OSI server to an OSI client, the transfer of
> credentials from an OSI client to an OSI server, or during exchange of
> private or integrity checked messages, Kerberos protocol messages may
> be treated as opaque objects and the type of the authentication
> mechanism will be:
>
> iso (1), org(3), dod(5),internet(1), security(5), kerberosv5(2)
>
>Since GSSAPI isn't related to OSI (thank goodness!), it wasn't clear
>whether or not we wanted to use that OID or pick a new one. It also
>wasn't clear whether or not who had the authority to assign OID's below
>this arc, which was where I put the mechanism-specific name type.
Also, the Kerberos protocol isn't synonymous with the Kerberos GSS-API
mechanism; there are arbitrarily many ways of integrating Kerberos into
protocols, only a subset of which have anything to do with GSS-API,
and there are arbitrarily many ways of constructing a GSS-API mechanism
based on Kerberos technology, only one of which corresponds to the
specific protocol in the I-D. I think we're validly identifying
a different and specific object here.
>That brings up another question. In the OID assignments that I
>released, we used the following convention:
>
> krb5 (2) (algorithm)
nit: "(algorithm)" -> "(mechanism)"
> krb5_name (1) (nametype)
> krb5_principal (2) (nametype)
...
>I'm not particularily tied to one way of doing things over another; but
>I'd rather not change them unless there's a really good reason why one
>of the alternative hierarchical schemes.
I think the approach you've taken is fine. I'll edit the new
name types into the I-D and change the mechanism's OID to
{iso(1) member-body(2) United States(840) mit(113554) infosys(1)
gssapi(2) krb5(2)}.
--jl
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06097;
24 May 94 11:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07980;
24 May 94 11:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06069;
24 May 94 11:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05821;
24 May 94 10:55 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-rip at xylogics.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-ripv2-protocol-analysis-01.txt
Date: Tue, 24 May 94 10:55:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405241055.aa05821 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the RIP Version II Working Group
of the IETF.
Title : RIP Version 2 Protocol Analysis
Author(s) : G. Malkin
Filename : draft-ietf-ripv2-protocol-analysis-01.txt
Pages : 4
Date : 04/23/1994
As required by Routing Protocol Criteria (RFC 1264), this report documents
the key features of the RIP-2 protocol and the current implementation
experience. This report is a prerequisite to advancing RIP-2 on the
standards track.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ripv2-protocol-analysis-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ripv2-protocol-analysis-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940523174903.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-ripv2-protocol-analysis-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ripv2-protocol-analysis-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940523174903.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06283;
24 May 94 11:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08059;
24 May 94 11:03 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06271;
24 May 94 11:03 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06114;
24 May 94 11:01 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-borenstein-mailcap-00.txt, .ps
Date: Tue, 24 May 94 11:01:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405241101.aa06114 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : A User Agent Configuration Mechanism For Multimedia Mail
Format Information
Author(s) : N. Borenstein
Filename : draft-borenstein-mailcap-00.txt, .ps
Pages : 16
Date : 05/23/1994
This memo suggests a file format to be used to inform multiple mail reading
user agent programs about the locally-installed facilities for handling
mail in various formats. The mechanism is explicitly designed to work with
mail systems based Internet mail as defined by RFC's 821, 822, 934, 1049,
1113, and the Multipurpose Internet Mail Extensions, known as MIME.
However, with some extensions it could probably be made to work for
X.400-based mail systems as well. The format and mechanism are proposed in
a manner that is generally operating-system independent. However, certain
implementation details will inevitably reflect operating system
differences, some of which will have to be handled in a uniform manner for
each operating system. This memo makes such situations explicit, and, in
an appendix, suggests a standard behavior under the UNIX operating system.
This is a minor update to RFC 1524. Differences are detailed
in Appendix E.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-borenstein-mailcap-00.txt".
Or
"get draft-borenstein-mailcap-00.ps".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-borenstein-mailcap-00.txt".
Or
"FILE /internet-drafts/draft-borenstein-mailcap-00.ps".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940523133959.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-borenstein-mailcap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-borenstein-mailcap-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940523133959.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06612;
24 May 94 11:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08303;
24 May 94 11:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06599;
24 May 94 11:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06541;
24 May 94 11:09 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-lcp-fs-02.txt
Date: Tue, 24 May 94 11:09:34 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405241109.aa06541 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : The Point-to-Point Protocol (PPP)
Author(s) : W. Simpson
Filename : draft-ietf-pppext-lcp-fs-02.txt
Pages : 52
Date : 05/23/1994
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP is
comprised of three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
This document defines the PPP organization and methodology, and the PPP
encapsulation, together with an extensible option negotiation mechanism
which is able to negotiate a rich assortment of configuration parameters
and provides additional management functions. The PPP Link Control
Protocol (LCP) is described in terms of this mechanism.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-lcp-fs-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-lcp-fs-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940523143615.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pppext-lcp-fs-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-lcp-fs-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940523143615.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06834;
24 May 94 11:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08555;
24 May 94 11:22 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06823;
24 May 94 11:22 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06767;
24 May 94 11:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-borenstein-pgp-mime-00.txt, .ps
Date: Tue, 24 May 94 11:19:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405241119.aa06767 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The application/pgp MIME Content-type
Author(s) : N. Borenstein, C. Plumb, P. Zimmermann
Filename : draft-borenstein-pgp-mime-00.txt, .ps
Pages : 7
Date : 05/23/1994
MIME [RFC-1341, RFC-1521] defines a format and general framework for the
representation of a wide variety of data types in Internet mail. This
document defines one particular type of MIME data, the application/pgp
type, for "pretty good" privacy, authentication, and encryption in Internet
mail. The application/pgp MIME type is intended to facilitate the wider
interoperation of private mail across a wide variety of hardware and
software platforms.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-borenstein-pgp-mime-00.txt".
Or
"get draft-borenstein-pgp-mime-00.ps".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-borenstein-pgp-mime-00.txt".
Or
"FILE /internet-drafts/draft-borenstein-pgp-mime-00.ps".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940523132527.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-borenstein-pgp-mime-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-borenstein-pgp-mime-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940523132527.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08875;
24 May 94 13:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10787;
24 May 94 13:09 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08864;
24 May 94 13:09 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08724;
24 May 94 13:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mobile-ip at ossi.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-mobileip-protocol-03.txt
Date: Tue, 24 May 94 13:07:06 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405241307.aa08724 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Routing for
Wireless/Mobile Hosts Working Group of the IETF.
Title : IP Mobility Support
Author(s) : W. Simpson
Filename : draft-ietf-mobileip-protocol-03.txt
Pages : 39
Date : 05/23/1994
This document specifies protocol enhancements that allow transparent
routing of IP datagrams to Mobile Nodes in the Internet. The Mobile Node
is always identified by its Home-Address, regardless of its current point
of attachment to the Internet. While situated away from its home, a Mobile
Node is also associated with a Care-Of-Address, which provides information
about its current point of attachment to the Internet. The protocol
provides for registering the Care-Of-Address with a Home Agent. The Home
Agent sends traffic destined for the Mobile Node through a tunnel to the
Care-Of-Address.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mobileip-protocol-03.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-mobileip-protocol-03.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940523095057.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-mobileip-protocol-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mobileip-protocol-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940523095057.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09644;
24 May 94 13:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11485;
24 May 94 13:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09613;
24 May 94 13:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09520;
24 May 94 13:41 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11437;
24 May 94 13:40 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA01455>; Tue, 24 May 1994 10:40:31 -0700
Message-Id: <199405241740.AA01455 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: STD50, RFC1623 on Ethernet-Like MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 24 May 94 10:40:45 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
STD 50:
RFC 1623:
Title: Definitions of Managed Objects for
the Ethernet-like Interface Types
Author: F. Kastenholz
Mailbox: kasten at ftp.com
Pages: 19
Characters: 38,745
Obsoletes: 1398
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing ethernet-like objects.
This memo also includes a MIB module. This MIB module corrects minor
errors in the earlier version of this MIB, RFC 1398. This document is
a product of the Interfaces MIB Working Group of the IETF.
This is now a 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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940524103039.RFC at ISI.EDU>
SEND /rfc/rfc1623.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1623.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940524103039.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09768;
24 May 94 13:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11628;
24 May 94 13:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09757;
24 May 94 13:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09731;
24 May 94 13:48 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa11591;
24 May 94 13:48 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA01719>; Tue, 24 May 1994 10:48:38 -0700
Message-Id: <199405241748.AA01719 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1634 on IPXWAN
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 24 May 94 10:48:53 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1634:
Title: Novell IPX Over Various WAN Media (IPXWAN)
Author: M. Allen
Mailbox: mallen at novell.com
Pages: 23
Characters: 55,347
Obsoletes: 1551, 1362
This document describes how Novell IPX operates over various WAN
media. Specifically, it describes the common "IPX WAN" protocol
Novell uses to exchange necessary router to router information prior
to exchanging standard IPX routing information and traffic over WAN
datalinks. This document supercedes RFC 1362 and RFC 1551. The
changes from RFC 1551 are to correct a problem in the wording when an
RFC 1362 router talks to an RFC 1551 router and to allow numbers to be
specified in a Router Name.
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-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940524104648.RFC at ISI.EDU>
SEND /rfc/rfc1634.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1634.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940524104648.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12522;
24 May 94 15:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19342;
24 May 94 15:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12510;
24 May 94 15:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12458;
24 May 94 15:40 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <IESG-Secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: UPS MIB (upsmib) to Conclude
Date: Tue, 24 May 1994 15:40:49 -0400
X-Orig-Sender: jstewart at IETF.CNRI.Reston.VA.US
Message-ID: <9405241540.aa12458 at IETF.CNRI.Reston.VA.US>
With the publication of "UPS Management Information Base" (RFC
1628), the Uninterruptible Power Supply Working Group of the IETF
has concluded. The mailing list will remain active as a forum
for implementors. The IESG contact person is Marshall T. Rose.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12993;
24 May 94 16:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12977;
24 May 94 16:07 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa26804;
24 May 94 16:07 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <PAA29037 at pad-thai.aktis.com>; Tue, 24 May 1994 15:41:33 -0400
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA13118; Tue, 24 May 94 15:40:36 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id MAA01949; Tue, 24 May 1994 12:36:47 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA22856; Tue, 24 May 94 12:34:25 -0700
Date: Tue, 24 May 94 12:34:25 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405241934.AA22856 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: "John Wray, Digital DPE,\
(508) 486-5210 20-May-1994 1205" <wray at tuxedo.enet.dec.com>
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
Cc: cat-ietf at mit.edu, gssapi at ocsg.com
Reply-To: dpg at ocsg.com
> >> The only reasons I could see for wanting a context to time-out
> >> would be:
> >>
> >> i) If you feel that the context's session key has been used
> >> for too long. At this point, you should either
> >> re-authenticate to get a new session key from Kerberos,
> >> or roll-over to a new session key, chained from the
> >> current one. Neither of these options is supported by the
> >> current GSSAPI definition (except by tearing down the
> >> context, and establishing a new one).
> >>
> >> or ii) You want to make sure that the client or server's
> >> long-term keys haven't been revoked by the KDC.
> >
> >
> >or iii, to enforce the realm's security policy.
>
> How does GSSAPI find out what the realm's security policy
> is? I've been assuming that we're talking about the case
> where the client askes for an infinite lifetime context -
> There's no dispute that, for cases where the client asks
> for a shorter lifetime, then GSSAPI should honor that
> requested lifetime.
>
The realm's security policy (expiration policy) can be determined by
looking at a credential (if applicable), expiration definitions found
in krb5/config.h, and the peer's context expiration time (if
exchanged).
> >From a security perspective, an infinite key lifetime should be
> >avoided. The longer an application uses the same key the more
> >susceptible it is to compromise.
>
> I agree that you don't want to use a session key forever.
> But what's a good expiration time for GSSAPI to pick
> (assuming the client hasn't specified one)?
>
The KDC subjects Kerberos tickets to a local, site, and realm
expiration policy. The KDC function process_tgs_req() returns tickets
against the expirations times requested and "server.max_life" and
"max_life_for_realm". I found other "policy" code but those
functions were empty.
I suggest the GSS-API expiration time be chosen as the minimum from
the user provided time, the ticket's "end" time, defaults found in
krb5/config.h, and the expiration time provided by the peer. In the
case of renewable tickets, a ticket's expiration time should be the
maximum of its end and renew times.
> >Telnet and FTP are two examples where context expiration is
> >desirable.
>
> I'd have thought that these applications are examples of
> ones where you _don't_ want GSSAPI to enforce context
> expiration. If I use secure telnet to connect to a remote
> host, I'd be very unhappy if GSSAPI were to unilaterally
> tear down my conection, just because I happened to have
> only a few minutes of time left on my TGT at the time I opened
> my connection.
>
I agree having the context expire is inconvenient, yet someone chose
the expiration policy. What you are saying is you don't want to
adhere to their policy.
The application could check the context's time and warn the user at
some fixed period before the context expires.
> Maybe I'm misunderstanding the requirement here. Are
> you asking for an enforced context timeout, calculated
> by GSSAPI, or are you asking just for somewhere in the
> protocol for a GSSAPI implementation to put a context
> expiration time, to support the case where there's some
> additional security policy in place at one end?
>
I am asking for three things. First, to discuss the issue of
enforcing expirations. From a security perspective there is good
reason to enforce a expiration policy. Second, returning a
reasonable approximation of context expiration to the GSS-API
programmer. Last, discuss renewable tickets and their applicability.
It seems reasonable the GSS Kerberos mechanism should adhere to the
Kerberos karma.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13999;
24 May 94 17:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13991;
24 May 94 17:17 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa18448;
24 May 94 17:17 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <QAA00570 at pad-thai.aktis.com>; Tue, 24 May 1994 16:44:43 -0400
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA17834; Tue, 24 May 94 16:43:39 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA18761; Tue, 24 May 94 13:33:34 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA08894; Tue, 24 May 94 16:33:12 -0400
Message-Id: <9405242033.AA08894 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Tue, 24 May 94 16:33:12 EDT
Date: Tue, 24 May 94 16:33:12 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 24-May-1994 1544" <wray at tuxedo.enet.dec.com>
To: dpg at ocsg.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, dpg at ocsg.com
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
>I agree having the context expire is inconvenient, yet someone chose
>the expiration policy. What you are saying is you don't want to
>adhere to their policy.
The policies to which you refer apply to Kerberos tickets. I certainly believe
that GSSAPI should honor this policy, as indeed it does, by relying on Kerberos
to refuse to honor expired tickets. This ticket lifetime should be reflected
in the GSSAPI-reported credential lifetime for INIT-type (ticket-based)
credentials. What I don't see is any reason to expect the same lifetime to
apply to GSSAPI contexts. Kerberos itself doesn't use ticket lifetimes as an
upper bound on session lifetimes.
>I am asking for three things. First, to discuss the issue of
>enforcing expirations. From a security perspective there is good
>reason to enforce a expiration policy. Second, returning a
>reasonable approximation of context expiration to the GSS-API
>programmer. Last, discuss renewable tickets and their applicability.
>It seems reasonable the GSS Kerberos mechanism should adhere to the
>Kerberos karma.
But Kerberos doesn't expire its sessions at all, so to be most Kerberos-like,
GSSAPI contexts would have infinite lifetime. The Kerberos messaging
primitives (krb_mk_safe & krb_mk_priv) just take a keyblock; the application
can continue to use a given session key for as long as it wishes.
I'm open to providing a way for context expiration times to be (optionally?)
conveyed between the peers, and enforced by GSSAPI when they're present, to
allow individual GSSAPI implementations to honor site-specific policies for
context expiration. This would enable a GSSAPI implementation that had some
site-specific policy to at least warn the peer application that the context has
a limited life. There is a minor problem with actually finding somewhere in
the protocol to place this information (at least in the direction
acceptor->initiator, as there's nowhere obvious for it to go in a KRB_AP_REP
message), but that's a detail.
What I don't see is any reason to impose on all implementations a particular
policy for context expiration. In general, I don't believe that GSSAPI should
be in the business of inventing security policy. Bounding the context lifetime
by ticket lifetime is certainly a possible policy, but I've not seen a
convincing argument for it's universal applicability.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15215;
24 May 94 18:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15207;
24 May 94 18:53 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa18197;
24 May 94 18:53 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <SAA02695 at pad-thai.aktis.com>; Tue, 24 May 1994 18:35:36 -0400
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA25549; Tue, 24 May 94 18:34:45 EDT
Received: from dun-dun-noodles.aktis.com by pad-thai.aktis.com (8.6.8/) with SMTP
id <SAA02688 at pad-thai.aktis.com>; Tue, 24 May 1994 18:35:25 -0400
Received: by dun-dun-noodles.aktis.com (4.1/4.7) id AA04263; Tue, 24 May 94 18:35:17 EDT
Message-Id: <9405242235.AA04263 at dun-dun-noodles.aktis.com>
To: "John Wray, Digital DPE,\
(508) 486-5210 24-May-1994 1544" <wray at tuxedo.enet.dec.com>
Cc: dpg at ocsg.com, cat-ietf at mit.edu
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
In-Reply-To: Your message of "Tue, 24 May 1994 16:33:12 EDT."
<9405242033.AA08894 at us1rmc.bb.dec.com>
Date: Tue, 24 May 1994 18:35:15 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Marc Horowitz <marc at cam.ov.com>
>> But Kerberos doesn't expire its sessions at all, so to be most
>> Kerberos-like, GSSAPI contexts would have infinite lifetime. The
>> Kerberos messaging primitives (krb_mk_safe & krb_mk_priv) just take a
>> keyblock; the application can continue to use a given session key for
>> as long as it wishes.
(Naming point: krb5 uses credential where gssapi uses context. This
should be fun :-)
Kerberos may not use context expiration times, but the concept is
there. In particular, the krb5_creds structure has an element times,
which contains an endtime, among other things. In fact, one might
consider it a bug that {mk,rd}_{priv,safe} ignore this.
Marc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15447;
24 May 94 19:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15439;
24 May 94 19:21 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa26773;
24 May 94 19:21 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <TAA03252 at pad-thai.aktis.com>; Tue, 24 May 1994 19:05:25 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA26964; Tue, 24 May 94 19:04:42 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA02655; Tue, 24 May 94 19:04:32 EDT
Date: Tue, 24 May 94 19:04:32 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9405242304.AA02655 at tsx-11.MIT.EDU>
To: Marc Horowitz <marc at cam.ov.com>
Cc: "John Wray, Digital DPE, 486-5210 24-May-1994 1544" <wray at tuxedo.enet.dec.com>,
dpg at ocsg.com, cat-ietf at mit.edu
In-Reply-To: Marc Horowitz's message of Tue, 24 May 1994 18:35:15 -0400,
<9405242235.AA04263 at dun-dun-noodles.aktis.com>
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Tue, 24 May 1994 18:35:15 -0400
From: Marc Horowitz <marc at cam.ov.com>
>> But Kerberos doesn't expire its sessions at all, so to be most
>> Kerberos-like, GSSAPI contexts would have infinite lifetime. The
>> Kerberos messaging primitives (krb_mk_safe & krb_mk_priv) just take a
>> keyblock; the application can continue to use a given session key for
>> as long as it wishes.
(Naming point: krb5 uses credential where gssapi uses context. This
should be fun :-)
Kerberos may not use context expiration times, but the concept is
there. In particular, the krb5_creds structure has an element times,
which contains an endtime, among other things. In fact, one might
consider it a bug that {mk,rd}_{priv,safe} ignore this.
The endtime is the endtime of the ticket, not necessarily of the
context. Whether or not the concept is there depends on whether or not
you are deteremined to attach any meaning to the lifetime of the ticket
with respect to the lifetime of the context.
Note that {mk,rd}_{priv,safe} don't even take a krb5_creds structure;
they just take a krb5_keyblock....
- Ted
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03952;
25 May 94 11:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07798;
25 May 94 11:21 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03909;
25 May 94 11:21 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03611;
25 May 94 11:08 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-clark-dns-support-00.txt
Date: Wed, 25 May 94 11:08:56 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405251108.aa03611 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Using DNS to Support Multiprotocol Interoperability
Author(s) : R. Clark, M. Ammar, K. Calvert
Filename : draft-clark-dns-support-00.txt
Pages : 18
Date : 05/24/1994
Multiprotocol systems are a vital tool for achieving interoperability in
today's heterogeneous communication networks. An important aspect of these
systems is the need to determine which of the multiple available protocols
will be used to carry out a given communication task; an uninformed choice
can result in failure to communicate when communication should be possible.
In this document we consider ways to make information about hosts'
supported protocol configurations available through the Domain Name System.
We discuss various representation approaches, and describe their use with
multiprotocol applications. We present the use of our approach with an
example multiprotocol system incorporating IPng protocols.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-clark-dns-support-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-clark-dns-support-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940525110800.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-clark-dns-support-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-clark-dns-support-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940525110800.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03982;
25 May 94 11:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03954;
25 May 94 11:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07799;
25 May 94 11:21 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03910;
25 May 94 11:21 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03569;
25 May 94 11:06 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at merit.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pppext-hdlc-fs-02.txt
Date: Wed, 25 May 94 11:06:46 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405251106.aa03569 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Note: This revision reflects comments received during the last call period.
Title : PPP in HDLC-like Framing
Author(s) : W. Simpson
Filename : draft-ietf-pppext-hdlc-fs-02.txt
Pages : 25
Date : 05/24/1994
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC-like framing for
PPP encapsulated packets.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-hdlc-fs-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pppext-hdlc-fs-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940524141125.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pppext-hdlc-fs-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-hdlc-fs-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940524141125.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06738;
25 May 94 14:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12246;
25 May 94 14:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06724;
25 May 94 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06594;
25 May 94 14:10 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12125;
25 May 94 14:10 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16)
id <AA24474>; Wed, 25 May 1994 11:10:01 -0700
Message-Id: <199405251810.AA24474 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI24, RFC1635 on How To FTP
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 25 May 94 11:10:00 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Jon Postel <postel at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
FYI 24:
RFC 1635:
Title: How to Use Anonymous FTP
Author: P. Deutsch, A. Emtage & A. Marine
Mailbox: peterd at bunyip.com, bajan at bunyip.com,
amarine at atlas.arc.nasa.gov
Pages: 13
Characters: 27,258
Update/Obsoletes: none
This document provides information for the novice Internet user about
using the File Transfer Protocol (FTP). It explains what FTP is, what
anonymous FTP is, and what an anonymous FTP archive site is. It shows
a sample anonymous FTP session. It also discusses common ways files
are packaged for efficient storage and transmission. This document is
the product of the Internet Anonymous FTP Archives Working Group of
the IETF.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <940524153138.RFC at ISI.EDU>
SEND /rfc/rfc1635.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1635.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <940524153138.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07627;
25 May 94 14:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12942;
25 May 94 14:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07600;
25 May 94 14:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07521;
25 May 94 14:40 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <IESG-Secretary at CNRI.Reston.VA.US>
Subject: WG ACTION: Internet Anonymous FTP Archives (iafa) to Concluded
Date: Wed, 25 May 1994 14:40:51 -0400
X-Orig-Sender: jstewart at IETF.CNRI.Reston.VA.US
Message-ID: <9405251440.aa07521 at IETF.CNRI.Reston.VA.US>
With the publication of "How to Use Anonymous FTP" (FYI 24/
RFC 1635), the Internet Anonymous FTP Archives Working Group
of the IETF has concluded. Responsibility for the group's
Internet-Draft "draft-ietf-iafa-publishing-01.txt" has been
moved to the Integration of Internet Information Resources
Working Group.
The IESG contact persons are Joyce K. Reynolds, Erik Huizer,
and John Klensin.
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10562;
25 May 94 17:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10554;
25 May 94 17:43 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa16720;
25 May 94 17:44 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <RAA24603 at pad-thai.aktis.com>; Wed, 25 May 1994 17:25:18 -0400
Received: from TSX-11.MIT.EDU by MIT.EDU with SMTP
id AA29537; Wed, 25 May 94 17:24:35 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA19606; Wed, 25 May 94 17:24:30 EDT
Date: Wed, 25 May 94 17:24:30 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at mit.edu>
Message-Id: <9405252124.AA19606 at tsx-11.MIT.EDU>
To: cat-ietf at mit.edu
Subject: The Kerberos V5 mechanism OID....
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
After talking to John Linn, and exchanging mail with Cliff, it appears
that I made a mistake --- I didn't realize that the version 0 of the
Kerberos V5 mechanism draft already defined an OID for the V5 mechanism;
it used the OID specified in the Krb5 RFC.
Now, there are some reasons why it might be better not to use that OID.
For example, the RFC states that it should be used for when an OSI
client and OSI server authenticate using Kerberos V5, and its suggestion
of what the packet format will be isn't the same as the GSSAPI Krb5
mechanism token format. However, the mechanism 0 draft does specify
this OID, and changing it would break existing implementations.
At some level, this shouldn't matter, since implementators who create
implementations based on an internet-draft should be prepared to have
the specification change out from under them --- indeed this is true
even at the proposed standard level. Even at the internet-draft level,
however, it is somewhat desireable not to make changes unless it is
really necessary.
After conferring with John Linn, we've come up with the following
proposed solution. And that is to continue using the existing OID for
the Kerberos V5 mechanism, until the mechanism specification goes to
proposed standard status. At that point, the mechanism OID will be
changed to be the one under the MIT arc, which I had announced last
week.
Presumably, there will be continuing changes to the Krb5 GSSAPI
mechanism, as various matters get debated on this list. Some of these
changes may involve protocol incompatible changes with the version 0
internet draft. Changing the mechanism OID at the point when we advance
the document to proposed standard will allow implementations to know
whether they are talking to a older internet draft version of the
protocol, or whether they are guaranteed to be talking to the proposed
standard RFC version of the mechanism.
Normally, I wouldn't worry so much about this point; but given that
there are several different implementations, some of which are either in
or will soon be released as products, I think we do need to be careful
about how we handle changes to the mechanism spec. We should definitely
not allow the fact that some implementations have already been released
in product stop us from making necessary changes to improve the
specification. Changing the OID when we go to Proposed Standard seems
to be an elegant way of addressing these concerns.
What do people think?
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11057;
25 May 94 18:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11049;
25 May 94 18:42 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa17840;
25 May 94 18:42 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <SAA25712 at pad-thai.aktis.com>; Wed, 25 May 1994 18:26:01 -0400
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA03739; Wed, 25 May 94 18:25:04 EDT
Received: from us1rmc.bb.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA05508; Wed, 25 May 94 15:17:21 -0700
Received: from tuxedo.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
id AA09871; Wed, 25 May 94 18:16:55 -0400
Message-Id: <9405252216.AA09871 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Wed, 25 May 94 18:16:57 EDT
Date: Wed, 25 May 94 18:16:57 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 25-May-1994 1739" <wray at tuxedo.enet.dec.com>
To: tytso at mit.edu
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, tytso at mit.edu
Subject: RE: The Kerberos V5 mechanism OID....
Ted,
>Presumably, there will be continuing changes to the Krb5 GSSAPI
>mechanism, as various matters get debated on this list. Some of these
>changes may involve protocol incompatible changes with the version 0
>internet draft. Changing the mechanism OID at the point when we advance
>the document to proposed standard will allow implementations to know
>whether they are talking to a older internet draft version of the
>protocol, or whether they are guaranteed to be talking to the proposed
>standard RFC version of the mechanism.
>
>Normally, I wouldn't worry so much about this point; but given that
>there are several different implementations, some of which are either in
>or will soon be released as products, I think we do need to be careful
>about how we handle changes to the mechanism spec. We should definitely
>not allow the fact that some implementations have already been released
>in product stop us from making necessary changes to improve the
>specification. Changing the OID when we go to Proposed Standard seems
>to be an elegant way of addressing these concerns.
This makes a lot of sense, although by itself, using different OIDs will only
solve I-D client -> Proposed Standard RFC interoperability, and only then if
the I-D protocol is also documented in the proposed standard. That's a lot
better than nothing, though. Or are you recommending treating the I-D and
future proposed standard protocols as two completely separate mechanisms, which
the application would have to explicitly choose between?
Actually, since the first context set-up message of the I-D protocol has space
for expansion built into it (in the Kerberos application-checksum field, which
GSSAPI hi-jacks to use for its own use), it would be possible to write an I-D
implementation today that would interoperate in both directions with a
yet-to-be-defined RFC protocol, provided we constrain any changes to that first
message to stay within the "for future use" field. That way, an I-D client
would tell an RFC server to use the I-D protocol (via its use of the old-style
OID in the first message), while an RFC client would realize that it was
talking to an I-D server by virtue of the old OID that came back in the
mutual-response token (assuming that mutual authentication is being done, and
lots of other things don't work very well if you're only doing one-way
authentication).
To achieve this, we'd have to do the following:
i) I-D implementations would have to accept initial authentication tokens with
either the I-D OID or the RFC OID (treating them both as I-D protocol tokens).
ii) Any changes to the initial token would have to be done as extra subfields,
placed in the "for future use" section of the application checksum field (which
GSSAPI currently uses for channel bindings and context flags). The I-D says
that an implementation should ignore any data that appears after the 24 bytes
that are defined in the I-D.
iii) If an RFC implementation receives a context-setup token tagged with the
I-D OID, then it should restrict itself to using the I-D protocol (and should
assume that any information it may have sent in a context-setup token after the
first 24 bytes was ignored by its peer).
If we were to try to do this, then those of us who have products implementing
the I-D protocol could issue updates to our customers, to provide latent
support for a future proposed standard protocol - i.e. do step (i). Then, when
RFC-protocol implementations are released, they'd transparently interoperate
with I-D implementations.
John
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02961;
26 May 94 9:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05548;
26 May 94 9:10 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02870;
26 May 94 9:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02534;
26 May 94 8:55 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call2: PPP in HDLC-like Framing to Standard
Date: Thu, 26 May 1994 08:55:07 -0400
X-Orig-Sender: jstewart at IETF.CNRI.Reston.VA.US
Message-ID: <9405260855.aa02534 at IETF.CNRI.Reston.VA.US>
Note: This is the second Last Call for this document. The new
version of the Internet-Draft reflects minor changes made as a
result of comments received during the Last Call period. Another
Last Call is being initiated because the document is up for the
status of Internet Standard.
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "PPP in HDLC-like Framing"
<draft-ietf-pppext-hdlc-fs-02.txt> for the status of Standard.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any comments
to the iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing
lists by 9 June 1994.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02981;
26 May 94 9:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05547;
26 May 94 9:10 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02869;
26 May 94 9:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02547;
26 May 94 8:56 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-ppp at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call2: The Point-to-Point Protocol (PPP) to Standard
Date: Thu, 26 May 1994 08:56:08 -0400
X-Orig-Sender: jstewart at IETF.CNRI.Reston.VA.US
Message-ID: <9405260856.aa02547 at IETF.CNRI.Reston.VA.US>
Note: This is the second Last Call for this document. The new
version of the Internet-Draft reflects minor changes made as a
result of comments received during the Last Call period. Another
Last Call is being initiated because the document is up for the
status of Internet Standard.
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "The Point-to-Point Protocol
(PPP)" <draft-ietf-pppext-lcp-fs-02.txt> for the status of Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
9 June 1994.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06105;
26 May 94 11:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08884;
26 May 94 11:40 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06090;
26 May 94 11:40 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05910;
26 May 94 11:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iiir at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-iiir-publishing-01.txt
Date: Thu, 26 May 94 11:33:18 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405261133.aa05910 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Integration of Internet
Information Resources Working Group of the IETF.
Title : Publishing Information on the Internet
with Anonymous FTP
Author(s) : P. Deutsch, A. Emtage
Filename : draft-ietf-iiir-publishing-01.txt
Pages : 28
Date : 05/25/1994
This document specifies a range of information that your site may wish to
make available on your Anonymous FTP Archive to the Internet user
community. Automatic archive indexing tools have been created that can
gather and index this information, thus making it easier for users to find
and access it. It also may be used by the general user community for
extracting information about the archive itself, or about material
contained on the archive.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-iiir-publishing-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-iiir-publishing-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940525105429.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-iiir-publishing-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iiir-publishing-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940525105429.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06984;
26 May 94 12:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06966;
26 May 94 12:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10429;
26 May 94 12:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06929;
26 May 94 12:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab06818;
26 May 94 12:39 EDT
Received: from mwunix.mitre.org by CNRI.Reston.VA.US id aa10337;
26 May 94 12:39 EDT
Return-Path: manette at mitre.org
Received: from ciis.mitre.org (ciis.mitre.org [128.29.53.1]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id MAA02903; Thu, 26 May 1994 12:16:23 -0400
Received: from [128.29.51.105] (chesapeake.mitre.org) by ciis.mitre.org (4.1/SMI-4.1)
id AA16334; Thu, 26 May 94 12:26:09 EDT
Message-Id: <9405261626.AA16334 at ciis.mitre.org>
X-Sender: manette at ciis.mitre.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 26 May 1994 12:21:31 +0100
To: hayn at cs.odu.edu, hinkle.7 at osu.edu, hlasus at gmu.edu,
hobbes at hobbes.mitre.org, holmes at orionsci.com,
hott-list <@joe.uwex.edu:hott-list at ucsd.edu.hoymand>,
hwylen at access.digex.net, icove at dockmaster.ncsc.mil, idix at seq1.loc.gov,
idix at seq1.loc.gov, ietf at CNRI.Reston.VA.US, ietf at isi.edu,
info <@bucknell.edu:info at educom.edu.iolack>, ira at mitre.org,
irmss910 at svim.si.edu, isoc <@larc.nasa.gov:isoc at isoc.org.j.s.caywood>,
jaleh at literacy.nifl.gov, james at nssdca.nasa.gsfc.gov, jbelt at ars.grir.gov,
jbkerper at central.cis.upenn.edu, jbohlen at class.org, jcarrick at po7.ahcpr.gov,
jeff at gumedlib.dml.georgetown.edu, jeremy at servo.hs.jhu.edu,
jgra at seq1.loc.gov, jgraber at mitre.org, jhagermn at capcon.net,
jjacobs at ncdc.noaa.gov, jkinsfather at ngdc.noaa.gov,
jlmerch at aftprbfe.ncsc.mil, jlycas at lmi.org, jng at ncsa.uiuc.edu,
johns at oxygen.house.gov, jpacheco at traning.hq.nasa.gov,
jrollins at umd5.umd.edu, jsbrown at mitre.org, jso at uunet.uu.net,
jsturgis at gmu.edu, jthomas at mitre.org, jtrimble at mitre.org, jtt at nrc.gov,
jwalker at msmac.prc.hq.nasa.gov, jward at uspto.gov, jwinston at ota.gov,
jwright at nalusda.gov, jzhu at gettysburg.edu, jzidar at nalusda.gov,
kapjscinssi.jacques at epamail.epa.gov, kathy at romana.crystal.pnl.gov,
kbitting at mitre.org, kchaitin at esusda.gov, kcleland at cc.swarthmore.edu,
kerchner at mitre.org, kevin.gamiel at cnidr.org,
kfrazer <@umd5.umd.edu:kfrazer at is.internic.net.khoffman>,
kingsland at nlm.nih.gov, kjohnson at gettysburg.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Manette B. Lazear" <manette at mitre.org>
Subject: SIGNIDR V Preliminary Meeting Announcement
SIGNIDR V Preliminary Meeting Announcement
Special Interest Group on Networked Information, Discovery, and Retrieval
(Previously SIGWAIS, Special Interest Group on Wide Area Information Server)
-----------------------------------------------------------------------------
The MITRE Corporation will sponsor the next meeting of the Special
Interest Group on Networked Information, Discovery, and Retrieval. General
topics of interest for this group are WAIS, gopher, World Wide Web, and
other information retrieval and discovery technologies. We are planning
for an interesting and exciting meeting. We look forward to seeing you
there.
This meeting will focus in on three areas: 1. security including firewall
issues, 2. electronic publishing and copyright issues, and 3. knowbots and
other information discovery technologies. IF YOU WOULD BE INTERESTED IN
MAKING A PRESENTATION IN ANY OF THESE AREAS, PLEASE INDICATE THIS ON THE
REGISTRATION FORM BELOW AND SEND IT TO US AT "signidr at mitre.org".
Date: Thursday, August 4, 1994
Time: 9:00 AM to 5:00 PM
Place: The MITRE Corporation
7525 Colshire Drive
McLean, VA 22102
Registration:
PLEASE REGISTER EARLY TO ASSURE YOUR ATTENDANCE.
Space is limited to 300 attendees.
Complete registration form below and return by e-mail or fax:
e-mail: signidr at mitre.org
fax: 703/883-1397 (c/o Lorrayne Schaefer)
Fee: None
Demos Welcome:
If you have a demo you would like to share with your colleagues
in our demo area, there is space to indicate this on the registration
form; please let us know. Demo selection will be coordinated based on
space availability and focus of presentation.
Vendors Welcome:
We would like to include vendor information and demos at this meeting.
If you are a vendor and would like to participate please indicate this
in the space provided on the registration form. Selection will be
coordinated based on space availability and focus of presentation.
Access: Free, on-site, parking at MITRE Corporation. Driving directions to
MITRE will appear in a later announcement. Nearest Metro is
West Falls Church (orange line) with approximately an $8 taxi ride
(~7 minute) from Metro to MITRE. Bus #3B marked "Tyson's Corner"
also runs from West Falls Church Metro to the vicinity of MITRE.
The fare is $1 and takes about 15 min. plus a short walk from the
bus stop.
Airport:
MITRE is approximately equi-distant from Washington National Airport
and Washington Dulles Airport. Travel time from the airports to
MITRE is about 25 minutes and taxi cost is approximately $30.00.
Nearby Hotels:
Best Western Tyson's Westpark 2 miles to MITRE
8401 Westpark Drive
McLean, VA 22102
703/734-2800
McLean Hilton at Tyson's Corner 1.5 miles to MITRE
7920 Jones Branch Drive
McLean, VA 22102
703/847-5000
Ritz-Carlton, Tyson's Corner .5 miles to MITRE
1700 Tyson's Blvd
McLean, VA 22102
703/506-4300
Tyson's Corner Ramada 1 mile to MITRE
7801 Leesburg Pike
Falls Church, VA 22043
703/893-1340
Tyson's Corner Marriott 1 mile to MITRE
8028 Leesburg Pike
Vienna, VA 22182
800/228-9290
-------------------------Registration Form----------------------------
SIGNIDR V Registration
Thursday, August 4, 1994
MITRE CORPORATION
McLean, VA
Name:___________________________________________________________________
Title:____________________________________________________________________
Affiliation:_____________________________________________________________
Address:__________________________________________________________________
__________________________________________________________________
E-mail:___________________________________________________________________
Phone:_________________________________FAX:______________________________
Which previous SIGNIDR/SIGWAIS have you attended? (Check all that apply.)
SIGWAIS I (USGS, Reston, VA) _________
SIGWAIS II (Library of Congress, Wash., DC) _________
SIGNIDR III (Nat. Library of Med., Bethesda, MD) _________
SIGNIDR IV (Dept. of Commerce, Wash., DC) _________
Participant Information:
If you wish to participate through a presentation, demonstration, or vendor
display please complete the appropriate information area(s) below. For
demos you must supply all equipment you will need, including workstations
and other hardware, software, etc. Connections to the Internet will be
available.
PRESENTATION Title:_______________________________________________________
Brief Description:_________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
DEMO Name:________________________________________________________________
Demo Description:_________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
VENDOR Name:______________________________________________________________
Description of how you would like to participate:__________________________
____________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
__ __
' ' / \ \__/__)
/ / / / /___/ ___ /
/ / / / / \ / \/
/ /_/ / /_____/ \___/\
\__Manette\__/ B. Lazear__
Digital Libraries Technologies
MITRE, 7525 Colshire Dr., McLean, VA 22102
Phone: 703/883-6728 FAX:703/883-3315
(manette at mitre.org) MITRE Mail Stop: Z160
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07007;
26 May 94 12:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06977;
26 May 94 12:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10430;
26 May 94 12:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06931;
26 May 94 12:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06865;
26 May 94 12:41 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10378;
26 May 94 12:40 EDT
Received: from mwunix.mitre.org by venera.isi.edu (5.65c/5.61+local-14)
id <AA29825>; Thu, 26 May 1994 09:39:32 -0700
Return-Path: manette at mitre.org
Received: from ciis.mitre.org (ciis.mitre.org [128.29.53.1]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id MAA03348; Thu, 26 May 1994 12:19:57 -0400
Received: from [128.29.51.105] (chesapeake.mitre.org) by ciis.mitre.org (4.1/SMI-4.1)
id AA16409; Thu, 26 May 94 12:29:42 EDT
Message-Id: <9405261629.AA16409 at ciis.mitre.org>
X-Sender: manette at ciis.mitre.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 26 May 1994 12:25:05 +0100
To: hayn at cs.odu.edu, hinkle.7 at osu.edu, hlasus at gmu.edu,
hobbes at hobbes.mitre.org, holmes at orionsci.com,
hott-list <@joe.uwex.edu:hott-list at ucsd.edu.hoymand>,
hwylen at access.digex.net, icove at dockmaster.ncsc.mil, idix at seq1.loc.gov,
idix at seq1.loc.gov, ietf at CNRI.Reston.VA.US, ietf at isi.edu,
info <@bucknell.edu:info at educom.edu.iolack>, ira at mitre.org,
irmss910 at svim.si.edu, isoc <@larc.nasa.gov:isoc at isoc.org.j.s.caywood>,
jaleh at literacy.nifl.gov, james at nssdca.nasa.gsfc.gov, jbelt at ars.grir.gov,
jbkerper at central.cis.upenn.edu, jbohlen at class.org, jcarrick at po7.ahcpr.gov,
jeff at gumedlib.dml.georgetown.edu, jeremy at servo.hs.jhu.edu,
jgra at seq1.loc.gov, jgraber at mitre.org, jhagermn at capcon.net,
jjacobs at ncdc.noaa.gov, jkinsfather at ngdc.noaa.gov,
jlmerch at aftprbfe.ncsc.mil, jlycas at lmi.org, jng at ncsa.uiuc.edu,
johns at oxygen.house.gov, jpacheco at traning.hq.nasa.gov,
jrollins at umd5.umd.edu, jsbrown at mitre.org, jso at uunet.uu.net,
jsturgis at gmu.edu, jthomas at mitre.org, jtrimble at mitre.org, jtt at nrc.gov,
jwalker at msmac.prc.hq.nasa.gov, jward at uspto.gov, jwinston at ota.gov,
jwright at nalusda.gov, jzhu at gettysburg.edu, jzidar at nalusda.gov,
kapjscinssi.jacques at epamail.epa.gov, kathy at romana.crystal.pnl.gov,
kbitting at mitre.org, kchaitin at esusda.gov, kcleland at cc.swarthmore.edu,
kerchner at mitre.org, kevin.gamiel at cnidr.org,
kfrazer <@umd5.umd.edu:kfrazer at is.internic.net.khoffman>,
kingsland at nlm.nih.gov, kjohnson at gettysburg.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Manette B. Lazear" <manette at mitre.org>
Subject: SIGNIDR V Preliminary Meeting Announcement
SIGNIDR V Preliminary Meeting Announcement
Special Interest Group on Networked Information, Discovery, and Retrieval
(Previously SIGWAIS, Special Interest Group on Wide Area Information Server)
-----------------------------------------------------------------------------
The MITRE Corporation will sponsor the next meeting of the Special
Interest Group on Networked Information, Discovery, and Retrieval. General
topics of interest for this group are WAIS, gopher, World Wide Web, and
other information retrieval and discovery technologies. We are planning
for an interesting and exciting meeting. We look forward to seeing you
there.
This meeting will focus in on three areas: 1. security including firewall
issues, 2. electronic publishing and copyright issues, and 3. knowbots and
other information discovery technologies. IF YOU WOULD BE INTERESTED IN
MAKING A PRESENTATION IN ANY OF THESE AREAS, PLEASE INDICATE THIS ON THE
REGISTRATION FORM BELOW AND SEND IT TO US AT "signidr at mitre.org".
Date: Thursday, August 4, 1994
Time: 9:00 AM to 5:00 PM
Place: The MITRE Corporation
7525 Colshire Drive
McLean, VA 22102
Registration:
PLEASE REGISTER EARLY TO ASSURE YOUR ATTENDANCE.
Space is limited to 300 attendees.
Complete registration form below and return by e-mail or fax:
e-mail: signidr at mitre.org
fax: 703/883-1397 (c/o Lorrayne Schaefer)
Fee: None
Demos Welcome:
If you have a demo you would like to share with your colleagues
in our demo area, there is space to indicate this on the registration
form; please let us know. Demo selection will be coordinated based on
space availability and focus of presentation.
Vendors Welcome:
We would like to include vendor information and demos at this meeting.
If you are a vendor and would like to participate please indicate this
in the space provided on the registration form. Selection will be
coordinated based on space availability and focus of presentation.
Access: Free, on-site, parking at MITRE Corporation. Driving directions to
MITRE will appear in a later announcement. Nearest Metro is
West Falls Church (orange line) with approximately an $8 taxi ride
(~7 minute) from Metro to MITRE. Bus #3B marked "Tyson's Corner"
also runs from West Falls Church Metro to the vicinity of MITRE.
The fare is $1 and takes about 15 min. plus a short walk from the
bus stop.
Airport:
MITRE is approximately equi-distant from Washington National Airport
and Washington Dulles Airport. Travel time from the airports to
MITRE is about 25 minutes and taxi cost is approximately $30.00.
Nearby Hotels:
Best Western Tyson's Westpark 2 miles to MITRE
8401 Westpark Drive
McLean, VA 22102
703/734-2800
McLean Hilton at Tyson's Corner 1.5 miles to MITRE
7920 Jones Branch Drive
McLean, VA 22102
703/847-5000
Ritz-Carlton, Tyson's Corner .5 miles to MITRE
1700 Tyson's Blvd
McLean, VA 22102
703/506-4300
Tyson's Corner Ramada 1 mile to MITRE
7801 Leesburg Pike
Falls Church, VA 22043
703/893-1340
Tyson's Corner Marriott 1 mile to MITRE
8028 Leesburg Pike
Vienna, VA 22182
800/228-9290
-------------------------Registration Form----------------------------
SIGNIDR V Registration
Thursday, August 4, 1994
MITRE CORPORATION
McLean, VA
Name:___________________________________________________________________
Title:____________________________________________________________________
Affiliation:_____________________________________________________________
Address:__________________________________________________________________
__________________________________________________________________
E-mail:___________________________________________________________________
Phone:_________________________________FAX:______________________________
Which previous SIGNIDR/SIGWAIS have you attended? (Check all that apply.)
SIGWAIS I (USGS, Reston, VA) _________
SIGWAIS II (Library of Congress, Wash., DC) _________
SIGNIDR III (Nat. Library of Med., Bethesda, MD) _________
SIGNIDR IV (Dept. of Commerce, Wash., DC) _________
Participant Information:
If you wish to participate through a presentation, demonstration, or vendor
display please complete the appropriate information area(s) below. For
demos you must supply all equipment you will need, including workstations
and other hardware, software, etc. Connections to the Internet will be
available.
PRESENTATION Title:_______________________________________________________
Brief Description:_________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
DEMO Name:________________________________________________________________
Demo Description:_________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
VENDOR Name:______________________________________________________________
Description of how you would like to participate:__________________________
____________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
__ __
' ' / \ \__/__)
/ / / / /___/ ___ /
/ / / / / \ / \/
/ /_/ / /_____/ \___/\
\__Manette\__/ B. Lazear__
Digital Libraries Technologies
MITRE, 7525 Colshire Dr., McLean, VA 22102
Phone: 703/883-6728 FAX:703/883-3315
(manette at mitre.org) MITRE Mail Stop: Z160
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14880;
26 May 94 20:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25427;
26 May 94 20:35 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14855;
26 May 94 20:35 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14719;
26 May 94 20:32 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: iiir at merit.edu
Cc: Internet Engineering Steering Group <iesg at CNRI.Reston.VA.US>
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: WAIS over Z39.50-1988 to Informational
Date: Thu, 26 May 1994 20:32:08 -0400
X-Orig-Sender: jstewart at IETF.CNRI.Reston.VA.US
Message-ID: <9405262032.aa14719 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet-Draft "WAIS over Z39.50-1988"
<draft-ietf-iiir-wais-00.txt> and recommends that it be published
by the RFC Editor as an Informational RFC. This document is the
product of the Integration of Internet Information Resources
Working Group. The IESG contact person is Joyce K. Reynolds.
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15111;
26 May 94 20:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25695;
26 May 94 20:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15097;
26 May 94 20:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15057;
26 May 94 20:51 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
cc: poised at tis.com
Subject: WG ACTION: Process for Organization of Internet Standards (poised)
Date: Thu, 26 May 1994 20:51:13 -0400
X-Orig-Sender: jstewart at IETF.CNRI.Reston.VA.US
Message-ID: <9405262051.aa15057 at IETF.CNRI.Reston.VA.US>
The Process for Organization of Internet Standards Working Group
of the IETF has been re-activated. For more information, please
contact the working group's chair or the area director.
IESG Secretary
Process for Organization of Internet Standards (poised)
-------------------------------------------------------
Charter
Chair(s):
Steve Crocker <crocker at tis.com>
None Director(s)
Paul Mockapetris <pvm at isi.edu>
Mailing lists:
General Discussion:poised at tis.com
To Subscribe: poised-request at tis.com
Archive: ietf.cnri.reston.va.us:~/ietf-mail-archive/poised/*
Description of Working Group:
In 1992 and 1993, the POISED effort revised the responsibilities of
the IESG and IAB and instituted a selection process for filling
positions on these bodies. The ISOC Trustees gave interim approval
to these arrangements and asked that we revisit, revise and formalize
the arrangements after two rounds of selection had been completed.
The POISED Working Group will now review the current rules, propose
charters and rules for the IESG, IETF, IAB, IRSG, and IRTF, and submit
them to the ISOC Trustees after approval by the IETF.
There appears to be general consensus that the current assignments of
responsibility and the selection process are working moderately well,
so it is not anticipated that there will be large changes.
Nonetheless, some issues have been raised and need review. Among
these are:
o There is a complex interplay between the IETF area structure and the
selection process for the IESG. The IESG has the power to create,
split, merge and remove areas, but the nominations committee has the
responsibility to fill positions. The IESG needs some flexibility
to balance work loads, use its people effectively, and meet the
changing needs of the IETF. The current rules are not completely
clear as to how to handle all of the likely situations; these need to
be spelled out and agreed to.
o The nominations committee has non-voting liaisons from the IESG and
IAB. Both nominations committees also had current IAB or IESG
members, who volunteered and were selected at random, as voting
members. It has been suggested that current IESG and IAB members
carry too much weight in the deliberations and should be barred from
serving on the nominations committee.
o The selection and role of the nominations committee chair is somewhat
unclear. In particular, what power does the chair have to deal with
unresponsive committee members and/or to resolve disputes?
o At what point, if any, does the nominations committee's list of
candidates become public. This ties in with the apparent double-
standard of how publically incumbents vs. non-incumbents announce
their candidacy.
o The way to handle interim appointments is not clear. Two specific
issues are: who appoints interim members (and is ``ratification''
required), and how long does interim appointees serve?
o When the nominations committee has completed its work, it informs the
IAB and the ISOC Trustees. The procedures for doing so need to be
spelled out. At issue is when the nominations become public, whether
the community at large is invited to comment, and what to do if there
is difficulty in filling any of the positions.
o There is currently no specific mechanism for the IAB to use to
provide architectural guidance to working groups before the RFC
submission stage. POISED may discuss whether such a mechanism is
necessary, and if so, what that mechanism looks like.
o The role of the IRTF and research groups has not yet been defined.
o Should there be a regular mechanism for convening a POISED Working
Group in the future?
o The ISOC Trustees require that the procedures adopted meet with the
approval of counsel and the insurance carriers in order to protect
the Society from exposure. The procedures, rules, etc. adopted by
the community will most likely be satisfactory to counsel, but input
and review from counsel is essential.
In its deliberations, POISED may produce new documents (e.g., an IETF
Charter -- if the lack of such a charter delays the POISED effort),
and it may request changes to existing documents (e.g., ``The IAB
Charter'' [RFC 1601], ``The Internet Standards Process -- Version 2''
[RFC 1602], and ``IETF Working Group Guidelines and Procedures''
[RFC 1603]).
Goals and Milestones:
Done Produce an Internet-Draft describing the current selection process.
Apr 94 Produce an Internet-Draft summarizing "what's broke".
May 94 Send an e-mail message to the POISED and IETF-Announce mailing lists
giving people a deadline for inputs to the POISED process.
May 94 First drafts of all documents.
Jul 94 Complete set of documents filed in Internet-Drafts directory.
Jul 94 Toronto IETF meeting.
Dec 94 Present final reports, charters, etc. to ISOC Board at its meeting.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08408;
27 May 94 16:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08396;
27 May 94 16:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23160;
27 May 94 16:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08377;
27 May 94 16:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08147;
27 May 94 16:44 EDT
Received: from relay.surfnet.nl by CNRI.Reston.VA.US id aa21790;
27 May 94 16:43 EDT
Received: from erasmus.rare.nl by relay.surfnet.nl with SMTP (PP)
id <25189-0 at relay.surfnet.nl>; Fri, 27 May 1994 18:20:19 +0200
Received: from [192.87.30.3] by erasmus.rare.nl (5.65c/4.31) with SMTP
id AA24322; Fri, 27 May 1994 18:18:26 +0200
Message-Id: <199405271618.AA24322 at erasmus.rare.nl>
X-Sender: kiers at erasmus.rare.nl
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="========================_19562380==_"
Date: Fri, 27 May 1994 18:18:03 +0100
To: inet-jenc at rare.nl, inet-track at rare.nl, inet-authors at rare.nl,
inet-jenc-ex at rare.nl, session at rare.nl, inet-ust at rare.nl, inet-da at rare.nl,
inet-pi at rare.nl, inet-neo at rare.nl, inet-nt at rare.nl, inet-ri at rare.nl,
coa at rare.nl, wg-all at rare.nl, newsletters at rare.nl, ceec at rare.nl,
M2107 at eurokom.ie, tcp-ip at nic.ddn.mil, iepg at nri.reston.va.us,
ietf at nri.reston.va.us, ccirn at lbl.gov, apccir at aarnet.edu.au, ripe at ripe.net,
ifip65-prog at ics.uci.edu, ifip-gtwy at ics.uci.edu, mhsnews at ics.uci.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: kiers at rare.nl
Subject: Final Programme INET'94/JENC5 Prague - version 1 -
--========================_19562380==_
Content-Type: text/plain; charset="us-ascii"
--========================_19562380==_
Content-Type: text/plain; name="PP-final.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="PP-final.txt"
- Version 1 -
(Apologies if you receive this more than once)
FINAL PROGRAMME
- INET'94/JENC5 -
INET'94, the Annual Conference of the Internet Society
held in conjunction with the
5th Joint European Networking Conference (JENC5)
Prague, Czech Republic, June 13-17, 1994
Jointly organized by
The Internet Society (ISOC) and
Reseaux Associes pour la Recherche Europeenne (RARE)
ORGANIZATION:
CONFERENCE Committee
Chair......................Geoff Manning, Independent consultant, UK
Co-ordination & ...........Marieke Dekker, RARE, The Netherlands
Assistance................Elizabeth Barnhart, EDUCOM, USA
Local Organizers...........Jan Gruntorad, CVUT, Czech Republic
...........................Ingrid Ledererova, CVUT, Czech Republic
Internet Society Liaison...Larry Landweber, University of Wisconsin,
...........................USA
RARE Liaison...............Tomaz Kalin, RARE, The Netherlands
Programme Committee Chair..Bernhard Plattner, ETH Zurich, Switzerland
Workshop Liaison...........George Sadowsky, University of New York,
USA
PROGRAMME Committee
Chair......................Bernhard Plattner, ETH Zurich, Switzerland
Co-chair...................Hannes Lubich, SWITCH, Switzerland
Co-ordination & ...........Judith Kiers, RARE, The Netherlands
Assistance
Track Leaders:
T1. User Support and.......Jill Foster, University of Newcastle, UK
....Training...............Joyce Reynolds, ISI, USA
T2. Distributed............Erik Huizer, SURFnet, The Netherlands
....Applications...........Barry Leiner, USRA, USA
T3. Policy Issues..........Michael Roberts, EDUCOM, USA
...........................Jurgen Harms, University of Geneva,
...........................Switzerland
T4. Regional Issues........Richard Mandelbaum, NYSERNet, USA
T5. Network Engineering....Elise Gerich, Merit Network Inc., USA
...........................Peter Elford, Cisco Systems, Australia
T6. Network Technology.....Paul Mockapetris, ISI, USA
...........................Juha Heinanen, FUNET, Finland
CONFERENCE SPONSORS
BT (British Telecommunications plc), Cisco, Digital Equipment
Corporation, IBM, Novell, Sun Microsystems, 3COM
CONFERENCE CONTRIBUTORS
Advantis, Bellcore, Canarie, Canadian Government of Industries,
HP, Interop, Newbridge, Positron, Telekom
CONFERENCE VENUE
Palace of Culture
Trida 5.kvetna
140 09 PRAGUE 4
Czech Republic
Telephone: +42-2-6117-1111
CONFERENCE HALLS:
T1. User Support and Training.......Concert Hall (max. 1000 people)
T2. Distributed Applications........Small Hall (max. 300 people)
T3. Policy Issues...................Club Room I (max. 85 people)
T4. Regional Issues.................Club Room II (max. 85 people)
T5. Network Engineering.............Baletny Hall (max. 100 people)
T6. Network Technology..............Chamber Hall (max. 180 people)
Plenary sessions....................Concert Hall (max. 1000 people)
Please note: there are some exceptions.
WEDNESDAY, JUNE 15
09:00-10:30.......Opening Session........................CONCERT HALL
..................Welcome & Keynote Addresses by:
......- Mr. George Soros, Founder of the Soros Foundations,
........New York, USA
......- Professor Emanuel Ondracek, PhD, Deputy Minister of
........Education, Czech Republic
..................Chair: Geoff Manning, UK
11:00-12:30.......Parallel Sessions
T1-1. Training for the Network Citizen...................CHAMBER HALL
......Chair: Peter Kemp, University of Glasgow, Scotland
- EDUCATE - End-user Courses in Information Access through
Communication Technology / Nancy Fjaellbrant, Sweden
- Approaches to network training with particular reference
to a perceived need for self-help materials /
Margaret Isaacs, UK
- Network training: Anywhere, Anytime, Anyplace? /
Jodi-Ann Chu, USA
T2-1. MultiMedia (first session).........................SMALL HALL
......Chair: Chris Adie, Edinburgh University, UK
- FOCS - A Toolkit for Flexibility Telecommunication Systems /
Jens-Peter Redlich, Germany
- HTML and Mosaic: A taste for more /
Peter Linde, The Netherlands
- Developments in WWW technology / Dave Raggett, UK
T3-1. National and Regional Policies.....................BALETNY HALL
......Chair: Tomaz Kalin, RARE, The Netherlands
- The European Commission RTD networking strategy /
Luis Rodriguez Rosello, DG XIII C/3, EU
- Policy issues from a Pacific perspective /
Geoff Huston, Australia
- USA policy update / Stephen Wolff, USA
- Policies required for the Internet development /
Vinton G. Cerf, USA
T4-1. Networking assists Societal Stability..............CLUB ROOM II
......Chair: Steve Goldstein, National Science
.............Foundation, USA
- The role of the Internet in distance education:
the Russian experience /
Peter Thomas, USA and Alexei Platonov, Russia
- Marketing the Internet to the industrial R & D sector
in Israel / Dov Winer and Jacob Bar, Israel
T5-1. Routing and Addressing.............................CLUB ROOM I
......Chair: Elise Gerich, Merit Network Inc.,
.............Ann Arbor, Michigan, USA
- Comparison of geographical and provider-rooted
Internet addressing / Paul Francis, Japan
- Authority and routing registration for CLNS networks /
Henk Steenman, The Netherlands and Marcel Wiget, Switzerland
- Rough Cuts - CIDR Deployment / Bill Manning, USA
T6-1. ATM Standardization and Deployment:................CONCERT HALL
......Current Status and Issues ......
Chair: Les Clyne, JNT, UK
This session is a tutorial-type presentation on ATM.
It will discuss the latest technology announcements,
deployment and standardization timeframe projections
and needs from application providers.
Presentation by: Fred Sammartino, President ATM Forum, USA
14:00-15:30.......PLENARY Session........................CONCERT HALL
........Overview: Technical Programs of the IETF and RARE
...........Introduction by:
..................- Vinton G. Cerf, President of ISOC
..................- Kees Neggers, President of RARE
...........Speakers: Paul Mockapetris, IETF & IESG Chair
.....................Erik Huizer, RARE Technical Committee member
...........Chair: Erik Huizer, SURFnet, The Netherlands
16:00-18:00.......Parallel Sessions
T1-2. Network Information: Tools and Access.............CONCERT HALL
......Chair: David Sitman, EARN, France
- Mosaic, WWW and networked Multimedia as a learning tool /
..Michael Greenhalgh, Australia
- Becoming an information provider on the WWW /
..Brian Kelly, UK
- Wild beasts and unapproachable bogs /
..Chris Weider, USA
T2-2. Internet Usage and Dial-up Access.................SMALL HALL
......Chairs: Hariharasubrahmanian Shrikumar,
..............Temporal Systems, India /
..............Archie Marshall, Jamaica
- Connecting the Carribean area /
Archie Marshall, Jamaica
- Thinternet: Life at the end of a tether /
H. Shrikumar, India
- The growth of IP usage at Chrysler /
Robert Moskowitz, USA
- Dial-up in India: Needs, demands and regulation /
T.H. Choudary, India
- Dial-up X.400 is moved forward by the APS Alliance /
David Knight, USA
- SITA: A worldwide X.28 /
Jean Mourain, SITA, France
T3-2. International Coordination of Internet Standards..CLUB ROOM I
......Chair: Lyman Chapin, Bolt Beranek and Newman, USA
A panel discussion of the cluster of issues around
evolution of OSI and IP protocols in the international
policy context.
Panelists: Steven Wolff, National Science Foundation, USA
...........Erik Huizer, SURFnet, The Netherlands
...........Lyman Chapin, Bolt Beranek nad Newman, USA
T4-2. Regional Developments I - Eastern Europe and CIS..CLUB ROOM II
......Chair: Frode Greisen, UNI-C Lyngby, Denmark
- The Romanian national academic network:
The regional node of CLUJ-NAPOCA / Kalman Pusztai,
Vasile Dadarlat and Marius Joldos, Rumania
- Satellite link Moscow-Maribor:
The aims and the prospective /
Slobodanka Vidakovic, Slovenia and Dmitry Demidov, CIS
- Networking for science and education in Byelorussia /
Andrey Ivanov and Sergei Kritsky, CIS
- Coordinating networks in Central and Eastern
Europe: CEENet / Peter Rastl, Austria
- Russian networks and services, general and
subject oriented / Nikolai Repin, CIS
T5-2. Performance Analysis..............................BALETNY HALL
......Chair: Olivier Martin, CERN, Switzerland
- Optimising FTP traffic in the Internet /
K. Jayanthi, G. Mansfield, Y.Kimura, T. Johannsen,
Y. Nemoto and S. Noguchi, Japan
- Internet interaction pinged and mapped /
John S. Quarterman, Smoot Carl-Mitchell and
Gretchen Phillips, USA
- Windowed Ping: An IP layer performance
disgnostic / Matt Mathis, USA
T6-2. Broadband Technology..............................CHAMBER HALL
......Chair: Jaap van Till, Consultancy Group
.............Stratix BV, The Netherlands
- VINCE - A Vendor Independent Network Control
Environment / Allison Mankin and Eric Hoffman, USA
- Sorting out reality from the hype:
Why you should be interested in ATM WANs /
Milo Medin, USA
- Bay area broadband testbeds and technology /
Mark Laubach and Berry Kercheval, USA
20:00-23:00.......Gala Dinner
THURSDAY, JUNE 16
09:00-10:30.......Parallel Sessions
T1-3. Electronic Documents..............................CONCERT HALL
......Chair: Maria Heijne, SURFnet BV, Netherlands
- From Babel to Edil: The evolution of a standard /
Andrew Braid, UK
- Work in Progress:
......- ELDORADOC 'the promised land of gold?' /
........Robert Janz, The Netherlands
......- RED SAge / Czeslaw Jan Grycz , USA
......- Networked delivery of Multimedia resources /
........Jane Williams, UK
......- Discussion
T3-3. European CERT Activities..........................CLUB ROOM I
......Chair: Hannes Lubich, SWITCH, Switzerland
- The DFN-CERT experience: Building up a new CERT
within Europe / Klaus-Peter Kossakowski, Germany
- Current development of CERTs in Europe: A progress
report / Barry Spaul, UK
T4-3. Regional Developments II:.........................CLUB ROOM II
......Pacific Rim and Latin America
......Chair: Richard Mandelbaum, NYSERnet, USA
- Chilean network for primary schools /
Ernesto Laval, Pedro E. Hepp and Enrique
Hinostroza, Chile
- Electronic networking: Social and policy
aspects of a rapidly growing technology /
Daniel Ingvarson, Dora Marinova and Peter Newman,
Australia
- Issues in academic networking in the PRC /
Franklin F. Kuo, Jian Ding, Cindy Zheng and
Farooq Hussain, USA
- An Internet project for 100.000 users in Thailand /
Srisakdi Charmonman and Firouz Anaraki, Thailand
- The Pacific Neighborhood consortium:
A status report / Art St. George, USA
T5-3. Heterogeneous Networks............................BALETNY HALL
......Chair: Toshiya Asaba, Internet Initiative
.............Japan, Inc., Japan
- GeNeRIC: Living multi-protocols for years.
So what? / Manfred Bogen, Germany
- The INFNet distributed gateway system /
C. Allocchio, P. Bonetti and A. Ghiselli, Italy
T6-3. Broadband deployment and experiments..............CHAMBER HALL
......Chair: Mark Laubach, HP Labs, USA
- Overview of US testbeds / Darleen Fisher, and
Mike StJohns, USA
- Implementation of a B-ISDN/ATM connectionless
data service in an Internet environment /
Nail Kavak, Kim Laraqui, Ala Nazari and
Patrick Ernberg, Sweden
- BALI - Integration of inhouse ATM and LANs/WANs:
An ideal base for Multimedia teleservices /
Hermann Hartenthaler, Dirk Hetzer and
Berthold Butscher, Germany
11:00-12:30.......Parallel Sessions
T1-4. Building and Supporting Electronic Communities....BALETNY HALL
......Chair: David Conrad, Asia Pacific Network
.............Information Center, Japan
- Rural datafication: A multiple-network collaboration
to extend the Internet to underserved communities /
E. Michael Staman, John Hankins,
Paul Holbrook and Rhana Jacot, USA
- Building electronic communities: Implementing
electronic communication within the European Law
Students' Association (ELSA ) /
Christian B. Fulda, Switzerland
- The Internet and schools: A survey of networking
activities / Tracy LaQuey Parker, USA
T2-4. Networked Simulation and Virtual Reality..........SMALL HALL
......Chair: Mark Pullen, George Mason University, USA
- Distributed Virtual Simulation / Duncan Miller, USA
- Extending WWW to support Platform Independent
Virtual Reality / Dave Raggett, UK
- Internetting Distributed Virtual Simulation /
Mark Pullen, USA
T3-4. The Economics of Networks and Network Growth......CLUB ROOM I
......Chair: Robert Cohen, Fellow Strategy
.............Institute, USA
- From SWITCH to SWITCH* - extrapolating from a case study /
Jurgen Harms, Switzerland
- Funding an Internet public good: Definitions and example /
Martyne Hallgren, USA
- The changing Internet landscape: A six-year perspective
from NSFNET data Eric Aupperle and Ellen Hoffman, USA
T4-4. Internationalization of Network Applications......CLUB ROOM II
......Chair: Borka Jerman-Blazic, J. Stefan Institute,
.............Ljubljana, Slovenia
- A tool supporting the Internationalisation of the
generic network services / Borka Jerman-Blazic, Slovenia
- Creating an Internet-enhanced directory of Central
and Eastern European environmental libraries /
Czeslaw Jan Grycz, USA
- Writing your own language in X.400 messages /
Harald Alvestrand, Norway
T5-4. Joint Videoconference with EEMA....................CONCERT HALL
......Chair: Jeroen Houttuin, RARE, The Netherlands
Electronic mail has been one of the main applications
of the Internet and international networking in general.
This session will establish a live link between the
participants of the Annual Conference of the European
Electronic Messaging Association (EEMA), to be held
in Stockholm, Sweden, and Internet experts and interested
participants of INET'94/JENC5.
T6-4. Mobility...........................................CHAMBER HALL
......Chair: Charles Perkins, T.J. Watson Research
.............Center IBM, USA
- An ISO IP protocol suite for the integrated road
transport and traffic mobile environment /
Kim Laraqui, Magnus Lengdell, Frank Reichert and
Andreas Fasbender, Sweden
- The Internet mobile host protocol /
Charles E. Perkins, Andrew W. Myles and
David B. Johnson, USA
- IP/Secure: Providing security on datagram
delivery for mobile host environment /
Takeshi Tanida and Yoichi Shinoda, Japan
14:00-15:30.......Parallel Sessions
T1-5. Panel: Power to the User!..........................CHAMBER HALL
.............Enabling users to help themselves
......Chair: Rolf Nordhagen, University of Oslo Information
.............Technology Services, Norway
To provide support for the increasing numbers of users
on the network is a formidable task. This session will
be run as a panel discussion with expert panelists from
around the world sharing their knowledge and experience.
Audience participation is highly encouraged.
Panelists: Robert F. Janz, University of Groningen, The Netherlands
...........David Hartland, NISP/Mailbase, Newcastle University, UK
...........Anders Gillner, NORDUnet, The Royal Institute of
...........................Technology, Sweden
T2-5. MultiMedia (second session)..........................SMALL HALL
......Chair: John Dyer, Joint Network Team (JANET), UK
- Remote seminars through Multimedia conferencing:
Experiences from the MICE project / Martina Angela Sasse,
Ulf Bilting, Claus-Dieter Schulz and Thierry Turletti, Sweden
- Experience with large videoconferences on Xunet II /
S. Keshav, USA
- NTTs strategy for highspeed Multimedia communications /
Akihiro Shimizu and Hisao Uose, Japan
T3-5. Privacy.............................................CLUB ROOM I
......Chair: David Farber, University of
.............Pennsylvania, USA
- Electronic privacy legislation in the USA /
Marc Rotenberg, USA
- Principles of Internet privacy /
Frank Tuerkheimer, USA
T4-5. Regional Developments III:.........................CLUB ROOM II
......Africa and the Middle East
......Chair: Mondher Makni, Tunisia
- A national research and technology network in Tunisia:
A must for innovation and technology transfer /
Mondher Makni, Khaled Sellami, Karima Bounemra
Ben Soltane, Tunisia
- Connectivity and internetworking requirements for Africa /
Tierno S. Bah, USA
T5-5. Quality Assurance..................................BALETNY HALL
......Chair: Manfred Bogen, GMD, St. Augustin, Germany
- Assessing quality from an Internet service provider /
Peter Dawe, UK
- There is no such thing as a free Internet /
Dai Davies, UK
- From network quality to project quality /
Wulf-Dieter Bauerfeld, Germany
T6-5. IPng: State of the art and process.................CONCERT HALL
.....Chair: Allison Mankin, NRL, USA
- Report from the IPng directorate /
Scott Bradner, USA - IPng
- A vendor's perspective / Stev Knowles, USA
- ATM and IPng / Fred Sammartino, USA
16:00-17:30.......PLENARY Session........................CONCERT HALL
........... Panel discussion on 'Industry and the Internet'
..................Chair: Bernhard Plattner, Switzerland
..................Moderator: Tony Rutkowsky, USA
The interest of the industry in the Internet - both as
a resource and as a marketplace - has grown tremendously
in the last few years. The panel will explore issues,
requirements and future developments as seen from
industry leaders
Panelists: Janet M. Perry, ..Manager Higher Education Programs,
.............................Novell
...........Vinton G. Cerf, ..Senior Vice President Data Architecture,
.............................MCI
...........Paul Scherer, ....Director of Technology Development, 3COM
...........Betsy Huber, .....Manager TCP/IP Technology Marketing
.............................Strategy, IBM
...........Tony Peatfield, ..Market Development for Universities and
.............................Research (Europe), CISCO
...........Eric Schmidt, ....Chief Technology Officer, SUN
...........Dave Probert, ....European Business Development Manager,
.............................DEC
...........David Giddings,...Multi-Media & Applications Product
.............................Marketing, National Business
.............................Communications, BT
18:00-19:00.......Cocktail Party
FRIDAY, JUNE 17
09:00-10:30.......Parallel Sessions
T1-6. Issues in building the Virtual Library..............CLUB ROOM I
......Chair: Michael Breaks, Heriot-Watt University
.............Library, UK
- Internet resource guides: Stories for the Net /
Louis B. Rosenfeld, USA
- Commercial services on the Infobahn / George Brett, USA
- Electronic journals: transforming the information cycle? /
Hans Roes, The Netherlands
T2-6. Directory Services..................................SMALL HALL
......Chair: Paul-Andre Pays, INRIA, France
- Strangers in paradise / Bruno Koechlin, Katy Treca and
Paul-Andre Pays, France
- Schema publishing in X.500 directory / P.V. Rajeev,
S.V. Raghavan, India and Glenn Mansfield, Japan
- The SOLO directory access protocol / Christian Huitema,
France
T3-6. The Internet and the Media.........................CONCERT HALL
......Chair: Ole Jacobsen, ConneXions, USA
Discussion forum with participants from around the world.
Panelists: Rick Tetzeli, Fortune Magazine, USA
...........Vinton G. Cerf, ISOC, USA
...........Peter Judge, Technology Appraisals, UK
...........Ole Jacobsen, ConneXions, USA
T4-6. National Research and Education Networks,..........CLUB ROOM II
......Telephone Companies and PTT's
......Chair: Gary Augustson, Pennsylvania State
.............University, USA
A panel discussion focussing on the relationships
between Telephone Companies and PTT's and national
and regional research and education networks.
What is the current relationship? How is the development
of the coming global information infrastructure and the
continuing deregulation and increased competitiveness
in the telephone industry going to affect these relationships.
Panelists: Howard Davies, DANTE, UK
...........Dave Riffelmacher, EuroTel, Prague, Czech Republic
...........Rhett Williams, ATT Europe, Belgium
T5-6. Network Management.................................BALETNY HALL
......Chair: Peter Elford, Cisco Systems, Australia
- A high-level notation for the specification of
network management applications / Alfredo C.S.C. Brites,
Paulo A.F. Simoes, Paulo M.C. Leitao, Edmundo H.S. Monteiro
and Fernando P.L. Boavida Fernandes, Portugal
- A scheme for FTP management /
Jose Aparecido Carrilho and Edmundo Madeira, Brazil
- Network discovery algorithms for the NSFnet /
Bill Norton, USA
T6-6. Future Generations of Internet Technology..........CHAMBER HALL
......Chair: Dave Morton, ECRC, Germany
- DDT - a versatile tunnelling technology /
Noritoshi Demizu and Suguru Yamaguchi, Japan
- Growing the MBone: scaling, performance, and security
issues with Internet multicasting / Steve Deering, USA
- Massive and real time storage server for Multimedia
applications / Milind Buddhikot and Guru Parulkar, USA
11:00-12:30.......Closing Session........................CONCERT HALL
..................Farewell & Keynote Addresses
......Keynote Speakers:
......- Mr. Thomas Kalil, Director to the National
........Economic Council, Washington D.C., USA
......- Mr. Michel Richonnier, Director DG XIII/C, EU
..................Chair: Geoff Manning, UK
DEMONSTRATIONS...........................................FOYER
At the Conference there will be a demonstrations area
in the Foyer near the main entrance where participants
may visit a number of stands to see displays and
demonstrations of various projects and applications of
network services for the academic community.
- Super JANET /John Dyer, UK
- Demonstration of MICE technology /
Peter Kirstein, UK
- MS-Windows X.500 DUA /
Nils Meulemans, Belgium
- A Multimedia WPS using X.500/WWW integration /
Jean-Christophe Touvet and Paul-Andre Pays, France
- 'Wright Brothers Flyer', a virtual simulation /
Mark Pullen, USA
- Tools for conversion of character sets /
Keld Simonsen, Denmark and Peter Svanberg,
Sweden
- Security Project: PASSWORD /
Peter Kirstein, UK
TUTORIAL..................................................FORUM HOTEL
'High-Speed Networking for MultiMedia Applications'
Chair: Dave Probert, Digital Equipment Corporation,
.......European Headquarters
Monday, June 13, programme:
09:15 Introduction and Overview
09:30 ATM-1: What is ATM? ATM Definition and Architecture -
.............From Desktop to LAN, MAN and WAN ...
Tutor:.......Bernard Collonier, European ATM & High-Performance
.............Networks Consultant, DEC, France
11:15 ATM-2: Why migrate to ATM? The ATM Marketplace,
.............Technologies, MultiMedia Applications ...
Tutor:.......John Kreatsoulas, European Science & Research
.............Applications, DEC, Belgium
12:45 Interactive Questions & Answers panel
13:00 Lunch
14:00 ATM-3: How do I integrate ATM networks? High-Performance
.............Network Routers, Bridges, Switches and Hubs ...
Tutor:.......Bjorn Tuft, Principal European Networking Consultant,
.............DEC, France
15:30 ATM-4: How do I implement ATM Networks? Planning, Design,
............ Implementation & Management of High-Performance Networks
Tutor:.......Ken Punshon, Scientific & Research Networking
.............Consultant, DEC, England
16:45 Interactive Questions & Answers panel - Wrap-Up
17:00 Close
Registration from 08:30 -11:00 (for tutorial only) in foyer of
the Forum Hotel.
RARE WORKING GROUP MEETINGS...............................FORUM HOTEL
Prior to the conference, on Monday June 13 and
Tuesday June 14, RARE Working Group meetings
will take place. During these meetings the different
Working Groups will introduce their current activities
and discuss various high priority topics.
The meetings are open to all those who are interested.
Monday, June 13
a.....09:00-12:30 RARE Working Group on Network Applications Support
..................(NAP)
......14:00-17:30 Plenary RARE Working Group NAP
b.....09:00-18:00 RARE Working Group on Information Services and User
..................Support
c.....09:00-12:30 RARE Working Group on Security Technology
d.....12:30-18:00 RARE Task Force on ATM
e.....14:00-18:00 RARE Working Group on Mail and Messaging
Tuesday, June 14
f.....09:00-12:00 RARE Working Group on Lower-Layers Technology
b.....09:00-12:00 RARE Working Group on Information Services and User
..................Support
g.....09:00-13:00 RARE Working Group on MultiMedia
h.....09:00-13:00 RARE Working Group on Network Operations
i.....09:00-12:00 RARE Working Group on International Character Sets
14:00-18:00 RARE WORKING GROUP PLENARY...................SMALL HALL
- How to bring Research Networking into the year 2000 -
RARE Working Group/ RARE Technical Committee open plenary session on
the introduction of new applications on the network and proposals for
the EC 4th Framework Telematics programme.
INVITATION TO ALL INTERESTED PARTIES
In case you hadn't noticed, a new age in networking has started.
Information Super Highway and MultiMedia are buzzwords that make the
newspapers every day. The Internet and associated research networks
have been designated by the US Vice President Al Gore as: "The
prototype of the future in networking".
To make sure that research networks and associated networks in Europe
keep that leading edge, and that we develop, test and implement
applications and services that can evolve into the European
Information Super Highway, it is essential that ongoing network
developments in Europe are coordinated.
The Rare Technical Committee (RTC) aims at establishing a set of pan
European co-ordination projects, building upon existing and future
national/network/organizational initiatives and involving industry.
These coordination projects will hopefully promote the advancement of
interworking new applications and services in European networking. It
is intended that these projects will also be submitted as proposals
to the EC as a response to a call for proposals for Telematics for
Research (part of the 4th Framework programme) to apply for matching
funding.
This plenary meeting is meant as a kick-off for this RTC initiative.
Several people will share their views on this initiative, and how it
ties in with the European Commissions 4th Framework initiative. After
these short presentations there will be a discussion with all
attendees on the feasibility of this initiative and on a possible
structure for the coordination projects.
CONFERENCE EVENTS
All participants and accompanying persons are invited to attend the
following events. We hope these events will provide an opportunity to
renew old friendships and to create new ones with colleagues from all
over the world.
- Opening Reception..................................FOYER
Tuesday, June 14, 18.30-20.30 Palace of Culture:
Enjoy light refreshments while "catching up" with friends
and colleagues directly on the premises of the Congress Venue.
- Gala Dinner........................................MUNICIPAL HOUSE
Wednesday, June 15, 20.00-23.00 Obecni dum
(Municipal House):
Come and see the beautifully decorated interiors of
the most impressive building in Art Nouveau style in
Prague from the beginning of this century.
There are six representative halls; the biggest one,
the Smetana Hall, is frequently used for concerts.
..........MUNICIPAL HOUSE (OBECNI DUM):
.................How to get there?
..By metro: From the Palace of Culture (station Vysehrad)
.....you take line C to station Florenc, you change to line B,
.....direction Namesti Republiky. At metro station Namesti
.....Republiky you get off, at the exit of the station one
.....of the hostesses will await you. The Municipal House
.....is next to the metro station.
..By taxi: the address is:
...........Obecni Dum
...........Namesti Republiky 5
...........PRAHA 1
- Cocktail Party........................................FOYER/TERRACE
Thursday, June 16, 18.00-19.00 Palace of Culture:
A Cocktail Party will be held on the second floor
of the Palace of Culture. The adjoining terrace has
the most unforgettable view of Prague.
TERMINAL ROOM
The conference facility on the first floor will include a number of
workstations and terminals connected to the Internet. Software will
support access to electronic mail, gopher servers, and telnet and ftp
across the Internet.
Terminal room hours will be:
Tuesday...........12:00-21:00
Wednesday.........08:00-19:00
Thursday..........08:00-19:00
Friday............08:00-13:00
REGISTRATION:
The registration area on the second floor in the Palace of Culture
will be open the following hours:
Tuesday...........12:00-18:00
Wednesday.........08:00-18:00
Thursday..........08:00-18:00
Friday............08:00-13:00
REGISTRATION OFFICE
VC CVUT INET'94/JENC5
Conference Registration Office
Zikova 4
166 35 PRAHA 6
CZECH REPUBLIC
E-mail: register at earn.cvut.cz
Tel: +42-2-3322916
Fax: +42-2-24310271
ACCOMMODATION AND TOURS INET'94/JENC5
Guarant Ltd.
Opletalova 15
110 00 PRAHA 1
CZECH REPUBLIC
Tel: +42-2-24210650/24210735
Fax: +42-2-260130
GENERAL INQUIRIES
INET'94/JENC5 Secretariat
c/o RARE Secretariat
Singel 466-468
NL-1017 AW AMSTERDAM
Tel: +31 20 639 1131
Fax: +31 20 639 3289
E-mail: inet-jenc-sec at rare.nl
X.400: C=nl; ADMD=400net; PRMD=surf; O=rare; S=inet-jenc-sec
HOTEL ACCOMMODATIONS
The following hotels are offering special INET'94/JENC5 conference
rates. The prices include breakfast and V.A.T. tax.
Forum Hotel....USD 153,- /single..........USD 168,- /double
(Conference headquarters)
Kongresova 1, Prague 4
Tel.: +42-2-6119-1111
Fax.: +42-2-421-669
Located opposite the Congress venue (approx. 200 meters).
Panorama Hotel..USD125,- /single..........USD 142,- /double
Milevska 7, Prague 4
Tel.: +42-2-6116-1111
Fax.: +42-2-426-263
Located very close to the Metro, line C, two stops from the Congress
venue (approx. 10 minutes).
* Globus Hotel..USD 82,- /single............USD 102,- /double
Gregorova 2115/10, 149 00 Prague 4 - Roztyly
Tel.: +42-2-792-7700
Fax.: +42-2-792-0095
Located on Metro-Roztyly, line C (approx. 15 minutes)
* Karl-Inn Hotel.USD 70,- /single...........USD 90,- /double
Saldova 54, 180 00 Prague 8 - Karlin
Tel.: +42-2-2481-1718
Located on Metro-Krizikova, Line B (approx. 15 minutes)
ILF Hotel.........USD 50,- /single.........USD 65,- /double
(3 kilometers from Congress Venue)
Budejovicka 15, Prague 4
Tel.: +42-2-433-553
Fax.: +42-2-423-692
Located very close to Metro, line C, three stops from the Congress
venue (approx. 10 minutes).
Kupa Hotel.........USD 30,-/single..........USD 40,-/double
(8 kilometers from Congress Venue)
Kupeckeho 842, Prague 4 -H
Tel.: +42-2-791-0321
Fax.: +42-2-791-0216
Located on Metro, line C (approx. 15 minutes)
The Hotel Globus and Karl-Inn are an alternative for the
Hotel Union and Patty, that have been fully booked.
CONFERENCE AND HOTEL RESERVATION
All participants are encouraged to register before May 1st to obtain
the reduced registration fee. Please complete the enclosed conference
registration form and return it, with a check payable in U.S.
dollars, by mail to the address listed on the form. Registration with
credit card payments are possible and may be sent by E-mail or Fax to
the Conference Registration Office. The conference registration form
also serves as a reservation for hotel accommodation. In order to
reserve a hotel room, either complete the credit card authorisation
section on the conference registration form, or include 1 night's
payment for accommodation along with the conference registration fee,
payable by company check in US dollars. (Personal checks are not
acceptable.)
A Registration and Information desk will be open at the Palace of
Culture in Prague beginning Tuesday, June 14, 1994, from 12.00 hours
up until Friday, June 17 12.00 hours.
CONFIRMATION OF REGISTRATION
A letter confirming conference registration and hotel accommodation
will be sent to each participant upon receipt of the completed
registration form and accompanying payment. This letter should be
presented to the Registration Desk at the Palace of Culture upon
arrival.
---------------------------------------------------------
INET'94/JENC5 CONFERENCE REGISTRATION FORM
Return completed form to:
VC CVUT
INET'94/JENC5
Conference Registration Office
Zikova 4
166 35 Praha 6
Czech Republic
Tel. +42-2-3322916
Fax. +42-2-24310271
E-mail: register at earn.cvut.cz
Conference registration fee MUST accompany this form and must
be received before registration or accommodation can be processed.
Please make a copy of this form for your records. Please type
all applicable information requested below. Only one registration
per form, please.
__________________________________________________________________
SURNAME ......................
FIRST NAME ...................
Prof__ Dr__ Mr__ Ms__
Internet Society Member #___________________
TITLE .......................
AFFILIATION .................
STREET ADDRESS ..................................
CITY ........................
STATE .......................
POSTAL CODE .................
COUNTRY .....................
TELEPHONE ...................
FAX .........................
E-MAIL .......................
NAME TO APPEAR ON BADGE ...................
REGISTERED ACCOMPANYING PERSON(S)
.................................................
SPECIAL NEEDS/MEALS
.................................................
____________________________________________________________________
Payment Method:
All payments must be in United States Dollars. Bank transfer,
check and international credit cards (VISA, American Express and
Master Card) are acceptable. Personal checks are not acceptable.
Name of the account is: KONFERENCE INET'94/JENC5, bank account no.
1412130287/0100, Komercni banka, Dejvicka 52, Praha 6, Czech
Republic. PLEASE MENTION THE PARTICIPANT'S NAME.
_____________________________________________________________________
Registration Fees
Internet Society Member ..... (Before May 15) .....USD 425 ..USD____
............................. (May 15 - June 5) .......475 ..USD____
Desk Registration............ (from June 6) ...........525 ..USD____
Non-Member (includes a one year ISOC
membership).................. (Before May 15) .....USD 475 ..USD____
............................. (May 15 - June 5) .......525 ..USD____
Desk Registration ........... (from June 6) ...........575 ..USD____
Accompanying Person(s)
(Includes Opening Reception,
Gala Dinner and Cocktails) ........................USD 115 ..USD____
Hotel Deposit (if not guaranteed by credit card).............USD____
Tutorial...........................................USD 60 ...USD____
TOTAL AMOUNT TO BE CHARGED:..................................USD____
____VISA
____MasterCard
____American Express
____International Money Order
____Wire Transfer
Credit Card Number_________________________
Expiration Date____________________________
Name on Card_______________________________
Billing Address_____________________________
Signature__________________________________
---------------------------------------------------------------------
---
---------------------------------------------------------------------
---
INET'94/JENC5
Accommodation Reservation
Accommodation reservations must be made by completing this form.
Guaranteed accommodation cut-off date: MAY 1
Rooms: / Nights:
________Forum Hotel....USD 153,-/single,...USD 168,-/double
________Panorama Hotel.USD 125,-/single....USD 142,-/double
________Karl-Inn.......USD 82,-/single.....USD 102,-/double
________Globus.........USD 70,-/single.....USD 93,-/double
________ILF Hotel......USD 50,-/single.....USD 65,-/double
________Kupa Hotel.....USD 30,-/single.....USD 40,-/double
Hotel extras will be paid directly to the hotel reception.
Room Reservation Name:____________________Sharing
With:_________________
Arrival Date:________/______/1994
Departure Date:______/______/1994
Please check one of the following:
- 1 person, one bed
- 2 persons, double beds
- 2 persons, twin beds
Do you have a special accommodation request (e.g. no-smoking room)?
_______________________________________________
Suites (extra cost)?___________________________
Please describe disability/handicap
needs:_________________________________________
______I am arranging my own accommodation.
Accommodation Deposit:
Your room reservation can be guaranteed by either of the following
methods:
1. Complete the Credit Card Authorization section of this form. This
is the
easiest way to guarantee your reservation. 2. Send one night's hotel
fee
along with the registration fee, if other payment methods are used.
____VISA
____MasterCard
____American Express
____International Money Order
Credit Card Number_________________________
Expiration Date____________________________
Name on Card_______________________________
Signature__________________________________
---------------------------------------------------------------------
------
--========================_19562380==_--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22709;
28 May 94 9:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22697;
28 May 94 9:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01900;
28 May 94 9:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22445;
28 May 94 9:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20197;
28 May 94 9:24 EDT
Received: from abac.au.ac.th by CNRI.Reston.VA.US id aa28963; 28 May 94 9:23 EDT
Received: by abac.au.ac.th (5.0/SMI-SVR4)
id AA06965; Sat, 28 May 94 20:10:01 GMT
Date: Sat, 28 May 1994 20:10:00 +0700 (GMT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Prof.Dr. Srisakdi Charmonman" <charm at abac.au.ac.th>
Subject: International Conference on Internet Technology & Applications
To: kiers at rare.nl
Cc: inet-jenc at rare.nl, inet-track at rare.nl, inet-authors at rare.nl,
inet-jenc-ex at rare.nl, session at rare.nl, inet-ust at rare.nl, inet-da at rare.nl,
inet-pi at rare.nl, inet-neo at rare.nl, inet-nt at rare.nl, inet-ri at rare.nl,
coa at rare.nl, wg-all at rare.nl, newsletters at rare.nl, ceec at rare.nl,
M2107 at eurokom.ie, tcp-ip at nic.ddn.mil, iepg at nri.reston.va.us,
ietf at nri.reston.va.us, ccirn at lbl.gov, apccir at aarnet.edu.au, ripe at ripe.net,
ifip65-prog at ics.uci.edu, ifip-gtwy at ics.uci.edu, mhsnews at ics.uci.edu
In-Reply-To: <199405271618.AA24322 at erasmus.rare.nl>
Message-Id: <Pine.3.89.9405281952.A6913-0100000 at abac>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
content-length: 928
Sir:
We are organizing a one-day International Conference on Internet
Technology and Applications to be held at Asia Hotel, Bangkok, Thailand
on Wednesday September 28, 1994. Eight papers are expected. One has been
scheduled and that is on Multimedia via Internet by Dr.Harrison from the
University of North Carolina.
We have limited budget to pay for local expenses for all international
speakers. The expenses include local transportation, hotel, meals,
and sightseeing around Bangkok using a university van and students
serving as tour guides.
The papers will be published as a special issue of the International
Journal of Computer and Engineering Management (IJCEM), probably
Vol.2, No.3.
Call for Papers as well as sample copy of IJCEM will be available at
INET 94.
Those who are interested in sending papers for our consideration,
please drop us a line at <charm at abac.au.ac.th>.
Best regards,
Srisakdi Charmonman
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06310;
28 May 94 17:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06288;
28 May 94 17:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25644;
28 May 94 17:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06190;
28 May 94 17:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03785;
28 May 94 16:50 EDT
Received: from mason1.gmu.edu by CNRI.Reston.VA.US id aa22948;
28 May 94 16:50 EDT
Received: by mason1.gmu.edu (5.65/DEC-Ultrix/4.3/GMUv3)
id AA08082; Sat, 28 May 1994 16:50:02 -0400
Date: Sat, 28 May 1994 16:50:02 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Loc P Nguyen <lnguye1 at mason1.gmu.edu>
Message-Id: <9405282050.AA08082 at mason1.gmu.edu>
To: ieft-request at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
Subject: Please subcribe me
Please include my name in the mailing list. My return address is lnguye1 at gmu.edu.
Regards,
Loc Nguyen
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01116;
29 May 94 7:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01104;
29 May 94 7:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20767;
29 May 94 7:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01087;
29 May 94 7:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01005;
29 May 94 7:24 EDT
Received: from access1.digex.net by CNRI.Reston.VA.US id aa19849;
29 May 94 7:24 EDT
Received: by access1.digex.net id AA02028
(5.67b8/IDA-1.5 for IETF List <ietf at cnri.reston.va.us>); Sun, 29 May 1994 07:24:42 -0400
Newsgroups: tdr.paul.private.mail
Date: Sun, 29 May 1994 07:24:42 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Robinson <PAUL at tdr.com>
X-Orig-Sender: Paul Robinson <PAUL at tdr.com>
Reply-To: Paul Robinson <PAUL at tdr.com>
Subject: Cryptographic usenet news verification and rejection
To: IETF List <ietf at CNRI.Reston.VA.US>
Message-Id: <01.1994May29.07h09m34s.PAUL-0100000 at TDR.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
From: Paul Robinson <PAUL at TDR.COM>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
Most of you I am sure are fully aware of the incident involving Canter &
Siegel and their posting of the same message to as many newsgroups as
they could find, resulting in the identical message being posted some
5,000 times.
Ignoring the issue of messages being unrelated to most of the groups
posted to, or to the content of the messages (e.g. of their being
advertising), the big issue was of their posting each message separately
instead of cross-posting the message, which meant a site carrying, say,
1000 news groups carried 1000 identical copies of their message.
It's been reported that they and/or other groups are planning to repeat
the same activity of throwing a message at every group. I believe the
term that has been used is "spamming".
I think it is time to update the netnews RFC to allow a site to perform
cyptographic rejection of messages based on duplicity. This means that
if the text of a message is identical to another message, it can be
rejected.
To do this requires either using CRC-32 or MD-5. I'd like to propose the
creation of the standards to do this, first as a draft and then most
likely as an RFC along with perhaps the sources to patch some of the most
common news processors to allow them to reject duplicate messages.
I would like to know if there is a working group on this subject or if one
needs to be created. I'd like to see release of documents within a month
or two and having this made available before the end of the summer if not
sooner. This problem needs to be fixed and quickly to prevent the demands
by users of proactive legislation.
Much as I dislike seeing someone throwing 5,000 identical messages onto
Usenet, I find the possibility of having the content of the Internet
being made subject to government control and oversite a much worse one.
Most organizations prefer to claim that they can police their own members
quite well. We need to take the same tack and say we can police
ourselves quite well without the need for intervention by the authorities.
If we do not take steps to clean up our act, we may either end up losing
newsgroups as they become abandoned, moderated or curtailed, or else we see
invasive legislation and regulation forced on us by people who know
nothing of our culture.
I appreciate your comments and suggestions in this matter.
---
Paul Robinson - Paul at TDR.COM
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy at psg.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01281;
29 May 94 8:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01269;
29 May 94 8:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22933;
29 May 94 8:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01252;
29 May 94 8:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01199;
29 May 94 7:59 EDT
Received: from bushwire.apana.org.au by CNRI.Reston.VA.US id aa22724;
29 May 94 7:59 EDT
Received: (from markd at localhost) by bushwire.apana.org.au (8.6.7/bwnf7) id VAA16208; Sun, 29 May 1994 21:59:08 +1000
Date: Sun, 29 May 1994 21:38:30 +1000 (EST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Delany <markd at bushwire.apana.org.au>
Subject: Re: Cryptographic usenet news verification and rejection
To: Paul Robinson <PAUL at tdr.com>
cc: IETF List <ietf at CNRI.Reston.VA.US>
In-Reply-To: <01.1994May29.07h09m34s.PAUL-0100000 at TDR.COM>
Message-ID: <Pine.3.87.9405292130.B16119-0100000 at bushwire.apana.org.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 29 May 1994, Paul Robinson wrote:
> Most of you I am sure are fully aware of the incident involving Canter &
> Siegel and their posting of the same message to as many newsgroups as
> they could find, resulting in the identical message being posted some
> 5,000 times.
> I think it is time to update the netnews RFC to allow a site to perform
> cyptographic rejection of messages based on duplicity. This means that
> if the text of a message is identical to another message, it can be
> rejected.
> To do this requires either using CRC-32 or MD-5. I'd like to propose the
Quite an amirable proposal too, but far too easily bypassed to be of
any real protection against the serious spammer. How would such a
proposal protect against the following? (apologies to non-unix
people, but the gist is hopefully discernable):
#! /bin/ksh
for group in ` cut -f1 -d' ' .../active `
do
(
echo Subject: Buy from me if you read $group
echo Newsgroups: $group
echo
echo Message to $group to make a unique hash. ID is $RANDOM
cat text_of_advert
) | inews -h
done
Perhaps a fuzzier hash would be a better strategy?
M.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02248;
29 May 94 12:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02240;
29 May 94 12:39 EDT
Received: from pad-thai.aktis.com by CNRI.Reston.VA.US id aa16021;
29 May 94 12:39 EDT
Received: from MIT.EDU by pad-thai.aktis.com (8.6.8/) with SMTP
id <MAA05931 at pad-thai.aktis.com>; Sun, 29 May 1994 12:24:27 -0400
Received: from kerby.ocsg.com by MIT.EDU with SMTP
id AA22629; Sun, 29 May 94 12:23:27 EDT
Received: (uucp at localhost) by kerby.ocsg.com (8.6.9/8.6.4, dpg hack 10jan94) with UUCP id JAA28350; Sun, 29 May 1994 09:23:00 -0700
Received: by war04.ocsg.com (NX5.67d/NX3.0M, dpg hack 15dec93)
id AA04532; Sun, 29 May 94 09:18:53 -0700
Date: Sun, 29 May 94 09:18:53 -0700
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Glatting <war04!dennisg at kerby.ocsg.com>
Message-Id: <9405291618.AA04532 at war04.ocsg.com>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: Theodore Ts'o <tytso at mit.edu>
Subject: Re: Comment on Draft Kerberos Mechanism RFC: What is a context's time?
Cc: Marc Horowitz <marc at cam.ov.com>,
"John Wray, Digital DPE,\
486-5210 24-May-1994 1544" <wray at tuxedo.enet.dec.com>,
gssapi at ocsg.com, Adam Bernstein <adam.bernstein at ocsg.com>,
cat-ietf at mit.edu
Reply-To: dpg at ocsg.com
>
> Date: Tue, 24 May 1994 18:35:15 -0400
> From: Marc Horowitz <marc at cam.ov.com>
>
> >> But Kerberos doesn't expire its sessions at all, so to be
> >> most Kerberos-like, GSSAPI contexts would have infinite
> >> lifetime. The Kerberos messaging primitives (krb_mk_safe &
> >> krb_mk_priv) just take a keyblock; the application can
> >> continue to use a given session key for as long as it wishes.
>
> (Naming point: krb5 uses credential where gssapi uses context.
> This should be fun :-)
>
> Kerberos may not use context expiration times, but the concept
> is there. In particular, the krb5_creds structure has an
> element times, which contains an endtime, among other things.
> In fact, one might consider it a bug that {mk,rd}_{priv,safe}
> ignore this.
>
> The endtime is the endtime of the ticket, not necessarily
> of the context. Whether or not the concept is there
> depends on whether or not you are determined to attach
> any meaning to the lifetime of the ticket with respect to
> the lifetime of the context.
>
> Note that {mk,rd}_{priv,safe} don't even take a
> krb5_creds structure; they just take a
> krb5_keyblock....
>
> - Ted
>
(Sorry it took so long to respond. I had to think about the subject
for awhile and I have been engrossed in (and grossed by) Kerberos
memory leaks and network interaction problems.)
Long lived contexts are bad things. From a security perspective, it
would be advantageous to have (optional?) expirations on telnet
sessions however in a database replication application is may not be
advantageous (although larger expiration times could be selected).
Should the Kerberos mechanism of the GSS-API provide context
expiration? Probably not. Kerberos doesn't. However, should the
developer choose to tear down a context when the credentials at
either end expire then the developer should have the information to
make the decision.
-dpg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02865;
29 May 94 14:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02853;
29 May 94 14:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24731;
29 May 94 14:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02837;
29 May 94 14:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02803;
29 May 94 14:20 EDT
Received: from tenet.ICSI.Berkeley.EDU by CNRI.Reston.VA.US id aa24479;
29 May 94 14:20 EDT
Received: by tenet.ICSI.Berkeley.EDU (5.63/1.42)
id AA11348; Sun, 29 May 94 11:20:38 -0700
Message-Id: <9405291820.AA11348 at tenet.ICSI.Berkeley.EDU>
To: Mark Delany <markd at bushwire.apana.org.au>
Cc: Paul Robinson <PAUL at tdr.com>, IETF List <ietf at CNRI.Reston.VA.US>
Subject: Re: Cryptographic usenet news verification and rejection
In-Reply-To: Your message of "Sun, 29 May 1994 21:38:30 +1000."
<Pine.3.87.9405292130.B16119-0100000 at bushwire.apana.org.au>
Date: Sun, 29 May 1994 11:20:38 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Amit Gupta <amit at tenet.icsi.berkeley.edu>
:> I think it is time to update the netnews RFC to allow a site to perform
:> cyptographic rejection of messages based on duplicity. This means that
:> if the text of a message is identical to another message, it can be
:> rejected.
:Quite an admirable proposal too, but far too easily bypassed to be of
:any real protection against the serious spammer. How would such a
:proposal protect against the following? (apologies to non-unix
:people, but the gist is hopefully discernable):
[ script deleted ]
There are times, for example, when you need to post multiple times; e.g.,
when you discover that you forgot to post it to all relevant groups. Also,
what happens when I use an email-to-news gateway to feed a mailing list
to a newsgroup (and I want to post it to other newsgroups as well)?
What about the more "human-intervention"-based approach where the newsadmins
simply reject newsfeed from the offending organizations? This should stop
folks from repeating these activities. (I do not know whether the RFCs
permit a newsadmin to reject messages that originate at a site, but that
is an acceptable change, IMHO).
While it is important that we save the network bandwidth and disk space at
news servers, we should not ignore the larger cost in human resources. IMHO,
we should prevent these folks from cross-posting to the inappropriate
newsgroups.
thanks
-amit
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03413;
29 May 94 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03401;
29 May 94 16:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04488;
29 May 94 16:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03383;
29 May 94 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03339;
29 May 94 16:16 EDT
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa04290;
29 May 94 16:16 EDT
Received: from nsl.pa.dec.com by inet-gw-2.pa.dec.com (5.65/21Mar94)
id AA25019; Sun, 29 May 94 13:13:44 -0700
Received: by nsl.pa.dec.com; id AA09592; Sun, 29 May 94 13:13:43 -0700
Message-Id: <9405292013.AA09592 at nsl.pa.dec.com>
To: IETF List <ietf at CNRI.Reston.VA.US>
Cc: Glenn Trewitt <trewitt at pa.dec.com>, Bob Heiney <heiney at pa.dec.com>
Subject: Re: Cryptographic usenet news verification and rejection
Organization: DEC Network Systems Laboratory (Palo Alto, CA / WRL-1)
Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797
Date: Sun, 29 May 94 13:13:43 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Glenn Trewitt <trewitt at pa.dec.com>
X-Mts: smtp
> :> I think it is time to update the netnews RFC to allow a site to perform
> :> cyptographic rejection of messages based on duplicity. This means that
> :> if the text of a message is identical to another message, it can be
> :> rejected.
>
> :Quite an admirable proposal too, but far too easily bypassed to be of
> :any real protection against the serious spammer. How would such a
> :proposal protect against the following? (apologies to non-unix
> :people, but the gist is hopefully discernable):
>
> What about the more "human-intervention"-based approach where the newsadmins
> simply reject newsfeed from the offending organizations? This should stop
> folks from repeating these activities. (I do not know whether the RFCs
> permit a newsadmin to reject messages that originate at a site, but that
> is an acceptable change, IMHO).
Funny that this topic should come up. Bob Heiney, the news administrator
here at Digital's Palo Alto gateway has modified INN version 1.4sec to
make call-outs to do just this sort of thing. This mechanism will be
incorporated into INN version 1.5. A patch file for INN 1.4sec will be
available by the end of Tuesday (California time) at:
ftp://gatekeeper.dec.com/pub/news/inn/tcl_filtering.tar.gz
The kit will contain a patch for INN 1.4sec, sample Tcl code, and some
basic documentation.
We are well aware that this is a social problem, and that technology can't
solve it. However, we now have a mechanism that can be used to make some
adjustments.
I've attached Bob's description of the mechanism.
Glenn Trewitt
Network Systems Laboratory
Digital Equipment Corporation
Palo Alto, California
---------------------------------------------------------------------------
Several times in the past few months, a site or two has started posting
the same article over and over again, but with a different message id.
The cause is sometimes broken software (e.g. mail <-> news gateways,
which many have written, but few have written correctly), but more
typically is the deliberate action of someone trying to advertise to
everyone. Recent examples are the "Global Alert: Jesus Is Coming"
posting and the "Green Card" posting, each of which was posted over 2200 times.
I expect this to happen more often as the Internet continues its explosive
growth. Although my site (decwrl) usually has enough excess capacity to
weather these problems, many other sites cannot. One problem on
comp.sys.sgi.misc several months ago spewed 40MB of duplicate articles
before the offending sites were fixed, and this overflowed the spool at
many sites. Even for sites with lots of resources, there's still no need
to propagate erroneous or malicious duplicates.
I wanted a way to protect my site that was highly specific, flexible, and
quick.
Examination of duplicated articles showed that although the message ids
were different, it was usually easy for a news admin to come up with a
few rules based on the headers of the article that could be used to
differentiate the duplicates from other articles. (E.g. from
John.Doe at foo.com to comp.sys.sgi.misc with 'foobar' in the subject".)
I concluded that modifying innd to let me say "kill things that look
like _this_" would solve my problem.
I also wanted to allow enough flexibilty in the design that I could
later work on automatic detection and elimination of excessive
duplicates (using a body checksum instead of headers).
Since I needed a fairly powerful language to do all this, and since the
world doesn't need yet another special language, my solution was to add
TCL support to INN. I then modified "ARTpost" to call a TCL procedure
which could then accept or reject the article. The TCL code has access
to an associative array called "Headers", which contains all of the
articles headers. The TCL code may also call a 32-bit article-body
checksum procedure (this is to aid in future automatic detection of duplicates).
Here's what a sample TCL filter procedure looks like:
proc filter_news {} {
global o Headers
set sum [checksum_article]
puts $o "$Headers(Message-ID) $sum"
set newsgroups [split $Headers(Newsgroups) ,]
foreach i $newsgroups {
if {$i=="alt.test" && [string match "*heiney at pa.dec.com*" $Headers(From)]} {
return "dont like alt.test from heiney"
}
}
return "accept"
}
The above TCL code does a few things. First it computes a 32-bit
checksum and writes it and the message ID to a file. It then rejects
articles from me to alt.test.
The work I've done is totally integrated into the INN build and runtime
environments. For example, to turn filtering off, you'd just type
ctlinnd filter n
To reload the TCL code that does the filtering, you just say
ctlinnd reload filter.tcl 'your comment here'
(You may specify TCL callbacks to be executed right before and/or right
after reloading, in case your filter is doing fancy stuff.) See the
ctlinnd man page for more info.
Filtering capability that's this powerful can be used for many
purposes, some benign and useful (excessive duplicate detection and elimination,
on-the-fly statistics), others abusive. I would ask that news admins
think carefully about any filtering they do.
/Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04518;
29 May 94 20:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04506;
29 May 94 20:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23941;
29 May 94 20:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04476;
29 May 94 20:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04415;
29 May 94 20:08 EDT
Received: from databus.databus.com by CNRI.Reston.VA.US id aa23645;
29 May 94 20:09 EDT
Date: Sun, 29 May 94 20:15 EDT
Message-ID: <9405292015.AA21164 at databus.databus.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Barney Wolff <barney at databus.com>
To: Paul Robinson <PAUL at tdr.com>, IETF List <ietf at CNRI.Reston.VA.US>
Subject: Re: Cryptographic usenet news verification and rejection
Content-Length: 1117
Content-Type: text
> Date: Sun, 29 May 1994 07:24:42 -0400 (EDT)
> From: Paul Robinson <PAUL at tdr.com>
>
> I think it is time to update the netnews RFC to allow a site to perform
> cyptographic rejection of messages based on duplicity. This means that
> if the text of a message is identical to another message, it can be
> rejected.
>
> To do this requires either using CRC-32 or MD-5. I'd like to propose the
> creation of the standards to do this, first as a draft and then most
> likely as an RFC along with perhaps the sources to patch some of the most
> common news processors to allow them to reject duplicate messages.
But such an approach will be defeated just by adding a trailing blank
to each new message. With even a 56 Kb link, sending 10 KB individually
to each of thousands of lists/groups takes just a few hours.
We could rig the software which accepts postings to hang on to a TCP
connection for something like 5 minutes, which would pose no real problem
to legitimate posters but would tangle up a spammer. But that would
likely make problems for aol, c-serve, etc.
Barney Wolff <barney at databus.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02475;
30 May 94 11:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02463;
30 May 94 11:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09158;
30 May 94 11:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02446;
30 May 94 11:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02302;
30 May 94 10:57 EDT
Received: from smurfland.cit.buffalo.edu by CNRI.Reston.VA.US id aa07939;
30 May 94 10:57 EDT
Received: from localhost (jcmurphy at localhost) by cadman.cit.buffalo.edu (8.6.5/8.6.5) id KAA06457 for ietf at CNRI.Reston.VA.US; Mon, 30 May 1994 10:57:59 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jeff Murphy <jcmurphy at cadman.cit.buffalo.edu>
Message-Id: <199405301457.KAA06457 at cadman.cit.buffalo.edu>
Subject: Re: Cryptographic usenet news verification and rejection
To: ietf at CNRI.Reston.VA.US
Date: Mon, 30 May 1994 10:57:58 -0400 (EDT)
In-Reply-To: <9405291820.AA11348 at tenet.ICSI.Berkeley.EDU> from "Amit Gupta" at May 29, 94 11:20:38 am
X-Mailer: ELM [version 2.4 PL21]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 960
how about a compromises? allow crossposting, but eliminate duplication
by defining a new news header.
for example, you post to three groups: g1, g2, g3
the actual article goes to g1, and just the headers go to g2 and g3
in the headers will exist something like:
Crossposted-From: g1-12345blahblah
one major problem with this scheme is that all of the news readers
will have to be modified to handle this, otherwise you will only see the
headers, and will be forced to track down the article yourself.
another disadvantage is that your site will have to carry g1 in order for
you to be able to read the article.. (the news reader will automatically
look it up from the "Crossposted-From header" and display it for you)
the advantage is that the only thing that is duplicated is the header,
and not the article.
we will want inews to handle the creation of the header so that people
cant circumvent it..
hmmm.. any thoughts on this scheme?
-jeff
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03768;
30 May 94 14:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03756;
30 May 94 14:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27010;
30 May 94 14:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03741;
30 May 94 14:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03688;
30 May 94 14:40 EDT
Received: from arl-img-1.compuserve.com by CNRI.Reston.VA.US id aa26769;
30 May 94 14:40 EDT
Received: from csi.compuserve.com by arl-img-1.compuserve.com (8.6.4/5.940406sam)
id OAA27235; Mon, 30 May 1994 14:40:17 -0400
Received: by csi.compuserve.com (AA10395); Mon, 30 May 94 18:40:12 GMT
Date: Mon, 30 May 94 18:40:12 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "George M. Jones" <gjones at csi.compuserve.com>
Message-Id: <9405301840.AA10395 at csi.compuserve.com>
To: Barney Wolff <barney at databus.com>
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: barney at databus.com's message of Sun, 29 May 94 20:15 EDT
Subject: Re: Cryptographic usenet news verification and rejection
Reply-To: gjones at csi.compuserve.com
Date: Sun, 29 May 94 20:15 EDT
From: barney at databus.com (Barney Wolff)
Content-Length: 1117
Content-Type: text
We could rig the software which accepts postings to hang on to a TCP
connection for something like 5 minutes, which would pose no real problem
to legitimate posters but would tangle up a spammer. But that would
likely make problems for aol, c-serve, etc.
Glad to know someone's thinking of us :-). I'm not following you
completely: are you saying that it would cause the likes of us
problems because we (even when our customers are well behaved) have
legitimate needs to make lost of short short lived connections to post
or are you assuming that "aol, c-serve, etc." customers are always
going to misbehave so its OK to hang on to the line ?
---George Jones
CompuServe, Inc., 5000 Arlington Centre Blvd, Columbus, Ohio, 43220, USA
Email: gjones at csi.compuserve.com
Just because your're not paranoid, doesn't mean the world's not out to get you.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04688;
30 May 94 16:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04675;
30 May 94 16:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07791;
30 May 94 16:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04661;
30 May 94 16:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04618;
30 May 94 16:46 EDT
Received: from shiva1.cac.washington.edu by CNRI.Reston.VA.US id aa07623;
30 May 94 16:46 EDT
Received: by shiva1.cac.washington.edu
(5.65+UW94.4/UW-NDC Revision: 2.30 ) id AA23866;
Mon, 30 May 94 13:46:41 -0700
Date: Mon, 30 May 1994 13:46:41 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <mrc at cac.washington.edu>
Subject: Re: Cryptographic usenet news verification and rejection
To: "George M. Jones" <gjones at csi.compuserve.com>
Cc: Barney Wolff <barney at databus.com>, ietf at CNRI.Reston.VA.US
In-Reply-To: <9405301840.AA10395 at csi.compuserve.com>
Message-Id: <Pine.3.89.9405301305.B23753-0100000 at shiva1.cac.washington.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 30 May 1994, George M. Jones wrote:
> We could rig the software which accepts postings to hang on to a TCP
> connection for something like 5 minutes, which would pose no real problem
> to legitimate posters but would tangle up a spammer. But that would
> likely make problems for aol, c-serve, etc.
> Glad to know someone's thinking of us :-). I'm not following you
> completely: are you saying that it would cause the likes of us
> problems because we (even when our customers are well behaved) have
> legitimate needs to make lost of short short lived connections to post
> or are you assuming that "aol, c-serve, etc." customers are always
> going to misbehave so its OK to hang on to the line ?
I think that the general idea is that large service bureaus have such a
volume of traffic that they would be adversely affected. This kludge
punishes high-volume posting on a sitewide basis. Such high-volume
posting could be an abusive user, an abusive site, or simply a site that
has a lot of customers.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04925;
30 May 94 17:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04913;
30 May 94 17:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09662;
30 May 94 17:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04886;
30 May 94 17:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04857;
30 May 94 17:09 EDT
Received: from eik.ii.uib.no by CNRI.Reston.VA.US id aa09524;
30 May 94 17:09 EDT
Received: from haukugle.ii.uib.no by eik.ii.uib.no with SMTP id AA01341
(5.67b8/IDA-1.5 for <ietf at CNRI.Reston.VA.US>); Mon, 30 May 1994 23:09:13 +0200
Received: by haukugle.ii.uib.no; id AA06018; Mon, 30 May 1994 23:09:11 +0200
Date: Mon, 30 May 1994 23:09:11 +0200
Message-Id: <9405302109.AA06018 at haukugle.ii.uib.no>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: magnus at ii.uib.no
To: ietf at CNRI.Reston.VA.US
Subject: Re: Cryptographic usenet news verification and rejection
In-Reply-To: <Pine.3.89.9405301305.B23753-0100000 at shiva1.cac.washington.edu>
References: <9405301840.AA10395 at csi.compuserve.com>
<Pine.3.89.9405301305.B23753-0100000 at shiva1.cac.washington.edu>
Reply-To: magnus at ii.uib.no
X-Charset: LATIN1
X-Char-Esc: 29
Would it be possible to put some kind of soft limit on the number of
postings a site accepts from each site it accepts postings from? If
that limit was reached, the operator would be notified and the
postings held locally until he verified that a spamming was not in
progress. The limit should be set high enough that normal posting
doesn't trigger it, and could be set individually for each site to
avoid the Compuserve problem.
Another solution would be for the news server to regularily check the
postings ready to be sent out. If they cover an ureasonably large
number of groups (number of groups > 0.9 * number of messages) a
spamming is probable.
I think it's important that we solve this (still small) problem
technically.
-Magnus
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05609;
30 May 94 18:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05597;
30 May 94 18:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18166;
30 May 94 18:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05582;
30 May 94 18:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05541;
30 May 94 18:46 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa18002; 30 May 94 18:46 EDT
Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA04505 for ietf at cnri.reston.va.us; Mon, 30 May 94 18:46:06 -0400
Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN)
id PAA18687; Mon, 30 May 1994 15:43:45 -0700
Message-Id: <199405302243.PAA18687 at aland.bbn.com>
To: Paul Robinson <PAUL at tdr.com>
Cc: IETF List <ietf at CNRI.Reston.VA.US>
Subject: Re: Cryptographic usenet news verification and rejection
In-Reply-To: Your message of Sun, 29 May 94 07:24:42 -0400.
<01.1994May29.07h09m34s.PAUL-0100000 at TDR.COM>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Mon, 30 May 94 15:43:42 -0700
X-Orig-Sender: craig at aland.bbn.com
To do this requires either using CRC-32 or MD-5. I'd like to propose the
creation of the standards to do this, first as a draft and then most
likely as an RFC along with perhaps the sources to patch some of the most
common news processors to allow them to reject duplicate messages.
I would have thought that a more sophisticated matching scheme would work
better. Two immediate thoughts:
* Michael Rabin a while back developed an algorithm that tried to
generate unique signatures for software (the idea was that if someone
modified your software slightly, it would still have the same signature,
making it easier to catch copyright abuses). Maybe someone could do it
for netnews.
* On a similar note, there are well known (and simple) statistical
algorithms for identifying text written by a particular author. One
could presumably combine this with a length test to tickle out articles
highly likely to be dupes and forward them to a netnews admin.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06595;
30 May 94 21:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06583;
30 May 94 21:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29260;
30 May 94 21:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06568;
30 May 94 21:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06539;
30 May 94 20:58 EDT
Received: from sifon.CC.McGill.CA by CNRI.Reston.VA.US id aa29079;
30 May 94 20:58 EDT
Received: from java.cc.mcgill.ca (java.CC.McGill.CA [132.206.35.22]) by sifon.CC.McGill.CA (8.6.8/8.6.6) with SMTP id UAA26164; Mon, 30 May 1994 20:56:27 -0400
Date: Mon, 30 May 1994 20:56:26 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ian Duncan <id at cc.mcgill.ca>
Subject: Re: Cryptographic usenet news verification and rejection
To: Craig Partridge <craig at aland.bbn.com>
cc: Paul Robinson <PAUL at tdr.com>, IETF List <ietf at CNRI.Reston.VA.US>
In-Reply-To: <199405302243.PAA18687 at aland.bbn.com>
Message-ID: <Pine.3.89.9405302033.A4018-0100000 at java.cc.mcgill.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 30 May 1994, Craig Partridge wrote:
>
> To do this requires either using CRC-32 or MD-5. I'd like to propose the
> creation of the standards to do this, first as a draft and then most
> likely as an RFC along with perhaps the sources to patch some of the most
> common news processors to allow them to reject duplicate messages.
>
> I would have thought that a more sophisticated matching scheme would work
> better.
I'd go further and note that the CRC and MD-5 mechanisms are expressly
designed to be sensitive to very tiny differences (error) in data and
are by nature exactly what we don't want.
Some form of statistical lexicography, like your second suggestion, with
some real cleverness in 'best match' search algorithms is probably the
only effective technique. It could have a few potentially nice side
effects too. And it better because the costs in extra disk and cycles
would probably tilt it unless it was applied to some of the other
outstanding netnews problems, like compression.
... ian <id at cc.mcgill.ca>
Ian Duncan --- McGill University Computing Centre --- +.514.398.3710
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06852;
30 May 94 21:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06840;
30 May 94 21:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01414;
30 May 94 21:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06827;
30 May 94 21:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06797;
30 May 94 21:22 EDT
Received: from amway.ch.apollo.hp.com by CNRI.Reston.VA.US id aa01308;
30 May 94 21:22 EDT
Received: from snarfblatt.ch.apollo.hp.com by amway id <AA29165 at amway> Mon, 30 May 94 21:22:44 EDT
Received: by snarfblatt.ch.apollo.hp.com id <AA25452 at snarfblatt.ch.apollo.hp.com>; Mon, 30 May 1994 21:22:43 -0400
Date: Mon, 30 May 1994 21:22:43 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Sommerfeld <sommerfeld at apollo.hp.com>
To: craig at aland.bbn.com
Cc: PAUL at tdr.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <199405302243.PAA18687 at aland.bbn.com> (message from Craig Partridge on Mon, 30 May 94 15:43:42 -0700)
Subject: Re: Cryptographic usenet news verification and rejection
Message-ID: <9405302122.aa01308 at CNRI.Reston.VA.US>
Cc: IETF List <ietf at CNRI.Reston.VA.US>
From: Craig Partridge <craig at aland.bbn.com>
Date: Mon, 30 May 94 15:43:42 -0700
X-Orig-Sender: craig at aland.bbn.com
PAUL> To do this requires either using CRC-32 or MD-5. I'd like to
PAUL> propose the creation of the standards to do this, first as a
PAUL> draft and then most likely as an RFC along with perhaps the
PAUL> sources to patch some of the most common news processors to
PAUL> allow them to reject duplicate messages.
CRC32 would generate too many false positives; you'd expect false
positives on the order of once every 2**16 articles (maybe a day's
traffic these days?). MD5 would probably be too expensive -- I don't
think you really need cryptographic strength for this purpose.
A CRC64 might be about right..
CRAIG> I would have thought that a more sophisticated matching scheme
CRAIG> would work better.
Agreed; some sort of "canonicalize then hash 50% of the lines" would
probably work quite effectively to weed out deliberate attempts to
randomize the text; more sophisticated approaches would be more work.
- Bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14857;
31 May 94 1:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14845;
31 May 94 1:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24111;
31 May 94 1:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14832;
31 May 94 1:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14806;
31 May 94 1:51 EDT
Received: from access2.digex.net by CNRI.Reston.VA.US id aa23919;
31 May 94 1:51 EDT
Received: from tdr.com by access2.digex.net with BSMTP id AA27433
(5.67b8/IDA-1.5 for <ietf at cnri.reston.va.us>); Tue, 31 May 1994 01:51:52 -0400
Message-Id: <199405310551.AA27433 at access2.digex.net>
Received: by smtpgate.tdr.com; Thu, 24 Feb 1994 19:08:00 -0500
Date: Thu, 24 Feb 1994 19:07:20 -0500 (EST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Robinson <PAUL at tdr.com>
To: Jon Postel <postel at isi.edu>, ietf at CNRI.Reston.VA.US
Subject: Re: Domain Name Registration Disclaimer
From: Paul Robinson <PAUL at TDR.COM>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
Dr. Jon Postel <postel at isi.edu>, writes as follows about the incident
involving a domain name for Macedonia:
> Paul Robinson:
Yes, Doctor?
> The IANA is not in the business of deciding what is and what is not
> a country.
I believe that is what I said in my message: "This is a political
question...which should be decided with the ISO 3166 agency, the UN
Security Council, or with the legislature of that country. It is not
our responsibility..."
> The IANA did not choose any old scheme for identifying countries,
> careful consideration led to the selection of using the ISO 3166
> list.
Dr. Postel, the fact is that the decision to use ISO 3166 is
_arbitrary_. From a technical standpoint, IANA could have chosen
any method or scheme to define country identifiers as long as it
prevented duplicates and was consistent, could they not? Think
about it for a moment.
Defining country codes as a letter C followed by the 3 digit telephone
code, or the 2 or 3 digit telex number is another possible scheme that
could have been used, or using a letter and the numeric code expressed as
letters, e.g. the U.S., Canada and the Carribbean become C001 or CA (+1
code) while Hong Kong becomes CHGG (+877). Or using the telex number
code.
> The IANA has only used the ISO 3166 list of two letter codes to
> assign the "country code" top-level domain (not usually, only).
> The only exception to this rule is the use of the .UK code.
Dr. Postel, I use words to be _precise_. Let's be honest about it for a
moment: If someone drives to work every day unless roads become
impassible, and then takes the train otherwise, (even if that is but 1 day
a year) we do not say "He _only_ drives to work." We say "he almost
always" or "he usually" or "nearly always" drives to work. The corollary
applies: we would not say "he _never_ takes the train" since the statement
would not be true. Since there was an exception made for UK, it is not
"only", and "usually" was a valid choice of words. When the UK exception
is removed, then "only" is valid.
Had the UK situation not obtained, then "only" would be the correct term.
The .RU / .SU situation is not the same; the country in question changed
its name; the same thing would apply if there were hosts in Burma that
still use the old code instead of the new one for Myanamar. IANA didn't
give it a special assignment, they chose to change the one they had, but
England was _always_ GB. Now, if England _was_ UK under ISO 3166, then
changed to GB, then I am incorrect, but that you did say this was an
exception, so I believe my logic to be correct.
> This was set up long ago, and in fact a slow transition to the use of .GB
> is in progress. The .SU situation is now in transition to .RU.
I have a mailing list and I am just now seeing .GB addresses.
> In case of a dispute between domain name registrants as to
> the rights to a particular name, the registration authority shall
> have no role or responsibility other than to provide the contact
> information to both parties.
In other words, issue it to both of them and let them fight it out? :)
> The registration of a domain name does not have any Trademark
> status. It is up to the requestor to be sure he is not violating
> anyone else's Trademark.
I think that is what I said: "Who is entitled to a registration? .. the
first to apply is the one that gets it. It is not our responsibility to
determine if they are entitled, unless they get a court order, then it is..."
Perhaps an RFC on this needs to be issued? :) I could write one. :)
But I am still trying to figure where any point I said was incorrect, and
I can't think of any.
---
Paul Robinson - Paul at TDR.COM
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy at psg.com>
-----
The following Automatic Fortune Cookie was selected only for this message:
Festivity Level 1: Your guests are chatting amiably with each
other, admiring your Christmas-tree ornaments, singing carols around
the upright piano, sipping at their drinks and nibbling hors
d'oeuvres.
Festivity Level 2: Your guests are talking loudly -- sometimes
to each other, and sometimes to nobody at all, rearranging your
Christmas-tree ornaments, singing "I Gotta Be Me" around the upright
piano, gulping their drinks and wolfing down hors d'oeuvres.
Festivity Level 3: Your guests are arguing violently with
inanimate objects, singing "I can't get no satisfaction," gulping down
other peoples' drinks, wolfing down Christmas tree ornaments and
placing hors d'oeuvres in the upright piano to see what happens when
the little hammers strike.
Festivity Level 4: Your guests, hors d'oeuvres smeared all over
their naked bodies are performing a ritual dance around the burning
Christmas tree. The piano is missing.
You want to keep your party somewhere around level 3, unless
you rent your home and own Firearms, in which case you can go to level
4. The best way to get to level 3 is egg-nog.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00874;
31 May 94 5:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00862;
31 May 94 5:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09186;
31 May 94 5:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00848;
31 May 94 5:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00698;
31 May 94 5:01 EDT
Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa08177;
31 May 94 5:01 EDT
Via: uk.ac.edinburgh.festival; Tue, 31 May 1994 09:46:43 +0100
Received: from ucs.ed.ac.uk by festival.ed.ac.uk id aa10768; 31 May 94 9:28 BST
Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Tue, 31 May 94 09:29:52 BST
Date: Tue, 31 May 94 09:29:51 BST
Message-Id: <6190.9405310829 at scorpio.ucs.ed.ac.uk>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Graeme Wood <jaw at ucs.edinburgh.ac.uk>
Subject: Re: Domain Name Registration Disclaimer
To: Paul Robinson <PAUL at tdr.com>, Jon Postel <postel at isi.edu>,
ietf at CNRI.Reston.VA.US
In-Reply-To: Paul Robinson's message of Thu, 24 Feb 1994 19:07:20 -0500 (EST)
Reply-To: Graeme.Wood at edinburgh.ac.uk
X-Department: Unix Systems Support, Computing Services
X-Organisation: The University of Edinburgh
X-Phone: +44 (0)31 650 5003
X-Fax: +44 (0)31 650 6552
> Dr. Postel, I use words to be _precise_. Let's be honest about it for a
> moment: If someone drives to work every day unless roads become
> impassible, and then takes the train otherwise, (even if that is but 1 day
> a year) we do not say "He _only_ drives to work." We say "he almost
> always" or "he usually" or "nearly always" drives to work. The corollary
> applies: we would not say "he _never_ takes the train" since the statement
> would not be true. Since there was an exception made for UK, it is not
> "only", and "usually" was a valid choice of words. When the UK exception
> is removed, then "only" is valid.
>
> Had the UK situation not obtained, then "only" would be the correct term.
> The .RU / .SU situation is not the same; the country in question changed
> its name; the same thing would apply if there were hosts in Burma that
> still use the old code instead of the new one for Myanamar. IANA didn't
> give it a special assignment, they chose to change the one they had, but
> England was _always_ GB. Now, if England _was_ UK under ISO 3166, then
> changed to GB, then I am incorrect, but that you did say this was an
> exception, so I believe my logic to be correct.
>
> > This was set up long ago, and in fact a slow transition to the use of .GB
> > is in progress. The .SU situation is now in transition to .RU.
>
> I have a mailing list and I am just now seeing .GB addresses.
Let us be clear about this, the use of top-level domain name UK, which
denotes the United Kingdom which includes England, Scotland, Wales and
Northern Ireland, predates the bureaucratic blunder in ISO 3166, GB. GB
was decided on by some officials from the Department of Trade and
Industry who didn't:
a) have a clear idea of the existing situation with widespread
use of the domain UK
b) have any idea of geography (GB denotes Great Britain which is
the name of an island not a state which does not contain Northern
Ireland.)
We are now in the position where we have a "very" small number of GB
sites and a very large number of UK sites. Naturally there is resistance
to change for both reasons given above.
So the IANA inherited UK from our existing situation rather than from
any "political" decision to use ISO 3166 and then play with it. There is
no such counter-example with any other country in the world, as far as I
am aware.
Graeme Wood
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01615;
31 May 94 7:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01611;
31 May 94 7:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19905;
31 May 94 7:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01599;
31 May 94 7:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01595;
31 May 94 7:20 EDT
Received: from bhdcdns.trg.nynex.COM by CNRI.Reston.VA.US id aa19884;
31 May 94 7:20 EDT
Received: from A50VM1.TRG.NYNEX.COM by bhdcdns.trg.nynex.COM (4.1/SMI-4.1)
id AA23338; Tue, 31 May 94 07:24:32 EDT
Received: by A50VM1.TRG.NYNEX.COM
(Soft-Switch Central V4L380P3); 31 May 1994 07:07:07 GMT
Message-Id: <CCMAIL.JBURKITT.9360.1994 0531 07070707>
Date: 31 May 1994 07:07:07 GMT
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jim (CC120E) Burkitt" <CCMAIL.JBURKITT at a50vm1.trg.nynex.com>
Subject: Technical Report on Synchronization Status Messages
To: Ietf at CNRI.Reston.VA.US, IESG at CNRI.Reston.VA.US
Comment: MEMO 1994/05/31 07:16
To IEFT and IESG
Attached is a press release from Committee T1 announcing a new technical
report. While I am not a member of this list I was told that you may be
interested in type of information. If type of information is of interest
to this mailing list please let me know.
Jim Burkitt
T1X1 Chair
ccmail.jburkitt at nynex.com
-----------------------------------------------------------------------
Press Release:
From: Committee T1
Contact: Jim Burkitt, T1X1 Chairman
(914) 644-5075
ccmail.jburkitt at nynex.com (Internet)
Subject: Technical Report on Synchronization Status Messages
Committee T1 just published a technical report "Synchronization Network
Management Using Synchronization Status Messages". This new technical
report (Report #33) provides techniques and procedures for synchronization
message use in SONET and DS1 networks. While ANSI T1.105 (SONET) and
T1.403 (DS-1) standards provide codes that pass status information in the
synchronization network, this new technical report explains a number of
ways to use these status messages to maintain a network.
All digital networks require the distribution of what is commonly known as
network clock. This network clock starts with a primary reference source
at the stratum 1 level. Three other stratum levels subtend off these
primary clocks. In addition to the current clock distribution networks,
SONET fiber optic rings need to prevent timing loops. In order to help
maintain these synchronization distribution networks, T1X1 developed a
technical report on how to use Synchronization Status Messages.
Committee T1 is sponsored by the Alliance for Telecommunications Industry
Solutions (ATIS) and is accredited by the American National Standards
Institute (ANSI). Copies can be purchased from ATIS or obtained by
anonymous ftp from test.t1bbs.org (192.187.216.3) with the file name
/pub/techrpts/tr33.doc (Word for Windows 2.0 format) or tr33.ps
(Postscript).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02885;
31 May 94 8:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02873;
31 May 94 8:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28618;
31 May 94 8:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02859;
31 May 94 8:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02813;
31 May 94 8:57 EDT
Received: from arl-img-1.compuserve.com by CNRI.Reston.VA.US id aa28424;
31 May 94 8:57 EDT
Received: from csi.compuserve.com by arl-img-1.compuserve.com (8.6.4/5.940406sam)
id IAA24965; Tue, 31 May 1994 08:57:38 -0400
Received: by csi.compuserve.com (AA11355); Tue, 31 May 94 12:57:35 GMT
Date: Tue, 31 May 94 12:57:35 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "George M. Jones" <gjones at csi.compuserve.com>
Message-Id: <9405311257.AA11355 at csi.compuserve.com>
To: magnus at ii.uib.no
Cc: ietf at CNRI.Reston.VA.US, karl at charcoal.com
In-Reply-To: magnus at ii.uib.no's message of Mon, 30 May 1994 23:09:11 +0200
Subject: Re: Cryptographic usenet news verification and rejection
Reply-To: gjones at csi.compuserve.com
Sender: ietf-request at ietf.cnri.reston.va.us
Date: Mon, 30 May 1994 23:09:11 +0200
Sender: ietf-request at IETF.CNRI.Reston.VA.US
From: magnus at ii.uib.no
References: <9405301840.AA10395 at csi.compuserve.com>
<Pine.3.89.9405301305.B23753-0100000 at shiva1.cac.washington.edu>
Reply-To: magnus at ii.uib.no
X-Charset: LATIN1
X-Char-Esc: 29
Would it be possible to put some kind of soft limit on the number of
postings a site accepts from each site it accepts postings from? If
that limit was reached, the operator would be notified and the
postings held locally until he verified that a spamming was not in
progress. The limit should be set high enough that normal posting
doesn't trigger it, and could be set individually for each site to
avoid the Compuserve problem.
That would not stop "spamming" by users at large sites. Say you
impose a limit of N message a day from your friendly neighborhood
large site, where N > number of newsgroups. There would be nothing
preventing an individual user at such a site from posting a copy of
the same message to each group on the net.
What you really want is a per-user-per-site-per-day posting limit,
which would almost have to be enforced by the posting site. And now
you're back to relying on the admins at each site forcing its users to
play by the rules.
---George Jones
CompuServe, Inc., 5000 Arlington Centre Blvd, Columbus, Ohio, 43220, USA
Email: gjones at csi.compuserve.com
"The number of Unix installations has grown to 10, with more expected."
--- The Unix Programmer's Manual, 2nd Edition, June, 1972. ---
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03274;
31 May 94 9:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03262;
31 May 94 9:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00780;
31 May 94 9:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03248;
31 May 94 9:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03210;
31 May 94 9:18 EDT
Received: from eik.ii.uib.no by CNRI.Reston.VA.US id aa00585; 31 May 94 9:18 EDT
Received: from haukugle.ii.uib.no by eik.ii.uib.no with SMTP id AA14885
(5.67b8/IDA-1.5 for <ietf at CNRI.Reston.VA.US>); Tue, 31 May 1994 15:19:01 +0200
Received: by haukugle.ii.uib.no; id AA08209; Tue, 31 May 1994 15:19:01 +0200
Date: Tue, 31 May 1994 15:19:01 +0200
Message-Id: <9405311319.AA08209 at haukugle.ii.uib.no>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: magnus at ii.uib.no
To: ietf at CNRI.Reston.VA.US
Subject: Re: Cryptographic usenet news verification and rejection
In-Reply-To: <9405311257.AA11355 at csi.compuserve.com>
References: <9405311257.AA11355 at csi.compuserve.com>
Reply-To: magnus at ii.uib.no
X-Charset: LATIN1
X-Char-Esc: 29
>>>>> "George" == George M Jones <gjones at csi.compuserve.com> writes:
George> That would not stop "spamming" by users at large sites. Say
How many sites post thousands of messages every day? What are the
numbers for CompuServe, for example? Of course - sites that large
should (and will) probably put anti-spamming measures into effect
locally.
The point is that while it's probably almost impossible to stop the
determined, technically knowledgable bad guy, it should be pretty easy
to hinder your average Canter & Siegel long enough for the
administrators to remove their account.
-Magnus
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04223;
31 May 94 9:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04211;
31 May 94 9:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04361;
31 May 94 9:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04196;
31 May 94 9:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04136;
31 May 94 9:51 EDT
Received: from garcon.cso.uiuc.edu by CNRI.Reston.VA.US id aa04125;
31 May 94 9:51 EDT
Received: from [128.174.33.173] (maced.cso.uiuc.edu) by garcon.cso.uiuc.edu with SMTP id AA02569
(5.67a8+/IDA-1.5 for <ietf at CNRI.Reston.VA.US>); Tue, 31 May 1994 08:51:19 -0500
Date: Tue, 31 May 1994 08:51:19 -0500
X-Sender: krol at ux1.cso.uiuc.edu
Message-Id: <aa10aa34040210146108 at [128.174.33.173]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ed Krol <e-krol at uiuc.edu>
Subject: Re: Cryptographic usenet news verification and rejection
Actually this sounds like another subscription service on the
net - an inverse clipping service. This doesn't deal with the
bulk of the postings, but might limit them because they
become useless:
One contracts with a firm which manages your kill file for you.
You tell them your likes and dislikes and when you fire up
your newsreader it automatically fetches a fresh kill file addendum
from the service provider. This kill file addendum can have
autokills on all groups for spam.
---
Ed Krol Phone: 217 333 7886
University of Illinois
1120 DCL
1304 W. Springfield
Urbana, IL 61801
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06528;
31 May 94 11:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13196;
31 May 94 11:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06498;
31 May 94 11:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06362;
31 May 94 11:21 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: char-mib at decwrl.dec.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-charmib-mib-02.txt
Date: Tue, 31 May 94 11:21:10 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405311121.aa06362 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Character MIB Working Group
of the IETF.
Title : Character MIB
Author(s) : B. Stewart
Filename : draft-ietf-charmib-mib-02.txt
Pages : 25
Date : 05/26/1994
This memo defines an extension to the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for the management of character stream
devices.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-charmib-mib-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-charmib-mib-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940526143615.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-charmib-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-charmib-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940526143615.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06717;
31 May 94 11:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13852;
31 May 94 11:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06703;
31 May 94 11:33 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06611;
31 May 94 11:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rolc at maelstrom.timeplex.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-rolc-nbma-arp-00.txt
Date: Tue, 31 May 94 11:30:51 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405311130.aa06611 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Routing over Large Clouds
Working Group of the IETF.
Title : NBMA Address Resolution Protocol (NARP)
Author(s) : J. Heinanen, R. Govindan
Filename : draft-ietf-rolc-nbma-arp-00.txt
Pages : 11
Date : 05/26/1994
This document describes the NBMA Address Resolution Protocol (NARP). NARP
can be used by a source terminal (host or router) connected to a
Non-Broadcast, Multi-Access link layer (NBMA) network to find out the NBMA
addresses of the a destination terminal provided that the destination
terminal is connected to the same NBMA network. Although this document
focuses on NARP in the context of IP, the technique is applicable to other
network layer protocols as well.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-rolc-nbma-arp-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-rolc-nbma-arp-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940526095640.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-rolc-nbma-arp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rolc-nbma-arp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940526095640.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07016;
31 May 94 11:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14488;
31 May 94 11:40 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06999;
31 May 94 11:40 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05591;
31 May 94 10:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: char-mib at decwrl.dec.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-charmib-ppl-mib-02.txt
Date: Tue, 31 May 94 10:50:08 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405311050.aa05591 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Character MIB Working Group
of the IETF.
Title : Parallel-printer-like MIB
Author(s) : B. Stewart
Filename : draft-ietf-charmib-ppl-mib-02.txt
Pages : 18
Date : 05/26/1994
This memo defines an extension to the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for the management of
Parallel-printer-like devices.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-charmib-ppl-mib-02.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-charmib-ppl-mib-02.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940526144141.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-charmib-ppl-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-charmib-ppl-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940526144141.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07461;
31 May 94 12:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16616;
31 May 94 12:00 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07435;
31 May 94 12:00 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05933;
31 May 94 11:02 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: char-mib at decwrl.dec.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-charmib-rs232-mib-03.txt
Date: Tue, 31 May 94 11:02:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9405311102.aa05933 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Character MIB Working Group
of the IETF.
Title : RS-232-like MIB
Author(s) : B. Stewart
Filename : draft-ietf-charmib-rs232-mib-03.txt
Pages : 30
Date : 05/26/1994
This memo defines an extension to the Management Information Base (MIB) for
use with network management protocols in the Internet community. In
particular, it defines objects for the management of RS-232-like devices.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-charmib-rs232-mib-03.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-charmib-rs232-mib-03.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940526143859.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-charmib-rs232-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-charmib-rs232-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940526143859.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12845;
31 May 94 16:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12835;
31 May 94 16:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08937;
31 May 94 16:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12813;
31 May 94 16:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12761;
31 May 94 15:59 EDT
Received: from ADRASTEA.LCS.MIT.EDU by CNRI.Reston.VA.US id aa08600;
31 May 94 15:59 EDT
Received: by adrastea.lcs.mit.edu; id AA16692; Tue, 31 May 1994 15:59:16 -0400
Date: Tue, 31 May 1994 15:59:16 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Garrett Wollman <wollman at adrastea.lcs.mit.edu>
Message-Id: <9405311959.AA16692 at adrastea.lcs.mit.edu>
To: Ian Duncan <id at cc.mcgill.ca>
Cc: IETF List <ietf at CNRI.Reston.VA.US>
Subject: Re: Cryptographic usenet news verification and rejection
In-Reply-To: <Pine.3.89.9405302033.A4018-0100000 at java.cc.mcgill.ca>
References: <199405302243.PAA18687 at aland.bbn.com>
<Pine.3.89.9405302033.A4018-0100000 at java.cc.mcgill.ca>
<<On Mon, 30 May 1994 20:56:26 -0400 (EDT), Ian Duncan <id at cc.mcgill.ca> said:
> I'd go further and note that the CRC and MD-5 mechanisms are expressly
> designed to be sensitive to very tiny differences (error) in data and
> are by nature exactly what we don't want.
I, for one, think that what would be much more useful, at least in the
short term, is sender authenticability. (I guess this is 1/2 of
PEM...) This would make it possible for me to simply tell my
newsreader (and mailreader, for that matter) to automatically select
articles written by people who I know have something useful to say,
and automatically kill articles written by the ``differently clued''.
Indeed, we could even pass around such lists (news.winners, anyone?),
and I could automatically select the transitive closure of this
relation.
This idea is nothing new, of course; indeed, people have passed around
versions of it for as long as I've been USENET-aware (seven years...
gawd, does that make me an ``old fogey'' now?). Unfortunately, it
will never happen until someone solves both the patent and
government-regulation problems which currently prevent widespread free
distribution and adoption of even existing authentication
technologies.
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman at lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence. We like people
MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13766;
31 May 94 16:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13421;
31 May 94 16:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13750;
31 May 94 16:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13638;
31 May 94 16:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13145;
31 May 94 16:45 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13630;
31 May 94 16:44 EDT
To: IETF-Announce: ;
REPLY-TO: mwalnut at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
FROM: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 1a: INTRO: July 25-29, 1994/Toronto
Date: Tue, 31 May 94 16:44:56 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9405311644.aa13630 at IETF.CNRI.Reston.VA.US>
Dear IETFers:
Following this message (1a), you will receive three more listed below:
IETF MAILING 1b: IETF RSVP FORM. US$130.00 postmarked on or BEFORE Friday,
July 1, 1994. US$150.00 Registration postmarked after
Friday, July 1, 1994. Registration Forms will be
accepted via electronic mail and facsimile until 13:00 ET
on Thursday, 21, 1994. Registration and payment
will be accepted on-site. (In remote directories
0mtg-rsvp.txt)
******************ATTENTION*** please note the question on the RSVP
form pertaining to the Proceedings. If the form is
returned with that question unanswered, we will assume you
DO NOT want a hardcopy of the Proceedings.
IETF MAILING 1c: AT-A-GLANCE. (In remote directories,
0mtg-at-a-glance-94jul.txt)
IETF MAILING 1f: Travel Directions. (In remote directories,
0mtg-traveldirections.94jul.txt)
MAILINGS 1d and 1e will be sent at a later time.
NOTE: WE CANNOT STRESS THIS ENOUGH. Though we'd prefer to have a payment
of the meeting fee as soon as possible, we definitely want immediate
notification that you are planning on coming. So even though you know
that payment will be delayed for one reason or another, SEND THE RSVP
FORM IN ANYWAY.
ACCESS METHODS:
FTP
-----
IETF Information is available by anonymous FTP from several sites.
US East Coast Address: ds.internic.net (198.49.45.10)
US West Coast Address: venera.isi.edu (128.9.0.32)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
cd ietf
ls *0mtg*
Gopher
-------
Information pertaining to the 30th IETF is available on the Gopher
Server running on IETF.CNRI.RESTON.VA.US (132.151.1.35) under
"Internet Society / IETF / IETF Meetings / Toronto July 1994".
Thank You,
Megan
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13982;
31 May 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14307;
31 May 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13964;
31 May 94 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13899;
31 May 94 16:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14016;
31 May 94 16:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13892;
31 May 94 16:53 EDT
To: IETF-Announce: ;
REPLY-TO: ietf-rsvp at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
FROM: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 1b: IETF RSVP FORM: July 25-29, 1994/Toronto
Date: Tue, 31 May 94 16:53:11 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9405311653.aa13892 at IETF.CNRI.Reston.VA.US>
*************ATTENTION********* Please note the question below pertaining
to the Proceedings. If the form is returned with that question
unanswered, we will assume you DO NOT want a hardcopy of the
Proceedings.
REGISTRATION FORM
30th Internet Engineering Task Force - Page 1 of 2
July 25-29, 1994
Toronto, Ontario, CANADA
Please print or type:
Name (Mr/Dr/Ms)__________________________________________________________
Title____________________________________________________________________
Organization_____________________________________________________________
Address__________________________________________________________________
_________________________________________________________________________
City_____________________________State_____________Postal Code___________
Country__________________________________________________________________
Telephone______________________________Fax_______________________________
Email____________________________________________________________________
Do you plan to attend the Sunday, JULY 24th NEWCOMER'S ORIENTATION at 16:30?
YES___ NO___
Do you plan to attend the Sunday, JULY 24th reception at 18:00?
YES___ NO___
Do you want to receive a hardcopy of the Proceedings?
YES___ NO___
US$130.00 Registration postmarked on or BEFORE Friday, July 1, 1994.
US$150.00 (US$130.00 + US$20.00 late fee) Registration postmarked after
Friday, July 1, 1994.
Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check
(U.S. dollars, drawn on a U.S. Bank), payable to:
Corporation for National Research Initiatives
Account No.____________________________ Expiration Date__________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: ietf-rsvp at cnri.reston.va.us
Facsimile: +1-703-620-0913
Postal: Corporation for National Research Initiatives
Accounting Department - 30th IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
REGISTRATION FORM
30th Internet Engineering Task Force - Page 2 of 2
July 25-29, 1994
Toronto, Ontario, CANADA
IMPORTANT:
1. Payment MAY, but does NOT have to, accompany the Form.
2. Register ONE person per form. Substitutions are NOT allowed.
3. Include a completed Registration Form with payment.
4. Purchase orders are NOT accepted.
5. DD Form 1556 IS accepted.
6. We CANNOT invoice for payment.
7. Registration Forms will be accepted via electronic mail and
facsimile until 13:00 ET on Thursday, July 21, 1994
8. Requests for refunds must be received by Thursday, July 21, 1994.
9. Refund policy: Refunds are subject to a US$20.00 service charge.
Late fees will not be refunded.
10. Your registration fee includes Sunday evening reception (cash bar),
and a daily continental breakfast and coffee breaks.
ON-SITE PAYMENT PROCESSING IN TORONTO
The IETF Secretariat will be accepting payments on-site at the IETF meeting
in Toronto. As with all other meetings, payment can be made via check,
cash, travelers checks, and credit cards. Cash payment will be accepted
in US dollars AND/OR Canadian dollars.
1. All credit card payment slips will include the USD (US Dollar) notation.
2. The Secretariat will only be able to accept travelers checks in US
dollar denominations.
3. For those paying with checks, we will accept amounts written in US
dollars (drawn on US banks) or Canadian dollars (drawn on Canadian
banks). Checks should be made out to CNRI.
Payment in Canadian Dollars:
There will be one Canadian/US dollar exchange rate for the entire
week of the IETF meeting. This will be based on the closing exchange
rate on Saturday, July 23rd. We will not adjust the exchange rate on
a daily basis. DO NOT WRITE THE CHECK UNTIL YOU KNOW THE Canadian/US
dollar EXCHANGE RATE.
For additional information or assistance, please contact +1-703-620-8990,
+1-703-620-0913 (Fax) or ietf-rsvp at cnri.reston.va.us. Direct all inquiries
to: 30th IETF Meeting - Toronto, Ontario, CANADA.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14035;
31 May 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14354;
31 May 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14016;
31 May 94 16:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13922;
31 May 94 16:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14083;
31 May 94 16:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13915;
31 May 94 16:53 EDT
To: IETF-Announce: ;
REPLY-TO: mwalnut at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
FROM: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 1c: DRAFT AT-A-GLANCE: July 25-29, 1994/Toronto
Date: Tue, 31 May 94 16:53:41 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9405311653.aa13915 at IETF.CNRI.Reston.VA.US>
30th INTERNET ENGINEERING TASK FORCE Mailing Date : 5/31/94
AT-A-GLANCE Mailing Number: 1c
DATES: July 25-29, 1994 HOST(S):
Frank Pearce and
Norm Housley
University of Toronto
HOTEL/MEETING SITE: Sheraton Centre Toronto
123 Queen Street West
Toronto, Ontario CANADA M5H 2M9
Phone: (800) 325-3535 {fax: (416) 947-4874}
Phone: 1 (416) 361-1000 (international callers)
CI 16:00; CO 12:00
300 Rooms reserved until Friday, July 1, 1994
$130.00 (Canadian)/single; $130.00 (Canadian)/double
(please add 12% tax). Additional taxes may be charged in
accordance with Federal or Provincial direction. Certain
taxes are rebatable to internationl travelers.
Specify: 30th IETF/Engineering
ALTERNATE ACCOM: TBD
NEWCOMER'S Sunday, July 24, 1994
ORIENTATION: 16:30 - 17:30
Room: Essex Ballroom
PRE-REGISTRATION: Sunday, July 24, 1994
18:00 - 20:00 (reception)
Sheraton Centre Toronto
Room: Essex Ballroom
REGISTRATION: Monday, July 25, 1994
08:00 - 18:00
Tuesday, July 26 - Thursday, July 28, 1994
08:30 - 18:00
Friday, July 29, 1994
08:30 - 12:00
Sheraton Centre Toronto
Room: Outside Civic Ballroom
TERMINAL ROOM: Dufferin/Simcoe
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
US$130.00 if registered BY July 1, 1994
US$150.00 if registered AFTER July 1, 1994
AIRLINE: United Airlines (special rate roundtrip only)
1 (800) 521-4041 Meeting ID: 541YU (IETF)
We regret that discounted fares are not
available for international flights
Delta Airlines
1 (800) 241-6760 Meeting ID: P1014
AIRPORT: Lester Pearson International Airport (Toronto Intnt'l)
PARKING: Valet Parking CA$20.00 currently
Adjacent Municipal Lot CA$14.00 currently
SHUTTLE: Gray Coach Lines operates every 20 minutes.
CA$10.75 each way, currently.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14142;
31 May 94 16:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14580;
31 May 94 16:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14128;
31 May 94 16:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14017;
31 May 94 16:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14341;
31 May 94 16:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14005;
31 May 94 16:55 EDT
To: IETF-Announce: ;
REPLY-TO: mwalnut at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
FROM: mwalnut at CNRI.Reston.VA.US
Subject: IETF MAILING 1f: DIRECTIONS: July 25-29, 1994/Toronto
Date: Tue, 31 May 94 16:55:40 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9405311655.aa14005 at IETF.CNRI.Reston.VA.US>
Directions for the 30th IETF
July 25-29, 1994
Directions to the Sheraton Centre Toronto from Lester Pearson Intnt'l Airport.
=============================================================================
Take 427 South to Queen Elizabeth Way (Q.E.W)
Take Q.E.W. East
Q.E.W will eventually become Gardiner Expressway.
Take the Younge/York exit off of Gardiner.
Head North on York (only possible direction). Go approximately
four blocks.
The Sheraton Centre Toronto is locate at the corner of York and
Queen Streets.
Total driving time with little traffic ~20 minutes.
Sheraton Centre Toronto
123 Queen Street West
Toronto, Ontario CANADA M5H 2M9
416-361-1000
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01429;
1 Jun 94 9:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01416;
1 Jun 94 9:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13624;
1 Jun 94 9:41 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01301;
1 Jun 94 9:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id af00667;
1 Jun 94 9:28 EDT
Received: from gatekeeper.mcimail.com by CNRI.Reston.VA.US id aa01671;
1 Jun 94 7:31 EDT
Received: by gatekeeper.mcimail.com (5.65/fma-120691);
id AA12232; Wed, 1 Jun 94 06:24:25 -0500
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa04407;
1 Jun 94 11:21 GMT
Date: Wed, 1 Jun 94 06:21 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert H. Stine Jr" <0004219666 at mcimail.com>
To: gjones <gjones at csi.compuserve.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Cryptographic usenet news verification and rejection
Message-Id: <02940601112120/0004219666NA5EM at mcimail.com>
> What you really want is a per-user-per-site-per-day posting limit,
> which would almost have to be enforced by the posting site.
Why not per-member authentication?
Upon joining a mailing list, a new member would be issued a password,
perhaps a one-way hash of his name at host. The password would be required
in messages submitted for posting.
At the list site, no message would be posted if it did not include
a valid authentication password.
The list site would also maintain a database of list abusers. No messages
from members of the abuser list would be posted.
Spammers would have to go to the trouble of joining all the lists that
they wanted to target, for what could be only a one-shot fling.
- Bob Stine
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02042;
1 Jun 94 10:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02032;
1 Jun 94 10:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15511;
1 Jun 94 10:03 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02020;
1 Jun 94 10:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01971;
1 Jun 94 10:01 EDT
Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id ab15245;
1 Jun 94 10:00 EDT
Via: uk.ac.edinburgh.festival; Wed, 1 Jun 1994 14:57:50 +0100
Received: from ucs.ed.ac.uk by festival.ed.ac.uk id aa12754; 1 Jun 94 14:57 BST
Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Wed, 1 Jun 94 14:57:38 BST
Date: Wed, 1 Jun 94 14:57:37 BST
Message-Id: <8802.9406011357 at scorpio.ucs.ed.ac.uk>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Graeme Wood <jaw at ucs.edinburgh.ac.uk>
Subject: Re: Cryptographic usenet news verification and rejection
To: "Robert H. Stine Jr" <0004219666 at mcimail.com>,
gjones <gjones at csi.compuserve.com>, ietf <ietf at CNRI.Reston.VA.US>
In-Reply-To: Robert H. Stine Jr's message of Wed, 1 Jun 94 06:21 EST
Reply-To: Graeme.Wood at edinburgh.ac.uk
X-Department: Unix Systems Support, Computing Services
X-Organisation: The University of Edinburgh
X-Url: "http://www.ucs.ed.ac.uk/~jaw/";
X-Phone: +44 (0)31 650 5003
X-Fax: +44 (0)31 650 6552
> > What you really want is a per-user-per-site-per-day posting limit,
> > which would almost have to be enforced by the posting site.
>
> Why not per-member authentication?
>
> Upon joining a mailing list, a new member would be issued a password,
> perhaps a one-way hash of his name at host. The password would be required
> in messages submitted for posting.
Except that the discussion is not about mailing lists but about USENET
news.
Graeme
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03939;
1 Jun 94 11:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22347;
1 Jun 94 11:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03918;
1 Jun 94 11:36 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03855;
1 Jun 94 11:30 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: snadlcmib at cisco.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-snadlc-sdlc-mib-03.txt
Date: Wed, 01 Jun 94 11:30:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9406011130.aa03855 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the SNA DLC Services MIB
Working Group of the IETF.
Title : Definitions of Managed Objects for
SNA Data Link Control: SDLC
Author(s) : J. Hilgeman, S. Nix, A. Bartky, W. Clark
Filename : draft-ietf-snadlc-sdlc-mib-03.txt
Pages : 68
Date : 05/31/1994
This specification defines an extension to the Management Information Base
(MIB) for use with SNMP-based network management. In particular, it
defines objects for managing the configuration, monitoring and control of
data link controls in an SNA environment. This draft identifies managed
objects for SNA Synchronous Data Link Control (SDLC) links only.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-snadlc-sdlc-mib-03.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-snadlc-sdlc-mib-03.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940531104043.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-snadlc-sdlc-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snadlc-sdlc-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940531104043.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04122;
1 Jun 94 11:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22600;
1 Jun 94 11:41 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04105;
1 Jun 94 11:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04007;
1 Jun 94 11:39 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-oncrpc-rpcv2-01.txt
Date: Wed, 01 Jun 94 11:39:00 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9406011139.aa04007 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the ONC Remote Procedure Call
Working Group of the IETF.
Title : RPC: Remote Procedure Call Protocol Specification
Version 2
Author(s) : R. Srinivasan
Filename : draft-ietf-oncrpc-rpcv2-01.txt
Pages : 22
Date : 05/31/1994
This document describes the ONC Remote Procedure Call (ONC RPC Version 2)
protocol as it is currently deployed and accepted. "ONC" stands for
"Open Network Computing".
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-oncrpc-rpcv2-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-rpcv2-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940531163912.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-oncrpc-rpcv2-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-rpcv2-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940531163912.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04232;
1 Jun 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22666;
1 Jun 94 11:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04217;
1 Jun 94 11:44 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04145;
1 Jun 94 11:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-oncrpc-auth-00.txt
Date: Wed, 01 Jun 94 11:41:54 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9406011141.aa04145 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the ONC Remote Procedure Call
Working Group of the IETF.
Title : Authentication Mechanisms for ONC RPC
Author(s) : R. Srinivasan
Filename : draft-ietf-oncrpc-auth-00.txt
Pages : 16
Date : 05/31/1994
This document describes two authentication mechanisms created by Sun
Microsystems that are commonly used in conjunction with the ONC Remote
Procedure Call (ONC RPC Version 2) protocol.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-oncrpc-auth-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-auth-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940601114022.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-oncrpc-auth-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-auth-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940601114022.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05424;
1 Jun 94 13:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24427;
1 Jun 94 13:03 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05412;
1 Jun 94 13:03 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03984;
1 Jun 94 11:38 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-oncrpc-xdr-01.txt
Date: Wed, 01 Jun 94 11:38:08 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9406011138.aa03984 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the ONC Remote Procedure Call
Working Group of the IETF.
Title : XDR: External Data Representation Standard
Author(s) : R. Srinivasan
Filename : draft-ietf-oncrpc-xdr-01.txt
Pages : 26
Date : 03/31/1994
This document describes the External Data Representation Standard (XDR)
protocol as it is currently deployed and accepted.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-oncrpc-xdr-01.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-xdr-01.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940531164859.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-oncrpc-xdr-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-xdr-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940531164859.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05818;
2 Jun 94 11:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05808;
2 Jun 94 11:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09271;
2 Jun 94 11:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05788;
2 Jun 94 11:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05546;
2 Jun 94 11:08 EDT
Received: from inet-gw-1.pa.dec.com by CNRI.Reston.VA.US id aa08833;
2 Jun 94 11:08 EDT
Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94)
id AA12959; Thu, 2 Jun 94 08:00:42 -0700
Received: by skidrow.lkg.dec.com (5.65/MS-081993);
id AA14144; Thu, 2 Jun 1994 11:02:57 -0400
Message-Id: <9406021502.AA14144 at skidrow.lkg.dec.com>
To: IETF List <ietf at CNRI.Reston.VA.US>
Subject: Re: Cryptographic usenet news verification and rejection
In-Reply-To: Your message of "Tue, 31 May 94 15:59:16 EDT."
<9405311959.AA16692 at adrastea.lcs.mit.edu>
Date: Thu, 02 Jun 94 11:02:57 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Beast)" <dee at skidrow.lkg.dec.com>
X-Mts: smtp
I've just read through all the stuff with this subject line and I have
a slightly different slant on things. Yes, it would be great to
automatically detect "duplicate" postings with a slightly fuzzy
criterion. But when you do, it seem to me that the best thing to do
would be to merge them into one multi-group posting. Then you could
just have site wide and/or user selected thresholds such that if a
message is posted to more than that number of groups, it is
ignored/invisible. While you are at it, you might want to hack things
so that a message posted to both x.y.z and x.y (and x) would be
ignored for group x.y (and x) as it is preferable to only see messages
in the most specific group they are posted to. (At least I think it
is preferable. I suppose this could also be a user option.)
Deleting or not forwarding a message is much more likely to lead to
escalating wars between duplicate detection and randomizing software.
Providing a way individual users can say "I don't want to see a
message posted to more than X groups" or the like will work better for
longer although it won't ultimately solve the problem.
From: Garrett Wollman <wollman at adrastea.lcs.mit.edu>
Sender: ietf-request at IETF.CNRI.Reston.VA.US
To: Ian Duncan <id at cc.mcgill.ca>
Cc: IETF List <ietf at CNRI.Reston.VA.US>
In-Reply-To: <Pine.3.89.9405302033.A4018-0100000 at java.cc.mcgill.ca>
References: <199405302243.PAA18687 at aland.bbn.com><Pine.3.89.9405302033.A4018-0100000 at java.cc.mcgill.ca
>
><<On Mon, 30 May 1994 20:56:26 -0400 (EDT), Ian Duncan <id at cc.mcgill.ca> said:
>
>> I'd go further and note that the CRC and MD-5 mechanisms are expressly
>> designed to be sensitive to very tiny differences (error) in data and
>> are by nature exactly what we don't want.
>
>I, for one, think that what would be much more useful, at least in the
>short term, is sender authenticability. (I guess this is 1/2 of
>PEM...) This would make it possible for me to simply tell my
>newsreader (and mailreader, for that matter) to automatically select
>articles written by people who I know have something useful to say,
>and automatically kill articles written by the ``differently clued''.
>Indeed, we could even pass around such lists (news.winners, anyone?),
>and I could automatically select the transitive closure of this
>relation.
>
>This idea is nothing new, of course; indeed, people have passed around
>versions of it for as long as I've been USENET-aware (seven years...
>gawd, does that make me an ``old fogey'' now?). Unfortunately, it
>will never happen until someone solves both the patent and
>government-regulation problems which currently prevent widespread free
>distribution and adoption of even existing authentication
>technologies.
These problems are a lot smaller than they seem. The main problem in
inertia and the effort needed. There are plenty of implementations of
MD5, RSA, etc., available via anonymous ftp including RSAREF which,
for non-profit use, is free of royalties in the USA. And the
government export regulations have no practical effect on software
produced by volunteer efforts and in any case are quite liberal when
it comes to authentication only.
>-GAWollman
>
>--
>Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
>wollman at lcs.mit.edu | Shashish is the bonding of hearts in spite of distance.
>Opinions not those of| It is a bond more powerful than absence. We like people
>MIT, LCS, ANA, or NSA| who like Shashish. - Claude McKenzie + Florent Vollant
Donald
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06456;
2 Jun 94 11:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10090;
2 Jun 94 11:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06444;
2 Jun 94 11:58 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06299;
2 Jun 94 11:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: oncrpc-wg at sunroof.eng.sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-oncrpc-bind-00.txt
Date: Thu, 02 Jun 94 11:53:01 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9406021153.aa06299 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the ONC Remote Procedure Call
Working Group of the IETF.
Title : Binding Protocols for ONC RPC Version 2
Author(s) : R. Srinivasan
Filename : draft-ietf-oncrpc-bind-00.txt
Pages : 15
Date : 06/01/1994
This document describes the binding protocols used in conjunction with the
ONC Remote Procedure Call (ONC RPC Version 2) protocols.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-oncrpc-bind-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-oncrpc-bind-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940602115152.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-oncrpc-bind-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-oncrpc-bind-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940602115152.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06813;
2 Jun 94 12:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06809;
2 Jun 94 12:15 EDT
Received: from relay.tis.com by CNRI.Reston.VA.US id aa10711; 2 Jun 94 12:15 EDT
Received: by relay.tis.com id AA01087; Thu, 2 Jun 94 12:00:57 EDT
Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr)
id sma001070; Thu Jun 2 12:00:22 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa18224;
2 Jun 94 11:53 EDT
Received: from sol.tis.com by magellan.TIS.COM id aa18220; 2 Jun 94 11:51 EDT
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06899; Thu, 2 Jun 94 11:52:57 EDT
Received: by relay.tis.com id AA00972; Thu, 2 Jun 94 11:51:55 EDT
Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3mjr)
id sma000967; Thu Jun 2 11:51:42 1994
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06199;
2 Jun 94 11:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com at CNRI.Reston.VA.US, tis.com at magellan.tis.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Mmdf-Warning: Parse error in original version of preceding line at magellan.TIS.COM
Cc: pem-dev at tis.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pem-sigenc-00.txt
Date: Thu, 02 Jun 94 11:50:12 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9406021150.aa06199 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Privacy-Enhanced Electronic
Mail Working Group of the IETF.
Title : Security Multiparts for MIME: Multipart/Signed
and Multipart/Encrypted
Author(s) : J. Galvin, S. Murphy, S. Crocker, N. Freed
Filename : draft-ietf-pem-sigenc-00.txt
Pages : 9
Date : 06/01/1994
This document defines two new content types for specifying the application
of security services to MIME message bodies. MIME, an acronym for
"Multipurpose Internet Mail Extensions", defines the format of the contents
of Internet mail messages and provides for multi-part textual and
non-textual message bodies. The new content types are subtypes of
multipart: signed and encrypted. Each will contain two body parts: one for
the protected data and one for the control information necessary to remove
the protection. Two control information content types are defined,
application/signature and application/keys, one for each of the multiparts.
The first is to be used when a body part is digitally signed; the second is
to be used when a body part is encrypted.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pem-sigenc-00.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pem-sigenc-00.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19940601174611.I-D at CNRI.Reston.VA.US>
FILE /internet-drafts/draft-ietf-pem-sigenc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pem-sigenc-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19940601174611.I-D at CNRI.Reston.VA.US>
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06833;
2 Jun 94 12:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06829;
2 Jun 94 12:16 EDT
Received: from relay.tis.com by CNRI.Reston.VA.US id aa10740; 2 Jun 94 12:16 EDT
Received: by relay.tis.com id AA01085; Thu, 2 Jun 94 12:00:56 EDT
Received: from magellan.tis.com(192.33.112.124) by relay via smap (V1.3mjr)
id smab01070; Thu Jun 2 12:00:30 1994
Received: from magellan.tis.com by magellan.TIS.COM id aa18241;
2 Jun 94 11:54 EDT
Received: from sol.tis.com by magellan.TIS.COM id aa18237; 2 Jun 94 11:52 EDT
Received: from relay.tis.com by tis.com (4.1/SUN-5.64)
id AA06967; Thu, 2 Jun 94 11:53:57 EDT
Received: by relay.tis.com id AA00981; Thu, 2 Jun 94 11:52:55 EDT
Received: from ietf.cnri.reston.va.us(132.151.1.35) by relay via smap (V1.3mjr)
id sma000977; Thu Jun 2 11:51:58 1994
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06239;
2 Jun 94 11:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;, tis.com at CNRI.Reston.VA.US, tis.com at magellan.tis.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Mmdf-Warning: Parse error in original version of preceding line at magellan.TIS.COM
Cc: pem-dev at tis.com
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-To: Internet-Drafts at CNRI.Reston.VA.US
Subject: I-D ACTION:draft-ietf-pem-mime-05.txt
Date: Thu, 02 Jun 94 11:51:19 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-Id: <9406021151.aa06239 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Privacy-Enhanced Electronic
Mail Working Group of the IETF.
Title : PEM Security Services and MIME
Author(s) : S. Crocker, N. Freed, J. Galvin, S. Murphy
Filename : draft-ietf-pem-mime-05.txt
Pages : 21
Date : 06/01/1994
This document specifies how the services of MIME and PEM can be used in a
complementary fashion. MIME, an acronym for "Multipurpose Internet Mail
Extensions", defines the format of the contents of Internet mail messages
and provides for multi-part textual and non-textual message bodies. PEM,
an acronym for "Privacy Enhanced Mail", provides message
authentication/integrity and message encryption services for Internet mail
messages.
An Internet electronic mail message consists of two parts: the headers
and the body. The headers form a collection of field/value
pairs structured according to RFC 822, whilst the body, if structured, is
defined according to MIME. MIME does not provide for the application of
security services.
PEM specifies how to apply encryption and authentication/integrity
services to the contents of a textual electronic mail message
but does not provide message structuring or type labelling
facilities. This document specifies how to use PEM with the
multipart/signed and multipart/encrypted MIME content types to provide
authentication/integrity and encryption services. We refer to the
authentication/integrity service as a digital signature service.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pem-mime-05.txt".
Internet-Drafts directories are located at:
o US East Coast
Address: ds.internic.net (198.49.45.10)
o US West Coast
Address: ftp.isi.edu (128.9.0.32)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-pem-mime-05.txt".
For questions, please mail to Internet-Drafts at cnri.reston.va.us.
Below is the data which wi 
