Internet Society Press Release
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Internet Society Press Release
===============================================================
16 June 1992
Internet Society
PRESS RELEASE
* * * * * INTERNET SOCIETY TAKES HISTORIC STEPS * * * * *
At its first formal meeting, the Internet Society Board of Trustees
gathering from all corners of the world in Kobe, Japan, took several
historic actions that will significantly affect internetworking
worldwide.
The Internet Society is an international professional organization
established for evolving and extending availability of the techniques
and technologies that allow diverse information systems to openly
communicate. It also includes the huge network of networks known as
the Internet which links millions of users worldwide. These
technologies and the Internet are very rapidly evolving and widely
viewed as critically important infrastructure.
The organization formerly known as the Internet Activities Board
was merged into the Internet Society as a body called the Internet
Architecture Board (IAB). The IAB evolves the technology of the Internet
and develops the series of international standards which are the
predominant means today for common open interconnection, management,
and use of diverse equipment, networks and applications. Some of the
most popular include electronic mail, file transfer, news distribution,
remote logon, and knowledge discovery.
The Board also decided to establish a cooperative relationship with the
Geneva-based U.N. specialized agency known as the International
Telecommunication Union (ITU). In conjunction with this action, the Board
also decided to establish an advisory liaison relationship between the
standards bodies of the two organizations, thus effecting a link between
the IAB and the International Telegraph and Telephone Consultative
Committee (CCITT). Lastly the ISOC will submit a contribution to the
ITU's Plenipotentiary Conference that underscores internetworking as
critical infrastructure and the use of the Internet to significantly
enhance global telecommunications collaboration.
By taking these historic steps, the Board hopes not only to greatly
advance the development and use of internetworking technologies and the
Internet, but also to stimulate more effective collaboration within the
telecommunications field.
---------------------------------------------------------------
For further information, contact:
Internet Society Secretariat
1895 Preston White Drive, suite 100
Reston VA 22091
USA
tel: +1 703 620 8990
fax: +1 703 620 0913
email: <isoc at nri.reston.va.us>
===============================================================
----- End Included Message -----
Received: from nri.ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09131;
17 Jun 92 22:07 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09828;
17 Jun 92 22:07 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22554>; Wed, 17 Jun 1992 13:53:00 -0700
Received: from relay1.UU.NET by venera.isi.edu (5.65c/5.65+local-6)
id <AA22550>; Wed, 17 Jun 1992 13:52:56 -0700
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA16087; Wed, 17 Jun 92 16:51:39 -0400
Received: from kentrox.UUCP by uunet.uu.net with UUCP/RMAIL
(queueing-rmail) id 165042.532; Wed, 17 Jun 1992 16:50:42 EDT
Received: from ktxs8.ktxnet by ktxnet (4.1/SMI-4.1)
id AA01423; Wed, 17 Jun 92 13:35:00 PDT
Received: by ktxs8.ktxnet (4.1/SMI-4.1)
id AA16198; Wed, 17 Jun 92 13:34:57 PDT
Date: Wed, 17 Jun 92 13:34:57 PDT
From: Peter Uchytil <kentrox!ktxs8!peter at uunet.uu.net>
Message-Id: <9206172034.AA16198 at ktxs8.ktxnet>
To: uunet!isi.edu!ietf at uunet.uu.net
Subject: need info on 802.11 committee
I realize this may not be the correct place to post this, but I'm not
sure where to look. I need to get information on the 802.11 committee.
Specifically I need to know when are where the next meeting is, and I
need th minutes for the past year. If you have any information, please
let me know. Thanks!
Pete
--
Peter Uchytil | Kentrox Industries | "Don't give up on desire
uunet!kentrox!peter | Portland, Oregon | And you will have your day"
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08101;
18 Jun 92 15:44 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa05312;
18 Jun 92 15:44 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08254>; Thu, 18 Jun 1992 09:12:28 -0700
Received: from relay.hp.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA08215>; Thu, 18 Jun 1992 09:11:49 -0700
Received: from jazz.cnd.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA01997; Thu, 18 Jun 92 09:10:26 -0700
Received: from localhost by jazz.cnd.hp.com with SMTP
(1.37.187.3/16.2) id AA10229; Thu, 18 Jun 92 10:07:07 -0600
To: Peter Uchytil <kentrox!ktxs8!peter at uunet.uu.net>
Cc: ietf at isi.edu
Subject: Re: need info on 802.11 committee
Organization: Hewlett Packard, Colorado Networks Division
In-Reply-To: Your message of Wed, 17 Jun 92 13:34:57 -0700.
<9206172034.AA16198 at ktxs8.ktxnet>
Date: Thu, 18 Jun 92 10:07:06 -0600
Message-Id: <10227.708883626 at jazz.cnd.hp.com>
From: Jason Zions <jason at jazz.cnd.hp.com>
>I realize this may not be the correct place to post this, but I'm not
>sure where to look. I need to get information on the 802.11 committee.
>Specifically I need to know when are where the next meeting is, and I
>need th minutes for the past year. If you have any information, please
>let me know. Thanks!
The chairman of 802.11 is Vic Hayes:
Hayes, Vic
NCR systems Engineering B.V.
Zadelstede 1-10, 3431 JZ
Nieuwegein-Holland
Phone 011 31 3402 76528
Fax 011 31 3402 39125
The chair of the parent group, 802, is William Lidinsky:
Lidinsky, William
Fermilab
M/S 234, P.O. Box 500
Batavia, IL 60510
Phone 708-840-8067
lidinsky at fnal.gov
All this information was extracted from the April '92 issue of the IEEE-CS
Standards Status Report. "For more information on Computer Society Standards
Activities, or to order draft documents:
IEEE Computer Society
Lisa Granoien
Assistant Director for Standards/TAB
1730 Massachusettes Ave NW
Washington DC 20036-1903
Phone 1 202 371 0101
Fax 1 202 728 9614
Jason
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09720;
19 Jun 92 0:30 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa19796; 19 Jun 92 0:30 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08254>; Thu, 18 Jun 1992 09:12:28 -0700
Received: from relay.hp.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA08215>; Thu, 18 Jun 1992 09:11:49 -0700
Received: from jazz.cnd.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA01997; Thu, 18 Jun 92 09:10:26 -0700
Received: from localhost by jazz.cnd.hp.com with SMTP
(1.37.187.3/16.2) id AA10229; Thu, 18 Jun 92 10:07:07 -0600
To: Peter Uchytil <kentrox!ktxs8!peter at uunet.uu.net>
Cc: ietf at isi.edu
Subject: Re: need info on 802.11 committee
Organization: Hewlett Packard, Colorado Networks Division
In-Reply-To: Your message of Wed, 17 Jun 92 13:34:57 -0700.
<9206172034.AA16198 at ktxs8.ktxnet>
Date: Thu, 18 Jun 92 10:07:06 -0600
Message-Id: <10227.708883626 at jazz.cnd.hp.com>
From: Jason Zions <jason at jazz.cnd.hp.com>
>I realize this may not be the correct place to post this, but I'm not
>sure where to look. I need to get information on the 802.11 committee.
>Specifically I need to know when are where the next meeting is, and I
>need th minutes for the past year. If you have any information, please
>let me know. Thanks!
The chairman of 802.11 is Vic Hayes:
Hayes, Vic
NCR systems Engineering B.V.
Zadelstede 1-10, 3431 JZ
Nieuwegein-Holland
Phone 011 31 3402 76528
Fax 011 31 3402 39125
The chair of the parent group, 802, is William Lidinsky:
Lidinsky, William
Fermilab
M/S 234, P.O. Box 500
Batavia, IL 60510
Phone 708-840-8067
lidinsky at fnal.gov
All this information was extracted from the April '92 issue of the IEEE-CS
Standards Status Report. "For more information on Computer Society Standards
Activities, or to order draft documents:
IEEE Computer Society
Lisa Granoien
Assistant Director for Standards/TAB
1730 Massachusettes Ave NW
Washington DC 20036-1903
Phone 1 202 371 0101
Fax 1 202 728 9614
Jason
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09873;
19 Jun 92 1:38 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa21327; 19 Jun 92 1:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA19689>; Thu, 18 Jun 1992 13:49:09 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA19668>; Thu, 18 Jun 1992 13:48:35 -0700
Received: from port25.sc.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA12252; Thu, 18 Jun 92 16:46:03 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA14006; Thu, 18 Jun 92 13:45:18 PDT
Message-Id: <9206182045.AA14006 at aland.bbn.com>
To: ietf at isi.edu
Subject: RDP implementation available for anonymous FTP
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 18 Jun 92 13:45:18 -0700
Sender: craig at aland.bbn.com
An implementation of the Reliable Data Protocol (RDP) as specified
in RFCs 908 and 1151 is now available by anonymous FTP. RDP is a
connection-oriented reliable transport protocol like TCP, but unlike
TCP it preserves segment boundaries end-to-end, and can deliver segments
out of order if the application wishes.
This implementation was done as my Master's Thesis project at Harvard
in 1987. The code implements RDP in the 4.2/4.3 BSD kernel and was
tested on both a VAX and SUN workstations. It has not been seriously
used since 1987.
I would like to thank my employer, Bolt Beranek and Newman, Inc., for
allowing me to make this distribution available. (Since I was a BBN
employee at the time I wrote the code, BBN owns it). Please observe the
following notice which is also included in the source code:
/**************************************************************************/
/* Copyright(c) 1987, 1992 by BBN Systems and Technologies, */
/* A Division of Bolt Beranek and Newman Inc. */
/* */
/* RDP implementation for 4.2/4.3bsd by Craig Partridge */
/* */
/* Permission to use, copy, modify, distribute, and sell this software */
/* and its documentation for any purpose is hereby granted without fee, */
/* provided that the above copyright notice and this permission appear */
/* in all copies and in supporting documentation, and that the name of */
/* Bolt Beranek and Newman Inc. not be used in advertising or */
/* publicity pertaining to distribution of the software without */
/* specific, written prior permission. BBN makes no representations */
/* about the suitability of this software for any purposes. It is */
/* provided "AS IS" without express or implied warranties. */
/**************************************************************************/
The source code can be retrieved by anonymous FTP from nnsc.nsf.net.
The source code is available in both a regular and compressed TAR file:
rdp/RDP.tar.Z -- compressed (31 Kbytes)
rdp/RDP.tar -- regular (90 Kbytes)
As a project completed in early 1987, this code lacks a number of
features of a modern transport protocol implementation. These missing
features include:
* Karn's algorithm for round-trip time sampling
* Jacobson's round-trip time estimation algorithm
* slow-start
* header prediction
As the RDP code is structured, one cannot simply borrow the appropriate code
from a TCP implementation. Note too, that the code is for 4.2/4.3 BSD and
will require modification to run with 4.4BSD or streams. Porting and
putting in the missing features might be a fruitful Master's degree
project. In any case, if anyone does propose to do this work, I'd like
to know, so I can tell you what little thinking has been done already and
so that if more than one person is working on the problems, I can put
you in touch with each other.
Craig Partridge
E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09887;
19 Jun 92 1:58 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa22000; 19 Jun 92 1:58 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00301>; Thu, 18 Jun 1992 15:36:33 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA20064>; Thu, 18 Jun 1992 13:58:27 -0700
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa08313;
18 Jun 92 16:54 EDT
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08720;
18 Jun 92 16:54 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at nri.reston.va.us
Reply-To: Internet-Drafts at nri.reston.va.us
Subject: ID ACTION:draft-ietf-bgp-bgp4-01.txt
Date: Thu, 18 Jun 92 16:54:18 -0400
Sender: cclark at nri.reston.va.us
Message-Id: <9206181654.aa08720 at IETF.NRI.Reston.VA.US>
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-01.txt
Pages : 56
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol. It is built on experience gained with EGP as
defined in RFC 904 and EGP usage in the NSFNET Backbone as described
in RFC 1092 and RFC 1093.
BGP-4 provides a new set of mechanisms for supporting classless
interdomain routing. These mechanisms include support for advertising
an IP prefix and eliminates the concept of network "class" within BGP.
BGP-4 also introduces mechanisms which allow aggregation of routes,
including aggregation of AS paths. These changes provide support for
the proposed supernetting scheme.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-bgp-bgp4-01.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from nri.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03651;
19 Jun 92 3:11 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00788; 19 Jun 92 3:12 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA18545>; Thu, 18 Jun 1992 13:19:55 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA18540>; Thu, 18 Jun 1992 13:19:52 -0700
Received: from mcimail.com by NRI.Reston.VA.US id ad06558; 18 Jun 92 16:11 EDT
Date: Thu, 18 Jun 92 20:08 GMT
From: David Greenfield <0004020699 at mcimail.com>
To: Jason Zions <jason at jazz.cnd.hp.com>
Cc: "David E. McDysan" <0002806303 at mcimail.com>
Cc: Kelly Jackson <0004073507 at mcimail.com>
Cc: Johna Johnson <0004143837 at mcimail.com>
Cc: "RND Inc." <0004393582 at mcimail.com>
Cc: Mary Jander <0004734998 at mcimail.com>
Cc: Salvatore Salamone <0005379565 at mcimail.com>
Cc: Blair Sanders <SN=Blair_Sanders%SU=_SANDERS%GI=BLAIR%TI at mcimail.com>
Cc: Bob Stine <0004219666 at mcimail.com>
Cc: Mustafa Soysal <0003310988 at mcimail.com>
Cc: Russell Dietz <0003649994 at mcimail.com>
Cc: Scott Brigham <0002442341 at mcimail.com>
Cc: Peter Uchytil <kentrox!ktxs8!peter at uunet.uu.net>
Cc: ietf <ietf at isi.edu>
Subject: Re: need info on 802.11 committee
Message-Id: <81920618200818/0004020699PK1EM at mcimail.com>
in general you can get most if not all ieee documents through the IEEE society
in piscataway, NJ.....anybody got the phone number out there?
Dave Greenfield
Received: from nri.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03862;
19 Jun 92 5:56 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04192; 19 Jun 92 5:56 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06118>; Thu, 18 Jun 1992 17:46:24 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA20428>; Thu, 18 Jun 1992 14:04:33 -0700
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa08442;
18 Jun 92 16:56 EDT
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08760;
18 Jun 92 16:56 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at nri.reston.va.us
Reply-To: Internet-Drafts at nri.reston.va.us
Subject: ID ACTION:draft-ietf-stjohns-ipso-00.txt
Date: Thu, 18 Jun 92 16:56:21 -0400
Sender: cclark at nri.reston.va.us
Message-Id: <9206181656.aa08760 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Son of IPSO A Generic IP Sensitivity Labeling
Option
Author(s) : Michael C. StJohns
Filename : draft-ietf-stjohns-ipso-00.txt
Pages : 20
This document is a direct descendent of RFC1038 and RFC1108 and is a
close cousin to the work done in the Commercial IP Security Option
(CIPSO) Working Group of the Trusted Systems Interoperability Group.
The original IP Security options defined by 1038 and 1108 were
designed with one specific purpose in mind - to support the fielding
of an IP packet encryption device called a BLACKER. Because of this,
the definitions and assumptions in those documents were necessarily US
Department of Defense and BLACKER centric. This document is meant to
serve a larger community, while still meeting the needs of the
1038/1108 audience.
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-stjohns-ipso-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-stjohns-ipso-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from nri.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03876;
19 Jun 92 5:59 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04222; 19 Jun 92 5:59 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03699>; Thu, 18 Jun 1992 16:44:54 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA20442>; Thu, 18 Jun 1992 14:04:39 -0700
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa08615;
18 Jun 92 17:01 EDT
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08832;
18 Jun 92 17:00 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at nri.reston.va.us
Reply-To: Internet-Drafts at nri.reston.va.us
Subject: ID ACTION:draft-ietf-pppext-osinlcp-01.txt
Date: Thu, 18 Jun 92 17:00:52 -0400
Sender: cclark at nri.reston.va.us
Message-Id: <9206181700.aa08832 at IETF.NRI.Reston.VA.US>
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 OSI Network Layer Control Protocol
(OSINLCP)
Author(s) : D. Katz
Filename : draft-ietf-pppext-osinlcp-01.txt
Pages : 12
The Point-to-Point Protocol (PPP) provides a standard method of method
of encapsulating Network Layer protocol information over
point-to-point links. PPP also defines an extensible Link Control
Protocol, and proposes a family of Network Control Protocols (NCPs)
for establishing and configuring different network-layer protocols.
This document defines the NCP for establishing and configuring OSI
Network Layer 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-osinlcp-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-pppext-osinlcp-01.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from nri.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03908;
19 Jun 92 6:01 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04298; 19 Jun 92 6:01 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05817>; Thu, 18 Jun 1992 17:36:01 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA20436>; Thu, 18 Jun 1992 14:04:36 -0700
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa08559;
18 Jun 92 16:59 EDT
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08809;
18 Jun 92 16:59 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at nri.reston.va.us
Reply-To: Internet-Drafts at nri.reston.va.us
Subject: ID ACTION:draft-ietf-cat-netcom-00.txt, .ps
Date: Thu, 18 Jun 92 16:59:33 -0400
Sender: cclark at nri.reston.va.us
Message-Id: <9206181659.aa08809 at IETF.NRI.Reston.VA.US>
A New 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 : Networking and Communications Architecture
Author(s) : John Linn
Filename : draft-ietf-cat-netcom-00.txt, .ps
Pages : 62
This Generic Security Service Application Program Interface (GSS-API)
definition provides security services to callers in a generic fashion,
supportable with a range of underlying mechanisms and technologies and
hence allowing source-level portability of applications to different
environments. This document defines GSS-API services and primitives at
a level independent of underlying mechanism and programming language
environment, and is to be complemented by other, related documents.
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-netcom-00.txt" or
"get draft-ietf-cat-netcom-00.ps"
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-cat-netcom-00.txt" or
"SEND internet-drafts/draft-ietf-cat-netcom-00.ps"
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04402;
19 Jun 92 8:02 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07111; 19 Jun 92 8:02 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07732>; Thu, 18 Jun 1992 18:45:46 -0700
Received: from nisc.jvnc.net by venera.isi.edu (5.65c/5.65+local-6)
id <AA07727>; Thu, 18 Jun 1992 18:45:43 -0700
Received: by nisc.jvnc.net (5.65/1.34)
id AA22785; Thu, 18 Jun 92 21:44:21 -0400
From: Vikas Aggarwal <aggarwal at nisc.jvnc.net>
Message-Id: <9206190144.AA22785 at nisc.jvnc.net>
Subject: AVAILABILITY OF NOCOL (JvNCnet's Network Monitoring System)
To: ietf at isi.edu, net-ops at pa.dec.com
Date: Thu, 18 Jun 92 21:44:20 EDT
Cc: net at jvnc.net
X-Mailer: ELM [version 2.3 PL11]
JvNCnet is pleased to announce that their network monitoring software,
NOCOL (Network Operation Center On-Line) is now available via anonymous
ftp from ftp.jvnc.net (128.121.50.7) under ~ftp/pub/nocol.tar.Z
The software runs on Unix systems, and has been in use at JvNCnet since
1990. The display can be seen by logging into 'nocol.jvnc.net' as username
'nocol'. A 'l 4' will give a full display and 'h' will show a brief help
screen.
The program can monitor OSI sites also (had been demo-ed at the InterOP 92
in Washington)- the OSI monitor can probably still be seen by logging into
'marmot.nersc.gov' as user 'nocol'.
The README file from the software is included below.
-vikas Network Engineering
vikas at jvnc.net (609) 258-2403
...rutgers!jvncnet!vikas (609) 258-2424 (fax)
JvNCnet, Princeton, NJ
-----------------------------------------------------------------------------
README for NOCOL v2.0
=====================
NOCOL (Network Operation Center On-Line) is a collection of network
monitoring programs that runs on Unix platforms primarily for IP networks.
The software consists of a number of monitoring agents that poll various
parameters from any system and put it in a format suitable for
post-processing. The post-processors can be a display agent, an automated
troubleshooting program, an event logging program, etc. Presently the display
module (called 'nocol' after which the software is named) is available
alongwith a number of monitoring agents. Work on an 'intelligent' module is
currently in progress for event logging and some automatic troubleshooting.
The software is very flexible and allows enhancements and development with a
minimum amount of effort. The display module processes all the files present
in the data directory, and displays them sequentially. This allows new
monitoring programs to simply start generating data in the data directory and
the display module will automatically start displaying the new data. The
design also allows running just one set of monitoring agents and any number
of display monitoring agents, all of which see the same consistent data.
The display uses UNIX 'curses' screen management and can thus run on a large
variety of terminals. The condition of any entity being monitored is assigned
a priority level ranging from 'INFO' to 'CRITICAL'. The user running the
display can select the minimum display priority- all sites above this
priority level are displayed.
The actual monitoring agents can actually monitor any entity, protocol,
or variable. To date, the various monitoring agents developed are:
- IP ICMP monitor (using 'ping' or 'multiping')
- OSI reachability monitor (using the OSI ping)
- SNMP trap monitor
- IP data throughput monitor
- Nameserver (named) monitor
- Monitor for the number of terminal server lines in use (for cisco
terminal servers using xtacacs)
It is easy to add monitors for DECnet and/or other protocols.
Has been tested on SunOS4.1.1, Ultrix and NeXT. Documentation is under
'src/docs'.
The software is available from 'ftp.jvnc.net' (128.121.50.7) under ~ftp/pub/.
Please send a message to 'nocol-users-request at jvnc.net' to be added to the
'nocol-users' mailing list for updates and bug fixes. Mail comments to
'nocol-info at jvnc.net' and bugs to 'nocol-bugs at jvnc.net'.
The JvNCnet display can be seen by logging onto 'nocol.jvnc.net' as user
'nocol'.
Vikas Aggarwal
vikas at jvnc.net
JvNCnet
June 18, 1992
--------------
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04465;
19 Jun 92 8:26 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07764; 19 Jun 92 8:26 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07748>; Thu, 18 Jun 1992 18:47:35 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA20421>; Thu, 18 Jun 1992 14:04:29 -0700
Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa08441;
18 Jun 92 16:56 EDT
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08742;
18 Jun 92 16:55 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ullmann-net-utf-00.txt
Date: Thu, 18 Jun 92 16:55:20 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206181655.aa08742 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : NET-UTF: International character set
Author(s) : R. L. Ullmann
Filename : draft-ullmann-net-utf-00.txt
Pages : 10
The Internet is no longer a creature of the United States, much less
of DARPA (the US Defence Advance Research Projects Agency). It is now
an international network, and the ability to communicate in any of the
world languages on an equal footing is an imperative.
This draft attempts to track the development of ISO 10646, a moving
target at this writing. The reference citation below is to the 2nd
10646 draft, for which balloting has just concluded. (June 1992). It
is therefore expected that this memo will potentially change until the
publication of IS 10646. Some of the following text refers to 10646
in the present tense, as if it is IS now; it should be understood in
this context.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ullmann-net-utf-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ullmann-net-utf-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04929;
19 Jun 92 9:39 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10592; 19 Jun 92 9:39 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08940>; Thu, 18 Jun 1992 19:36:13 -0700
Received: from relay2.UU.NET by venera.isi.edu (5.65c/5.65+local-6)
id <AA20687>; Thu, 18 Jun 1992 14:09:46 -0700
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA28883; Thu, 18 Jun 92 17:08:31 -0400
Received: from kentrox.UUCP by uunet.uu.net with UUCP/RMAIL
(queueing-rmail) id 170702.11837; Thu, 18 Jun 1992 17:07:02 EDT
Received: from ktxs8.ktxnet by ktxnet (4.1/SMI-4.1)
id AA06046; Thu, 18 Jun 92 13:21:15 PDT
Received: by ktxs8.ktxnet (4.1/SMI-4.1)
id AA18586; Thu, 18 Jun 92 13:21:14 PDT
Date: Thu, 18 Jun 92 13:21:14 PDT
From: Peter Uchytil <kentrox!ktxs8!peter at uunet.uu.net>
Message-Id: <9206182021.AA18586 at ktxs8.ktxnet>
To: uunet!isi.edu!ietf at uunet.uu.net
Subject: Thanks for the 802.11 info everybody!
Just wanted to say thanks to everyone for the information on 802.11.
I'm not the one who needed it, but I'm the one who knows how to use
email :-) (yeah, I know it's not that tough, but these are marketing
people we're talking about...) It was just what we needed!
Pete
--
Peter Uchytil | Kentrox Industries | "Don't give up on desire
uunet!kentrox!peter | Portland, Oregon | And you will have your day"
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05434;
19 Jun 92 10:34 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12455;
19 Jun 92 10:34 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07883>; Thu, 18 Jun 1992 18:54:26 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA19668>; Thu, 18 Jun 1992 13:48:35 -0700
Received: from port25.sc.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA12252; Thu, 18 Jun 92 16:46:03 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA14006; Thu, 18 Jun 92 13:45:18 PDT
Message-Id: <9206182045.AA14006 at aland.bbn.com>
To: ietf at isi.edu
Subject: RDP implementation available for anonymous FTP
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 18 Jun 92 13:45:18 -0700
Sender: craig at aland.bbn.com
An implementation of the Reliable Data Protocol (RDP) as specified
in RFCs 908 and 1151 is now available by anonymous FTP. RDP is a
connection-oriented reliable transport protocol like TCP, but unlike
TCP it preserves segment boundaries end-to-end, and can deliver segments
out of order if the application wishes.
This implementation was done as my Master's Thesis project at Harvard
in 1987. The code implements RDP in the 4.2/4.3 BSD kernel and was
tested on both a VAX and SUN workstations. It has not been seriously
used since 1987.
I would like to thank my employer, Bolt Beranek and Newman, Inc., for
allowing me to make this distribution available. (Since I was a BBN
employee at the time I wrote the code, BBN owns it). Please observe the
following notice which is also included in the source code:
/**************************************************************************/
/* Copyright(c) 1987, 1992 by BBN Systems and Technologies, */
/* A Division of Bolt Beranek and Newman Inc. */
/* */
/* RDP implementation for 4.2/4.3bsd by Craig Partridge */
/* */
/* Permission to use, copy, modify, distribute, and sell this software */
/* and its documentation for any purpose is hereby granted without fee, */
/* provided that the above copyright notice and this permission appear */
/* in all copies and in supporting documentation, and that the name of */
/* Bolt Beranek and Newman Inc. not be used in advertising or */
/* publicity pertaining to distribution of the software without */
/* specific, written prior permission. BBN makes no representations */
/* about the suitability of this software for any purposes. It is */
/* provided "AS IS" without express or implied warranties. */
/**************************************************************************/
The source code can be retrieved by anonymous FTP from nnsc.nsf.net.
The source code is available in both a regular and compressed TAR file:
rdp/RDP.tar.Z -- compressed (31 Kbytes)
rdp/RDP.tar -- regular (90 Kbytes)
As a project completed in early 1987, this code lacks a number of
features of a modern transport protocol implementation. These missing
features include:
* Karn's algorithm for round-trip time sampling
* Jacobson's round-trip time estimation algorithm
* slow-start
* header prediction
As the RDP code is structured, one cannot simply borrow the appropriate code
from a TCP implementation. Note too, that the code is for 4.2/4.3 BSD and
will require modification to run with 4.4BSD or streams. Porting and
putting in the missing features might be a fruitful Master's degree
project. In any case, if anyone does propose to do this work, I'd like
to know, so I can tell you what little thinking has been done already and
so that if more than one person is working on the problems, I can put
you in touch with each other.
Craig Partridge
E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06218;
19 Jun 92 11:54 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15351;
19 Jun 92 11:54 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA09148>; Thu, 18 Jun 1992 19:42:01 -0700
Received: from relay.hp.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA20075>; Thu, 18 Jun 1992 13:58:37 -0700
Received: from jazz.cnd.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA09819; Thu, 18 Jun 92 13:57:11 -0700
Received: from localhost by jazz.cnd.hp.com with SMTP
(1.37.187.3/16.2) id AA14643; Thu, 18 Jun 92 14:53:29 -0600
To: David Greenfield <0004020699 at mcimail.com>
Cc: Jason Zions <jason at jazz.cnd.hp.com>,
"David E. McDysan" <0002806303 at mcimail.com>,
Kelly Jackson <0004073507 at mcimail.com>,
Johna Johnson <0004143837 at mcimail.com>,
"RND Inc." <0004393582 at mcimail.com>, Mary Jander <0004734998 at mcimail.com>,
Salvatore Salamone <0005379565 at mcimail.com>,
Blair Sanders <SN=Blair_Sanders%SU=_SANDERS%GI=BLAIR%TI at mcimail.com>,
Bob Stine <0004219666 at mcimail.com>,
Mustafa Soysal <0003310988 at mcimail.com>,
Russell Dietz <0003649994 at mcimail.com>,
Scott Brigham <0002442341 at mcimail.com>,
Peter Uchytil <kentrox!ktxs8!peter at uunet.uu.net>, ietf <ietf at isi.edu>
Subject: Re: need info on 802.11 committee
Organization: Hewlett Packard, Colorado Networks Division
In-Reply-To: Your message of Thu, 18 Jun 92 20:08:00 +0000.
<81920618200818/0004020699PK1EM at mcimail.com>
Date: Thu, 18 Jun 92 14:53:28 -0600
Message-Id: <14641.708900808 at jazz.cnd.hp.com>
From: Jason Zions <jason at jazz.cnd.hp.com>
>in general you can get most if not all ieee documents through the IEEE
>society in piscataway, NJ.....anybody got the phone number out there?
To order published standards:
IEEE Computer Society
10662 Los Vaqueros Circle
Los Alamitos, CA 90720
1-800-272-6657 (outside California)
1-714-821-8380 (in CA or outside US)
Fax 1-714-821-4010
IEEE Standards Sales
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
908-562-3800
1-800-678-IEEE
IEEE Computer Society
13 Avenue de l'Aquilon
B-1200 Brussels, Belgium
Phone 32.2.770.21.98
Fax 32.2.770.85.05
IEEE Computer Society
Ooshima Building
2-19-1 Minami Aoyama
Minato-ku
Tokyo 107 Japan
Phone (81) 3-408-3118
Fax (81) 3-408-3553
Jason Zions
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07248;
19 Jun 92 14:28 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20519;
19 Jun 92 14:29 EDT
Received: from BITSY.MIT.EDU by NRI.Reston.VA.US id aa20507; 19 Jun 92 14:28 EDT
Received: by bitsy.MIT.EDU
id AA09145; Fri, 19 Jun 92 14:09:22 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA09139; Fri, 19 Jun 92 14:09:15 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA07637; Fri, 19 Jun 92 14:09:06 EDT
Received: by inet-gw-2.pa.dec.com; id AA00238; Fri, 19 Jun 92 11:08:57 -0700
Received: by us1rmc.bb.dec.com; id AA25876; Fri, 19 Jun 92 14:10:19 -0400
Message-Id: <9206191810.AA25876 at us1rmc.bb.dec.com>
Received: from erlang.enet; by us1rmc.enet; Fri, 19 Jun 92 14:10:21 EDT
Date: Fri, 19 Jun 92 14:10:21 EDT
From: John Linn 19-Jun-1992 1408 <linn at erlang.enet.dec.com>
To: cat-ietf at mit.edu
Cc: linn at erlang.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Inputs for July CAT agenda?
You've seen the updated GSS-API draft which I submitted earlier this week in
response to Steve Crocker's comments. (BTW, for any others who read the I-D
announcement in detail, no, its title wasn't meant to be "Networking and
Communications Architecture" -- which happens to be my organizational
affiliation but would be a very ambitious title for an I-D -- and I've
requested that this be fixed.) It will be passed to a (now being constituted)
review group prior to IESG submission, which may or may not return comments
warranting discussion at the meeting.
As previous messages to the list have indicated, I've been approached by
representatives from X/Open and POSIX who would like to use GSS-API as the
basis for standards in their arenas; I'll plan to report on the situation as I
understand it as a basis for discussion.
Does anyone have other agenda topics they'd like to propose (and, preferably,
lead a discussion on) at the July CAT sessions? If not, we may be able to trim
the time consumption down to one rather than two slots.
--jl
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07248;
19 Jun 92 14:28 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa20519;
19 Jun 92 14:29 EDT
Received: from BITSY.MIT.EDU by NRI.Reston.VA.US id aa20507; 19 Jun 92 14:28 EDT
Received: by bitsy.MIT.EDU
id AA09145; Fri, 19 Jun 92 14:09:22 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA09139; Fri, 19 Jun 92 14:09:15 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA07637; Fri, 19 Jun 92 14:09:06 EDT
Received: by inet-gw-2.pa.dec.com; id AA00238; Fri, 19 Jun 92 11:08:57 -0700
Received: by us1rmc.bb.dec.com; id AA25876; Fri, 19 Jun 92 14:10:19 -0400
Message-Id: <9206191810.AA25876 at us1rmc.bb.dec.com>
Received: from erlang.enet; by us1rmc.enet; Fri, 19 Jun 92 14:10:21 EDT
Date: Fri, 19 Jun 92 14:10:21 EDT
From: John Linn 19-Jun-1992 1408 <linn at erlang.enet.dec.com>
To: cat-ietf at mit.edu
Cc: linn at erlang.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Inputs for July CAT agenda?
You've seen the updated GSS-API draft which I submitted earlier this week in
response to Steve Crocker's comments. (BTW, for any others who read the I-D
announcement in detail, no, its title wasn't meant to be "Networking and
Communications Architecture" -- which happens to be my organizational
affiliation but would be a very ambitious title for an I-D -- and I've
requested that this be fixed.) It will be passed to a (now being constituted)
review group prior to IESG submission, which may or may not return comments
warranting discussion at the meeting.
As previous messages to the list have indicated, I've been approached by
representatives from X/Open and POSIX who would like to use GSS-API as the
basis for standards in their arenas; I'll plan to report on the situation as I
understand it as a basis for discussion.
Does anyone have other agenda topics they'd like to propose (and, preferably,
lead a discussion on) at the July CAT sessions? If not, we may be able to trim
the time consumption down to one rather than two slots.
--jl
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07952;
19 Jun 92 16:13 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa24034;
19 Jun 92 16:13 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21097>; Fri, 19 Jun 1992 05:54:49 -0700
Received: from MITVMA.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA21093>; Fri, 19 Jun 1992 05:54:45 -0700
Message-Id: <199206191254.AA21093 at venera.isi.edu>
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2)
with BSMTP id 8837; Fri, 19 Jun 92 08:53:39 EDT
Received: from SMCVAX.BITNET (KUMQUAT) by MITVMA.MIT.EDU (Mailer R2.08 R208004)
with BSMTP id 9591; Fri, 19 Jun 92 08:53:38 EDT
Date: Fri, 19 Jun 92 08:47 EDT
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT%SMCVAX.BITNET at mitvma.mit.edu>
Subject: Re: need info on 802.11 committee
To: 0004020699 at mcimail.com, ietf at isi.edu
X-Vms-To: IN%"0004020699 at mcimail.com"
Actually, you can get standards from the IEEE but almost *never* get drafts
or minutes. You are usually referred to a plcae like Alpha Graphics,
Phoenix, AZ, 602-863-0999 (fax = 602-866-8801).
IEEE standards office in Piscataway, NJ is at 908-562-3800 or 800-678-4333
/Gary C. Kessler
MAN Technology Corporation
802-879-3375
kumquat at smcvax.bitnet
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08344;
19 Jun 92 16:42 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa25296;
19 Jun 92 16:43 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22059>; Fri, 19 Jun 1992 06:51:08 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA22055>; Fri, 19 Jun 1992 06:51:04 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04987;
19 Jun 92 9:44 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-x400ops-charactersets-00.txt
Date: Fri, 19 Jun 92 09:44:18 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206190944.aa04987 at IETF.NRI.Reston.VA.US>
A New 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 : X.400 use of extended character sets
Author(s) : Harald Alvestrand
Filename : draft-ietf-x400ops-charactersets-00.txt
Pages : 18
Abstract not provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-x400ops-charactersets-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-x400ops-charactersets-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08849;
19 Jun 92 18:50 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa29808;
19 Jun 92 18:50 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05718>; Fri, 19 Jun 1992 12:20:04 -0700
From: Jon Postel <postel at isi.edu>
Received: from bel.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA05701>; Fri, 19 Jun 1992 12:19:57 -0700
Date: Fri, 19 Jun 1992 12:18:17 -0700
Posted-Date: Fri, 19 Jun 1992 12:18:17 -0700
Message-Id: <199206191918.AA21449 at bel.isi.edu>
Received: by bel.isi.edu (5.65c/4.0.3-4)
id <AA21449>; Fri, 19 Jun 1992 12:18:17 -0700
To: ietf at isi.edu, rfc-dist at noc.ddn.mil
Subject: RFC 1347 on TCP and UDP with Bigger Addresses (TUBA)
Cc: jkrey at isi.edu
A new Request for Comments is now available in the online RFC
libraries.
Note: This is a PostScript RFC, a secondary version is available in
ASCII. The secondary ASCII version may lack figures and the
information encoded in typographic variation (italics, boldface,
etc.). Since this information often provides essential context, the
ASCII version is at best incomplete and at worst misleading. Anyone
expecting to understand this document is strongly encouraged to obtain
the PostScript version.
RFC 1347:
Title: TCP and UDP with Bigger Addresses (TUBA),
A Simple Proposal for Internet Addressing and Routing
Author: R. Callon
Mailbox: callon at bigfut.lkg.dec.com
PS-Pages: 7 ASCII-Pages: 9
PS-Characters: 42,398 ASCII-Characters: 26,563
Obsoletes/Updates: none
This paper describes a simple proposal which provides a long-term
solution to Internet addressing, routing, and scaling. This involves
a gradual migration from the current Internet Suite (which is based
on Internet applications, running over TCP or UDP, running over IP)
to an updated suite (based on the same Internet applications, running
over TCP or UDP, running over CLNP). This approach is known as "TUBA"
(TCP & UDP with Bigger Addresses).
This memo provides information for the Internet community. It
does not specify an Internet standard. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at NRI.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.
RFCs can be obtained via FTP from FTP.NISC.SRI.COM, NIS.NSF.NET,
NISC.JVNC.NET, VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or 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 to be added to or deleted from this distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC at NIC.DDN.MIL. 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 1111, "Instructions to RFC
Authors", for further information.
Requests to be added to or deleted from this distribution list should
be sent to RFC-REQUEST at NIC.DDN.MIL.
Joyce K. Reynolds
USC/Information Sciences Institute
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09120;
19 Jun 92 22:16 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05163;
19 Jun 92 22:17 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa05159;
19 Jun 92 22:17 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA06313; Fri, 19 Jun 92 21:16:58 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA06899; 4.1/CRI-5.5; Fri, 19 Jun 92 21:16:54 CDT
Received: from venera.isi.edu by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA06310; Fri, 19 Jun 92 21:16:52 CDT
Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA24684>; Fri, 19 Jun 1992 19:18:07 -0700
Date: Fri, 19 Jun 1992 19:16:43 -0700
Posted-Date: Fri, 19 Jun 1992 19:16:43 -0700
Message-Id: <199206200216.AA02663 at tgo.isi.edu>
Received: by tgo.isi.edu (5.65c/4.0.3-4)
id <AA02663>; Fri, 19 Jun 1992 19:16:43 -0700
From: Clifford Neuman <bcn at isi.edu>
Sender: bcn at isi.edu
To: stevea at i88.isc.com, dab at timbuk.cray.com
Cc: telnet-ietf at timbuk.cray.com, tytso at mit.edu, prasad at isi.edu
In-Reply-To: Steve Alexander's message of Tue, 16 Jun 92 07:16:14 -0500 <9206161216.AA02903 at ozzy.i88.isc.com>
Subject: Revised Kerberos V Draft
Here are my comments on the telnet option for Kerberos V5.
Network Working Group Internet Engineering Task Force
Internet-Draft Telnet Working Group
D. Borman, Editor
Cray Research, Inc.
June 1992
Telnet Authentication: Kerberos Version 5
2. Command Meanings
IAC SB AUTHENTICATION <authentication-type-pair> AUTH <kerberos tick-
et and authenticator> IAC SE
Are you sure that you want to explicitly specify that the ticket and
authenticator is sent, as opposed to specifying that the Kerberos
Version 5 KRB_AP_REQ message (also known as an authentication header)
is sent. The KRB_AP_REQ message includes the authenticator and
ticket, plus some other bookkeeping information, much of which is
redundant with information you provide.
In any event, explicitly stating that the ticket and authenticator only
are sent will not affect the security of the protocol. The only
possible concern here is that the common way to add Kerberos to an
application is to make a single call that returns the full KRB_AP_REQ,
and to just send that value to the server. As you've specified it,
the client side must construct its own <kerberos ticket and
authenticator> by making several calls to the Kerberos code.
A second concern here is what happens if the <kerberos ticket and
authenticator> which includes ciphertext, includes the sequence of
octets " IAC SE<CR>" (i't more likely to contain a single <CR>, which
might also cause problems for implementations that expect everything
to be on a single line>. While extremely unlikely, are you prepared
to have strange things happen if it should arise. Two options to
counter this are to either precede this opaque data with an octet
count, or to somehow encode it so that it doesn't include such special
character sequences.
IAC SB AUTHENTICATION <authentication-type-pair> CHALLENGE <encrypted
challenge> IAC SE
IAC SB AUTHENTICATION <authentication-type-pair> RESPONSE <encrypted
response> IAC SE
The "encrypted challenge" value sent/received in the CHALLENGE
command is also encrypted with the session key on both sides of
the session, to produce a random 8-byte key to be used as the de-
fault key for the ENCRYPTION option.
This may present vulnerability to a chosen plaintext attack. In
particular, someone observing the challenge will now have data that if
encrypted under the session key, gives away the store. The version 5
exchanges have been constructed in such away to make it difficult to
get such chosen plaintext encrypted, BUT there will be applications
that don't use the Kerberos routines for subsequent encryption, and
they might provide the path the attacker needs.
The above two concerns apply to the V4 authentication option as well.
The authenticator (Kerberos Principal) used is of the form
"rcmd.host at realm".
Several problems here. First, the text describing this should say
The Kerberos principal identifier for the telnet sever is of
the form:
Second, the form of the principal should be
rcmd/host at realm
Note that the "." is now a "/". You should then be even more explicit
by stating that rcmd is the first component of the principal name, and
that the full host name forms the second component, and you need to
specify that host is the primary fully qualified domain name for the
host in lower case. (a different rule applies in V4, one that can
cause some problems for interoperability).
Finally, the reason the first component of the name is "rcmd" is
historical: this principal identifier was used for the Berkeley R
commands and thus existed on just about every host. However, I think
that for V5, it might be time now to come up with a new convention,
and this might just be the right place to do it since it will be the
first time the form of a service principal name officially appears in
an RFC or similar document. I would suggest that instead of using the
string "rcmd" you use the string "host" as the first component.
~ Cliff
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09146;
19 Jun 92 22:50 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa05917;
19 Jun 92 22:51 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa05909;
19 Jun 92 22:50 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA07341; Fri, 19 Jun 92 21:50:56 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA07382; 4.1/CRI-5.5; Fri, 19 Jun 92 21:50:54 CDT
Received: from tsx-11.MIT.EDU by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA07338; Fri, 19 Jun 92 21:50:52 CDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA07290; Fri, 19 Jun 92 22:50:31 -0400
Date: Fri, 19 Jun 92 22:50:31 -0400
From: Theodore Ts'o <tytso at athena.mit.edu>
Message-Id: <9206200250.AA07290 at tsx-11.MIT.EDU>
To: bcn at isi.edu
Cc: stevea at i88.isc.com, dab at timbuk.cray.com, telnet-ietf at timbuk.cray.com,
prasad at isi.edu
In-Reply-To: Clifford Neuman's message of Fri, 19 Jun 1992 19:16:43 -0700,
<199206200216.AA02663 at tgo.isi.edu>
Subject: Re: Revised Kerberos V Draft
Reply-To: tytso at athena.mit.edu
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Fri, 19 Jun 1992 19:16:43 -0700
Posted-Date: Fri, 19 Jun 1992 19:16:43 -0700
Are you sure that you want to explicitly specify that the ticket and
authenticator is sent, as opposed to specifying that the Kerberos
Version 5 KRB_AP_REQ message (also known as an authentication header)
is sent. The KRB_AP_REQ message includes the authenticator and
ticket, plus some other bookkeeping information, much of which is
redundant with information you provide.
.... As you've specified it,
the client side must construct its own <kerberos ticket and
authenticator> by making several calls to the Kerberos code.
Well, actually, what *is* being sent is a KRB_AP_REQ message. I believe
I mentioned this in my previous message when I talked about "tightening
up wording". While what is in the protocol spec is technically true ---
a KRB_AP_REQ message contains a kerberos ticket and authenticator, as
well as some other bookkeeping information --- it does not specify _how_
the kerberos ticket and authenticator are to be sent. This is more of a
defect in wordsmithing, and not in the protocol design.
BTW, the same defect can be found in the V4 spec --- it specifies
<kerberos ticket and authenticator>, and what is actually sent in the
implementation is a V4 KRB_AP_REQ message.
A second concern here is what happens if the <kerberos ticket and
authenticator> which includes ciphertext, includes the sequence of
octets " IAC SE<CR>".....
If the IAC character occurs in the KRB_AP_REQ message, it is quoted
using the standard mechanism of doubling it: IAC IAC. This is already
specified in the RFC 854, but perhaps it might be a good thing to add a
sentence to remind implementors of this.
IAC SB AUTHENTICATION <authentication-type-pair> CHALLENGE <encrypted
challenge> IAC SE
IAC SB AUTHENTICATION <authentication-type-pair> RESPONSE <encrypted
response> IAC SE
This may present vulnerability to a chosen plaintext attack.....
I've proposed changing the V5 spec to use a KRB_AP_REP message instead
of this "roll-your-own" challenge/response protocol for mutual
authentication in a previous message, and I haven't heard any comments
so far. Since I haven't heard any objections, I'll work on the changes
to the draft and submit them to Steve either shortly before or at the
Boston IETF meeting. Perhaps if it is necessary, we can spend few
minutes talking about this at the IETF meeting.
- Ted
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09192;
19 Jun 92 23:25 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06590;
19 Jun 92 23:25 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05936>; Fri, 19 Jun 1992 12:26:31 -0700
From: Jon Postel <postel at isi.edu>
Received: from bel.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA05930>; Fri, 19 Jun 1992 12:26:22 -0700
Date: Fri, 19 Jun 1992 12:24:42 -0700
Posted-Date: Fri, 19 Jun 1992 12:24:42 -0700
Message-Id: <199206191924.AA21479 at bel.isi.edu>
Received: by bel.isi.edu (5.65c/4.0.3-4)
id <AA21479>; Fri, 19 Jun 1992 12:24:42 -0700
To: ietf at isi.edu, rfc-dist at nic.ddn.mil
Subject: RFC1346 on Resource Allocation, Control, and Accounting
Cc: jkrey at isi.edu
A new Request for Comments is now available in online RFC libraries.
RFC 1346:
Title: Resource Allocation, Control, and Accounting
for the Use of Network Resources
Author: P. Jones
Mailbox: p.jones at jnt.ac.uk
Pages: 6
Characters: 13,084
Obsoletes/Updates: none
This paper gives reasons for wanting better sharing mechanisms for
networks. It concludes that the challenge of sharing network resources
(and for example intercontinental link resources) between groups of
users is neither well understood, nor well catered for in terms of
tools for those responsible for managing the services. The situation
is compared with other fields, both inside and outside IT, and
examples are cited. Recommendations for further work are made.
The purpose of this RFC is to focus discussion on particular
challenges in large service networks in general, and the International
IP Internet in particular. No solution discussed in this document is
intended as a standard. Rather, it is hoped that a general consensus
will emerge as to the appropriate solutions, leading eventually to the
adoption of standards.
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at NRI.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.
RFCs can be obtained via FTP from FTP.NISC.SRI.COM, NIS.NSF.NET,
NISC.JVNC.NET, VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or 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 NIC at NIC.DDN.MIL. 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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
======================================================================
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09400;
20 Jun 92 0:30 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07962;
20 Jun 92 0:31 EDT
Received: from BITSY.MIT.EDU by NRI.Reston.VA.US id aa07956; 20 Jun 92 0:31 EDT
Received: by bitsy.MIT.EDU
id AA16046; Sat, 20 Jun 92 00:12:51 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA16040; Sat, 20 Jun 92 00:12:44 EDT
Received: from venera.isi.edu by MIT.EDU with SMTP
id AA01518; Sat, 20 Jun 92 00:12:39 EDT
Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA25985>; Fri, 19 Jun 1992 20:19:12 -0700
Date: Fri, 19 Jun 1992 20:17:48 -0700
Posted-Date: Fri, 19 Jun 1992 20:17:48 -0700
Message-Id: <199206200317.AA02684 at tgo.isi.edu>
Received: by tgo.isi.edu (5.65c/4.0.3-4)
id <AA02684>; Fri, 19 Jun 1992 20:17:48 -0700
From: Clifford Neuman <bcn at isi.edu>
Sender: bcn at isi.edu
To: ietf at isi.edu, saag at tis.com, cat-ietf at mit.edu
Subject: BOF on Authorization and Access Control (aac)
There will be a new BOF on Authorization and Access Control at the
July IETF. A description of the BOF follows. I'd appreciate it if
those with ideas for additional topics would let me know.
WEDNESDAY, July 15, 1992
7:00-10:00pm Evening Session
BOF Authorization and Access Control BOF (aac)
(Clifford Neuman/ISI)
Authorization and Access Control Mechanisms for the Internet
------------------------------------------------------------
A BOF has been scheduled to discuss authorization and access control
issues for the Internet. The discussion will center around two
problems: first, the need for a uniform method for specifying access
control information, and second on services and mechanisms for
managing authorization in the Internet.
Specifying Access Control Information
Several authentication mechanisms are now in place on the Internet.
These mechanisms include the use of passwords, simple assertion,
network addresses, trust in the identification of users by remote
hosts, and stronger methods such such as Kerberos and Digital
Equipment Corporation's DASS. Authorization mechanisms are usually
application specific and rely on a single authentication method.
We will discuss the methods used by various applications to specify
authorization information, in hopes of coming up with a common method
that can be applied across all applications. Such an approach should
allow the specification of the strength of the authentication method
to be used, as well as the identity of the individual.
Managing and Distributing Authorization Information
The second topic for discussion will be evolving mechanisms and
architectures for authorization in distributed systems. Among the
methods to be discussed are those used by the Open Software
Foundation's Distributed Computing Environment, the Digital
Distributed System Security Architecture, restricted proxies and
Kerberos, and the European Computer Manufacturers Association
standards. We will look for common characteristics among these
mechanisms and discuss what might be appropriate for the IETF to do in
this area.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00434;
20 Jun 92 5:54 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id ab03456; 20 Jun 92 5:55 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25991>; Fri, 19 Jun 1992 20:19:17 -0700
Received: from tgo.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA25985>; Fri, 19 Jun 1992 20:19:12 -0700
Date: Fri, 19 Jun 1992 20:17:48 -0700
Posted-Date: Fri, 19 Jun 1992 20:17:48 -0700
Message-Id: <199206200317.AA02684 at tgo.isi.edu>
Received: by tgo.isi.edu (5.65c/4.0.3-4)
id <AA02684>; Fri, 19 Jun 1992 20:17:48 -0700
From: Clifford Neuman <bcn at isi.edu>
Sender: bcn at isi.edu
To: ietf at isi.edu, saag at tis.com, cat-ietf at mit.edu
Subject: BOF on Authorization and Access Control (aac)
There will be a new BOF on Authorization and Access Control at the
July IETF. A description of the BOF follows. I'd appreciate it if
those with ideas for additional topics would let me know.
WEDNESDAY, July 15, 1992
7:00-10:00pm Evening Session
BOF Authorization and Access Control BOF (aac)
(Clifford Neuman/ISI)
Authorization and Access Control Mechanisms for the Internet
------------------------------------------------------------
A BOF has been scheduled to discuss authorization and access control
issues for the Internet. The discussion will center around two
problems: first, the need for a uniform method for specifying access
control information, and second on services and mechanisms for
managing authorization in the Internet.
Specifying Access Control Information
Several authentication mechanisms are now in place on the Internet.
These mechanisms include the use of passwords, simple assertion,
network addresses, trust in the identification of users by remote
hosts, and stronger methods such such as Kerberos and Digital
Equipment Corporation's DASS. Authorization mechanisms are usually
application specific and rely on a single authentication method.
We will discuss the methods used by various applications to specify
authorization information, in hopes of coming up with a common method
that can be applied across all applications. Such an approach should
allow the specification of the strength of the authentication method
to be used, as well as the identity of the individual.
Managing and Distributing Authorization Information
The second topic for discussion will be evolving mechanisms and
architectures for authorization in distributed systems. Among the
methods to be discussed are those used by the Open Software
Foundation's Distributed Computing Environment, the Digital
Distributed System Security Architecture, restricted proxies and
Kerberos, and the European Computer Manufacturers Association
standards. We will look for common characteristics among these
mechanisms and discuss what might be appropriate for the IETF to do in
this area.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05955;
22 Jun 92 14:24 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04452;
22 Jun 92 14:24 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22698>; Mon, 22 Jun 1992 07:44:44 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA22694>; Mon, 22 Jun 1992 07:44:41 -0700
Received: from [128.127.2.105] by NRI.Reston.VA.US id aa01482;
22 Jun 92 10:32 EDT
Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP
id AA11838; Mon, 22 Jun 92 10:36:12 -0400
Date: Mon, 22 Jun 92 10:36:12 -0400
Message-Id: <9206221436.AA11838 at ftp.com>
To: ietf at NRI.Reston.VA.US
Subject: Re: postscript
From: stev knowles <stev at ftp.com>
Sender: stev at ftp.com
Repository: babyoil.ftp.com
Originating-Client: d-cell.ftp.com
allow me to suggest a compromise, which will get a portion of what each side
wants:
for the time being, the primary copy of RFC's will be plain ASCII text.
RFC diagrams can be included in a seperate file, in PS format, which will
allow diagrams to be provide in a better form than allowable with current
ASCII technology:)
i have a feeling, but i am not a PS wizard, that most of the problem with
PS is related to the fact that the file may expect a specific font, while
the printer may not have it available, which causes the file to not print.
the above should solve this problem by restricting the PS files to diagrams
which, hopefully, will only be bitmap type stuff . . . .
i would also suggest a side option to deal with the postscript issue. if i
am correct about a large portion of the PS problem being the lack of font
deployment, a suggestion for fixing the problem would be to write a program
to fondle the file, changing the fonts to be ones that are localy available.
maybe the final solution will be for the IEFT to just define a set of
"standard" font abstractions (italics, bold, large, medium, small) which
could then allow us then to have some simple programs to do string
substitutions in the RFC files when we are preparing to print them.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13567;
22 Jun 92 16:37 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa22926;
22 Jun 92 16:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA26763>; Mon, 22 Jun 1992 09:21:30 -0700
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.65+local-6)
id <AA26755>; Mon, 22 Jun 1992 09:21:23 -0700
Message-Id: <199206221621.AA26755 at venera.isi.edu>
Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.28403-0 at bells.cs.ucl.ac.uk>; Mon, 22 Jun 1992 17:19:50 +0100
To: IETF <ietf at isi.edu>
Subject: the Extended Internet Protocol (EIP): a long-term solution
Date: Mon, 22 Jun 92 17:19:49 +0100
From: Zheng Wang <Z.Wang at cs.ucl.ac.uk>
A revised and more complete draft on EIP is available for
anonymous ftp from
beta.xerox.com transient/eip.txt
bells.cs.ucl.ac.uk docs/eip.txt
Enlosed below is the abstract. Comments on Big-Internet list please.
Cheers
Zheng
---------
EIP: The Extended Internet Protocol
a long-term solution to Internet address exhaustion
In this paper, we present the Extended Internet Protocol (EIP) which
provides a long-term solution to Internet address exhaustion. What we
propose here is not a new addressing and routing scheme, but a
framework in which any addressing and routing schemes can be
accommodated. The goal of EIP is to provide maximum flexibility to
accommodate any addressing and routing schemes yet to maintain
maximum backward compatibility with current IP. It can substantially
reduce the amount of modifications needed to the current Internet
systems and greatly ease the difficulties of transition. This is an
"idea" paper and discussion is strongly encouraged on Big-
Internet at munnari.oz.au. Distribution of this memo is unlimited.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14976;
22 Jun 92 18:18 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07136;
22 Jun 92 18:19 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05164>; Mon, 22 Jun 1992 11:51:13 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05160>; Mon, 22 Jun 1992 11:51:10 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa06915;
22 Jun 92 14:42 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-blaesing-transpro-mib-00.txt
Date: Mon, 22 Jun 92 14:42:18 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206221442.aa06915 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : ISO Transport Protocol (ISO 8072 & ISO 8073)
Management Information Base
Author(s) : Russell Blaesing, James Verploegh
Filename : draft-blaesing-transpro-mib-00.txt
Pages : 20
This memo defines an experimental version of an ISO Transport
Management Information Base for use with network management 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-blaesing-transpro-mib-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-blaesing-transpro-mib-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15029;
22 Jun 92 18:52 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa12037;
22 Jun 92 18:52 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa12033;
22 Jun 92 18:52 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA19765; Mon, 22 Jun 92 17:52:37 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA29571; 4.1/CRI-5.5; Mon, 22 Jun 92 17:52:35 CDT
Received: from relay.hp.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA19749; Mon, 22 Jun 92 17:51:56 CDT
Received: from hpindvh.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA09357; Mon, 22 Jun 92 15:51:49 -0700
Received: by hpindsy.cup.hp.com with SMTP
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA10261; Mon, 22 Jun 92 15:52:09 pdt
To: telnet-ietf at timbuk.cray.com
Subject: Re: Revised Environment Draft
In-Reply-To: Your message of "Tue, 16 Jun 92 07:15:17 PDT."
<9206161215.AA02888 at ozzy.i88.isc.com>
Date: Mon, 22 Jun 92 15:52:07 PDT
Message-Id: <10259.709253527 at hpindvh.cup.hp.com>
From: Marjo Mercado <marjo at hpindsy.cup.hp.com>
Hi,
We have implemented the Environment Draft and we have an
implementation question. We realize that this may turn out to be a
general Telnet implementation question, independent of the Environ
option.
What is the correct and proper behavior or response, if any, in cases
where we agree to do ENV option negotiation but we ask for values of
variables the other side does not know about? How should the remote
side respond?
The BSD 4.3 Tahoe based implementation on Sun Microsystems' PC-NFS
product responds by sending a well formed answer with no variable
values specified.
Geoff Arnold of Sun Microsystems has posted a similar question, but no
one has responded on this mailing list.
By the way, is there an agenda for the Working Group meeting yet?
Regards,
Marjo Mercado
Hewlett Packard Company
(408) 447-2826
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15297;
22 Jun 92 22:07 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11908;
22 Jun 92 22:07 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05182>; Mon, 22 Jun 1992 11:51:31 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05175>; Mon, 22 Jun 1992 11:51:20 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa06955;
22 Jun 92 14:46 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-x400ops-mgtdomains-01.txt
Date: Mon, 22 Jun 92 14:46:29 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206221446.aa06955 at IETF.NRI.Reston.VA.US>
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 : Operational Requirements for X.400 Management
Domains
Author(s) : Robert Hagens, Alf Hansen
Filename : draft-ietf-x400ops-mgtdomains-01.txt
Pages : 16
Abstract not provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-x400ops-mgtdomains-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-x400ops-mgtdomains-01.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15339;
22 Jun 92 23:32 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa23154;
22 Jun 92 23:33 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05173>; Mon, 22 Jun 1992 11:51:22 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05165>; Mon, 22 Jun 1992 11:51:14 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa06926;
22 Jun 92 14:43 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-iplpdn-directed_arp-00.txt
Date: Mon, 22 Jun 92 14:43:43 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206221443.aa06926 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
IP over Large Public Data Networks Working Group of the IETF.
Title : Directed ARP
Author(s) : John Garrett, John Hagan, Jeff Wong
Filename : draft-ietf-iplpdn-directed_arp-00.txt
Pages : 7
A router with an interface to two IP networks via the same link level
interface could observe that the two IP networks share the same link
level network, and could advertise that information to hosts (via ICMP
Redirects) and routers (via dynamic routing protocols). However, a
host or router on only one of the IP networks could not use that
information to communicate directly with hosts and routers on the
other IP network unless it could resolve IP addresses on the "foreign"
IP network to their corresponding link level addresses. Directed ARP
is a dynamic address resolution procedure that enables hosts and
routers to resolve advertised potential next-hop IP addresses on
foreign IP networks to their associated link level 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-iplpdn-directed_arp-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-iplpdn-directed_arp-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15397;
22 Jun 92 23:58 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa26616;
22 Jun 92 23:59 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05579>; Mon, 22 Jun 1992 12:01:41 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05560>; Mon, 22 Jun 1992 12:01:28 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07299;
22 Jun 92 14:49 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-decnet-01.txt
Date: Mon, 22 Jun 92 14:49:34 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206221449.aa07299 at IETF.NRI.Reston.VA.US>
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 : Point-to-Point Protocol Extensions for DECnet Phase
IV
Author(s) : Steven Senum
Filename : draft-ietf-pppext-decnet-01.txt
Pages : 8
The Point-to-Point Protocol (PPP) provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links. PPP also defines an extensible Link Control Protocol, and
proposes a family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
This document defines the NCP for establishing and configuring
Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
This document applies only to DNA Phase IV Routing messages (both data
and control), and not to other DNA Phase IV protocols (MOP, LAT,etc).
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-decnet-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-pppext-decnet-01.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15533;
23 Jun 92 0:25 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00960; 23 Jun 92 0:25 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05188>; Mon, 22 Jun 1992 11:51:34 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05174>; Mon, 22 Jun 1992 11:51:20 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa06962;
22 Jun 92 14:47 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-cat-genericsec-01.txt, .ps
Date: Mon, 22 Jun 92 14:47:01 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206221447.aa06962 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Common Authentication Technology Working Group of the IETF.
Title : Generic Security Service Application Program
Interface
Author(s) : John Linn
Filename : draft-ietf-cat-genericsec-01.txt, .ps
Pages : 61
This Internet-Draft proposes a Generic Security Service Application
Program Interface (GSS-API) definition, providing security services to
callers in a generic fashion which is supportable with a range of
underlying mechanisms and technologies. Security contexts are
established between peers, accomplishing peer entity authentication
and providing the basis for subsequent per-message data origin
authentication, integrity, and confidentiality protection services in
conjunction with those contexts.
This memo defines GSS-API services and primitives at a level which is
independent of underlying security mechanism and programming language
environment, and is to be complemented by related documents defining
parameter bindings for particular language environments and defining
token formats, protocols, and procedures to be implemented in order to
realize GSS-API services atop a variety of underlying security
mechanisms.
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-genericsec-01.txt" or
"get draft-ietf-cat-genericsec-01.ps"
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-cat-genericsec-01.txt" or
"SEND internet-drafts/draft-ietf-cat-genericsec-01.ps"
For questions, please mail to internet-drafts at nri.reston.va.us.
------- End of Forwarded Message
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15766;
23 Jun 92 1:31 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07735; 23 Jun 92 1:32 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08381>; Mon, 22 Jun 1992 12:56:41 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AB08376>; Mon, 22 Jun 1992 12:56:38 -0700
Received: from MITCHELL.CIT.CORNELL.EDU by NRI.Reston.VA.US id aa14955;
22 Jun 92 15:37 EDT
Received: from FALCON.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3)
id AA09768; Mon, 22 Jun 92 15:36:53 EDT
Message-Id: <9206221936.AA09768 at mitchell.cit.cornell.edu>
To: stev knowles <stev at ftp.com>
Cc: ietf at NRI.Reston.VA.US
Reply-To: swb at nr-tech.cit.cornell.edu
Subject: Re: postscript
In-Reply-To: stev knowles's message of Mon, 22 Jun 92 10:36:12 -0500.
<9206221436.AA11838 at ftp.com>
Date: Mon, 22 Jun 92 15:36:51 -0400
From: Scott Brim <swb at nr-tech.cit.cornell.edu>
Fonts don't usually cause my problems. Instead it's things like certain
printers not letting you load alternative dictionaries or not
understanding some commands. On something I just tried I got a stack
underflow (although it printed fine on a different printer). The
formatting packages generally do all of this in the preamble, which is
almost always included whether it's needed or not.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03244;
23 Jun 92 7:08 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04224; 23 Jun 92 7:08 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA12067>; Mon, 22 Jun 1992 14:12:14 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA12063>; Mon, 22 Jun 1992 14:12:11 -0700
Received: from WLV.IMSD.CONTEL.COM by NRI.Reston.VA.US id aa27085;
22 Jun 92 17:06 EDT
Received: by WLV.IMSD.CONTEL.COM (5.65/1.35)
id AA12415; Mon, 22 Jun 92 14:06:30 -0700
Date: Mon, 22 Jun 92 14:06:30 -0700
From: Merton Campbell Crockett <mcc at wlv.imsd.contel.com>
Message-Id: <9206222106.AA12415 at WLV.IMSD.CONTEL.COM>
To: ietf at NRI.Reston.VA.US, stev at ftp.com
Subject: Re: postscript
Another solution would be to have three sets of files for each RFC. The
immediately usable ASCII form, the PostScript form, and the raw form. The
raw form would be in the format of the editor, word processor, etc. used by the
author to prepare the document.
Assuming that I have the equivalent editor, word processor, etc. or have one
that deals with the particular format; I can generate the document for what-
ever printers I have available and don't have to worry about PostScript
incompatibilities. Pagination always seems to be a problem. I always seem
to end up with some little bit that rolls to the next page owing to white
space requirements of the printer.
Merton Campbell Crockett
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03798;
23 Jun 92 9:03 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa07581;
23 Jun 92 9:03 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa07577;
23 Jun 92 9:03 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA25573; Tue, 23 Jun 92 08:03:46 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA19218; 4.1/CRI-5.5; Tue, 23 Jun 92 08:03:45 CDT
Received: from laidbak.i88.isc.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA25568; Tue, 23 Jun 92 08:03:41 CDT
Received: from ozzy.i88.isc.com by laidbak.i88.isc.com with SMTP
(5.65/isc-mail-gw/5/18/92) id AA12112; Tue, 23 Jun 92 08:03:38 -0500
Received: from localhost by ozzy.i88.isc.com (4.1/SMI-4.1)
id AA12215; Tue, 23 Jun 92 08:03:01 CDT
Message-Id: <9206231303.AA12215 at ozzy.i88.isc.com>
To: Marjo Mercado <marjo at hpindsy.cup.hp.com>
Cc: telnet-ietf at timbuk.cray.com
Subject: Re: Revised Environment Draft
In-Reply-To: Message from marjo at hpindsy.cup.hp.com of 22 Jun 92 15:52:07 PDT
Date: Tue, 23 Jun 92 08:03:00 -0500
From: Steve Alexander <stevea at i88.isc.com>
Well, as far as I am able to determine by looking at telnet[d].91.03.25,
telnet is doing what the author intends it to do. I notice that it does
a similar thing for TERMINAL TYPE if $TERM (on a UNIX client) is NULL.
RFC 854/5 say nothing about whether it is legal for there to be no data
between the SB and the SE. It would probably be good if the draft said
something about this condition; the behavior seems reasonable to me. If no
one objects, I will add a note about the expected behavior in the face of an
empty environment. Otherwise, someone please feel free to point out why this
behavior would be bad.
WRT the agenda, I don't have one yet. As always, we can talk about anything
that's telnet related. If I manage to come up for air, I hope to have a
strawman for merged authentication/encryption. Otherwise, there may not be
much point in meeting. I haven't received many comments on the drafts sent
out last week, with the exception of Kerberos V, which thankfully is being
worked on by someone more familiar with Kerberos V than I am. So it seems
like either most people are happy with the drafts, or they've been too busy
to look at them. If it's the latter, I encourage everyone to look at in the
next couple of days so I can send them off to Internet-Draft land and widen
the reviewing audience. It would be good to get some of these things off of
our plate.
-- Steve
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04694;
23 Jun 92 10:08 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04690;
23 Jun 92 10:08 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa14815;
23 Jun 92 10:09 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA29529; Tue, 23 Jun 92 09:09:10 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA23642; 4.1/CRI-5.5; Tue, 23 Jun 92 09:09:07 CDT
Received: from handel.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA29511; Tue, 23 Jun 92 09:09:06 CDT
Received: by handel.cray.com
id AA06130; 5.57/CRI-5.5; Tue, 23 Jun 92 09:08:11 -0500
Date: Tue, 23 Jun 92 09:08:11 -0500
From: "David A. Borman" <dab at berserkly.cray.com>
Message-Id: <9206231408.AA06130 at handel.cray.com>
To: marjo at hpindsy.cup.hp.com, telnet-ietf at timbuk.cray.com
Subject: Re: Revised Environment Draft
The correct thing to do is to inform the requesting side that the
variable is undefined. This is allowed for in the spec. Say the
server asked the client what the values were for "foo", "bar", and "junk",
and the client only had a value for "bar". Both "foo" and "junk" are
undefined in the client. The proper response (assuming they are
all well-defined variables) would be:
IAC SB ENVIRON IS VAR "foo" VAR "bar" VALUE "something"
VAR "junk" IAC SE
The ``VAR "foo"'' is immediatly followed by the next VAR/USERVAR,
or IAC SE to indicate that it is undefined. To indicate that it
is defined, but has no value, you would send ``VAR "foo" VALUE''.
Read the description on page 2 for ``IAC SB ENVIRON IS''
-David Borman, dab at cray.com
> From marjo at hpindsy.cup.hp.com Mon Jun 22 17:52:37 1992
> To: telnet-ietf at cray.com
> Subject: Re: Revised Environment Draft
> Date: Mon, 22 Jun 92 15:52:07 PDT
> From: Marjo Mercado <marjo at hpindsy.cup.hp.com>
>
> Hi,
>
> We have implemented the Environment Draft and we have an
> implementation question. We realize that this may turn out to be a
> general Telnet implementation question, independent of the Environ
> option.
>
> What is the correct and proper behavior or response, if any, in cases
> where we agree to do ENV option negotiation but we ask for values of
> variables the other side does not know about? How should the remote
> side respond?
>
> The BSD 4.3 Tahoe based implementation on Sun Microsystems' PC-NFS
> product responds by sending a well formed answer with no variable
> values specified.
>
> Geoff Arnold of Sun Microsystems has posted a similar question, but no
> one has responded on this mailing list.
>
> By the way, is there an agenda for the Working Group meeting yet?
>
> Regards,
>
> Marjo Mercado
> Hewlett Packard Company
> (408) 447-2826
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05180;
23 Jun 92 10:52 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa20880;
23 Jun 92 10:52 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08104>; Tue, 23 Jun 1992 05:16:13 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA08100>; Tue, 23 Jun 1992 05:16:03 -0700
Received: from THOR.INNOSOFT.COM by NRI.Reston.VA.US id aa05841;
23 Jun 92 8:11 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF #1336 ) id
<01GLJIMYVPB49D4DHK at INNOSOFT.COM>; Tue, 23 Jun 1992 05:10:24 PDT
Date: 23 Jun 1992 05:10:24 -0700 (PDT)
From: Ned Freed <NED at innosoft.com>
Subject: Re: postscript
To: swb at nr-tech.cit.cornell.edu
Cc: ietf at NRI.Reston.VA.US
Message-Id: <01GLJIMYVPB69D4DHK at INNOSOFT.COM>
X-Envelope-To: ietf at nri.reston.va.us
X-Vms-To: IN%"swb at nr-tech.cit.cornell.edu"
X-Vms-Cc: IN%"ietf at nri.reston.va.us"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN
Content-Transfer-Encoding: 7BIT
I agree with Scott on this -- fonts are almost never the problem these
days. The basic set of Abode fonts have become so widespread that it is
a rare thing to find PostScript that expects to find other fonts in the
hardware of the drawing engine.
Scott is also correct in saying that things like alternate dictionaries for
various environments are usually the underlying cause of a lot of failures.
Things like dictionaries that don't allow for enough entries are one example
of this; there are many others.
Finally, another common problem with PostScript documents is their handling
a files. PostScript is at its base a raw stream of bytes. The fact that
most PostScript is somewhat readable in no way implies that all PostScript
can be treated as readable. People are forever transferring PostScript
using tools appropriate for ASCII files and getting themselves burned.
I feel compelled to point out that the solution to most of these
interoperability problems is pretty simple. Just set up a group of
test devices that all PostScript RFCs have to be able to print on them, and
don't allow documents that fail on one or more of these devices into the
process. Even a single test device will catch most of the problems, I
believe.
Ned
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05198;
23 Jun 92 11:04 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05194;
23 Jun 92 11:04 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa22553;
23 Jun 92 11:04 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA03594; Tue, 23 Jun 92 10:04:54 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA28393; 4.1/CRI-5.5; Tue, 23 Jun 92 10:04:51 CDT
Received: from handel.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA03588; Tue, 23 Jun 92 10:04:49 CDT
Received: by handel.cray.com
id AA06172; 5.57/CRI-5.5; Tue, 23 Jun 92 10:03:54 -0500
Date: Tue, 23 Jun 92 10:03:54 -0500
From: "David A. Borman" <dab at berserkly.cray.com>
Message-Id: <9206231503.AA06172 at handel.cray.com>
To: marjo at hpindsy.cup.hp.com, stevea at i88.isc.com
Subject: Re: Revised Environment Draft
Cc: telnet-ietf at timbuk.cray.com
The description of the "IAC SB ENVIRON IS" explicitly states that
not only should the IS command contain a response for each variable
received in a SEND command, it must format them in the same order.
Sending back an empty IS command in response to a request for a
specific environment variable is just plain wrong.
The server could very well be waiting for the ENVIRON IS command
before proceeding with the login procedure (on UNIX systems, you
have to set up the environment before you can exec login). The
only way for the server to know that the client doesn't have a
value for a variable that it requested is for the client to explicitly
tell it so.
It should be perfectly legal to have no data between the SB and SE.
An ``IAC SB ENVIRON IS IAC SB'' is a valid response to:
``IAC SB ENVIRON SEND IAC SB''
``IAC SB ENVIRON SEND VAR IAC SB''
``IAC SB ENVIRON SEND USERVAR IAC SB''
``IAC SB ENVIRON SEND VAR USERVAR IAC SB''
(the last is the equivialant to the first...)
In all these cases, the server is saying "send me your default (well
defined/user defined) environment", and the client is saying "nothing
is defined in the default (well defined/user defined) environment".
I thought that the description of the IS command was quite specific
about all of this.
The "type"/VALUE must be returned in the same order as
the SEND request specified them.
and:
If a "type" is not followed by a VALUE (e.g., by
another VAR or an IAC) then that variable is undefined.
I guess it's not quite clear enough. Perhaps these two sentences
should be changed to:
The "type ..."/VALUE must be returned in the same order as
the SEND request specified them, and there must be a
response for each "type ..." explicitly requested.
and:
If a "type ..." is not followed by a VALUE (e.g., by
another VAR, USERVAR or IAC SE) then that variable is
undefined. If the VALUE after a "type ..." is followed is
immediatly followed by VAR, USERVAR, or IAC SE, then
that variable is defined, but has no value.
Any comments or better suggestions?
-David Borman, dab at cray.com
> From stevea at i88.isc.com Tue Jun 23 08:03:47 1992
> To: Marjo Mercado <marjo at hpindsy.cup.hp.com>
> Cc: telnet-ietf at cray.com
> Subject: Re: Revised Environment Draft
> Date: Tue, 23 Jun 92 08:03:00 -0500
> From: Steve Alexander <stevea at i88.isc.com>
>
> Well, as far as I am able to determine by looking at telnet[d].91.03.25,
> telnet is doing what the author intends it to do. I notice that it does
> a similar thing for TERMINAL TYPE if $TERM (on a UNIX client) is NULL.
> RFC 854/5 say nothing about whether it is legal for there to be no data
> between the SB and the SE. It would probably be good if the draft said
> something about this condition; the behavior seems reasonable to me. If no
> one objects, I will add a note about the expected behavior in the face of an
> empty environment. Otherwise, someone please feel free to point out why this
> behavior would be bad.
>
> WRT the agenda, I don't have one yet. As always, we can talk about anything
> that's telnet related. If I manage to come up for air, I hope to have a
> strawman for merged authentication/encryption. Otherwise, there may not be
> much point in meeting. I haven't received many comments on the drafts sent
> out last week, with the exception of Kerberos V, which thankfully is being
> worked on by someone more familiar with Kerberos V than I am. So it seems
> like either most people are happy with the drafts, or they've been too busy
> to look at them. If it's the latter, I encourage everyone to look at in the
> next couple of days so I can send them off to Internet-Draft land and widen
> the reviewing audience. It would be good to get some of these things off of
> our plate.
>
> -- Steve
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05609;
23 Jun 92 12:17 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05605;
23 Jun 92 12:17 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa05085;
23 Jun 92 12:17 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA08368; Tue, 23 Jun 92 11:17:36 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA03332; 4.1/CRI-5.5; Tue, 23 Jun 92 11:17:30 CDT
Received: from laidbak.i88.isc.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA08365; Tue, 23 Jun 92 11:17:27 CDT
Received: from ozzy.i88.isc.com by laidbak.i88.isc.com with SMTP
(5.65/isc-mail-gw/5/18/92) id AA16287; Tue, 23 Jun 92 11:17:08 -0500
Received: from localhost by ozzy.i88.isc.com (4.1/SMI-4.1)
id AA12345; Tue, 23 Jun 92 11:16:38 CDT
Message-Id: <9206231616.AA12345 at ozzy.i88.isc.com>
To: "David A. Borman" <dab at berserkly.cray.com>
Cc: marjo at hpindsy.cup.hp.com, telnet-ietf at timbuk.cray.com
Subject: Re: Revised Environment Draft
In-Reply-To: Message from dab at berserkly.cray.com of 23 Jun 92 10:03:54 CDT
Date: Tue, 23 Jun 92 11:16:37 -0500
From: Steve Alexander <stevea at i88.isc.com>
I think I see the confusion. The scenario that I observed with telnet.91.03.25
was as follows:
RCVD IAC SB ENVIRON SEND
SENT IAC SB ENVIRON IS
Essentially, the server asked for the default environment and got an empty one
back. This is what I thought Marjo meant; I should have read his mail more
carefully. I did not mean to imply that sending back an empty IS to a
request for a specific variable was the correct behavior.
Sorry,
-- Steve
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06351;
23 Jun 92 13:04 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14517;
23 Jun 92 13:05 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA10495>; Tue, 23 Jun 1992 06:18:15 -0700
Received: from life.ai.mit.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA10490>; Tue, 23 Jun 1992 06:18:10 -0700
Received: by life.ai.mit.edu (4.1/AI-4.10) id AA06474; Tue, 23 Jun 92 09:16:44 EDT
Date: Tue, 23 Jun 92 09:16:44 EDT
From: "Leonard H. Tower Jr." <tower at ai.mit.edu>
Message-Id: <9206231316.AA06474 at life.ai.mit.edu>
To: swb at nr-tech.cit.cornell.edu
Subject: Re: postscript
Cc: ietf at isi.edu
Date: Mon, 22 Jun 92 15:36:51 -0400
From: Scott Brim <swb at nr-tech.cit.cornell.edu>
Fonts don't usually cause my problems. Instead it's things like certain
printers not letting you load alternative dictionaries or not
understanding some commands. On something I just tried I got a stack
underflow (although it printed fine on a different printer). The
formatting packages generally do all of this in the preamble, which is
almost always included whether it's needed or not.
Two other solutions (made without any analysis):
1) a tool that checks if a postscript RFC meet the common intersection
of all postscript implementations in use by the Internet community.
RFCs that don't pass the tool are sent back for more editing.
2) a requirment that all Postscript RFCs work with a freely available
Postscript intrepreter. (ghostscript? ;-) RFCs that don't work with
the reference postscript are sent back for more editing.
enjoy -len
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08910;
23 Jun 92 16:26 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16860;
23 Jun 92 16:27 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AB11335>; Tue, 23 Jun 1992 06:44:55 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA11330>; Tue, 23 Jun 1992 06:44:52 -0700
Received: from babyoil.ftp.com by NRI.Reston.VA.US id aa09828;
23 Jun 92 9:36 EDT
Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP
id AA08073; Tue, 23 Jun 92 09:40:31 -0400
Date: Tue, 23 Jun 92 09:40:31 -0400
Message-Id: <9206231340.AA08073 at ftp.com>
To: ietf at NRI.Reston.VA.US
Subject: Sun RPC program IDs
From: "James B. Van Bokkelen" <jbvb at ftp.com>
Reply-To: jbvb at ftp.com
Sender: jbvb at ftp.com
Repository: babyoil.ftp.com
Originating-Client: plug.ftp.com
It has recently come to my attention that Sun Microsystems is not publishing
a current list of registered RPC programs. Their reasoning is that some
of those who've requested registration want the IDs kept secret, and they
haven't kept track of which, so they can't print anything since that long-
ago day when almost all of the registered programs were Sun's. This doesn't
make Sun RPC any easier to manage or support.
Now, nobody's ever asked me for a Packet Driver interface type with the
requirement that I not publish it, so maybe I haven't been tempered in
the proper fire, but I do wish that people wouldn't create situations
like this. Any vendor types want to make a defense of secret IDs other
than "security through obscurity"? Anyone from Sun want to comment?
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa12919;
23 Jun 92 18:46 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07718;
23 Jun 92 18:47 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA18847>; Tue, 23 Jun 1992 09:28:57 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA18842>; Tue, 23 Jun 1992 09:28:54 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05839;
23 Jun 92 12:26 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-secmib-00.txt
Date: Tue, 23 Jun 92 12:26:38 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206231226.aa05839 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Point-to-Point Protocol Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the Security
Protocols of the Point-to-Point Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-secmib-00.txt
Pages : 30
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 describes managed objects
used for managing the Security Protocols on subnetwork interfaces
using the family of Point-to-Point 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-secmib-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-pppext-secmib-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa25108;
23 Jun 92 19:40 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16811;
23 Jun 92 19:41 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA18839>; Tue, 23 Jun 1992 09:28:52 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA18832>; Tue, 23 Jun 1992 09:28:48 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05777;
23 Jun 92 12:23 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-bridgemib-00.txt
Date: Tue, 23 Jun 92 12:23:43 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206231223.aa05777 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Point-to-Point Protocol Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the Bridge
Network Control Protocol of the Point-to-Point
Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-bridgemib-00.txt
Pages : 25
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 describes managed objects
used for managing the bridge Network Control Protocol on subnetwork
interfaces using the family of Point-to-Point 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-bridgemib-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-pppext-bridgemib-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa26136;
23 Jun 92 21:15 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa02306;
23 Jun 92 21:15 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA19283>; Tue, 23 Jun 1992 09:37:43 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA19278>; Tue, 23 Jun 1992 09:37:40 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05914;
23 Jun 92 12:30 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-lcpmib-00.txt
Date: Tue, 23 Jun 92 12:30:02 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206231230.aa05914 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Point-to-Point Protocol Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the Link
Control Protocol of the Point-to-Point Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-lcpmib-00.txt
Pages : 34
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 describes managed objects
used for managing the Link Control Protocol and Link Quality
Monitoring on subnetwork interfaces that use the family of
Point-to-Point 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-lcpmib-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-pppext-lcpmib-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa26217;
23 Jun 92 22:17 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12869;
23 Jun 92 22:18 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA19337>; Tue, 23 Jun 1992 09:39:04 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA19333>; Tue, 23 Jun 1992 09:38:59 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa06009;
23 Jun 92 12:35 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-ipcpmib-00.txt
Date: Tue, 23 Jun 92 12:35:57 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206231235.aa06009 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Point-to-Point Protocol Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the IP
Network Control Protocol of the Point-to-Point
Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-ipcpmib-00.txt
Pages : 18
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 describes managed objects
used for managing the IP Network Control Protocol on subnetwork
interfaces using the family of Point-to-Point 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-ipcpmib-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-pppext-ipcpmib-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa26273;
23 Jun 92 22:31 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa26269;
23 Jun 92 22:30 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa15097;
23 Jun 92 22:31 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA08285; Tue, 23 Jun 92 21:31:31 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA01116; 4.1/CRI-5.5; Tue, 23 Jun 92 21:31:29 CDT
Received: from mnementh.cs.adfa.oz.au by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA08279; Tue, 23 Jun 92 21:31:24 CDT
Received: by mnementh.cs.adfa.oz.au (5.64/1.34)
id AA16647; Wed, 24 Jun 92 12:31:18 +1000
Message-Id: <9206240231.AA16647 at mnementh.cs.adfa.oz.au>
From: Lawrie.Brown at adfa.oz.au
Date: Wed, 24 Jun 1992 12:31:17 +1000
In-Reply-To: Steve Alexander <stevea at i88.isc.com>
"Revised Kerberos IV Draft" (Jun 16, 7:15am)
X-The-Answer: To Life, the Universe, and Everything . . . is 42
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: telnet-ietf at timbuk.cray.com
Subject: Re: Revised Kerberos IV Draft
I have one query about both the Kerberos v4 & v5 drafts.
In section 2 detailing the Command Meanings I believe the IS and REPLY
suboption commands have been left out, though they are shown in the
examples in section 4. If they have been left out, then they need to
be re-inserted, otherwise I have some real reservations about the
changed format.
The authentication option draft appears fine.
Cheers
Lawrie.
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa26289;
23 Jun 92 22:35 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa26285;
23 Jun 92 22:35 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa15910;
23 Jun 92 22:36 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA08777; Tue, 23 Jun 92 21:36:08 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA01211; 4.1/CRI-5.5; Tue, 23 Jun 92 21:36:06 CDT
Received: from mnementh.cs.adfa.oz.au by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA08774; Tue, 23 Jun 92 21:36:00 CDT
Received: by mnementh.cs.adfa.oz.au (5.64/1.34)
id AA16684; Wed, 24 Jun 92 12:35:56 +1000
Message-Id: <9206240235.AA16684 at mnementh.cs.adfa.oz.au>
From: Lawrie.Brown at adfa.oz.au
Date: Wed, 24 Jun 1992 12:35:56 +1000
In-Reply-To: Steve Alexander <stevea at i88.isc.com>
"Revised Environment Draft" (Jun 16, 7:15am)
X-The-Answer: To Life, the Universe, and Everything . . . is 42
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: telnet-ietf at timbuk.cray.com
Subject: Re: Revised Environment Draft
I have one minor editorial query about this draft. In section 2 page 2,
the definitions for SEND & IS refer to type
whilst in the definition for INFO "type" is used. I don't believe the
quotes should be present in the latter case.
Apart from that I have no other comments.
Regards
Lawrie.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa26491;
23 Jun 92 23:15 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa23105;
23 Jun 92 23:15 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20743>; Tue, 23 Jun 1992 10:06:17 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA20739>; Tue, 23 Jun 1992 10:06:12 -0700
Date: Tue, 23 Jun 1992 10:04:41 -0700
Posted-Date: Tue, 23 Jun 1992 10:04:41 -0700
Message-Id: <199206231704.AA01140 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA01140>; Tue, 23 Jun 1992 10:04:41 -0700
To: ietf at isi.edu
Subject: Re: Protocol Action: SNMP Security to Proposed Standard
Cc: iab at isi.edu, iab-stds at isi.edu, iesg at isi.edu
At IAB meeting last week, the IAB approved the IESG recommendation that
the Internet Drafts:
o "SNMP Administrative Model",
<draft-ietf-snmpsec-admin-02>,
o "SNMP Security Protocols"
<draft-ietf-snmpsec-protocols-02>, and
o "Definitions of Managed Objects for Administration of SNMP Parties"
<draft-ietf-snmpsec-mib-02>
be published as Proposed Standards. These documents are products of
the SNMP Security Working Group of the IETF.
Bob Braden for the IAB
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00274;
24 Jun 92 3:23 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08232; 24 Jun 92 3:24 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA12121>; Tue, 23 Jun 1992 17:47:58 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA12117>; Tue, 23 Jun 1992 17:47:54 -0700
Received: from Sun.COM by NRI.Reston.VA.US id aa26028; 23 Jun 92 20:39 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA27540; Tue, 23 Jun 92 17:39:07 PDT
Received: from camilla.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA10745; Tue, 23 Jun 92 17:39:10 PDT
Received: from rand.Eng.Sun.COM by camilla.Eng.Sun.COM (4.1/SMI-4.1)
id AA19167; Tue, 23 Jun 92 17:39:00 PDT
Date: Tue, 23 Jun 92 17:39:00 PDT
From: Steve Nahm <sxn at camilla.eng.sun.com>
Message-Id: <9206240039.AA19167 at camilla.Eng.Sun.COM>
To: ietf at NRI.Reston.VA.US
Subject: Re: Sun RPC program IDs
"James B. Van Bokkelen" <jbvb at ftp.com> writes:
>It has recently come to my attention that Sun Microsystems is not publishing
>a current list of registered RPC programs. Their reasoning is that some
>of those who've requested registration want the IDs kept secret, and they
>haven't kept track of which, so they can't print anything since that long-
>ago day when almost all of the registered programs were Sun's.
The reason that Sun registers RPC numbers is to avoid RPC program
number collision. Sun wouldn't be registering RPC numbers at all
if this wasn't an issue.
An RPC application, like any other application, is the property of
those who implement it. Sun has no rights to make details of
a proprietary application public unless it is given permission
to do so. [The question of *why* someone would want to keep an
RPC protocol confidential is not relevant to this discussion.]
Even if we were given permission, Sun could not publish a complete
list. We occasionally get requests for blocks of numbers. The vendor
assigns numbers itself to applications that it develops. We usually
never hear from them after they get the block, so we clearly do not
have a comprehensive list of RPC protocols.
If the developer of an RPC application wants to publish the
specification for its protocol, they can certainly do that. Sun should
simply keep its side of the number assignment bargain by making sure
numbers are unique.
>This doesn't make Sun RPC any easier to manage or support.
And it doesn't make it any harder either. Every application that
uses UDP implements a user-level protocol; does the lack of publishing
every UDP application protocol make UDP less easy to manage or support?
You should be looking to your application vendor for solutions to
management and support problems you perceive.
Steve Nahm
Sun RPC Project Leader
PS: If all this talk about Sun RPC and RPC program numbers gets people
writing more RPC applications, the procedure for registering
an RPC program number is documented in the RPC Programming Guide:
To register a protocol specification, send a request by network mail to
rpc at sun.com, or write to:
RPC Administrator
Sun Microsystems, Inc.
2550 Garcia Avenue
Mountain View, CA 94043
(email is preferred)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00511;
24 Jun 92 6:30 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00902; 24 Jun 92 6:31 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08635>; Tue, 23 Jun 1992 16:28:15 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA08631>; Tue, 23 Jun 1992 16:28:13 -0700
Received: from uu.psi.com by NRI.Reston.VA.US id aa13269; 23 Jun 92 19:20 EDT
Received: from fibermux.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
id AA09077; Tue, 23 Jun 92 18:32:35 -0400
Received: from ccrelay.fibermux.com by fibermux.com (4.1/SMI-4.1)
id AA28518; Tue, 23 Jun 92 11:30:01 PDT
Received: from cc:Mail by ccrelay.fibermux.com (1.20/SMTPLink)
id A32171; Tue, 23 Jun 92 11:32:09 PST
Date: Tue, 23 Jun 92 11:32:09 PST
From: MICHAEL SUNG <msung at ccrelay.fibermux.com>
Message-Id: <9206231132.A32171 at ccrelay.fibermux.com>
To: ietf at NRI.Reston.VA.US
Cc: ietf-info at NRI.Reston.VA.US
Subject: IETF Plenary meeting in Boston
Hi,
Can anyone provide me with information on the next plenary
meeting at Boston in July? Such as the location, how to make
travel arrangement, and meeting schedule and agenda etc. ?
Or whom I can contact to get this information ?
I just became a subscriber and I must have missed all these
wonderful informations.
My mailing address is msung at fibermux.com.
Thanks!!!!!
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04350;
24 Jun 92 9:25 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04346;
24 Jun 92 9:25 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa07771;
24 Jun 92 9:26 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA08837; Wed, 24 Jun 92 08:26:07 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA16811; 4.1/CRI-5.5; Wed, 24 Jun 92 08:26:04 CDT
Received: from handel.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA08830; Wed, 24 Jun 92 08:26:02 CDT
Received: by handel.cray.com
id AA06848; 5.57/CRI-5.5; Wed, 24 Jun 92 08:25:05 -0500
Date: Wed, 24 Jun 92 08:25:05 -0500
From: "David A. Borman" <dab at berserkly.cray.com>
Message-Id: <9206241325.AA06848 at handel.cray.com>
To: Lawrie.Brown at adfa.oz.au, telnet-ietf at timbuk.cray.com
Subject: Re: Revised Kerberos IV Draft
> From lpb at mnementh.cs.adfa.oz.au Tue Jun 23 21:31:31 1992
> From: Lawrie.Brown at adfa.oz.au
> Date: Wed, 24 Jun 1992 12:31:17 +1000
> X-The-Answer: To Life, the Universe, and Everything . . . is 42
> X-Mailer: Mail User's Shell (7.2.2 4/12/91)
> To: telnet-ietf at cray.com
> Subject: Re: Revised Kerberos IV Draft
>
> I have one query about both the Kerberos v4 & v5 drafts.
> In section 2 detailing the Command Meanings I believe the IS and REPLY
> suboption commands have been left out, though they are shown in the
> examples in section 4. If they have been left out, then they need to
> be re-inserted, otherwise I have some real reservations about the
> changed format.
>
> The authentication option draft appears fine.
>
> Cheers
> Lawrie.
Egad, you are absolutly right! For the Kerberos IV specification,
the following changes should be made to section 2. The same changes
should be made to the Kerberos V specification.
43,44c43,44
< IAC SB AUTHENTICATION <authentication-type-pair> AUTH <kerberos tick-
< et and authenticator> IAC SE
---
> IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <kerberos
> ticket and authenticator> IAC SE
50c50
< IAC SB AUTHENTICATION <authentication-type-pair> ACCEPT IAC SE
---
> IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
62,63c62,63
< IAC SB AUTHENTICATION <authentication-type-pair> REJECT <optional
< reason for rejection> IAC SE
---
> IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op-
> tional reason for rejection> IAC SE
69,72c69,72
< IAC SB AUTHENTICATION <authentication-type-pair> CHALLENGE <encrypted
< challenge> IAC SE
< IAC SB AUTHENTICATION <authentication-type-pair> RESPONSE <encrypted
< response> IAC SE
---
> IAC SB AUTHENTICATION IS <authentication-type-pair> CHALLENGE <en-
> crypted challenge> IAC SE
> IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE <en-
> crypted response> IAC SE
Steve, can you change your nroff source to reflect this? Thanks.
-David Borman, dab at cray.com
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04674;
24 Jun 92 9:28 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04670;
24 Jun 92 9:28 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa08108;
24 Jun 92 9:28 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA09313; Wed, 24 Jun 92 08:28:49 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA17180; 4.1/CRI-5.5; Wed, 24 Jun 92 08:28:46 CDT
Received: from handel.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA09292; Wed, 24 Jun 92 08:28:44 CDT
Received: by handel.cray.com
id AA06855; 5.57/CRI-5.5; Wed, 24 Jun 92 08:27:46 -0500
Date: Wed, 24 Jun 92 08:27:46 -0500
From: "David A. Borman" <dab at berserkly.cray.com>
Message-Id: <9206241327.AA06855 at handel.cray.com>
To: Lawrie.Brown at adfa.oz.au, telnet-ietf at timbuk.cray.com
Subject: Re: Revised Environment Draft
> From lpb at mnementh.cs.adfa.oz.au Tue Jun 23 21:36:07 1992
> From: Lawrie.Brown at adfa.oz.au
> Date: Wed, 24 Jun 1992 12:35:56 +1000
> X-The-Answer: To Life, the Universe, and Everything . . . is 42
> X-Mailer: Mail User's Shell (7.2.2 4/12/91)
> To: telnet-ietf at cray.com
> Subject: Re: Revised Environment Draft
>
> I have one minor editorial query about this draft. In section 2 page 2,
> the definitions for SEND & IS refer to type
> whilst in the definition for INFO "type" is used. I don't believe the
> quotes should be present in the latter case.
>
> Apart from that I have no other comments.
>
> Regards
> Lawrie.
Yes, I agree. We should drop the quotes around "type" in the
descripton of the INFO command.
Steve, another minor editing job for you...
-David Borman, dab at cray.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa11808;
24 Jun 92 15:40 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00942;
24 Jun 92 15:40 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07634>; Wed, 24 Jun 1992 08:25:57 -0700
Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.65+local-6)
id <AA07629>; Wed, 24 Jun 1992 08:25:53 -0700
Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI)
for ietf at venera.isi.edu id AA09920; Wed, 24 Jun 92 08:24:11 -0700
Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI)
for @sgi.sgi.com:ietf at venera.isi.edu id AA17470; Wed, 24 Jun 92 08:36:48 -0600
Date: Wed, 24 Jun 92 08:36:48 -0600
From: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Message-Id: <9206241436.AA17470 at rhyolite.wpd.sgi.com>
To: ietf at isi.edu
Subject: Re: Sun RPC program IDs
> "James B. Van Bokkelen" <jbvb at ftp.com> writes:
>
>It has recently come to my attention that Sun Microsystems is not publishing
>a current list of registered RPC programs. Their reasoning is that some
>of those who've requested registration want the IDs kept secret, and they
>haven't kept track of which, so they can't print anything since that long-
>ago day when almost all of the registered programs were Sun's.
>...
> Steve Nahm <sxn at camilla.eng.sun.com> writes:
> ...
> [The question of *why* someone would want to keep an
> RPC protocol confidential is not relevant to this discussion.]
>
> Even if we were given permission, Sun could not publish a complete
> list. We occasionally get requests for blocks of numbers. The vendor
> assigns numbers itself to applications that it develops. We usually
> never hear from them after they get the block, so we clearly do not
> have a comprehensive list of RPC protocols.
> ...
Silicon Graphics has such a block of numbers. I don't think we think any
of their uses are secret, but I know we appreciate the fact that we don't
need to run back to Sun every time we figure out what to do with one of
them.
The question of why the numbers might be secret may be relevant. Knowing
who is receiving new blocks of "ethernet" numbers from the IEEE would tell
you who is working on new hardware, or selling lots of existing hardware.
Such information is commonly considered confidential by those who own it
and nice to have by others, at least in the commerical world. Yes,
eventually the facts are evident to the network monitors of the world, but
does not mean you want to engineering to pre-announce. There are so many
"OUI's" allocated now that this effect does not matter as much as it did
many years ago.
The situation with RPC numbers is more so. Should Silicon Graphics figure
out a neat way to use RPC to run toasters, routers, and payroll check
printers, we might not want to announce the details before the code was
written, let alone on the streets. After the product is out, it's too
late; everyone who knows enough about the protocol to document it for the
curious or other makers of network monitors is likely to be busy elsewhere.
Even when no such secrecy is desired, there is the hassle. The hoops you
must pass before getting a TCP or UDP port number, or even a multicast
address very effectively reduce the number of those allocated. Many times
I've been asked "how do we get a port number" and responded with the line
about just writing an RFC. I've also mentioned that getting an RPC number
is easier. Guess how many port numbers have been assigned to RFC's written
at SGI? On the other hand, a bunch of RPC numbers have been used only to
get the portmapper to allocate a port number, with no XDR ever written.
Vernon Schryver, vjs at sgi.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13437;
24 Jun 92 17:33 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16526;
24 Jun 92 17:33 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA10018>; Wed, 24 Jun 1992 09:15:04 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA09998>; Wed, 24 Jun 1992 09:15:01 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08710;
24 Jun 92 12:10 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-idpr-architecture-05.txt, .ps
Date: Wed, 24 Jun 92 12:10:41 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206241210.aa08710 at IETF.NRI.Reston.VA.US>
This revision of the document reflects editorial changes in response
to the last call. This is the version which will be recommended to
the IAB.
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Inter-Domain Policy Routing Working Group of the IETF.
Title : An Architecture for Inter-Domain Policy Routing
Author(s) : Marianne Lepp, Martha Steenstrup
Filename : draft-ietf-idpr-architecture-05.txt, .ps
Pages : 36
We present an architecture for inter-domain policy routing (IDPR). The
objective of inter-domain policy routing is to construct routes
between source and destination administrative domains, that provide
user traffic with the requested service within the constraints
stipulated for the domains transited. The IDPR architecture is
designed to accommodate an internetwork containing tens of thousands
of administrative domains with heterogeneous service requirements and
restrictions.
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-idpr-architecture-05.txt" or
"get draft-ietf-idpr-architecture-05.ps"
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-idpr-architecture-05.txt" or
"SEND internet-drafts/draft-ietf-idpr-architecture-05.ps"
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14014;
24 Jun 92 19:22 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03126;
24 Jun 92 19:22 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA10656>; Wed, 24 Jun 1992 09:28:51 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA10650>; Wed, 24 Jun 1992 09:28:46 -0700
Received: from uu2.psi.com by NRI.Reston.VA.US id aa03491; 24 Jun 92 12:23 EDT
Received: from port13.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA06365; Wed, 24 Jun 92 12:22:48 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA12303; Wed, 24 Jun 92 09:21:51 PDT
Message-Id: <9206241621.AA12303 at aland.bbn.com>
To: Steve Nahm <sxn at camilla.eng.sun.com>
Cc: ietf at NRI.Reston.VA.US
Cc: jbvb at ftp.com
Subject: re: Sun RPC program IDs
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 24 Jun 92 09:21:51 -0700
Sender: craig at aland.bbn.com
> An RPC application, like any other application, is the property of
> those who implement it. Sun has no rights to make details of
> a proprietary application public unless it is given permission
> to do so. [The question of *why* someone would want to keep an
> RPC protocol confidential is not relevant to this discussion.]
Yes, but the network wire is a shared resource and managers of the network
have a very compelling need to know how their network is being used
and by what applications. By knowing what RPC applications are using
the wire, the network manager is in a better position to (re)configure
the network to improve performance. (They are also in a better
position to figure out which applications should be shut off -- e.g.
RWHOD in the old days).
>>This doesn't make Sun RPC any easier to manage or support.
>
> And it doesn't make it any harder either. Every application that
> uses UDP implements a user-level protocol; does the lack of publishing
> every UDP application protocol make UDP less easy to manage or support?
If one wants an assigned UDP port number (one that someone else can't
use too) one is required to publish the application protocol.
> You should be looking to your application vendor for solutions to
> management and support problems you perceive.
How can I figure out which application vendor to talk to if I don't know
who's application is beating up on my network? Kindly be consistent.
[I think the larger moral of this tale is that Postel's policy that all
number spaces for Internet protocols should be managed by the IANA, not
by individuals or corporations is the right one].
Craig Partridge
NSF Network Service Center
Editor, IEEE Network Magazine
craig at bbn.com or craig at nnsc.nsf.net
PS: To JBvB -- can we reverse engineer and publish the list as was
done with Ethernet address groups a while back?
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa14140;
24 Jun 92 19:43 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14136;
24 Jun 92 19:43 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa06616;
24 Jun 92 19:44 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA14811; Wed, 24 Jun 92 18:44:01 CDT
Received: by hemlock.cray.com
id AA27094; 4.1/CRI-5.5; Wed, 24 Jun 92 18:43:59 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA27090; 4.1/CRI-5.5; Wed, 24 Jun 92 18:43:58 CDT
Received: from mnementh.cs.adfa.oz.au by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA14808; Wed, 24 Jun 92 18:43:52 CDT
Received: by mnementh.cs.adfa.oz.au (5.64/1.34)
id AA22280; Thu, 25 Jun 92 09:43:47 +1000
Message-Id: <9206242343.AA22280 at mnementh.cs.adfa.oz.au>
From: Lawrie.Brown at adfa.oz.au
Date: Thu, 25 Jun 1992 09:43:47 +1000
In-Reply-To: dab at berserkly.cray.com (David A. Borman)
"Re: Revised Kerberos IV Draft" (Jun 24, 8:25am)
X-The-Answer: To Life, the Universe, and Everything . . . is 42
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: telnet-ietf at timbuk.cray.com
Subject: Re: Revised Kerberos IV Draft
} > In section 2 detailing the Command Meanings I believe the IS and REPLY
} > suboption commands have been left out, though they are shown in the
} > examples in section 4. If they have been left out, then they need to
} Egad, you are absolutly right! For the Kerberos IV specification,
and the same problem exists with the SPX draft as well.
While discussing this I do have a general query as to why you chose to format
the suboption negotiations in all of these as:
IS ... AUTH ...
REPLY ... ACCEPT ...
REPLY ... REJECT ...
IS ... CHALLENGE ...
REPLY ... RESPONSE ...
rather than just
AUTH ...
ACCEPT ...
REJECT ...
CHALLENGE ...
RESPONSE ...
where the above commands are obviously given numbers that don't conflict with
the standard IS SEND REPLY etc
To me it seems that you are occupying 2 bytes to carry information that
quite easily is carried in one. It also makes the parsing of responses
harder, since you have varying formats for a given sub-option command
that you must distonguish between, rather than just a single format.
It was for all these reasons we chose the latter approach with the
LOKI challenge-response system we're using here, and I'm curious as
to your reasons for taking the alternate.
Regards
Lawrie.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14667;
24 Jun 92 21:24 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa22620;
24 Jun 92 21:25 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA12367>; Wed, 24 Jun 1992 10:01:49 -0700
Received: from gatech.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA12357>; Wed, 24 Jun 1992 10:01:44 -0700
Received: from burdell.cc.gatech.edu by gatech.edu (4.1/Gatech-9.1)
id AA00651 for ietf at isi.edu; Wed, 24 Jun 92 13:00:15 EDT
Received: from terminus.cc.gatech.edu by burdell.cc.gatech.edu (4.1/SMI-4.1)
id AA23060; for snmp at psi.com; Wed, 24 Jun 92 12:58:04 EDT
Received: by terminus.cc.gatech.edu (4.1/SMI-4.1)
id AA16381; Wed, 24 Jun 92 12:57:57 EDT
From: Cheryl Krupczak <cheryl at cc.gatech.edu>
Message-Id: <9206241657.AA16381 at terminus.cc.gatech.edu>
Subject: Object Management Group (OMG)
To: snmp at psi.com
Date: Wed, 24 Jun 92 12:57:55 EDT
Cc: ietf at isi.edu
X-Mailer: ELM [version 2.3 PL11]
Hi!
I'm trying to find information on the Object Management Group.
Who are they? What is their charter? When do they meet?
Who is the contact?
I would sure appreciate any pointers!
thanks!
- Cheryl Krupczak
cheryl at cc.gatech.edu
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14737;
24 Jun 92 21:52 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa27419;
24 Jun 92 21:52 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA16329>; Wed, 24 Jun 1992 11:19:49 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA16321>; Wed, 24 Jun 1992 11:19:45 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa10044;
24 Jun 92 14:11 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mpsnmp-overipx-00.txt
Date: Wed, 24 Jun 92 14:11:39 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206241411.aa10044 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
SNMP over a Multi-protocol Internet Working Group of the IETF.
Title : SNMP over IPX
Author(s) : Theodore Brunner
Filename : draft-ietf-mpsnmp-overipx-00.txt
Pages : 7
This document defines a convention for encapsulating Simple Network
Management Protocol (SNMP) packets over the transport mechanism
provided via the Internetwork Packet (IPX) 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-mpsnmp-overipx-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-mpsnmp-overipx-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14912;
24 Jun 92 23:01 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09546;
24 Jun 92 23:01 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA17066>; Wed, 24 Jun 1992 11:36:41 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA17062>; Wed, 24 Jun 1992 11:36:39 -0700
Received: from HQ.TGV.COM by NRI.Reston.VA.US id aa19892; 24 Jun 92 14:29 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Wed, 24 Jun 92 11:18:35 PDT
Received: from karl.lvs.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA01506; Wed, 24 Jun 92 11:19:37 PDT
Date: Wed, 24 Jun 92 11:19:37 PDT
Message-Id: <9206241819.AA01506 at mel-brooks.empirical.com>
To: sxn at camilla.eng.sun.com
Subject: Re: Sun RPC program IDs
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at mel-brooks.tgv.com>
Reply-To: karl at tgv.com
Cc: ietf at NRI.Reston.VA.US
Sender: karl at mel-brooks.tgv.com
Repository: empirical.com
Originating-Client: lvs.empirical.com
> >It has recently come to my attention that Sun Microsystems is not publishing
> >a current list of registered RPC programs. Their reasoning is that some
> >of those who've requested registration want the IDs kept secret,...
> >This doesn't make Sun RPC any easier to manage or support.
> And it doesn't make it any harder either.
Protocol secrecy *does* make things harder to manage. If I see RPC
#xxx floating around my network and have no idea what it is, then to
that extent I do not have control of my network. I don't know
whether this is somebody playing a new version of dogfight or some
critical new application. And suppose it is eating a significant
part of my bandwidth, how do I know whether that is a legitimate use
or not?
It is silly to mislead developers into believing that they are
somehow more secure because you chose to not publish RPC
number-protocol name bindings.
And it is a disservice to those of us who have to run networks.
--karl--
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa14940;
24 Jun 92 23:10 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11129;
24 Jun 92 23:11 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21282>; Wed, 24 Jun 1992 13:13:36 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA21278>; Wed, 24 Jun 1992 13:13:33 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa12309;
24 Jun 92 16:06 EDT
To: ietf at isi.edu
Reply-To: ietf-rsvp at NRI.Reston.VA.US
From: ietf-rsvp at NRI.Reston.VA.US
Subject: IETF MAILING 4: July 13-17, 1992/Boston
Date: Wed, 24 Jun 92 16:06:52 -0400
Sender: mdavies at NRI.Reston.VA.US
Message-Id: <9206241606.aa12309 at IETF.NRI.Reston.VA.US>
Enclosures:
At-A-Glance
RSVP
Directions
Dear IETFers:
This is the FOURTH (almost final) mailing of logistics for the
upcoming IETF meeting, (July 13-17, 1992). The Agenda will be
mailed separately.
We have already pre-registered 410 attendees for the Boston Meeting.
Not quite as much as in San Diego, but it will still mean longer lines
and more congestion during registration. To minimize the impact of such
a large number of people on the registration process the following actions
are recommended:
1. Pre-register and pre-pay (via email). (most helpful)
2. Pre-register (via email) but pay on-site. (helpful)
3. Attend Sunday Evenings' Registration/Reception. (helpful)
Thank You,
Megan
===========
24th INTERNET ENGINEERING TASK FORCE Mailing Date : 6/24/92
AT-A-GLANCE Mailing Number: 4
DATES: July 13-17, 1992 HOST(S): James Davin, MIT
Jeffrey Schiller, MIT
John Curran, NEARnet
HOTEL/MEETING SITE: Hyatt Regency Cambridge
Overlooking Boston
575 Memorial Drive
Cambridge, MA 02139
Phone: (617) 492-1234 {fax: (617) 491-6906}
CI 4:00 p.m.; CO 12:00 p.m.
250 Rooms reserved until June 12, 1992
$99.00/single; $99.00/double (please add 9.7% tax)
Specify: IETF or 24th Internet Engineering Task Force
ALTERNATE ACCOM:* The Inn at Harvard
1201 Massachusetts Avenue (Harvard Square)
Cambridge, MA 02138
Phone (617) 491-2222 {fax: (617) 496-5020}
CI 3:00 p.m.; CO 12:00 p.m.
20 Rooms reserved until June 12, 1992
$105/single; $105/double (please add 9.7%tax)
Specify: GC-INTER
The Royal Sonesta
5 Cambridge Parkway
Phone (617) 491-3600 {fax: (617) 661-5956}
10 Rooms reserved until June 12, 1992
$120 (single/double)
Specify: IETF Group
PRE-REGISTRATION: Sunday, July 12, 1992
6pm - 8pm (reception during)
Hyatt Regency Cambridge
Room: Riverside
REGISTRATION: Monday, July 13, 1992
8am - 9am
Hyatt Regency Cambridge
Room: Outside Adams
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
$130.00 if received BY June 12, 1992
$150.00 if received AFTER June 12, 1992
AIRLINE: United Airlines (special rate roundtrip only)
1 (800) 521-4041 Meeting ID: 514VS (IETF)
We regret that discounted fares are not
available for international flights.
CAR RENTAL: Hertz Discounts available through United.
AIRPORT: Logan International Airport
PARKING: Hyatt Regency: $12/day for guests
SHUTTLE: None available
==========
REGISTRATION FORM
24th Internet Engineering Task Force - Page 1 of 2
July 13 - 17, 1992
Boston, MA
Please print or type:
Name (Mr/Dr/Ms)__________________________________________________________
Title____________________________________________________________________
Organization_____________________________________________________________
Address__________________________________________________________________
City_______________________________State______________Zip Code___________
Telephone______________________________Fax_______________________________
Email____________________________________________________________________
Please check a) and b) below so we can identify your organization type and
interest.
a) Organization Type ___HW/SW Vendor ___Government ___Network Provider
___University ___Other (_______________________)
b) Your interest in 24th IETF Meeting: ___Network Operator
___Network User ___Product Developer ___Researcher
___Other (________________)
Do you plan to attend the Sunday, July 12, 1992 evening reception?
YES___ NO___
$150.00 ($130.00 + $20.00 late fee) Registration postmarked after
June 12, 1992.
Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check enclosed
(U.S. dollars, drawn on a U.S. Bank), payable to:
Corporation for National Research Initiatives
Account No.____________________________ Expiration Date__________________
Cardholder Signature_____________________________________________________
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: ietf-rsvp at nri.reston.va.us
Facsimile: +1-703-620-0913
Postal: Corporation for National Research Initiatives
Accounting Department - 24th IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
REGISTRATION FORM
24th Internet Engineering Task Force - Page 2 of 2
July 13 - 17, 1992
Boston, MA
IMPORTANT:
1. Register ONE person per form. Substitutions are NOT allowed.
2. Purchase orders are NOT accepted.
3. DD Form 1556 IS accepted.
4. Request for refunds must be received by July 10, 1992.
5. Refund policy: Refunds are subject to a $20.00 service charge.
Late fees will not be refunded.
6. Your registration fee includes a copy of the Meeting's Proceedings,
Sunday evening reception (cash bar), daily continental
breakfasts and coffee breaks.
For additional information or assistance, please contact +1-703-620-8990,
+1-703-620-0913 (Fax) or ietf-rsvp at nri.reston.va.us. Direct all inquiries
to: 24th IETF Meeting - Boston.
===========
24th Internet Engineering Task Force
July 13-17, 1992
Boston, Massachusetts
Directions from the Logan International Airport to the Hyatt Cambridge:
Follow signs to Sumner Tunnel. After leaving the tunnel, stay to the left
and follow signs to 93 North. Take Exit 26 onto Storrow Drive. Look for
signs: Kendall Square/Cambridge. Follow Kendall Square signs to
Memorial Drive/Route 3N (Route 3N and Memorial Drive are the same road at
this point). Turn right at the first traffic light (Amesbury Street).
(Although the hotel address is 575 Memorial Drive, the main entrance is
off of Amesbury Street.)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa15711;
25 Jun 92 0:50 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa27430; 25 Jun 92 0:50 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21426>; Wed, 24 Jun 1992 13:16:54 -0700
Received: from is.rice.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA21412>; Wed, 24 Jun 1992 13:16:43 -0700
Received: from san-miguel.is.rice.edu by is.rice.edu (AA10516); Wed, 24 Jun 92 15:15:20 CDT
Received: by san-miguel.is.rice.edu (AA07453); Wed, 24 Jun 92 15:15:19 CDT
From: William Manning <bmanning at is.rice.edu>
Message-Id: <9206242015.AA07453 at san-miguel.is.rice.edu>
Subject: Re: Sun RPC program IDs
To: ietf at isi.edu
Date: Wed, 24 Jun 92 15:15:18 CDT
X-Mailer: ELM [version 2.3 PL11]
The public forum, as used for port assignments is of benefit. There is a well
known place to provide authoritative lists helps align test environments that
may "escape" intothe real world. One does NOT have to go to the IANA to get
port numbers assigned. Witness the complaint in the kerberos list on the
assignment for port 750. Lots of folks used it for test, and have since
figured out that they need real ports, and have gotten them.
If SUN (nor anyone else) keeps a publicly available list of assigned RPC number
then whats to prevent me from making mine up on the fly? There is no way to
arbitrate, since they are all kept "secret". From a network monitor point
of view, I think you would want your products mode of operation to be defined
in as many monitors as you can get your hands on.
--
Regards,
Bill Manning bmanning at rice.edu PO Box 1892
713-285-5415 713-527-6099 Houston, Texas
R.U. (o-kome) 77251-1892
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa16097;
25 Jun 92 1:27 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00660; 25 Jun 92 1:27 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA26174>; Wed, 24 Jun 1992 14:55:22 -0700
Received: from amway.ch.apollo.hp.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA26169>; Wed, 24 Jun 1992 14:55:19 -0700
Message-Id: <199206242155.AA26169 at venera.isi.edu>
Received: from mapcar.ch.apollo.hp.com by amway.ch.apollo.hp.com id <AA25216 at amway.ch.apollo.hp.com> Wed, 24 Jun 92 17:47:58 EDT
Received: by mapcar.ch.apollo.hp.com id <AA06405 at mapcar.ch.apollo.hp.com>; Wed, 24 Jun 92 17:47:54 EDT
From: Nathaniel Mishkin <mishkin at apollo.hp.com>
Date: Wed, 24 Jun 92 17:47:53 EDT
Subject: Re: Sun RPC program IDs
To: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Cc: ietf at isi.edu
In-Reply-To: vjs at rhyolite.wpd.sgi.com (Vernon Schryver), Wed, 24 Jun 92 08:36:48 -0600
To my (biased) way of thinking, this whole discussion of allocation of
Sun RPC program IDs just makes it clear that schemes based on a centrally
administered and relatively small space of IDs are bad for identifying
distributed services. In contrast, the OSF DCE RPC mechanism uses unique
IDs (composed from a timestamp and an IEEE 802 address) to identify
interfaces (programs). (UUIDs are handy for other purposes and the DCE
applies them in other situations.) The downside is that they're 128
bits long, but I think I'd take that over the administrative hassles.
-- Nat Mishkin
Distributed Object Computing Program / East
Hewlett-Packard Company
mishkin at apollo.hp.com
-------
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa16119;
25 Jun 92 1:27 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00757; 25 Jun 92 1:28 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21294>; Wed, 24 Jun 1992 13:14:03 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA21289>; Wed, 24 Jun 1992 13:13:58 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa12366;
24 Jun 92 16:10 EDT
To: ietf at isi.edu
Reply-To: ietf-rsvp at NRI.Reston.VA.US
From: ietf-rsvp at NRI.Reston.VA.US
Subject: 24TH IETF: DRAFT AGENDA: July 13-17, 1992/Boston
Date: Wed, 24 Jun 92 16:10:49 -0400
Sender: mdavies at NRI.Reston.VA.US
Message-Id: <9206241610.aa12366 at IETF.NRI.Reston.VA.US>
Below is the latest DRAFT of the Agenda for the 24th Internet
Engineering Task Force. This version is also available via ftp,
cd ietf, get 0mtg-agenda.txt.
Agenda of the Twenty-Fourth IETF - as of 6/24/92 11:00am
(July 13-17, 1992)
MONDAY, July 13, 1992
8:00-9:00 am IETF Registration and Continental Breakfast
9:00-9:30 am Introductions
9:30-12:00 noon Morning Sessions
APP Internet SMTP Extensions WG (smtpext)
(John Klensin/MIT)
INT IP over Appletalk WG (appleip) (John Veizades/Apple)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
OPS Network Status Reports (netstat) (Gene Hastings/PSC)
OSI OSI Directory Services WG (osids)
(Steve Hardcastle-Kille/ISODE)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG Open Shortest Path First IGP WG (ospf)
(John Moy/Proteon)
SEC Security Area Advisory Group (saag)
(Stephen Crocker/TIS)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF New Internet Routing and Addressing
Architecture BOF (nimrod) (Noel Chiappa)
BOF Remote Conferencing BOF (remconf)(Jack Drescher/MCNC
and Ari Ollikainen/LLNL)
INT IP over Appletalk WG (appleip) (John Veizades/Apple)
OSI OSI Directory Services WG (osids)
(Steve Hardcastle-Kille/ISODE)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Network Access Server Requirements WG (nasreq) WG
(Allan Rubens)
TSV Domain Name System WG (dns) (Mike Reilly/DEC)
USV Internet School Networking WG (isn)
(John Clement/EDUCOM, Connie Stout/TheNet and
Art St. George/UNM)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
BOF Email Requirements BOF (mailreq) (Russ Hobby/UCDavis)
BOF IP Routing for Wireless/Mobile Hosts BOF (moblhost)
(Steve Deering/Xerox)
BOF SNMP Security Implementors BOF (snmpseci)
(Keith McCloghrie/Hughes and Jim Galvin/TIS)
OPS Benchmarking Methodology WG (bmwg)
(Scott Bradner/Harvard)
OSI MHS-DS WG (mhsds) (Kevin Jordan/CDC and
Harald Alvestrand/SINTEF DELAB)
OSI Network OSI Operations WG (noop) (Sue Hares/Merit)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC TSIG/IETF Coordination Meeting
TSV Service Location Protocol WG (svrloc)
(John Veizades/Apple)
TUESDAY, July 14, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am IETF Technical Presentations
o ``The Futures of the Internet'' (Mitch Kapor/EFF)
9:30-12:00 noon TSIG Plenary Session
9:30-12:00 noon Morning Sessions
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF Routing Requirements Checklist BOF (rreqlist)
(Pushpendra Mohta/CERFnet)
APP Network Database WG (netdata) (Daisy Shen/IBM)
APP Telnet WG (telnet)
(Steve Alexander/INTERACTIVE Systems)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
INT Point-to-Point Protocol Extensions WG (pppext)
(Brian Lloyd/Consultant)
MGT FDDI MIB WG (fddimib) (Jeff Case/UTenn)
MGT Internet Accounting WG (acct) (Cyndi Mills/BBN
and Gregory Ruth/BBN)
OSI MHS-DS WG (mhsds) (Kevin Jordan/CDC and
Harald Alvestrand/SINTEF DELAB)
SEC Common Authentication Technology WG (cat)
(John Linn/DEC)
USV User Documents WG (userdoc2) (Ellen Hoffman/UMich
and Lenore Jackson/NASA)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF Host Resources MIB BOF (hostmib)
(Steve Waldbusser/CMU)
OPS Operational Statistics WG (opstat)
(Phill Gross/ANS and Bernhard Stockman/SUNET)
OSI MIME-MHS Interworking WG (mimemhs)
(Steve Thompson/SoftSwitch)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Common Authentication Technology WG (cat)
(John Linn/DEC)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV Internet User Glossary WG (userglos)
(Tracy LaQuey Parker/UTexas and Gary Malkin/Xylogics)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF IP Security BOF (ipsec) (Steve Crocker/TIS)
OPS Operational Statistics WG (opstat)
(Phill Gross/ANS and Bernhard Stockman/SUNET)
OSI SNMP over a Multi-protocol Internet WG (mpsnmp)
(Ted Brunner/Bellcore)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tnfs) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess)(Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV Internet User Glossary WG (userglos)
(Tracy LaQuey Parker/UTexas and Gary Malkin/Xylogics)
7:00-10:00 pm Evening Sessions
BOF Internet Society Q&A (isoc) (Vint Cerf/CNRI)
BOF Uninterruptable Power Supply BOF (upsmib)
(Jeff Case/UTenn and Bob Stewart/Xyplex)
OPS BGP Deployment and Application WG (bgpdepl)
(Jessica Yu/Merit)
OSI Network OSI Operations WG (noop) (Sue Hares/Merit)
RTG Multicast Extensions to OSPF WG (mospf)
(Steve Deering/Xerox PARC)
SEC TCP Client Identity Protocol WG (ident)
(Mike StJohns/DOD)
WEDNESDAY, July 15, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am Technical Presentations
o ``Pip: The `P' Internet Protocol''
(Paul Tsuchiya/Bellcore)
9:30-12:00 noon Morning Sessions
INT IP over ATM WG (atm) (Bob Hinden/Sun)
INT Point-to-Point Protocol Extensions WG (pppext)
(Brian Lloyd/Consultant)
MGT Chassis MIB WG (chassis) (Jeff Case/UTenn and
Bob Stewart/Xyplex)
MGT DS1/DS3 MIB WG (trunkmib) (Fred Baker/ACC and
Tracy Cox/Bellcore)
OSI Office Document Architecture WG (oda)
(Peter Kirstein/UCL)
RTG Inter-Domain Policy Routing WG (idpr)
(Martha Steenstrup/BBN)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV User Services WG (uswg) (Joyce Reynolds/ISI)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF Remote Conferencing BOF (remconf) (Jack Drescher/MCNC
and Ari Ollikainen/LLNL)
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT Token Ring Remote Monitoring WG (trmon)
(Mike Erlinger/Lexcel)
OPS BGP Deployment and Application WG (bgpdepl)
(Jessica Yu/Merit)
OSI X.400 Operations WG (x400ops)
(Alf Hansen/SINTEF DELAB)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
RTG RIP Version II WG (ripv2) (Gary Malkin/Xylogics)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
USV Internet Anonymous FTP Archives WG (iafa)
(Peter Deutsch/McGill and Alan Emtage/McGill)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT IEEE 802.3 Hub MIB WG (hubmib) (Keith McCloghrie/Hughes
and Donna McMaster/SynOptics)
OPS User Connectivity Problems WG (ucp) (Dan Long/BBN)
OSI X.400 Operations WG (x400ops) (Alf Hansen/SINTEF DELAB)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
USV Network Information Services Infrastructure WG (nisi)
(April Marine/SRI and Pat Smith/Merit)
7:00-10:00pm Evening Session
BOF Authorization and Access Control BOF (aac)
(Clifford Neuman/ISI)
BOF A New Internet Protocol BOF (pip)
(Paul Tsuchiya/Bellcore)
BOF Directory Resources Engineering Group BOF (dregs)
(Joan Gargano/UCDavis and Joyce K. Reynolds/ISI)
BOF Simple Management Protocol (SMP) Framework BOF
(smpframe) (Marshall Rose/DBC)
BOF Perspectives on the Next Generation of the NSFnet
(nsfnet)(Laura Breeden/FARNET)
THURSDAY, July 16, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am Technical Presentations
o ``DARPA Research Testbed Network'' (Bob Braden/ISI)
9:30-12:00 noon TSIG Plenary
9:30-12:00 noon Morning Sessions
BOF IP Address Encapsulation BOF (ipae)
(Bob Hinden/Sun and Dave Crocker/TBO)
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT Bridge MIB WG (bridge) (Fred Baker/ACC)
OPS User Connectivity Problems WG (ucp) (Dan Long/BBN)
RTG Inter-Domain Policy Routing WG (idpr)
(Martha Steenstrup/BBN)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Privacy-Enhanced Electronic Mail WG (pem)
(Steve Kent/BBN)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
Breaks Coffee available throughout the morning.
1:30-3:30 pm Afternoon Sessions I
APP Network Database WG (netdata) (Daisy Shen/IBM)
BOF IP Routing for Wireless/Mobile Hosts BOF (moblhost)
(Steve Deering/Xerox)
BOF TCP/UDP over CLNP BOF (tuc) (Peter Ford and Ross Callon)
MGT Internet Accounting WG (acct) (Cyndi Mills/BBN
and Gregory Ruth/BBN)
MGT X.25 Management Information Base WG (x25mib)
(Dean Throop/Data General)
OPS Network Joint Management WG (njm) (Gene Hastings/PSC)
SEC Security Area Advisory Group (saag)
(Stephen Crocker/TIS)
USV Directory Information Services Infrastructure WG (disi)
(Chris Weider/Merit)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Technical Presentations
FRIDAY, July 17, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30am Technical Presentations
9:30-12:00pm Summary Reports
APP Applications Area (Russ Hobby/UC Davis)
INT Internet Area (Noel Chiappa and
Philip Almquist/Consultant)
MGT Network Management Area (Chuck Davin/MIT)
OPS Operations Area (Susan Estrada/CERFnet, Phill Gross/ANS,
Bernhard Stockman/SUNET)
OSI OSI Integration Area (Erik Huizer/SURFnet and
David Piscitello/Bellcore)
RTG Routing Area (Bob Hinden/Sun)
SEC Security Area (Steve Crocker/TIS)
TSV Transport and Services Area
(David Borman/Cray Research)
USV User Services Area (Joyce K. Reynolds/ISI)
12:00 pm Concluding Remarks (Phill Gross/ANS)
12:30 pm Adjourn
Key to Abbreviations
APP Applications Area
BOF Birds of a Feather Session
INT Internet Area
MGT Network Management Area
OSI OSI Integration Area
OPS Operational Requirements Area
RTG Routing Area
SEC Security Area
TSG Trusted Sytems Interoperability Group (TSIG)
TSV Transport and Services Area
USV User Services Area
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03808;
25 Jun 92 4:55 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16916; 25 Jun 92 4:56 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07352>; Wed, 24 Jun 1992 19:36:08 -0700
Received: from nic.near.net by venera.isi.edu (5.65c/5.65+local-6)
id <AA04399>; Wed, 24 Jun 1992 18:01:27 -0700
Message-Id: <199206250101.AA04399 at venera.isi.edu>
To: Cheryl Krupczak <cheryl at cc.gatech.edu>
Cc: snmp at psi.com, ietf at isi.edu, soley at omg.org
Subject: Re: Object Management Group (OMG)
In-Reply-To: Your message of Wed, 24 Jun 92 12:57:55 -0400.
<9206241657.AA16381 at terminus.cc.gatech.edu>
Date: Wed, 24 Jun 92 21:00:01 -0400
From: John Curran <jcurran at nic.near.net>
--------
From: Cheryl Krupczak <cheryl at cc.gatech.edu>
Subject: Object Management Group (OMG)
Date: Wed, 24 Jun 92 12:57:55 EDT
Hi!
I'm trying to find information on the Object Management Group.
Who are they? What is their charter? When do they meet?
Who is the contact?
I would sure appreciate any pointers!
No problem. NEARnet members often make profiles of their organization
available via ftp in nic.near.net:/member-profiles. The profile for the
Object Management Group is attached.
If you need any more information, feel free to contact us at NEARnet
or contact the OMG folks as listed below.
John Curran
NEARnet Staff
617-873-8730
---
Member Profile: Object Management Group
Object Management Group (OMG), located in Framingham, Massachusetts, is an
international organization dedicated to promoting the theory and practice of
object management. OMG joined NEARnet on March 27, 1990.
OMG's goal is to adopt a core of commercially viable specifications of
implementations that will provide compatible applications across DOS, OS/2, and
UNIX operating systems. OMG's applications will be independent of the user
interface enabling compatibility of applications across heterogeneous networked
systems.
Primary Administrative and Technical Contact: Dr. Richard Mark Soley
soley at omg.org
(508) 820-4300
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03999;
25 Jun 92 7:09 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07560; 25 Jun 92 7:10 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA14056>; Wed, 24 Jun 1992 22:58:08 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA14052>; Wed, 24 Jun 1992 22:58:05 -0700
Received: from relay2.UU.NET by NRI.Reston.VA.US id aa02602; 25 Jun 92 1:44 EDT
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA02560; Thu, 25 Jun 92 01:44:07 -0400
Received: from practic.UUCP by uunet.uu.net with UUCP/RMAIL
(queueing-rmail) id 014325.2389; Thu, 25 Jun 1992 01:43:25 EDT
Received: from localhost
by practic.com (5.61/smail2.5/04-23-91)
id AA23303; Wed, 24 Jun 92 22:33:30 -0700
Message-Id: <9206250533.AA23303 at practic.com>
To: uunet!nri.reston.va.us!ietf at uunet.uu.net
Cc: brunner at uunet.uu.net
Subject: Re: Sun RPC program IDs
In-Reply-To: Your message of "Wed, 24 Jun 92 11:19:37 PDT."
<9206241819.AA01506 at mel-brooks.empirical.com>
Date: Wed, 24 Jun 92 22:33:27 PDT
From: "practic!brunner at uunet.uu.net" <brunner at practic.com>
As Karl just pointed out, from a network operations point of view (here,
let us assume that networks are large, heterogeneous, and composed of
semi-autonomous operational sub-groups), having unrecognized protocol
types make it past the first filter is at least vexing.
The onus is on SMI (and the like minded), to make the case that Karl's
implicit assertion,
> It is silly to mislead developers into believing that they are
> somehow more secure because you chose to not publish RPC
> number-protocol name bindings.
or, restated,
non-publication of rpc name-protocol name bindings provides (strong
case) no (weak case) limited security in and of it self to applications
using such rpc name-protocol name bindings.
Personally I'd like to see either a weak refutation, that it provides
some resistance to attack, or the strong case, that it provides more
than some resistance, whether passive, active, or denial attacks are
considered. If this is intuitively obvious to anyone, do me the kindness
of droping me a postcard with some cites on the back, I'm always willing
to try to learn.
Eric
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02442;
25 Jun 92 11:07 EDT
Received: from wdl1.wdl.loral.com by NRI.Reston.VA.US id aa13224;
25 Jun 92 11:08 EDT
Received: by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA13554; Thu, 25 Jun 92 07:14:46 -0700
Received: from mwunix.mitre.org by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA13548; Thu, 25 Jun 92 07:14:41 -0700
Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA23860; Thu, 25 Jun 92 10:12:20 -0400
Received: from loghost.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA11835; Thu, 25 Jun 92 10:14:36 EDT
Resent-Message-Id: <9206251414.AA11835 at smiley.mitre.org.stc>
Received: from mwunix.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA05854; Thu, 25 Jun 92 01:02:23 EDT
Received: from gateway.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA07869; Thu, 25 Jun 92 01:00:03 -0400
Return-Path: <owner-ietf at ISI.EDU>
Received: from venera.isi.edu by gateway.mitre.org (5.61/SMI-2.2)
id AA22789; Thu, 25 Jun 92 01:01:31 -0400
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21282>; Wed, 24 Jun 1992 13:13:36 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA21278>; Wed, 24 Jun 1992 13:13:33 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa12309;
24 Jun 92 16:06 EDT
To: ietf at isi.edu
Reply-To: ietf-rsvp at NRI.Reston.VA.US
From: ietf-rsvp at NRI.Reston.VA.US
Subject: IETF MAILING 4: July 13-17, 1992/Boston
Date: Wed, 24 Jun 92 16:06:52 -0400
Message-Id: <9206241606.aa12309 at IETF.NRI.Reston.VA.US>
Resent-To: tsig at wdl1.wdl.loral.com
Resent-Date: Thu, 25 Jun 92 10:14:34 -0400
Resent-From: "Jeffrey A. Edelheit" <edelheit at smiley.mitre.org>
Sender: tsig-request at wdl1.wdl.loral.com
==================================================================
>>> Submissions to the tsig list: tsig at wdl1.wdl.loral.com
>>> Additions/deletions/questions: tsig-request at wdl1.wdl.loral.com
>>> Archive Server: listserv at wdl1.wdl.loral.com
==================================================================
Enclosures:
At-A-Glance
RSVP
Directions
Dear IETFers:
This is the FOURTH (almost final) mailing of logistics for the
upcoming IETF meeting, (July 13-17, 1992). The Agenda will be
mailed separately.
We have already pre-registered 410 attendees for the Boston Meeting.
Not quite as much as in San Diego, but it will still mean longer lines
and more congestion during registration. To minimize the impact of such
a large number of people on the registration process the following actions
are recommended:
1. Pre-register and pre-pay (via email). (most helpful)
2. Pre-register (via email) but pay on-site. (helpful)
3. Attend Sunday Evenings' Registration/Reception. (helpful)
Thank You,
Megan
===========
24th INTERNET ENGINEERING TASK FORCE Mailing Date : 6/24/92
AT-A-GLANCE Mailing Number: 4
DATES: July 13-17, 1992 HOST(S): James Davin, MIT
Jeffrey Schiller, MIT
John Curran, NEARnet
HOTEL/MEETING SITE: Hyatt Regency Cambridge
Overlooking Boston
575 Memorial Drive
Cambridge, MA 02139
Phone: (617) 492-1234 {fax: (617) 491-6906}
CI 4:00 p.m.; CO 12:00 p.m.
250 Rooms reserved until June 12, 1992
$99.00/single; $99.00/double (please add 9.7% tax)
Specify: IETF or 24th Internet Engineering Task Force
ALTERNATE ACCOM:* The Inn at Harvard
1201 Massachusetts Avenue (Harvard Square)
Cambridge, MA 02138
Phone (617) 491-2222 {fax: (617) 496-5020}
CI 3:00 p.m.; CO 12:00 p.m.
20 Rooms reserved until June 12, 1992
$105/single; $105/double (please add 9.7%tax)
Specify: GC-INTER
The Royal Sonesta
5 Cambridge Parkway
Phone (617) 491-3600 {fax: (617) 661-5956}
10 Rooms reserved until June 12, 1992
$120 (single/double)
Specify: IETF Group
PRE-REGISTRATION: Sunday, July 12, 1992
6pm - 8pm (reception during)
Hyatt Regency Cambridge
Room: Riverside
REGISTRATION: Monday, July 13, 1992
8am - 9am
Hyatt Regency Cambridge
Room: Outside Adams
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
$130.00 if received BY June 12, 1992
$150.00 if received AFTER June 12, 1992
AIRLINE: United Airlines (special rate roundtrip only)
1 (800) 521-4041 Meeting ID: 514VS (IETF)
We regret that discounted fares are not
available for international flights.
CAR RENTAL: Hertz Discounts available through United.
AIRPORT: Logan International Airport
PARKING: Hyatt Regency: $12/day for guests
SHUTTLE: None available
==========
REGISTRATION FORM
24th Internet Engineering Task Force - Page 1 of 2
July 13 - 17, 1992
Boston, MA
Please print or type:
Name (Mr/Dr/Ms)__________________________________________________________
Title____________________________________________________________________
Organization_____________________________________________________________
Address__________________________________________________________________
City_______________________________State______________Zip Code___________
Telephone______________________________Fax_______________________________
Email____________________________________________________________________
Please check a) and b) below so we can identify your organization type and
interest.
a) Organization Type ___HW/SW Vendor ___Government ___Network Provider
___University ___Other (_______________________)
b) Your interest in 24th IETF Meeting: ___Network Operator
___Network User ___Product Developer ___Researcher
___Other (________________)
Do you plan to attend the Sunday, July 12, 1992 evening reception?
YES___ NO___
$150.00 ($130.00 + $20.00 late fee) Registration postmarked after
June 12, 1992.
Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check enclosed
(U.S. dollars, drawn on a U.S. Bank), payable to:
Corporation for National Research Initiatives
Account No.____________________________ Expiration Date__________________
Cardholder Signature_____________________________________________________
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: ietf-rsvp at nri.reston.va.us
Facsimile: +1-703-620-0913
Postal: Corporation for National Research Initiatives
Accounting Department - 24th IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
REGISTRATION FORM
24th Internet Engineering Task Force - Page 2 of 2
July 13 - 17, 1992
Boston, MA
IMPORTANT:
1. Register ONE person per form. Substitutions are NOT allowed.
2. Purchase orders are NOT accepted.
3. DD Form 1556 IS accepted.
4. Request for refunds must be received by July 10, 1992.
5. Refund policy: Refunds are subject to a $20.00 service charge.
Late fees will not be refunded.
6. Your registration fee includes a copy of the Meeting's Proceedings,
Sunday evening reception (cash bar), daily continental
breakfasts and coffee breaks.
For additional information or assistance, please contact +1-703-620-8990,
+1-703-620-0913 (Fax) or ietf-rsvp at nri.reston.va.us. Direct all inquiries
to: 24th IETF Meeting - Boston.
===========
24th Internet Engineering Task Force
July 13-17, 1992
Boston, Massachusetts
Directions from the Logan International Airport to the Hyatt Cambridge:
Follow signs to Sumner Tunnel. After leaving the tunnel, stay to the left
and follow signs to 93 North. Take Exit 26 onto Storrow Drive. Look for
signs: Kendall Square/Cambridge. Follow Kendall Square signs to
Memorial Drive/Route 3N (Route 3N and Memorial Drive are the same road at
this point). Turn right at the first traffic light (Amesbury Street).
(Although the hotel address is 575 Memorial Drive, the main entrance is
off of Amesbury Street.)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02720;
25 Jun 92 11:26 EDT
Received: from wdl1.wdl.loral.com by NRI.Reston.VA.US id aa15588;
25 Jun 92 11:26 EDT
Received: by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA13605; Thu, 25 Jun 92 07:17:44 -0700
Received: from mwunix.mitre.org by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA13575; Thu, 25 Jun 92 07:17:37 -0700
Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA24006; Thu, 25 Jun 92 10:15:18 -0400
Received: from loghost.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA11917; Thu, 25 Jun 92 10:17:33 EDT
Resent-Message-Id: <9206251417.AA11917 at smiley.mitre.org.stc>
Received: from mwunix.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA06112; Thu, 25 Jun 92 02:25:23 EDT
Received: from gateway.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA09485; Thu, 25 Jun 92 02:23:03 -0400
Return-Path: <owner-ietf at ISI.EDU>
Received: from venera.isi.edu by gateway.mitre.org (5.61/SMI-2.2)
id AA23411; Thu, 25 Jun 92 02:24:23 -0400
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21294>; Wed, 24 Jun 1992 13:14:03 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA21289>; Wed, 24 Jun 1992 13:13:58 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa12366;
24 Jun 92 16:10 EDT
To: ietf at isi.edu
Reply-To: ietf-rsvp at NRI.Reston.VA.US
From: ietf-rsvp at NRI.Reston.VA.US
Subject: 24TH IETF: DRAFT AGENDA: July 13-17, 1992/Boston
Date: Wed, 24 Jun 92 16:10:49 -0400
Message-Id: <9206241610.aa12366 at IETF.NRI.Reston.VA.US>
Resent-To: tsig at wdl1.wdl.loral.com
Resent-Date: Thu, 25 Jun 92 10:17:32 -0400
Resent-From: "Jeffrey A. Edelheit" <edelheit at smiley.mitre.org>
Sender: tsig-request at wdl1.wdl.loral.com
==================================================================
>>> Submissions to the tsig list: tsig at wdl1.wdl.loral.com
>>> Additions/deletions/questions: tsig-request at wdl1.wdl.loral.com
>>> Archive Server: listserv at wdl1.wdl.loral.com
==================================================================
Below is the latest DRAFT of the Agenda for the 24th Internet
Engineering Task Force. This version is also available via ftp,
cd ietf, get 0mtg-agenda.txt.
Agenda of the Twenty-Fourth IETF - as of 6/24/92 11:00am
(July 13-17, 1992)
MONDAY, July 13, 1992
8:00-9:00 am IETF Registration and Continental Breakfast
9:00-9:30 am Introductions
9:30-12:00 noon Morning Sessions
APP Internet SMTP Extensions WG (smtpext)
(John Klensin/MIT)
INT IP over Appletalk WG (appleip) (John Veizades/Apple)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
OPS Network Status Reports (netstat) (Gene Hastings/PSC)
OSI OSI Directory Services WG (osids)
(Steve Hardcastle-Kille/ISODE)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG Open Shortest Path First IGP WG (ospf)
(John Moy/Proteon)
SEC Security Area Advisory Group (saag)
(Stephen Crocker/TIS)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF New Internet Routing and Addressing
Architecture BOF (nimrod) (Noel Chiappa)
BOF Remote Conferencing BOF (remconf)(Jack Drescher/MCNC
and Ari Ollikainen/LLNL)
INT IP over Appletalk WG (appleip) (John Veizades/Apple)
OSI OSI Directory Services WG (osids)
(Steve Hardcastle-Kille/ISODE)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Network Access Server Requirements WG (nasreq) WG
(Allan Rubens)
TSV Domain Name System WG (dns) (Mike Reilly/DEC)
USV Internet School Networking WG (isn)
(John Clement/EDUCOM, Connie Stout/TheNet and
Art St. George/UNM)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
BOF Email Requirements BOF (mailreq) (Russ Hobby/UCDavis)
BOF IP Routing for Wireless/Mobile Hosts BOF (moblhost)
(Steve Deering/Xerox)
BOF SNMP Security Implementors BOF (snmpseci)
(Keith McCloghrie/Hughes and Jim Galvin/TIS)
OPS Benchmarking Methodology WG (bmwg)
(Scott Bradner/Harvard)
OSI MHS-DS WG (mhsds) (Kevin Jordan/CDC and
Harald Alvestrand/SINTEF DELAB)
OSI Network OSI Operations WG (noop) (Sue Hares/Merit)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC TSIG/IETF Coordination Meeting
TSV Service Location Protocol WG (svrloc)
(John Veizades/Apple)
TUESDAY, July 14, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am IETF Technical Presentations
o ``The Futures of the Internet'' (Mitch Kapor/EFF)
9:30-12:00 noon TSIG Plenary Session
9:30-12:00 noon Morning Sessions
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF Routing Requirements Checklist BOF (rreqlist)
(Pushpendra Mohta/CERFnet)
APP Network Database WG (netdata) (Daisy Shen/IBM)
APP Telnet WG (telnet)
(Steve Alexander/INTERACTIVE Systems)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
INT Point-to-Point Protocol Extensions WG (pppext)
(Brian Lloyd/Consultant)
MGT FDDI MIB WG (fddimib) (Jeff Case/UTenn)
MGT Internet Accounting WG (acct) (Cyndi Mills/BBN
and Gregory Ruth/BBN)
OSI MHS-DS WG (mhsds) (Kevin Jordan/CDC and
Harald Alvestrand/SINTEF DELAB)
SEC Common Authentication Technology WG (cat)
(John Linn/DEC)
USV User Documents WG (userdoc2) (Ellen Hoffman/UMich
and Lenore Jackson/NASA)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF Host Resources MIB BOF (hostmib)
(Steve Waldbusser/CMU)
OPS Operational Statistics WG (opstat)
(Phill Gross/ANS and Bernhard Stockman/SUNET)
OSI MIME-MHS Interworking WG (mimemhs)
(Steve Thompson/SoftSwitch)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Common Authentication Technology WG (cat)
(John Linn/DEC)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV Internet User Glossary WG (userglos)
(Tracy LaQuey Parker/UTexas and Gary Malkin/Xylogics)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF IP Security BOF (ipsec) (Steve Crocker/TIS)
OPS Operational Statistics WG (opstat)
(Phill Gross/ANS and Bernhard Stockman/SUNET)
OSI SNMP over a Multi-protocol Internet WG (mpsnmp)
(Ted Brunner/Bellcore)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tnfs) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess)(Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV Internet User Glossary WG (userglos)
(Tracy LaQuey Parker/UTexas and Gary Malkin/Xylogics)
7:00-10:00 pm Evening Sessions
BOF Internet Society Q&A (isoc) (Vint Cerf/CNRI)
BOF Uninterruptable Power Supply BOF (upsmib)
(Jeff Case/UTenn and Bob Stewart/Xyplex)
OPS BGP Deployment and Application WG (bgpdepl)
(Jessica Yu/Merit)
OSI Network OSI Operations WG (noop) (Sue Hares/Merit)
RTG Multicast Extensions to OSPF WG (mospf)
(Steve Deering/Xerox PARC)
SEC TCP Client Identity Protocol WG (ident)
(Mike StJohns/DOD)
WEDNESDAY, July 15, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am Technical Presentations
o ``Pip: The `P' Internet Protocol''
(Paul Tsuchiya/Bellcore)
9:30-12:00 noon Morning Sessions
INT IP over ATM WG (atm) (Bob Hinden/Sun)
INT Point-to-Point Protocol Extensions WG (pppext)
(Brian Lloyd/Consultant)
MGT Chassis MIB WG (chassis) (Jeff Case/UTenn and
Bob Stewart/Xyplex)
MGT DS1/DS3 MIB WG (trunkmib) (Fred Baker/ACC and
Tracy Cox/Bellcore)
OSI Office Document Architecture WG (oda)
(Peter Kirstein/UCL)
RTG Inter-Domain Policy Routing WG (idpr)
(Martha Steenstrup/BBN)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV User Services WG (uswg) (Joyce Reynolds/ISI)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF Remote Conferencing BOF (remconf) (Jack Drescher/MCNC
and Ari Ollikainen/LLNL)
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT Token Ring Remote Monitoring WG (trmon)
(Mike Erlinger/Lexcel)
OPS BGP Deployment and Application WG (bgpdepl)
(Jessica Yu/Merit)
OSI X.400 Operations WG (x400ops)
(Alf Hansen/SINTEF DELAB)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
RTG RIP Version II WG (ripv2) (Gary Malkin/Xylogics)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
USV Internet Anonymous FTP Archives WG (iafa)
(Peter Deutsch/McGill and Alan Emtage/McGill)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT IEEE 802.3 Hub MIB WG (hubmib) (Keith McCloghrie/Hughes
and Donna McMaster/SynOptics)
OPS User Connectivity Problems WG (ucp) (Dan Long/BBN)
OSI X.400 Operations WG (x400ops) (Alf Hansen/SINTEF DELAB)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
USV Network Information Services Infrastructure WG (nisi)
(April Marine/SRI and Pat Smith/Merit)
7:00-10:00pm Evening Session
BOF Authorization and Access Control BOF (aac)
(Clifford Neuman/ISI)
BOF A New Internet Protocol BOF (pip)
(Paul Tsuchiya/Bellcore)
BOF Directory Resources Engineering Group BOF (dregs)
(Joan Gargano/UCDavis and Joyce K. Reynolds/ISI)
BOF Simple Management Protocol (SMP) Framework BOF
(smpframe) (Marshall Rose/DBC)
BOF Perspectives on the Next Generation of the NSFnet
(nsfnet)(Laura Breeden/FARNET)
THURSDAY, July 16, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am Technical Presentations
o ``DARPA Research Testbed Network'' (Bob Braden/ISI)
9:30-12:00 noon TSIG Plenary
9:30-12:00 noon Morning Sessions
BOF IP Address Encapsulation BOF (ipae)
(Bob Hinden/Sun and Dave Crocker/TBO)
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT Bridge MIB WG (bridge) (Fred Baker/ACC)
OPS User Connectivity Problems WG (ucp) (Dan Long/BBN)
RTG Inter-Domain Policy Routing WG (idpr)
(Martha Steenstrup/BBN)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Privacy-Enhanced Electronic Mail WG (pem)
(Steve Kent/BBN)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
Breaks Coffee available throughout the morning.
1:30-3:30 pm Afternoon Sessions I
APP Network Database WG (netdata) (Daisy Shen/IBM)
BOF IP Routing for Wireless/Mobile Hosts BOF (moblhost)
(Steve Deering/Xerox)
BOF TCP/UDP over CLNP BOF (tuc) (Peter Ford and Ross Callon)
MGT Internet Accounting WG (acct) (Cyndi Mills/BBN
and Gregory Ruth/BBN)
MGT X.25 Management Information Base WG (x25mib)
(Dean Throop/Data General)
OPS Network Joint Management WG (njm) (Gene Hastings/PSC)
SEC Security Area Advisory Group (saag)
(Stephen Crocker/TIS)
USV Directory Information Services Infrastructure WG (disi)
(Chris Weider/Merit)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Technical Presentations
FRIDAY, July 17, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30am Technical Presentations
9:30-12:00pm Summary Reports
APP Applications Area (Russ Hobby/UC Davis)
INT Internet Area (Noel Chiappa and
Philip Almquist/Consultant)
MGT Network Management Area (Chuck Davin/MIT)
OPS Operations Area (Susan Estrada/CERFnet, Phill Gross/ANS,
Bernhard Stockman/SUNET)
OSI OSI Integration Area (Erik Huizer/SURFnet and
David Piscitello/Bellcore)
RTG Routing Area (Bob Hinden/Sun)
SEC Security Area (Steve Crocker/TIS)
TSV Transport and Services Area
(David Borman/Cray Research)
USV User Services Area (Joyce K. Reynolds/ISI)
12:00 pm Concluding Remarks (Phill Gross/ANS)
12:30 pm Adjourn
Key to Abbreviations
APP Applications Area
BOF Birds of a Feather Session
INT Internet Area
MGT Network Management Area
OSI OSI Integration Area
OPS Operational Requirements Area
RTG Routing Area
SEC Security Area
TSG Trusted Sytems Interoperability Group (TSIG)
TSV Transport and Services Area
USV User Services Area
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03319;
25 Jun 92 11:56 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa19933;
25 Jun 92 11:56 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20891>; Thu, 25 Jun 1992 06:11:33 -0700
Received: from netcs.netcs.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA20887>; Thu, 25 Jun 1992 06:10:43 -0700
Received: from hobbit.netcs.com by netcs.netcs.com (5.61++/IDA);
id AA09933; Thu, 25 Jun 92 15:07:15 +0200
Received: by hobbit.netcs.com (4.1/netCS-1.0)
id AA15544; Thu, 25 Jun 92 15:07:14 +0200
From: Oliver Korfmacher <okorf at netcs.com>
Message-Id: <9206251307.AA15544 at hobbit.netcs.com>
Subject: ISDN MIB
To: ietf at isi.edu
Date: Thu, 25 Jun 92 15:07:13 MET DST
Return-Receipt-To: okorf at netcs.com
X-Mailer: ELM [version 2.2 PL10]
Hello.
What do you think about creating a working group (or at least a
mailing list) for ISDN MIB? Is there already such thing?
Any ideas?
Gruesse, Oliver
Oliver Korfmacher (okorf at netcs.com, whois OK11,
/S=Korfmacher/P=netCS/A=DBP/C=DE)
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03429;
25 Jun 92 12:05 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03425;
25 Jun 92 12:04 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa21242;
25 Jun 92 12:05 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA02252; Thu, 25 Jun 92 11:05:36 CDT
Received: by hemlock.cray.com
id AA01496; 4.1/CRI-5.5; Thu, 25 Jun 92 11:05:27 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA01492; 4.1/CRI-5.5; Thu, 25 Jun 92 11:05:26 CDT
Received: from handel.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA02241; Thu, 25 Jun 92 11:05:21 CDT
Received: by handel.cray.com
id AA08723; 5.57/CRI-5.5; Thu, 25 Jun 92 11:04:21 -0500
Date: Thu, 25 Jun 92 11:04:21 -0500
From: "David A. Borman" <dab at berserkly.cray.com>
Message-Id: <9206251604.AA08723 at handel.cray.com>
To: Lawrie.Brown at adfa.oz.au, telnet-ietf at timbuk.cray.com
Subject: Re: Revised Kerberos IV Draft
> } > In section 2 detailing the Command Meanings I believe the IS and REPLY
> } > suboption commands have been left out, though they are shown in the
> } > examples in section 4. If they have been left out, then they need to
>
> } Egad, you are absolutly right! For the Kerberos IV specification,
>
> and the same problem exists with the SPX draft as well.
>
> While discussing this I do have a general query as to why you chose to format
> the suboption negotiations in all of these as:
>
> IS ... AUTH ...
> REPLY ... ACCEPT ...
> REPLY ... REJECT ...
> IS ... CHALLENGE ...
> REPLY ... RESPONSE ...
>
> rather than just
> AUTH ...
> ACCEPT ...
> REJECT ...
> CHALLENGE ...
> RESPONSE ...
>
> where the above commands are obviously given numbers that don't conflict with
> the standard IS SEND REPLY etc
>
> To me it seems that you are occupying 2 bytes to carry information that
> quite easily is carried in one. It also makes the parsing of responses
> harder, since you have varying formats for a given sub-option command
> that you must distonguish between, rather than just a single format.
> It was for all these reasons we chose the latter approach with the
> LOKI challenge-response system we're using here, and I'm curious as
> to your reasons for taking the alternate.
>
> Regards
> Lawrie.
Well, the reason for the distinction is one of layering. The IS and REPLY
(along with SEND and NAME) are the generic codes used by the authentication
option, for all forms of authentication. The AUTH, ACCEPT, REJECT,
CHALLENGE and RESPONSE were all defined within the context of a specific
authentication mechanism.
As for making the parsing harder, I'd argue that its all in how you
write your parser. A generic parser can be written to handel the
Authentication option, and it knows all the possible codes. The
addition of a new form of authentication will not require any changes
to the generic module. All the specifics for each authentication type
is buried in a sub-module. In my implementation, the telnet protocol
identifies the Authentication suboption, and then calls one of four
routines to process the IS, REPLY, SEND or NAME. Real simple code.
Those routines look up the authentication type in a table, and then
call the per-authentication routine. Those routines then do the
real per-authentication parsing, handeling the AUTH, ACCEPT,
REJECT, CHALLENGE and RESPONSE.
Yes, we could move them into the generic framework (that's what
happened to NAME). You might be able to argue that AUTH, ACCEPT
and REJECT are all generic, and should be moved into the main
framework, since everything defined so far uses them. But what
happens for the authentication scheme that requires multiple
interactions? Do we then add new codes for the intermediary
responses? Or do we add them now, when they might never be used?
The SEND/IS/REPLY provides a generic framework for passing
authentication information. The data contained in the IS/REPLY is
specific to the particular authentication scheme that is being used,
and has its own set of suboptions. NAME was moved to the generic
framework because it is not tied to a particular authentication scheme,
it is used to say who we want to be, once we are authenticated.
(You might authenticate yourself as "pete", but actually want to
log in as "joe". The NAME option allows for this.) The spec
for the authentication option itself will be very stable, and
new authentication schemes will not require any changes to the
main framework, no matter what its needs.
-David Borman, dab at cray.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04845;
25 Jun 92 14:00 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09825;
25 Jun 92 14:01 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22428>; Thu, 25 Jun 1992 06:49:29 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA22423>; Thu, 25 Jun 1992 06:49:26 -0700
Received: from Angband.Stanford.EDU by NRI.Reston.VA.US id aa00412;
25 Jun 92 9:41 EDT
Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0)
id AA14675; Thu, 25 Jun 92 06:41:07 -0700
Date: Thu, 25 Jun 92 09:00:50 EDT
From: William Allen Simpson <bsimpson at angband.stanford.edu>
Message-Id: <472.bsimpson at angband.stanford.edu>
To: ietf at NRI.Reston.VA.US
Reply-To: bsimpson at angband.stanford.edu
Subject: Re: postscript
> From: Ned Freed <NED at innosoft.com>
> I agree with Scott on this -- fonts are almost never the problem these
> days. The basic set of Abode fonts have become so widespread that it is
> a rare thing to find PostScript that expects to find other fonts in the
> hardware of the drawing engine.
>
No font problems? I guess nobody is reading Paul Tsuchiya's PIP draft.
It's full of PTxxx fonts, which I assume he had a wonderful time
creating, but which turn into Ghostscript Ugly font. His document is
completely unreadable.
Another item which needs to be tested is SIZE of fonts. Many of the
postscript RFCs I've tried to print have lots of tiny text in the pretty
little boxes and footnotes. This turns into lots of tiny little smudges
on screen preview and dot-matrix printers. I'd say all text must be a
minimum of pica size.
As part of the "test suite" being proposed, any document must be
printable on screen and dot-matrix printer. This mean it must be
representable at 60-72 dots per inch, not 300 dpi.
Also, this policy must be for more than RFCs. It must apply to all
internet-drafts as well. What's the purpose of having on-line documents
that aren't readable on-line?
If it were up to me, I'd outlaw Postscript documents entirely. The
documents should be posted in text format, and raw (un-formatted) form.
For raw form today, only the commonly available nroff and tex should be
allowed.
Bill_Simpson at um.cc.umich.edu
bsimpson at ray.lloyd.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05348;
25 Jun 92 15:11 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa20153;
25 Jun 92 15:11 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20603>; Thu, 25 Jun 1992 05:50:14 -0700
Received: from IESL.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA20599>; Thu, 25 Jun 1992 05:50:09 -0700
Message-Id: <199206251250.AA20599 at venera.isi.edu>
Received: from iesl-b.mit.edu by iesl.mit.edu id AA02782g; Thu, 25 Jun 92 08:54:42 EDT
Date: Thu, 25 Jun 92 08:54:42 EDT
From: Jim Culbert <culbert at iesl.mit.edu>
Received: by iesl-b.mit.edu (4.1/SMI-4.1)
id AA12528; Thu, 25 Jun 92 08:54:21 EDT
To: cheryl at cc.gatech.edu
Cc: snmp at psi.com, ietf at isi.edu
In-Reply-To: Cheryl Krupczak's message of Wed, 24 Jun 92 12:57:55 EDT <9206241657.AA16381 at terminus.cc.gatech.edu>
Subject: Object Management Group (OMG)
Here is a response that I got from a similar reply. The guy who sent it
is an OMG guy. I have many 2cents to put in about the organization but
little time this morning. Just approach this whole OMG hoopla thing
with a little caution and a big grain of salt.
-Jim
===========================================================================
> Jim Culbert <
> M.I.T Intelligent Engineering Systems Laboratory <
> Department of Civil Engineering <
> Room 1-270 <
> Cambridge, Ma. 02139. <
> <
> Phone (617) 253-7134 <
> e-mail: culbert at iesl.mit.edu <
===========================================================================
* When cows laugh does milk come out their nose? *
===========================================================================
______________________________________________________________________
Date: Tue, 14 Jan 92 09:31:09 est
From: soley at emerald.omg.ORG (Richard Mark Soley)
To: culbert at iesl.mit.edu
Cc: PCORRIGAN at vms.eurokom.ie
In-Reply-To: PCORRIGAN at vms.eurokom.ie's message of Tue, 14 Jan 1992 10:49 CET <01GFAXTIJX0G000BRY at vms.eurokom.ie>
Subject: OMG
Message-ID:<CULBERT.92Jan7152151 at phaeton.bloom-picayune>
Sorry if this is a FAQ.
I have sitting here in front of me several documents which make widespread
reference to the Object Management Group. What is this creature. Any
pointers would be greatly appreciated.
In answer to your general question about the OMG, here's a brief overview.
Feel free to call, fax or email for more information. I'll have a press
kit with current information sent to you.
-- Richard Soley
Vice President & Technical Director
Object Management Group, Inc.
and cooincidentally, MIT '82, SM '85, PhD '89 (EECS)
The Object Management Group (OMG) is an international software industry
consortium with two primary aims:
(*) promotion of the object-oriented approach to software engineering
in general, and
(*) development of command models and a common interface for the development
and use of large-scale distributed applications (open distributed
processing) using object-oriented methodology.
Although the OMG is not a recognized standards group (like ISO or national
bodies such as ANSI and IEEE), OMG is developing "standards" in the form
of wholesale consensus agreements between member companies leading to
a single architecture and interface specification for application and
enterprise integration on both the small and large scales.
The OMG was founded in April 1989, and continues to have a small,
vendor-neutral core staff of seven people. Now comprising about 200
companies, the OMG membership is composed of large and small hardware
& software vendors (IBM, Canon, DEC, Philips, Olivetti, AT&T, Sun
Microsystems, Informix, ICL, Enfin Systems, Architecture Projects
Management, Apple Computer, O2 Technology, etc.) as well as end-user
companies (Citicorp, American Airlines, Royal Bank of Canada, John
Deere, etc.) with a common goal: the promotion of open standards for
interoperability of applications using an object oriented framework.
A key differentiation of the OMG standards approach is that such
standards are and will be based, as far as possible, on existing,
commercially available products.
In late 1990 the OMG published its Object Management Architecture
(OMA) Guide document. This document outlines a single terminology for
object-oriented languages, systems, databases and application
frameworks; an abstract framework for object-oriented systems; a set
of both technical and architectural goals; and an architecture
(reference model) for distributed applications using object-oriented
techniques. To fill out this reference model, four areas of
standardization have been identified:
1) the Object Request Broker, or key communications element, for
handling distribution of messages between application objects in
a highly interoperable manner;
2) the Object Model, or single design-portability abstract model for
communicating with OMG-conforming object-oriented systems;
3) the Object Services, which will provide the main functions for
realising basic object functionality using the Object Request Broker -
the logical modelling and physical storage of objects; and
4) the Common Facilities will comprise facilities which are useful in
many application domains and which will be made available through OMA
compliant class interfaces.
The OMG adoption cycle includes Requests for Information and
Proposals, requesting detailed technical and commercial availability
information from OMG members about existing products to fill
particular parts of the reference model architecture. After passage
by Technical and Business committees to review these responses, the
OMG Board of Directors makes a final determination for technology adoption.
Adopted specifications are available on a fee-free basis to members and
non-members alike.
In late 1991 OMG adopted its first interface technology, for the Object
Request Broker portion of the reference model. This technology, adopted
from a joint proposal (named "CORBA") of Hewlett-Packard, NCR Corp.,
HyperDesk Corp., Digital Equipment Corp., Sun Microsystems and Object
Design Inc. includes both static and dynamic interfaces to an inter-
application request handling software "bus."
Unlike other organizations, the OMG itself does not and will not
develop nor sell software of any kind. Instead, it selects and promulgates
software interfaces; products which offer these interfaces continue to be
developed and offered by commercial companies.
In order to serve OMG membership interested in other object-oriented systems
arenas besides the distributed system problem, the Group supports Special
Interest Groups for discussion of possible standards in other areas. These
groups at present are:
1) Object Oriented Databases;
2) OO Languages;
3) End-User Requirements;
4) Parallel Processing;
5) Analysis & Design Methodologies;
6) Smalltalk; and
7) Class Libraries.
Any company, university/research institution or individual, whether
end-user or vendor, can become a member of this body. Administrative
details are given at the end of this paper.
______________________________________________________________________
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06634;
25 Jun 92 16:32 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa26523;
25 Jun 92 16:32 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA27325>; Thu, 25 Jun 1992 08:35:02 -0700
Received: from nic.cerf.net by venera.isi.edu (5.65c/5.65+local-6)
id <AA27317>; Thu, 25 Jun 1992 08:34:59 -0700
Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA02422; Thu, 25 Jun 92 08:35:00 PDT
From: Pushpendra Mohta <pushp-m at cerf.net>
Message-Id: <9206251535.AA02422 at nic.cerf.net>
Subject: Re: 24TH IETF: DRAFT AGENDA: July 13-17, 1992/Boston
To: ietf-rsvp at NRI.Reston.VA.US
Date: Thu, 25 Jun 92 8:34:59 PDT
Cc: ietf at isi.edu
In-Reply-To: <9206241610.aa12366 at IETF.NRI.Reston.VA.US>; from "ietf-rsvp at NRI.Reston.VA.US" at Jun 24, 92 4:10 pm
X-Usmail: CERFnet, P.O. BOX 85608, San Diego, CA 92186-9784
X-Mailer: ELM [version 2.3 PL11]
ietf-rsvp at NRI.Reston.VA.US writes:
>>
>>
>>
>>Below is the latest DRAFT of the Agenda for the 24th Internet
>>Engineering Task Force. This version is also available via ftp,
>>cd ietf, get 0mtg-agenda.txt.
>>
>>
>> Agenda of the Twenty-Fourth IETF - as of 6/24/92 11:00am
>> (July 13-17, 1992)
>>
>>
>>TUESDAY, July 14, 1992
>>
>>9:30-12:00 noon Morning Sessions
>>
>> BOF Routing Requirements Checklist BOF (rreqlist)
^^^
>> (Pushpendra Mohta/CERFnet)
Should read
BOF RoutER Requirements Checklist BOF (rreqlist)
Regards
--pushpendra
Pushpendra Mohta pushp at cerf.net +1 619 455 3908 (NEW)
CERFNet +1 800 876 2373
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06837;
25 Jun 92 16:51 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06829;
25 Jun 92 16:51 EDT
Received: from BITSY.MIT.EDU by NRI.Reston.VA.US id aa27244; 25 Jun 92 16:52 EDT
Received: by bitsy.MIT.EDU
id AA18766; Thu, 25 Jun 92 16:38:59 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA18760; Thu, 25 Jun 92 16:38:50 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA14098; Thu, 25 Jun 92 16:38:44 EDT
Received: by inet-gw-2.pa.dec.com; id AA26978; Thu, 25 Jun 92 13:38:12 -0700
Received: by us1rmc.bb.dec.com; id AA00226; Thu, 25 Jun 92 16:39:18 -0400
Message-Id: <9206252039.AA00226 at us1rmc.bb.dec.com>
Received: from erlang.enet; by us1rmc.enet; Thu, 25 Jun 92 16:39:32 EDT
Date: Thu, 25 Jun 92 16:39:32 EDT
From: John Linn 25-Jun-1992 1637 <linn at erlang.enet.dec.com>
To: cat-ietf at mit.edu
Cc: linn at erlang.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Fwd: comments from Raj
P. Rajaram (P.Rajaram at Eng.Sun.COM) sent the attached comments to me directly.
With his permission, I'm forwarding them to the list.
As an initial thought, it strikes me that gss_OID_set as input to
init_sec_context seems like a useful idea. On the other issue, if the
presumption of "confidentiality implies integrity and data origin
authentication as well" were removed, as it could be, this would imply that
GSS_Seal should accept an integ_req_flag or some such, and certainly that
GSS_Unseal should return an indicator of whether message integrity was or was
not verified. While possible in principle, I suspect that use of pure
encryption without integrity features is more likely to make sense at protocol
layers below the application layer where most GSS-API callers will reside.
--jl
---------Raj's comments follow------------
I just recovered Doug's comments (that you had posted long ago).
> o Section 3.3 on the gss_init_sec_context routine shows mech_type to be
> of type gss_OID. This is OK, but it would be nicer if it could be a
> gss_OID_set, listing a set of mech_types acceptable for use.
I don't know what Doug's motivations were, but here is one benefit.
It allows for selection of the mech_type while establishing a context
between a client and server.
Say the client somehow determined the set of mech_types acceptable to the
server. (You list 4 ways on page 6, latest GSSAPI draft)
The client would then feed this set into the GSS_Init_sec_context() call.
The mech_type selection would be done by GSSAPI based on:
1) The input set of mech_types,
2) The mech_types available to the client (via its cred_handle),
3) the flags specified (deleg_req, mutual_req, etc)
and possibly other implementation specific rules.
------------------------
How did the server determine the mech_types acceptable to it ?
That problem can be solved later, possibly by adding a call:
GSS_Map_mechanisms:
Inputs:
- claimant_cred_handle OCTET STRING
- desired_mechs SET OF OBJECT IDENTIFIER
- deleg_req_flag BOOLEAN
- mutual_req_flag BOOLEAN
- replay_det_req BOOLEAN
- ...
Outputs:
- major_status
- minor_status
- available_mechs SET OF OBJECT IDENTIFIER
(the function "maps" req_flags into a set of mechanisms)
------------------------
On a different issue, why do you feel that it is necessary to state that
clients can not get confidentiality without also getting integrity ?
Won't there be mechanisms that support these two services in a way that
allows one to be provided without the other ? (ref SDNS)
Some mechanisms will behave the way you describe, but by stating it in
the GSSAPI spec (page 10, section 1.2.2, para 2), the effect will be
to force all mechanisms to behave that way. Can you explain ?
[...]
1) Your struct and typedef names are:
----- struct name ----- ------ typedef names -----
gss_buffer_desc_struct gss_buffer_desc, *gss_buffer_t
gss_OID_desc *gss_OID
gss_OID_set_desc *gss_OID_set
gss_channel_bindings_struct *gss_channel_bindings
I wonder if the names can be made more uniform and therefore more
easily rememberable. One suggestion is:
gss_buffer_desc gss_buffer, *gss_buffer_t
gss_OID_desc gss_OID, *gss_OID_t
gss_OID_set_desc gss_OID_set, *gss_OID_set_t
gss_channel_bindings_desc gss_channel_bindings,
*gss_channel_bindings_t
All the structs have a '_desc' suffix, and all the typedefs are
pointers and have a '_t' suffix. Other good or better conventions
exist.
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06837;
25 Jun 92 16:51 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06829;
25 Jun 92 16:51 EDT
Received: from BITSY.MIT.EDU by NRI.Reston.VA.US id aa27244; 25 Jun 92 16:52 EDT
Received: by bitsy.MIT.EDU
id AA18766; Thu, 25 Jun 92 16:38:59 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA18760; Thu, 25 Jun 92 16:38:50 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA14098; Thu, 25 Jun 92 16:38:44 EDT
Received: by inet-gw-2.pa.dec.com; id AA26978; Thu, 25 Jun 92 13:38:12 -0700
Received: by us1rmc.bb.dec.com; id AA00226; Thu, 25 Jun 92 16:39:18 -0400
Message-Id: <9206252039.AA00226 at us1rmc.bb.dec.com>
Received: from erlang.enet; by us1rmc.enet; Thu, 25 Jun 92 16:39:32 EDT
Date: Thu, 25 Jun 92 16:39:32 EDT
From: John Linn 25-Jun-1992 1637 <linn at erlang.enet.dec.com>
To: cat-ietf at mit.edu
Cc: linn at erlang.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Fwd: comments from Raj
P. Rajaram (P.Rajaram at Eng.Sun.COM) sent the attached comments to me directly.
With his permission, I'm forwarding them to the list.
As an initial thought, it strikes me that gss_OID_set as input to
init_sec_context seems like a useful idea. On the other issue, if the
presumption of "confidentiality implies integrity and data origin
authentication as well" were removed, as it could be, this would imply that
GSS_Seal should accept an integ_req_flag or some such, and certainly that
GSS_Unseal should return an indicator of whether message integrity was or was
not verified. While possible in principle, I suspect that use of pure
encryption without integrity features is more likely to make sense at protocol
layers below the application layer where most GSS-API callers will reside.
--jl
---------Raj's comments follow------------
I just recovered Doug's comments (that you had posted long ago).
> o Section 3.3 on the gss_init_sec_context routine shows mech_type to be
> of type gss_OID. This is OK, but it would be nicer if it could be a
> gss_OID_set, listing a set of mech_types acceptable for use.
I don't know what Doug's motivations were, but here is one benefit.
It allows for selection of the mech_type while establishing a context
between a client and server.
Say the client somehow determined the set of mech_types acceptable to the
server. (You list 4 ways on page 6, latest GSSAPI draft)
The client would then feed this set into the GSS_Init_sec_context() call.
The mech_type selection would be done by GSSAPI based on:
1) The input set of mech_types,
2) The mech_types available to the client (via its cred_handle),
3) the flags specified (deleg_req, mutual_req, etc)
and possibly other implementation specific rules.
------------------------
How did the server determine the mech_types acceptable to it ?
That problem can be solved later, possibly by adding a call:
GSS_Map_mechanisms:
Inputs:
- claimant_cred_handle OCTET STRING
- desired_mechs SET OF OBJECT IDENTIFIER
- deleg_req_flag BOOLEAN
- mutual_req_flag BOOLEAN
- replay_det_req BOOLEAN
- ...
Outputs:
- major_status
- minor_status
- available_mechs SET OF OBJECT IDENTIFIER
(the function "maps" req_flags into a set of mechanisms)
------------------------
On a different issue, why do you feel that it is necessary to state that
clients can not get confidentiality without also getting integrity ?
Won't there be mechanisms that support these two services in a way that
allows one to be provided without the other ? (ref SDNS)
Some mechanisms will behave the way you describe, but by stating it in
the GSSAPI spec (page 10, section 1.2.2, para 2), the effect will be
to force all mechanisms to behave that way. Can you explain ?
[...]
1) Your struct and typedef names are:
----- struct name ----- ------ typedef names -----
gss_buffer_desc_struct gss_buffer_desc, *gss_buffer_t
gss_OID_desc *gss_OID
gss_OID_set_desc *gss_OID_set
gss_channel_bindings_struct *gss_channel_bindings
I wonder if the names can be made more uniform and therefore more
easily rememberable. One suggestion is:
gss_buffer_desc gss_buffer, *gss_buffer_t
gss_OID_desc gss_OID, *gss_OID_t
gss_OID_set_desc gss_OID_set, *gss_OID_set_t
gss_channel_bindings_desc gss_channel_bindings,
*gss_channel_bindings_t
All the structs have a '_desc' suffix, and all the typedefs are
pointers and have a '_t' suffix. Other good or better conventions
exist.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07420;
25 Jun 92 17:32 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa28861;
25 Jun 92 17:32 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA29529>; Thu, 25 Jun 1992 09:16:22 -0700
Received: from cerc.wvu.wvnet.edu (cathedral.cerc.wvu.wvnet.edu) by venera.isi.edu (5.65c/5.65+local-6)
id <AA29525>; Thu, 25 Jun 1992 09:16:19 -0700
Received: by cerc.wvu.wvnet.edu (4.1/SMI-4.0:RAL-041790)
id AA00463; Thu, 25 Jun 92 12:12:30 EDT
From: "R. Kannan" <kannan at cerc.wvu.wvnet.edu>
Message-Id: <9206251612.AA00463 at cerc.wvu.wvnet.edu>
Subject: Re: Sun RPC program IDs
To: Nathaniel Mishkin <mishkin at apollo.hp.com>
Date: Thu, 25 Jun 92 12:12:29 EDT
Cc: vjs at rhyolite.wpd.sgi.com, ietf at isi.edu
In-Reply-To: <199206242155.AA26169 at venera.isi.edu>; from "Nathaniel Mishkin" at Jun 24, 92 5:47 pm
X-Mailer: ELM [version 2.3 PL6]
>
> To my (biased) way of thinking, this whole discussion of allocation of
> Sun RPC program IDs just makes it clear that schemes based on a centrally
> administered and relatively small space of IDs are bad for identifying
> distributed services. In contrast, the OSF DCE RPC mechanism uses unique
> IDs (composed from a timestamp and an IEEE 802 address) to identify
> interfaces (programs). (UUIDs are handy for other purposes and the DCE
> applies them in other situations.) The downside is that they're 128
> bits long, but I think I'd take that over the administrative hassles.
>
> -- Nat Mishkin
> Distributed Object Computing Program / East
> Hewlett-Packard Company
> mishkin at apollo.hp.com
> -------
>
I would take it one step further for the following reasons:
IP Address + pid + timestamp
IP address is equivalent to the IEEE 802 address and
the IEEE 802 address discrimintes that node from every other node.
the pid discriminates the server process from every other
process that are active in a particular node.
And finally
the time stamp discriminates that particular service from any
other service offered by the same server.
Such a scheme guarantees global uniques. Note that ids can be
generated in decentralized manner. A process can generate its own ids
without ever conflicting with any other id generated in the whole
world.
We have successfully used this in our distributed environment called
the Communications Manager and the id is enough to locate the source
to the user whose process created the id.
It is an overkill but is very comprehensive and can take of the ever
expansive networks.
--
--
thank you very much
R. Kannan,
Concurrent Engineering Research Center
Drawer 2000, West Virginia University,
Morgantown, WV 26505
Ph:(304)293-7226, FAX:(304)293-7541
email:kannan at cerc.wvu.wvnet.edu
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07746;
25 Jun 92 18:16 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00665;
25 Jun 92 18:17 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20603>; Thu, 25 Jun 1992 05:50:14 -0700
Received: from IESL.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA20599>; Thu, 25 Jun 1992 05:50:09 -0700
Message-Id: <199206251250.AA20599 at venera.isi.edu>
Received: from iesl-b.mit.edu by iesl.mit.edu id AA02782g; Thu, 25 Jun 92 08:54:42 EDT
Date: Thu, 25 Jun 92 08:54:42 EDT
From: Jim Culbert <culbert at iesl.mit.edu>
Received: by iesl-b.mit.edu (4.1/SMI-4.1)
id AA12528; Thu, 25 Jun 92 08:54:21 EDT
To: cheryl at cc.gatech.edu
Cc: snmp at psi.com, ietf at isi.edu
In-Reply-To: Cheryl Krupczak's message of Wed, 24 Jun 92 12:57:55 EDT <9206241657.AA16381 at terminus.cc.gatech.edu>
Subject: Object Management Group (OMG)
Here is a response that I got from a similar reply. The guy who sent it
is an OMG guy. I have many 2cents to put in about the organization but
little time this morning. Just approach this whole OMG hoopla thing
with a little caution and a big grain of salt.
-Jim
===========================================================================
> Jim Culbert <
> M.I.T Intelligent Engineering Systems Laboratory <
> Department of Civil Engineering <
> Room 1-270 <
> Cambridge, Ma. 02139. <
> <
> Phone (617) 253-7134 <
> e-mail: culbert at iesl.mit.edu <
===========================================================================
* When cows laugh does milk come out their nose? *
===========================================================================
______________________________________________________________________
Date: Tue, 14 Jan 92 09:31:09 est
From: soley at emerald.omg.ORG (Richard Mark Soley)
To: culbert at iesl.mit.edu
Cc: PCORRIGAN at vms.eurokom.ie
In-Reply-To: PCORRIGAN at vms.eurokom.ie's message of Tue, 14 Jan 1992 10:49 CET <01GFAXTIJX0G000BRY at vms.eurokom.ie>
Subject: OMG
Message-ID:<CULBERT.92Jan7152151 at phaeton.bloom-picayune>
Sorry if this is a FAQ.
I have sitting here in front of me several documents which make widespread
reference to the Object Management Group. What is this creature. Any
pointers would be greatly appreciated.
In answer to your general question about the OMG, here's a brief overview.
Feel free to call, fax or email for more information. I'll have a press
kit with current information sent to you.
-- Richard Soley
Vice President & Technical Director
Object Management Group, Inc.
and cooincidentally, MIT '82, SM '85, PhD '89 (EECS)
The Object Management Group (OMG) is an international software industry
consortium with two primary aims:
(*) promotion of the object-oriented approach to software engineering
in general, and
(*) development of command models and a common interface for the development
and use of large-scale distributed applications (open distributed
processing) using object-oriented methodology.
Although the OMG is not a recognized standards group (like ISO or national
bodies such as ANSI and IEEE), OMG is developing "standards" in the form
of wholesale consensus agreements between member companies leading to
a single architecture and interface specification for application and
enterprise integration on both the small and large scales.
The OMG was founded in April 1989, and continues to have a small,
vendor-neutral core staff of seven people. Now comprising about 200
companies, the OMG membership is composed of large and small hardware
& software vendors (IBM, Canon, DEC, Philips, Olivetti, AT&T, Sun
Microsystems, Informix, ICL, Enfin Systems, Architecture Projects
Management, Apple Computer, O2 Technology, etc.) as well as end-user
companies (Citicorp, American Airlines, Royal Bank of Canada, John
Deere, etc.) with a common goal: the promotion of open standards for
interoperability of applications using an object oriented framework.
A key differentiation of the OMG standards approach is that such
standards are and will be based, as far as possible, on existing,
commercially available products.
In late 1990 the OMG published its Object Management Architecture
(OMA) Guide document. This document outlines a single terminology for
object-oriented languages, systems, databases and application
frameworks; an abstract framework for object-oriented systems; a set
of both technical and architectural goals; and an architecture
(reference model) for distributed applications using object-oriented
techniques. To fill out this reference model, four areas of
standardization have been identified:
1) the Object Request Broker, or key communications element, for
handling distribution of messages between application objects in
a highly interoperable manner;
2) the Object Model, or single design-portability abstract model for
communicating with OMG-conforming object-oriented systems;
3) the Object Services, which will provide the main functions for
realising basic object functionality using the Object Request Broker -
the logical modelling and physical storage of objects; and
4) the Common Facilities will comprise facilities which are useful in
many application domains and which will be made available through OMA
compliant class interfaces.
The OMG adoption cycle includes Requests for Information and
Proposals, requesting detailed technical and commercial availability
information from OMG members about existing products to fill
particular parts of the reference model architecture. After passage
by Technical and Business committees to review these responses, the
OMG Board of Directors makes a final determination for technology adoption.
Adopted specifications are available on a fee-free basis to members and
non-members alike.
In late 1991 OMG adopted its first interface technology, for the Object
Request Broker portion of the reference model. This technology, adopted
from a joint proposal (named "CORBA") of Hewlett-Packard, NCR Corp.,
HyperDesk Corp., Digital Equipment Corp., Sun Microsystems and Object
Design Inc. includes both static and dynamic interfaces to an inter-
application request handling software "bus."
Unlike other organizations, the OMG itself does not and will not
develop nor sell software of any kind. Instead, it selects and promulgates
software interfaces; products which offer these interfaces continue to be
developed and offered by commercial companies.
In order to serve OMG membership interested in other object-oriented systems
arenas besides the distributed system problem, the Group supports Special
Interest Groups for discussion of possible standards in other areas. These
groups at present are:
1) Object Oriented Databases;
2) OO Languages;
3) End-User Requirements;
4) Parallel Processing;
5) Analysis & Design Methodologies;
6) Smalltalk; and
7) Class Libraries.
Any company, university/research institution or individual, whether
end-user or vendor, can become a member of this body. Administrative
details are given at the end of this paper.
______________________________________________________________________
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07983;
25 Jun 92 19:26 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa02969;
25 Jun 92 19:26 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA28793>; Thu, 25 Jun 1992 09:01:57 -0700
Received: from sgi.sgi.com (SGI.COM) by venera.isi.edu (5.65c/5.65+local-6)
id <AA28787>; Thu, 25 Jun 1992 09:01:52 -0700
Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI)
for ietf at ISI.EDU id AA07352; Thu, 25 Jun 92 09:00:26 -0700
Received: by rhyolite.wpd.sgi.com (911016.SGI/911001.SGI)
for @sgi.sgi.com:ietf at ISI.EDU id AA26341; Thu, 25 Jun 92 10:00:21 -0600
Date: Thu, 25 Jun 92 10:00:21 -0600
From: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Message-Id: <9206251600.AA26341 at rhyolite.wpd.sgi.com>
To: ietf at isi.edu
Subject: Re: Sun RPC program IDs
> From: mishkin at apollo.hp.com (Nathaniel Mishkin)
>
> To my (biased) way of thinking, this whole discussion of allocation of
> Sun RPC program IDs just makes it clear that schemes based on a centrally
> administered and relatively small space of IDs are bad for identifying
> distributed services. In contrast, the OSF DCE RPC mechanism uses unique
> IDs (composed from a timestamp and an IEEE 802 address) to identify
> interfaces (programs). (UUIDs are handy for other purposes and the DCE
> applies them in other situations.) The downside is that they're 128
> bits long, but I think I'd take that over the administrative hassles.
>
> -- Nat Mishkin
> Distributed Object Computing Program / East
> Hewlett-Packard Company
> mishkin at apollo.hp.com
I think you argued this position at great length a few years ago in some
netnews forums.
That part of the Apollo scheme is irrelevant to the issue at hand.
Right now, today, we have globally unique, distributedly administrated ID's
for programs. In the Internet suite, they are the (IP address, Port
number) pair. Replacing that 48-bit value with the Apollo 128-bit value
does nothing for hard part of the problem.
The Sun RPC ID has 128 bits, consisting of 32 bits of IP address, 32 bits of
program number, 32 bits of version, and 32 bits of service.
The size of the unique ID which labels the service provider is not
interesting.
The problem is in the necessarily centrally administrated, globally unique
naming of services with names that humans and their agents can handle.
Yes, there is the location broker, but that is the same in formal senses as
the portmapper. You, the programmer or end user, must specify the name of
the service you want performed. The location broker does provide some nice
flexibility in that naming, but ultimately, some human must decide which
service gets the name "phonebook" (and in the Apollo scheme which servers
provide it--an advantage in my opinion). Simply replacing the global
"phonebook" with a zillion different 48-bit or 128-bit ID's doesn't do
anyone any good. Some mechanism must ensure that the service named
"phonebook" provided by the server on my machine is functionally the same
as service named "phonebook" provided by the server on your machine. The
old Apollo NCS Mendelbrot demo is an excellent case in point.
I picked "phonebook" because of some conflicts inside the Silicon Graphics
network about what service it was. It's a real life example that would not
have been helped, and in fact, would probably have been made worse for
uninteresting reasons by the location broker and the Apollo NCS scheme.
You didn't mentioned the big problem with the current incarnation of DCE,
which is it's incredible size, and that it is still not complete. I won't
repeat what I know of that problem, since no one who has not watched an
attempted port would believe me.
Vernon Schryver, vjs at sgi.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08372;
25 Jun 92 21:27 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06138;
25 Jun 92 21:27 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03142>; Thu, 25 Jun 1992 10:42:00 -0700
Received: from TGV.COM (HQ.TGV.COM) by venera.isi.edu (5.65c/5.65+local-6)
id <AA03124>; Thu, 25 Jun 1992 10:41:50 -0700
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Thu, 25 Jun 92 10:38:58 PDT
Received: from karl.lvs.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA02517; Thu, 25 Jun 92 10:40:01 PDT
Date: Thu, 25 Jun 92 10:40:01 PDT
Message-Id: <9206251740.AA02517 at mel-brooks.empirical.com>
To: mishkin at apollo.hp.com
Subject: How do they do that? Was: Re: Sun RPC program IDs
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at mel-brooks.tgv.com>
Reply-To: karl at tgv.com
Cc: vjs at rhyolite.wpd.sgi.com, ietf at isi.edu
Sender: karl at mel-brooks.tgv.com
Repository: empirical.com
Originating-Client: lvs.empirical.com
This is a technical question, and has nothing to do with the
publication or not of RPC numbers....
> In contrast, the OSF DCE RPC mechanism uses unique
> IDs (composed from a timestamp and an IEEE 802 address) to identify
> interfaces (programs).
Just curious -- how does this mechanism deal with multi-homed hosts
that have multiple interfaces (with distinctly different MAC/802
addresses)? Are all RPC's forced to enter the same interface?
Or is it just a naming convention and the host is merely required to
pick one of its various MAC addresses?
--karl--
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08445;
25 Jun 92 22:13 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07212;
25 Jun 92 22:14 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06077>; Thu, 25 Jun 1992 11:44:51 -0700
Received: from amway.ch.apollo.hp.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA06068>; Thu, 25 Jun 1992 11:44:47 -0700
Message-Id: <199206251844.AA06068 at venera.isi.edu>
Received: from mapcar.ch.apollo.hp.com by amway.ch.apollo.hp.com id <AA09737 at amway.ch.apollo.hp.com> Thu, 25 Jun 92 14:31:08 EDT
Received: by mapcar.ch.apollo.hp.com id <AA07145 at mapcar.ch.apollo.hp.com>; Thu, 25 Jun 92 14:31:04 EDT
From: Nathaniel Mishkin <mishkin at apollo.hp.com>
Date: Thu, 25 Jun 92 14:31:03 EDT
Subject: Re: How do they do that? Was: Re: Sun RPC program IDs
To: karl at tgv.com
Cc: vjs at rhyolite.wpd.sgi.com, ietf at isi.edu
In-Reply-To: karl at TGV.COM, Thu, 25 Jun 92 10:40:01 PDT
Just curious -- how does this mechanism deal with multi-homed hosts
that have multiple interfaces (with distinctly different MAC/802
addresses)? Are all RPC's forced to enter the same interface?
Or is it just a naming convention and the host is merely required to
pick one of its various MAC addresses?
Just a naming convention.
-- Nat Mishkin
Distributed Object Computing Program / East
Hewlett-Packard Company
mishkin at apollo.hp.com
-------
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08463;
25 Jun 92 22:15 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08459;
25 Jun 92 22:15 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa07255;
25 Jun 92 22:15 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA03287; Thu, 25 Jun 92 21:15:42 CDT
Received: by hemlock.cray.com
id AA00597; 4.1/CRI-5.5; Thu, 25 Jun 92 21:15:40 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA00593; 4.1/CRI-5.5; Thu, 25 Jun 92 21:15:38 CDT
Received: from laidbak.i88.isc.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA03261; Thu, 25 Jun 92 21:15:31 CDT
Received: from ozzy.i88.isc.com by laidbak.i88.isc.com with SMTP
(5.65/isc-mail-gw/5/18/92) id AA05738; Thu, 25 Jun 92 21:15:20 -0500
Received: from localhost by ozzy.i88.isc.com (4.1/SMI-4.1)
id AA02393; Thu, 25 Jun 92 21:15:14 CDT
Message-Id: <9206260215.AA02393 at ozzy.i88.isc.com>
To: telnet-ietf at timbuk.cray.com
Subject: Environment draft with changes from mailing list feedback
Date: Thu, 25 Jun 92 21:15:14 -0500
From: Steve Alexander <stevea at i88.isc.com>
Network Working Group Internet Engineering Task Force
Internet-Draft Telnet Working Group
D. Borman, Editor
Cray Research, Inc.
June 1992
Telnet Environment Option
Status of this Memo
This document is an Internet Draft. Internet Drafts are the working
notes of the Internet Engineering Task Force, it Areas, and Working
Groups. These are temporary notes valid for a maximum of six
months; these notes may updated, replaced, or obsoleted by other
documents at any time. It is not appropriate is use Internet Drafts
as reference material or to cite them other than as 'working draft'
or "work in progress'. Distribution of this memo is unlimited.
Please send comments to the telnet-ietf at cray.com mailing list.
1. Command Names and Codes
ENVIRON 36
IS 0
SEND 1
INFO 2
VAR 0
VALUE 1
ESC 2
USERVAR 3
2. Command Meanings
IAC WILL ENVIRON
The sender of this command is willing to send environment vari-
ables.
IAC WONT ENVIRON
The sender of this command refuses to send environment variables.
IAC DO ENVIRON
The sender of this command is willing to receive environment vari-
ables.
Telnet Working Group [Page 1]
Internet-Draft Telnet Environment Option June 1992
IAC DONT ENVIRON
The sender of this command refuses to accept environment vari-
ables.
IAC SB ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE
The sender of this command requests that the remote side send its
environment variables. The "type" may be either VAR or USERVAR,
to indicate either well known or user variable names. Only the
side that is DO ENVIRON may initiate a SEND command. If a list of
variables is specified, then only those variables should be sent.
If no list is specified, then the default environment, of both
well known and user defined variables, should be sent. If one of
the variables has no name, then all the variables of that type
(well known or user defined) in the default environment should be
sent.
IAC SB ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
... ] ] IAC SE
The sender of this command is sending environment variables. This
command is sent in response to a SEND request. Only the side that
is WILL ENVIRON may send an IS command. The "type"/VALUE pairs
must be returned in the same order as the SEND request specified |
them, and there must be a response for each "type ..." explicitly |
requested. The "type" will be VAR or USERVAR. Multiple environ-
ment variables may be sent. The characters following a "type" up
to the next "type" or VALUE specify the variable name. The char-
acters following a VALUE up to the next "type" specify the value
of the variable. If a "type" is not followed by a VALUE (e.g., by
another VAR or an IAC) then that variable is undefined. If a
VALUE is immediately followed by a "type" or IAC, then the vari-
able is defined, but has no value. If an IAC is contained between
the IS and the IAC SE, it must be sent as IAC IAC. If a variable
or a value contains a VAR, it must be sent as ESC VAR. If a vari-
able or a value contains a USERVAR, it must be sent as ESC USER-
VAR. If a variable or a value contains a VALUE, it must be sent
as ESC VALUE. If a variable or a value contains an ESC, it must
be sent as ESC ESC.
IAC SB ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ... ] [ |
... ] ] IAC SE
The sender of this command is sending information about environ-
ment variables that have changed. It is identical to the IS com-
mand, except that the command is INFO instead of IS. Only the
side that is WILL ENVIRON may send an INFO command. The INFO com-
mand is not to be used to send initial information; the SEND/IS
sequence is to be used for that. The INFO command is to be used
Telnet Working Group [Page 2]
Internet-Draft Telnet Environment Option June 1992
to propagate changes in environment variables, and may be spon-
taneously generated.
3. Default Specification
The default specification for this option is
WONT ENVIRON
DONT ENVIRON
meaning there will not be any exchange of environment information.
4. Motivation
Many operating systems have startup information and environment vari-
ables that contain information that should be propagated to remote
machines when Telnet connections are established. Rather than create
a new Telnet option each time someone comes up with some new informa-
tion that they need propagated through a Telnet session, but that the
Telnet session itself doesn't really need to know about, this generic
information option can be used.
5. Well Known Variables
USER This variable is used to transmit the user or account
name that the client wishes to log into on the remote
system. The format of the value the USER variable is
system dependent, as determined by the remote system.
JOB This variable is used to transmit the job ID that the
client wishes to use when logging into the remote system.
The format of the value the JOB variable is system depen-
dent, as determined by the remote system.
ACCT This variable is used to transmit the account ID that the
client wishes to use when logging into the remote system.
The format of the value the ACCT variable is system
dependent, as determined by the remote system.
PRINTER This variable is used to identify the default location
for printer output. Because there does not currently ex-
ist a standard way of naming a printer on a network, the
format of this variable is currently undefined.
SYSTEMTYPE This is used to transmit the type of operating system on
the system that sends this variable. It value is identi-
cal to the value of the SYSTEM (SYST) command in FTP [2].
The format of the value shall have as its first word one
of the system names listed in the current version of the
Telnet Working Group [Page 3]
Internet-Draft Telnet Environment Option June 1992
Assigned Numbers document [3].
DISPLAY This variable is used to transmit the X display location
of the client. The format for the value of the DISPLAY
variable is:
<host>:<dispnum>[.<screennum>]
This information is identical to the information passed
using the Telnet X-DISPLAY-LOCATION option. If both the
DISPLAY environment variable, and the X-DISPLAY-LOCATION
option[4] are received, and they contain conflicting in-
formation, the most recently received information re-
ceived should be used.
Because it is impossible to anticipate all variables that users may
wish to exchange, the USERVAR type is provided to allow users to
transmit arbitrary variable/value pairs. The use of an additional
type allows implementations to distinguish between values derived
by the remote host software and values supplied by the user.
Paranoid implementations will most likely treat both types with an
equal level of distrust. The results of a name-space collision
between a well-known and a user variable are implementation specif-
ic.
6. Implementation Rules
WILL and DO are used only at the beginning of the connection to ob-
tain and grant permission for future negotiations.
Once the two hosts have exchanged a WILL and a DO, the sender of
the DO ENVIRON is free to request that environment variables be
sent. Only the sender of the DO may send requests (IAC SB ENVIRON
SEND IAC SE) and only the sender of the WILL may transmit actual
environment information (via the IAC SB ENVIRON IS ... IAC SE com-
mand). Though this option may be used at anytime throughout the
life of the telnet connection, the exchange of environment informa-
tion will usually happen at the startup of the connection. This is
because many operating systems only have mechanisms for propagating
environment information at process creation, so the information is
needed before the user logs in.
The receiving host is not required to put all variables that it re-
ceives into the environment. For example, if the client should
send across USERVAR "TERM" VALUE "xterm" as an environment vari-
able, and the TERMINAL-TYPE [1] option has already been used to
determine the terminal type, the server may safely ignore the TERM
variable. Also, some startup information may be used in other
ways; for example, the values for "USER", "ACCT" and "PROJ" values
might be used to decide which account to log into, and might never
be put into the users environment. In general, if the server has
Telnet Working Group [Page 4]
Internet-Draft Telnet Environment Option June 1992
already determined the value of an environment variable by some
more accurate means, or if it does not understand a variable name,
it may ignore the value sent in the ENVIRON option. The server may
also prefer to just put all unknown information into the users en-
vironment. This is the suggested method of implementation, because
it allows the user the most flexibility.
The following is an example of use of the option:
Host1 Host2
IAC DO ENVIRON
IAC WILL ENVIRON
[ Host1 is now free to request environment information ]
IAC SB ENVIRON SEND VAR "USER"
VAR "ACCT" VAR USERVAR IAC SE
[ The server has now explicitly asked for the USER and ACCT vari-
ables, the default set of well known environment variables, and
the default set of user defined variables. Note that the
client includes the USER information twice; once because it was
explicitly asked for, and once because it is part of the de-
fault environment. ]
IAC SB ENVIRON IS VAR "USER"
VALUE "joe" VAR "ACCT" VALUE
"kernel" VAR "USER" VALUE "joe"
VAR "DISPLAY" VALUE "foo:0.0"
USERVAR "SHELL" VALUE "/bin/csh"
IAC SE
It is expected that any implementation that supports the Telnet EN-
VIRON option will support all of this specification.
7. Security Concerns
It is important for an implementor of the ENVIRON option to under-
stand the interaction of setting options and the login/authentication
process. Specifically careful analysis should be done to determine
which variables are "safe" to set prior to having the client login.
An example of a bad choice would be permitting a variable to be
changed that allows an intruder to circumvent or compromise the
login/authentication program itself.
8. References
[1] VanBokkeln, J., "Telnet Terminal-Type Option", RFC 1091, FTP
Software, Inc., February 1989.
[2] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC
959, ISI, October 1985
[3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1060, ISI,
March 1990
[4] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie
Telnet Working Group [Page 5]
Internet-Draft Telnet Environment Option June 1992
Mellon University, March 1989.
Author's Address
David A. Borman, Editor
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55123
Phone: (612) 452-6650
Mailing List: telnet-ietf at CRAY.COM
EMail: dab at CRAY.COM
Chair's Address
The working group can be contacted via the current chair:
Steve Alexander
INTERACTIVE Systems Corporation
1901 North Naper Boulevard
Naperville, IL 60563-8895
Phone: (708) 505-9100 x256
EMail: stevea at isc.com
Telnet Working Group [Page 6]
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08479;
25 Jun 92 22:15 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08475;
25 Jun 92 22:15 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa07271;
25 Jun 92 22:16 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA03310; Thu, 25 Jun 92 21:16:12 CDT
Received: by hemlock.cray.com
id AA00614; 4.1/CRI-5.5; Thu, 25 Jun 92 21:16:08 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA00610; 4.1/CRI-5.5; Thu, 25 Jun 92 21:16:06 CDT
Received: from laidbak.i88.isc.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA03295; Thu, 25 Jun 92 21:16:01 CDT
Received: from ozzy.i88.isc.com by laidbak.i88.isc.com with SMTP
(5.65/isc-mail-gw/5/18/92) id AA05742; Thu, 25 Jun 92 21:15:55 -0500
Received: from localhost by ozzy.i88.isc.com (4.1/SMI-4.1)
id AA02402; Thu, 25 Jun 92 21:15:51 CDT
Message-Id: <9206260215.AA02402 at ozzy.i88.isc.com>
To: telnet-ietf at timbuk.cray.com
Subject: SPX Authentication draft with changes from mailing list feedback
Date: Thu, 25 Jun 92 21:15:50 -0500
From: Steve Alexander <stevea at i88.isc.com>
Network Working Group Internet Engineering Task Force
Internet-Draft Telnet Working Group
Kannan Alagappan
Digital Equipment Corporation
June 1992
Telnet Authentication : SPX
Status of this Memo
This document is an Internet Draft. Internet Drafts are the working
notes of the Internet Engineering Task Force, it Areas, and Working
Groups. These are temporary notes valid for a maximum of six
months; these notes may updated, replaced, or obsoleted by other
documents at any time. It is not appropriate is use Internet Drafts
as reference material or to cite them other than as 'working draft'
or "work in progress'. Distribution of this memo is unlimited.
Please send comments to the telnet-ietf at cray.com mailing list.
1. Command Names and Codes
Authentication Types
SPX 3
Suboption Commands
AUTH 0
REJECT 1
ACCEPT 2
2. Command Meanings
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <SPX authen- |
tication token> IAC SE
This is used to pass the SPX authentication token to the remote
side of the connection. (A document which describes the authenti-
cation token syntax is forthcoming.) The first octet of the
<authentication-type-pair> value is SPX. The second octet is a
modifier to the SPX authentication type.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT <mutual |
response> IAC SE
This command indicates that the authentication was successful.
Telnet Working Group [Page 1]
Internet-Draft SPX for Telnet June 1992
After an SPX authentication exchange, both sides have securely es-
tablished a random 8-byte key to be used as the default key for
the ENCRYPTION option. If the AUTH_HOW_MUTUAL bit is set in the
second octet of the authentication-type-pair, the sender includes
the mutual response bytes. The receiver of the ACCEPT command
compares the "mutual response" with its expected mutual response.
(A document which describes the mutual response syntax is forth-
coming.) If the AUTH_HOW_ONE_WAY bit is set in the second octet
of the authentication-type-pair, the sender includes zero bytes of
mutual response.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op- |
tional reason for rejection> IAC SE
This command indicates that the authentication was not successful,
and if there is any more data in the sub-option, it is an ASCII
text message of the reason for the rejection.
3. Implementation Rules
Every command after the first AUTHENTICATION IS must carry the same
set of modifiers (e.g., CLIENT|MUTUAL) for subsequent AUTHENTICATION
IS and AUTHENTICATION REPLY commands.
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_WHO_CLIENT, then the client sends the initial AUTH
command, and the server responds with either ACCEPT or REJECT.
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_WHO_SERVER, then the server sends the initial AUTH
command, and the client responds with either ACCEPT or REJECT.
4. Examples
User "joe" may wish to log in as user "pete" on machine "foo". If
"pete" has set things up on "foo" to allow "joe" access to his ac-
count, then the client would send IAC SB AUTHENTICATION NAME "pete"
IAC SE IAC SB AUTHENTICATION IS SPX AUTH <joe's spx authentication
token> IAC SE. The server would then authenticate the user as "joe"
from the token information, and the server would send back either AC-
CEPT or REJECT. If mutual authentication is being used, the server
would include in the ACCEPT message, a mutual response. The authori-
zation check to see if "pete" is allowing "joe" to use his account is
made after the authentication exchange is complete. Therefore, it is
possible for the client to receive an ACCEPT response (based on the
authentication token), but for joe to be denied access to log in to
pete's account.
Telnet Working Group [Page 2]
Internet-Draft SPX for Telnet June 1992
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND SPX
CLIENT|MUTUAL SPX CLIENT|ONE_WAY
IAC SE
[ The server has requested mutual SPX authentication. If mutual
authentication is not supported, then the server is willing to
do one-way SPX authentication. ]
[ The client will now respond with the name of the user that it
wants to log in as, and the SPX authentication token. ]
IAC SB AUTHENTICATION NAME
"pete" IAC SE
IAC SB AUTHENTICATION IS SPX
CLIENT|MUTUAL AUTH <spx authen-
tication token information> IAC
SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
[ If AUTH_HOW_MUTUAL, the server responds with the mutual
response so the client can verify that it is really talking to
the right server. ]
[ If AUTH_HOW_ONE_WAY, the server responds with a NULL mutual
response, since the client is willing to trust the server al-
ready. ]
IAC SB AUTHENTICATION REPLY SPX
CLIENT|MUTUAL ACCEPT <mutual
response> IAC SE
Author's Address
Kannan Alagappan
Digital Equipment Corporation
550 King Street, LKG1-2/A19
Littleton, MA 01460
Mailing List: telnet-ietf at CRAY.COM
EMail: kannan at sejour.lkg.dec.com
Telnet Working Group [Page 3]
Internet-Draft SPX for Telnet June 1992
The working group can be contacted via the current chair: |
Steve Alexander |
INTERACTIVE Systems Corporation |
1901 North Naper Boulevard |
Naperville, IL 60563-8895 |
Phone: (708) 505-9100 x256 |
EMail: stevea at isc.com
Telnet Working Group [Page 4]
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08495;
25 Jun 92 22:16 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07284;
25 Jun 92 22:16 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03185>; Thu, 25 Jun 1992 10:42:45 -0700
Received: from amway.ch.apollo.hp.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA03180>; Thu, 25 Jun 1992 10:42:42 -0700
Message-Id: <199206251742.AA03180 at venera.isi.edu>
Received: from mapcar.ch.apollo.hp.com by amway.ch.apollo.hp.com id <AA09026 at amway.ch.apollo.hp.com> Thu, 25 Jun 92 13:38:10 EDT
Received: by mapcar.ch.apollo.hp.com id <AA07100 at mapcar.ch.apollo.hp.com>; Thu, 25 Jun 92 13:38:05 EDT
From: Nathaniel Mishkin <mishkin at apollo.hp.com>
Date: Thu, 25 Jun 92 13:38:04 EDT
Subject: Re: Sun RPC program IDs
To: "R. Kannan" <kannan at cerc.wvu.wvnet.edu>
Cc: vjs at rhyolite.wpd.sgi.com, ietf at isi.edu
In-Reply-To: kannan at cerc.wvu.wvnet.edu (R. Kannan), Thu, 25 Jun 92 12:12:29 EDT
I would take it one step further for the following reasons:
IP Address + pid + timestamp
In fact DCE UUIDs have a field called "clock sequence" which serves the
same role as your "pid". In the current implementation, the clock sequence
is derived from the PID. (It's actually a number from a pseudo-random
stream of numbers seeded by the PID and the time the first UUID was
generated in the process. A new clock sequence is taken from the stream
in case the UUID generator ever notices the clock go backwards.) Other
schemes for generating clock sequences are possible.
Note that having had the experience of an earlier generation of UUIDs
that in fact did use IP addresses instead of IEEE 802 addresses, we decided
to use 802 address instead. (The mechanisms for ensuring unique 802
addresses are more robust than those for ensuring unique IP addresses.
The set of IP addresses for hosts not connected to the Internet probably
contains duplicates. We would like to avoid the even remote possibility
that such systems might later join the Internet and then spread previously
generated and possibly duplicate UUIDs into the environment.) Also,
that the 802 space is larger than IP's is a plus.
One problem we found with 802 addresses is that, contrary to what we
had assumed, there's no standard/portable way to obtain them. (Some
UNIX systems have no way--presumably short of doing disgusting things
with /dev/kmem--to get them at all.) We decided that this problem was
not enough to outweigh the benefits. (I.e., we expect it to not be a
big deal for vendors who are bringing up the DCE to solve the problem.)
The DCE provides a default implementation of the "get 802 address" function
that reads an 802 address from a system configuration file. (You could
get fancy and store the value obtained from the file in some shared memory
segment for efficiency.)
Another issue is whether each system has at least one 802 address
"assigned" to it. The popular LAN technologies we're most interested
in--Ethernet and token (and FDDI as I recall)--all use 802 addresses.
Other systems can probably take other tacks (e.g., get a block of 802
addresses and jam an IP address into the lower bits).
-- Nat Mishkin
Distributed Object Computing Program / East
Hewlett-Packard Company
mishkin at apollo.hp.com
-------
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08812;
25 Jun 92 23:45 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08808;
25 Jun 92 23:45 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa09126;
25 Jun 92 23:46 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA06018; Thu, 25 Jun 92 22:46:42 CDT
Received: by hemlock.cray.com
id AA02495; 4.1/CRI-5.5; Thu, 25 Jun 92 22:46:41 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA02491; 4.1/CRI-5.5; Thu, 25 Jun 92 22:46:39 CDT
Received: from laidbak.i88.isc.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA06015; Thu, 25 Jun 92 22:46:30 CDT
Received: from ozzy.i88.isc.com by laidbak.i88.isc.com with SMTP
(5.65/isc-mail-gw/5/18/92) id AA05710; Thu, 25 Jun 92 21:14:38 -0500
Received: from localhost by ozzy.i88.isc.com (4.1/SMI-4.1)
id AA02385; Thu, 25 Jun 92 21:14:33 CDT
Message-Id: <9206260214.AA02385 at ozzy.i88.isc.com>
To: telnet-ietf at timbuk.cray.com
Subject: Kerberos IV draft with changes from mailing list feedback
Date: Thu, 25 Jun 92 21:14:33 -0500
From: Steve Alexander <stevea at i88.isc.com>
Network Working Group Internet Engineering Task Force
Internet-Draft Telnet Working Group
D. Borman, Editor
Cray Research, Inc.
June 1992
Telnet Authentication: Kerberos Version 4
Status of this Memo
This document is an Internet Draft. Internet Drafts are the working
notes of the Internet Engineering Task Force, it Areas, and Working
Groups. These are temporary notes valid for a maximum of six
months; these notes may updated, replaced, or obsoleted by other
documents at any time. It is not appropriate is use Internet Drafts
as reference material or to cite them other than as 'working draft'
or "work in progress'. Distribution of this memo is unlimited.
Please send comments to the telnet-ietf at cray.com mailing list.
1. Command Names and Codes
Authentication Types
KERBEROS_V4 1
Suboption Commands
AUTH 0
REJECT 1
ACCEPT 2
CHALLENGE 3
RESPONSE 4
2. Command Meanings
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <kerberos |
ticket and authenticator> IAC SE
This is used to pass the Kerberos ticket to the remote side of the
connection. The first octet of the <authentication-type-pair>
value is KERBEROS_V4, to indicate the usage of Kerberos version 4.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE |
This command indicates that the authentication was successful.
Telnet Working Group [Page 1]
Internet-Draft Kerberos Version 4 for Telnet June 1992
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op- |
tional reason for rejection> IAC SE
This command indicates that the authentication was not successful,
and if there is any more data in the sub-option, it is an ASCII
text message of the reason for the rejection.
IAC SB AUTHENTICATION IS <authentication-type-pair> CHALLENGE <en- |
crypted challenge> IAC SE
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE <en- |
crypted response> IAC SE
These two commands are used to perform mutual authentication.
They are only used when the AUTH_HOW_MUTUAL bit is set in the
second octet of the authentication-type-pair. After successfully
sending an AUTH and receiving an ACCEPT, a CHALLENGE is sent. The
challenge is a random 8 byte number with the most significant byte
first, and the least significant byte last. When the CHALLENGE
command is sent, the "encrypted challenge" is the 8-byte-challenge
encrypted in the session key. When the CHALLENGE command is re-
ceived, the contents are decrypted to get the original 8-byte-
challenge, this value is then incremented by one, re-encrypted
with the session key, and returned as the "encrypted response" in
the RESPONSE command. The receiver of the RESPONSE command de-
crypts the "encrypted response", and verifies that the resultant
value is the original 8-byte-challenge incremented by one.
The "encrypted challenge" value sent/received in the CHALLENGE
command is also encrypted with the session key on both sides of
the session, to produce a random 8-byte key to be used as the de-
fault key for the ENCRYPTION option.
3. Implementation Rules
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial
AUTH command, and the server responds with either ACCEPT or REJECT.
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, and the
server responds with ACCEPT, then the client then sends a CHALLENGE,
and the server sends a RESPONSE.
If the second octet of the authentication-type-pair has the AUTH_WHO
bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial
AUTH command, and the client responds with either ACCEPT or REJECT.
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, and the
client responds with ACCEPT, then the server then sends a CHALLENGE,
and the client sends a RESPONSE.
The authenticator (Kerberos Principal) used is of the form
Telnet Working Group [Page 2]
Internet-Draft Kerberos Version 4 for Telnet June 1992
"rcmd.host at realm".
4. Examples
User "joe" may wish to log in as user "pete" on machine "foo". If
"pete" has set things up on "foo" to allow "joe" access to his ac-
count, then the client would send IAC SB AUTHENTICATION NAME "pete"
IAC SE IAC SB AUTHENTICATION IS KERBEROS_V4 AUTH <joe's kerberos
ticket> IAC SE The server would then authenticate the user as "joe"
from the ticket information, and since "pete" is allowing "joe" to
use his account, the server would send back ACCEPT. If mutual au-
thentication is being used, the the client would send a CHALLENGE,
and verify the RESPONSE that the server sends back.
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KERBEROS_V4 CLIENT|MUTUAL
KERBEROS_V4 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Version 4 Kerberos authentica-
tion. If mutual authentication is not supported, then the
server is willing to do one-way authentication.
The client will now respond with the name of the user that it
wants to log in as, and the Kerberos ticket. ]
IAC SB AUTHENTICATION NAME
"pete" IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V4 CLIENT|MUTUAL AUTH
<kerberos ticket information>
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V4 CLIENT|MUTUAL ACCEPT
IAC SE
[ Next, the client sends across a CHALLENGE to verify that it is
really talking to the right server. ]
IAC SB AUTHENTICATION IS
KERBEROS_V4 CLIENT|MUTUAL CHAL-
LENGE xx xx xx xx xx xx xx xx
IAC SE
[ Lastly, the server sends across a RESPONSE to prove that it
really is the right server.
IAC SB AUTHENTICATION REPLY
Telnet Working Group [Page 3]
Internet-Draft Kerberos Version 4 for Telnet June 1992
KERBEROS_V4 CLIENT|MUTUAL
RESPONSE yy yy yy yy yy yy yy yy
IAC SE
Author's Address
David A. Borman, Editor
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55123
Phone: (612) 452-6650
Mailing List: telnet-ietf at CRAY.COM
EMail: dab at CRAY.COM
Chair's Address
The working group can be contacted via the current chair:
Steve Alexander
INTERACTIVE Systems Corporation
1901 North Naper Boulevard
Naperville, IL 60563-8895
Phone: (708) 505-9100 x256
EMail: stevea at isc.com
Telnet Working Group [Page 4]
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09605;
26 Jun 92 0:40 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10630; 26 Jun 92 0:41 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA09114>; Thu, 25 Jun 1992 12:59:11 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA09110>; Thu, 25 Jun 1992 12:59:08 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa06077;
25 Jun 92 15:56 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-smtpext-8bittransport-05.txt
Date: Thu, 25 Jun 92 15:56:16 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206251556.aa06077 at IETF.NRI.Reston.VA.US>
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 Extensions for Transport of Enhanced
Text-Based Messages
Author(s) : John Klensin
Filename : draft-ietf-smtpext-8bittransport-05.txt
Pages : 23
A series of extensions and clarifications are provided for the Simple
Mail Transfer Protocol specified by RFC-821. In combination, they
provide for the transport of "8 bit mail", i.e., data characters with
all bits of the octets used for information, for more robust and
efficient handling of large messages, and for an improved foundation
for any future extensions to 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-8bittransport-05.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-smtpext-8bittransport-05.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09634;
26 Jun 92 0:41 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10638; 26 Jun 92 0:41 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08924>; Thu, 25 Jun 1992 12:51:48 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA08916>; Thu, 25 Jun 1992 12:51:45 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05956;
25 Jun 92 15:46 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mpsnmp-overipx-00.txt
Date: Thu, 25 Jun 92 15:46:52 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206251546.aa05956 at IETF.NRI.Reston.VA.US>
THIS IS A RE-SEND ANNOUNCEMENT WITH CORRECTION MADE:
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
SNMP over a Multi-protocol Internet Working Group of the IETF.
Title : SNMP over IPX
Author(s) : Steve Bostock
Filename : draft-ietf-mpsnmp-overipx-00.txt
Pages : 7
This document defines a convention for encapsulating Simple Network
Management Protocol (SNMP) packets over the transport mechanism
provided via the Internetwork Packet (IPX) 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-mpsnmp-overipx-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-mpsnmp-overipx-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09714;
26 Jun 92 1:11 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11387; 26 Jun 92 1:12 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA12090>; Thu, 25 Jun 1992 14:14:36 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA12082>; Thu, 25 Jun 1992 14:14:33 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa06998;
25 Jun 92 17:11 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-netdata-netdata-03.txt
Date: Thu, 25 Jun 92 17:11:03 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206251711.aa06998 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Network Database Working Group of the IETF.
Title : Network Database Protocol
Author(s) : Daisy Shen
Filename : draft-ietf-netdata-netdata-03.txt
Pages : 14
This memo defines a protocol for use with relational database systems
in a TCP/IP based internet environment. This protocol is intended to
make interoperability among different database systems possible. It
is built on RPC (Remote Procedure Call) with a client/server type of
relationship. This document also defines the concept of Unit of Work.
The work of Network Database is involved with Data Conversion,
Security, I/O Buffer Management, and Transaction Management.
They will be described one by one 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-ietf-netdata-netdata-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-netdata-netdata-03.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02687;
26 Jun 92 6:15 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04383; 26 Jun 92 6:16 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25658>; Thu, 25 Jun 1992 19:41:44 -0700
Received: from MIT.EDU (MIT.MIT.EDU) by venera.isi.edu (5.65c/5.65+local-6)
id <AA25654>; Thu, 25 Jun 1992 19:41:39 -0700
Received: from TARDIS.MIT.EDU by MIT.EDU with SMTP
id AA16488; Thu, 25 Jun 92 22:39:55 EDT
Received: by tardis.MIT.EDU (AIX 3.1/UCB 5.61/4.7) id AA13518; Thu, 25 Jun 92 22:39:44 -0400
Date: Thu, 25 Jun 92 22:39:44 -0400
Message-Id: <9206260239.AA13518 at tardis.MIT.EDU>
To: "R. Kannan" <kannan at cerc.wvu.wvnet.edu>
Cc: Nathaniel Mishkin <mishkin at apollo.hp.com>, vjs at rhyolite.wpd.sgi.com,
ietf at isi.edu
In-Reply-To: R. Kannan's message of Thu, 25 Jun 92 12:12:29 EDT,
<9206251612.AA00463 at cerc.wvu.wvnet.edu>
Subject: Re: Sun RPC program IDs
From: Richard Basch <basch at mit.edu>
I would take it one step further for the following reasons:
IP Address + pid + timestamp
IP address is equivalent to the IEEE 802 address and
the IEEE 802 address discrimintes that node from every other node.
the pid discriminates the server process from every other
process that are active in a particular node.
And finally
the time stamp discriminates that particular service from any
other service offered by the same server.
Such a scheme guarantees global uniques. Note that ids can be
generated in decentralized manner. A process can generate its own ids
without ever conflicting with any other id generated in the whole
world.
I have not followed the entire chain, but as I see it, this does not
necessarily guarantee uniqueness; if a server is multi-threaded, it may
have the same pid, and processing requests concurrently in two threads
may also mean that they have the same timestamp.
There should be an implementation-dependent uniquifier, if such
uniqueness is required. This could be a timestamp, or it could simply
be a counter that is incremented for each request (and if you are
worried about multiple nodes sharing the same IP address, as would be
the case in a couple years when the IP address space is full; even
though the router may frob the IP header, the data portion will probably
still be in error... you can use some private DES key on the machine and
encrypt the counter).
-Richard Basch
MIT IS Systems Development
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03020;
26 Jun 92 7:49 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06284; 26 Jun 92 7:50 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA29207>; Thu, 25 Jun 1992 22:27:12 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA29203>; Thu, 25 Jun 1992 22:27:09 -0700
Received: from qdeck.UUCP by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA14496; Fri, 26 Jun 92 00:48:24 -0400
From: Jordan Brown <jbrown at qdeck.com>
X-Mailer: SCO System V Mail (version 3.2)
To: ietf at isi.edu
Subject: Re: postscript
Date: Thu, 25 Jun 92 21:18:21 PDT
Message-Id: <9206252118.aa14547 at sco1.qdeck.com>
It doesn't matter how beautiful and compatible the Postscript is,
you can't grep through it, and you can't cut-and-paste it. It's not
acceptable.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03768;
26 Jun 92 9:42 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10382; 26 Jun 92 9:42 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA26187>; Thu, 25 Jun 1992 20:06:25 -0700
Received: from hp.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA26183>; Thu, 25 Jun 1992 20:06:22 -0700
Received: from gourmet.ch.apollo.hp.com by hp.com with SMTP
(16.8/15.5+IOS 3.13) id AA07021; Thu, 25 Jun 92 20:04:55 -0700
Message-Id: <9206260304.AA07021 at hp.com>
Received: by gourmet.ch.apollo.hp.com id <AA10865 at gourmet.ch.apollo.hp.com>; Thu, 25 Jun 92 23:04:54 -0400
Date: Thu, 25 Jun 92 23:04:54 -0400
From: sommerfeld at apollo.hp.com
To: karl at tgv.com
Cc: mishkin at apollo.hp.com, vjs at rhyolite.wpd.sgi.com, ietf at isi.edu
In-Reply-To: Karl Auerbach's message of Thu, 25 Jun 92 10:40:01 PDT,
<9206251740.AA02517 at mel-brooks.empirical.com>
Subject: Re: How do they do that? (DCE RPC)
The ieee 802 address in a DCE RPC interface uuid has *nothing* to do
with the network address of a server; it's just part of what makes the
uuid unique.
In DCE RPC, each "interface" (a collection of remote operations,
roughly equivalent to a Sun RPC "program"), has a uuid assigned to it
when it is first defined; it appears in the interface definition
source file, and is compiled, as a constant, into the RPC stubs, and
thus, into any program using the interface.
A server registers itself with the DCE RPC endpoint mapper (in NCS
1.x, this was the "local location broker") when it starts up. The
endpoint mapper, like portmap, listens on a single well-known port
(per address family). Until the client learns the port number, it
directs requests to the mapper's well-known port.
[There is also a name service in DCE which can be used to locate the
host on which a service is running. In the case of a multi-homed, or
multi-protocol, host, the server can register multiple (network layer,
not MAC layer) addresses in the DCE name service; the client gets to
pick which one it wants to use.]
This has some definite advantages for developers... If I want to
create a simple distributed application prototype using DCE, and run
it on ten or twenty machines at my site, I don't need to either (a)
pick a port that nobody else is using and hope that nobody else starts
using it "for real", or (b) go through the trouble of getting a port
number offcially assigned to something which may just be a throwaway
prototype. Instead, I just run uuidgen, paste the output into a new
interface definition source file, and start developing the
application.
Note that DCE interfaces can use well known ports; the default,
however, is to just use a dynamically assigned port, and rendezvous
through the endpoint mapper.
- Bill
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06454;
26 Jun 92 13:13 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa19698;
26 Jun 92 13:14 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA09616>; Fri, 26 Jun 1992 07:00:45 -0700
Received: from cor3.pica.army.mil by venera.isi.edu (5.65c/5.65+local-6)
id <AA09609>; Fri, 26 Jun 1992 07:00:38 -0700
Received: from cor5.pica.army.mil by COR3.PICA.ARMY.MIL id aa27554;
26 Jun 92 9:52 EDT
Date: Fri, 26 Jun 92 09:51:08 EDT
From: "Dr. Edward Levinson (GC-ACCURATE|COURTESY) <levinson at PICA.ARMY.MIL>" <levinson at pica.army.mil>
To: mail-server at nisc.sri.com
Cc: IETF <ietf at isi.edu>
Subject: Re: ID ACTION:draft-ietf-netdata-netdata-03.txt
In-Reply-To: Your message of "Thu, 25 Jun 92 17:11:03 EDT."
<9206251711.aa06998 at IETF.NRI.Reston.VA.US>
X-Mailer: MH 6.7.2
Message-Id: <9206260952.aa27554 at COR3.PICA.ARMY.MIL>
SEND internet-drafts/draft-ietf-netdata-netdata-03.txt
SEND internet-drafts/draft-ietf-smtpext-8bittransport-05.txt
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06666;
26 Jun 92 13:35 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06662;
26 Jun 92 13:35 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa20653;
26 Jun 92 13:36 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA18381; Fri, 26 Jun 92 12:36:29 CDT
Received: by hemlock.cray.com
id AA00166; 4.1/CRI-5.5; Fri, 26 Jun 92 12:36:25 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA03070; 4.1/CRI-5.5; Fri, 26 Jun 92 12:23:12 CDT
Received: from laidbak.i88.isc.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA17782; Fri, 26 Jun 92 12:23:09 CDT
Received: from ozzy.i88.isc.com by laidbak.i88.isc.com with SMTP
(5.65/isc-mail-gw/5/18/92) id AA25314; Fri, 26 Jun 92 12:23:02 -0500
Received: from localhost by ozzy.i88.isc.com (4.1/SMI-4.1)
id AA02863; Fri, 26 Jun 92 12:22:54 CDT
Message-Id: <9206261722.AA02863 at ozzy.i88.isc.com>
To: Marjo Mercado <marjo at hpindsy.cup.hp.com>
Cc: telnet-ietf at timbuk.cray.com
Subject: Re: Environment draft with changes from mailing list feedback
In-Reply-To: Message from marjo at hpindsy.cup.hp.com of 26 Jun 92 10:11:17 PDT
Date: Fri, 26 Jun 92 12:22:52 -0500
From: Steve Alexander <stevea at i88.isc.com>
Marjo Mercado <marjo at hpindsy.cup.hp.com> writes:
> Under the description of the IS command, the sentence:
>
> If a "type" is not followed by a VALUE (e.g., by another VAR or an
> IAC) then that variable is undefined.
>
> should be changed to:
>
> If a "type ..." is not followed by a VALUE (e.g., by another VAR,
> USERVAR or IAC SE) then that variable is undefined. If the VALUE
> after a "type ..." is immediately followed by VAR, USERVAR, or IAC
> SE, then that variable is defined, but has no value.
It seems to me that this text is already present. I quote:
If a "type" is not followed by a VALUE (e.g., by
another VAR or an IAC) then that variable is undefined. If a
VALUE is immediately followed by a "type" or IAC, then the vari-
able is defined, but has no value.
I guess it should say VAR, USERVAR, or IAC instead of just VAR or IAC.
The rest is equivalent I think.
>2. We like Dave's examples. Can they be included in the RFC?
>
> It should be perfectly legal to have no data between the SB and SE.
> An ``IAC SB ENVIRON IS IAC SE'' is a valid response to:
> ``IAC SB ENVIRON SEND IAC SE''
> ``IAC SB ENVIRON SEND VAR IAC SE''
> ``IAC SB ENVIRON SEND USERVAR IAC SE''
> ``IAC SB ENVIRON SEND VAR USERVAR IAC SE''
> (the last is the equivialant to the first...)
>
I don't see why not.
>3. Can we clean up the wording of the "Status of this Memo"? I assume
> we're just following the Internet Draft Standard wording.
What specifically is wrong with the "status" section?
Thanks,
-- Steve
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06676;
26 Jun 92 13:36 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06672;
26 Jun 92 13:36 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa20660;
26 Jun 92 13:36 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA18401; Fri, 26 Jun 92 12:36:34 CDT
Received: by hemlock.cray.com
id AA00224; 4.1/CRI-5.5; Fri, 26 Jun 92 12:36:29 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA02724; 4.1/CRI-5.5; Fri, 26 Jun 92 12:11:24 CDT
Received: from relay.hp.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA17237; Fri, 26 Jun 92 12:11:22 CDT
Received: from hpindvh.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA21275; Fri, 26 Jun 92 10:11:19 -0700
Received: by hpindsy.cup.hp.com with SMTP
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA02931; Fri, 26 Jun 92 10:11:22 pdt
To: Steve Alexander <stevea at i88.isc.com>
Cc: telnet-ietf at timbuk.cray.com, marjo at hpindsy.cup.hp.com,
Sun-Kwan_Kimn at hp6600.desk.hp.com, Norman_Newlon at hp6600.desk.hp.com,
Raghavan_Seshadri at hp6600.desk.hp.com, charlie at hpindsy.cup.hp.com,
rajs at hpinddf.cup.hp.com
Subject: Re: Environment draft with changes from mailing list feedback
In-Reply-To: Your message of "Thu, 25 Jun 92 21:15:14 PDT."
<9206260215.AA02393 at ozzy.i88.isc.com>
Date: Fri, 26 Jun 92 10:11:17 PDT
Message-Id: <2929.709578677 at hpindvh.cup.hp.com>
From: Marjo Mercado <marjo at hpindsy.cup.hp.com>
Hi Steve and Dave,
Thank you very much for your answers to my questions. I didn't realize
you would send out a new draft so quickly. The latest changes look
fine, but we would like to add three more changes.
1. Per Dave's suggestion,
Under the description of the IS command, the sentence:
If a "type" is not followed by a VALUE (e.g., by another VAR or an
IAC) then that variable is undefined.
should be changed to:
If a "type ..." is not followed by a VALUE (e.g., by another VAR,
USERVAR or IAC SE) then that variable is undefined. If the VALUE
after a "type ..." is immediately followed by VAR, USERVAR, or IAC
SE, then that variable is defined, but has no value.
2. We like Dave's examples. Can they be included in the RFC?
It should be perfectly legal to have no data between the SB and SE.
An ``IAC SB ENVIRON IS IAC SE'' is a valid response to:
``IAC SB ENVIRON SEND IAC SE''
``IAC SB ENVIRON SEND VAR IAC SE''
``IAC SB ENVIRON SEND USERVAR IAC SE''
``IAC SB ENVIRON SEND VAR USERVAR IAC SE''
(the last is the equivialant to the first...)
3. Can we clean up the wording of the "Status of this Memo"? I assume
we're just following the Internet Draft Standard wording.
Thanks,
Marjo Mercado
Hewlett-Packard Company
(408) 447-2826
Network Working Group Internet Engineering Task Force
Internet-Draft Telnet Working Group
D. Borman, Editor
Cray Research, Inc.
June 1992
Telnet Environment Option
Status of this Memo
This document is an Internet Draft. Internet Drafts are the working
notes of the Internet Engineering Task Force, it Areas, and Working
Groups. These are temporary notes valid for a maximum of six
months; these notes may updated, replaced, or obsoleted by other
documents at any time. It is not appropriate is use Internet Drafts
as reference material or to cite them other than as 'working draft'
or "work in progress'. Distribution of this memo is unlimited.
Please send comments to the telnet-ietf at cray.com mailing list.
1. Command Names and Codes
ENVIRON 36
IS 0
SEND 1
INFO 2
VAR 0
VALUE 1
ESC 2
USERVAR 3
2. Command Meanings
IAC WILL ENVIRON
The sender of this command is willing to send environment vari-
ables.
IAC WONT ENVIRON
The sender of this command refuses to send environment variables.
IAC DO ENVIRON
The sender of this command is willing to receive environment vari-
ables.
Telnet Working Group [Page 1]
Internet-Draft Telnet Environment Option June 1992
IAC DONT ENVIRON
The sender of this command refuses to accept environment vari-
ables.
IAC SB ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE
The sender of this command requests that the remote side send its
environment variables. The "type" may be either VAR or USERVAR,
to indicate either well known or user variable names. Only the
side that is DO ENVIRON may initiate a SEND command. If a list of
variables is specified, then only those variables should be sent.
If no list is specified, then the default environment, of both
well known and user defined variables, should be sent. If one of
the variables has no name, then all the variables of that type
(well known or user defined) in the default environment should be
sent.
IAC SB ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
... ] ] IAC SE
The sender of this command is sending environment variables. This
command is sent in response to a SEND request. Only the side that
is WILL ENVIRON may send an IS command. The "type"/VALUE pairs
must be returned in the same order as the SEND request specified |
them, and there must be a response for each "type ..." explicitly |
requested. The "type" will be VAR or USERVAR. Multiple environ-
ment variables may be sent. The characters following a "type" up
to the next "type" or VALUE specify the variable name. The char-
acters following a VALUE up to the next "type" specify the value
of the variable. If a "type" is not followed by a VALUE (e.g., by
another VAR or an IAC) then that variable is undefined. If a
VALUE is immediately followed by a "type" or IAC, then the vari-
able is defined, but has no value. If an IAC is contained between
the IS and the IAC SE, it must be sent as IAC IAC. If a variable
or a value contains a VAR, it must be sent as ESC VAR. If a vari-
able or a value contains a USERVAR, it must be sent as ESC USER-
VAR. If a variable or a value contains a VALUE, it must be sent
as ESC VALUE. If a variable or a value contains an ESC, it must
be sent as ESC ESC.
IAC SB ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ... ] [ |
... ] ] IAC SE
The sender of this command is sending information about environ-
ment variables that have changed. It is identical to the IS com-
mand, except that the command is INFO instead of IS. Only the
side that is WILL ENVIRON may send an INFO command. The INFO com-
mand is not to be used to send initial information; the SEND/IS
sequence is to be used for that. The INFO command is to be used
Telnet Working Group [Page 2]
Internet-Draft Telnet Environment Option June 1992
to propagate changes in environment variables, and may be spon-
taneously generated.
3. Default Specification
The default specification for this option is
WONT ENVIRON
DONT ENVIRON
meaning there will not be any exchange of environment information.
4. Motivation
Many operating systems have startup information and environment vari-
ables that contain information that should be propagated to remote
machines when Telnet connections are established. Rather than create
a new Telnet option each time someone comes up with some new informa-
tion that they need propagated through a Telnet session, but that the
Telnet session itself doesn't really need to know about, this generic
information option can be used.
5. Well Known Variables
USER This variable is used to transmit the user or account
name that the client wishes to log into on the remote
system. The format of the value the USER variable is
system dependent, as determined by the remote system.
JOB This variable is used to transmit the job ID that the
client wishes to use when logging into the remote system.
The format of the value the JOB variable is system depen-
dent, as determined by the remote system.
ACCT This variable is used to transmit the account ID that the
client wishes to use when logging into the remote system.
The format of the value the ACCT variable is system
dependent, as determined by the remote system.
PRINTER This variable is used to identify the default location
for printer output. Because there does not currently ex-
ist a standard way of naming a printer on a network, the
format of this variable is currently undefined.
SYSTEMTYPE This is used to transmit the type of operating system on
the system that sends this variable. It value is identi-
cal to the value of the SYSTEM (SYST) command in FTP [2].
The format of the value shall have as its first word one
of the system names listed in the current version of the
Telnet Working Group [Page 3]
Internet-Draft Telnet Environment Option June 1992
Assigned Numbers document [3].
DISPLAY This variable is used to transmit the X display location
of the client. The format for the value of the DISPLAY
variable is:
<host>:<dispnum>[.<screennum>]
This information is identical to the information passed
using the Telnet X-DISPLAY-LOCATION option. If both the
DISPLAY environment variable, and the X-DISPLAY-LOCATION
option[4] are received, and they contain conflicting in-
formation, the most recently received information re-
ceived should be used.
Because it is impossible to anticipate all variables that users may
wish to exchange, the USERVAR type is provided to allow users to
transmit arbitrary variable/value pairs. The use of an additional
type allows implementations to distinguish between values derived
by the remote host software and values supplied by the user.
Paranoid implementations will most likely treat both types with an
equal level of distrust. The results of a name-space collision
between a well-known and a user variable are implementation specif-
ic.
6. Implementation Rules
WILL and DO are used only at the beginning of the connection to ob-
tain and grant permission for future negotiations.
Once the two hosts have exchanged a WILL and a DO, the sender of
the DO ENVIRON is free to request that environment variables be
sent. Only the sender of the DO may send requests (IAC SB ENVIRON
SEND IAC SE) and only the sender of the WILL may transmit actual
environment information (via the IAC SB ENVIRON IS ... IAC SE com-
mand). Though this option may be used at anytime throughout the
life of the telnet connection, the exchange of environment informa-
tion will usually happen at the startup of the connection. This is
because many operating systems only have mechanisms for propagating
environment information at process creation, so the information is
needed before the user logs in.
The receiving host is not required to put all variables that it re-
ceives into the environment. For example, if the client should
send across USERVAR "TERM" VALUE "xterm" as an environment vari-
able, and the TERMINAL-TYPE [1] option has already been used to
determine the terminal type, the server may safely ignore the TERM
variable. Also, some startup information may be used in other
ways; for example, the values for "USER", "ACCT" and "PROJ" values
might be used to decide which account to log into, and might never
be put into the users environment. In general, if the server has
Telnet Working Group [Page 4]
Internet-Draft Telnet Environment Option June 1992
already determined the value of an environment variable by some
more accurate means, or if it does not understand a variable name,
it may ignore the value sent in the ENVIRON option. The server may
also prefer to just put all unknown information into the users en-
vironment. This is the suggested method of implementation, because
it allows the user the most flexibility.
The following is an example of use of the option:
Host1 Host2
IAC DO ENVIRON
IAC WILL ENVIRON
[ Host1 is now free to request environment information ]
IAC SB ENVIRON SEND VAR "USER"
VAR "ACCT" VAR USERVAR IAC SE
[ The server has now explicitly asked for the USER and ACCT vari-
ables, the default set of well known environment variables, and
the default set of user defined variables. Note that the
client includes the USER information twice; once because it was
explicitly asked for, and once because it is part of the de-
fault environment. ]
IAC SB ENVIRON IS VAR "USER"
VALUE "joe" VAR "ACCT" VALUE
"kernel" VAR "USER" VALUE "joe"
VAR "DISPLAY" VALUE "foo:0.0"
USERVAR "SHELL" VALUE "/bin/csh"
IAC SE
It is expected that any implementation that supports the Telnet EN-
VIRON option will support all of this specification.
7. Security Concerns
It is important for an implementor of the ENVIRON option to under-
stand the interaction of setting options and the login/authentication
process. Specifically careful analysis should be done to determine
which variables are "safe" to set prior to having the client login.
An example of a bad choice would be permitting a variable to be
changed that allows an intruder to circumvent or compromise the
login/authentication program itself.
8. References
[1] VanBokkeln, J., "Telnet Terminal-Type Option", RFC 1091, FTP
Software, Inc., February 1989.
[2] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC
959, ISI, October 1985
[3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1060, ISI,
March 1990
[4] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie
Telnet Working Group [Page 5]
Internet-Draft Telnet Environment Option June 1992
Mellon University, March 1989.
Author's Address
David A. Borman, Editor
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55123
Phone: (612) 452-6650
Mailing List: telnet-ietf at CRAY.COM
EMail: dab at CRAY.COM
Chair's Address
The working group can be contacted via the current chair:
Steve Alexander
INTERACTIVE Systems Corporation
1901 North Naper Boulevard
Naperville, IL 60563-8895
Phone: (708) 505-9100 x256
EMail: stevea at isc.com
Telnet Working Group [Page 6]
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa07292;
26 Jun 92 14:30 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07288;
26 Jun 92 14:30 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa23309;
26 Jun 92 14:31 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA21955; Fri, 26 Jun 92 13:31:42 CDT
Received: by hemlock.cray.com
id AA03473; 4.1/CRI-5.5; Fri, 26 Jun 92 13:31:39 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA03469; 4.1/CRI-5.5; Fri, 26 Jun 92 13:31:37 CDT
Received: from relay.hp.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA21697; Fri, 26 Jun 92 13:28:34 CDT
Received: from hpindvh.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA23038; Fri, 26 Jun 92 11:27:12 -0700
Received: by hpindsy.cup.hp.com with SMTP
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA09605; Fri, 26 Jun 92 11:26:45 pdt
To: Steve Alexander <stevea at i88.isc.com>
Cc: Marjo Mercado <marjo at hpindsy.cup.hp.com>, telnet-ietf at timbuk.cray.com,
Sun-Kwan_Kimn at hp6600.desk.hp.com, marjo at hpindsy.cup.hp.com,
Norman_Newlon at hp6600.desk.hp.com, Raghavan_Seshadri at hp6600.desk.hp.com,
charlie at hpindsy.cup.hp.com, rajs at hpinddf.cup.hp.com
Subject: Re: Environment draft with changes from mailing list feedback
In-Reply-To: Your message of "Fri, 26 Jun 92 12:22:52 PDT."
<9206261722.AA02863 at ozzy.i88.isc.com>
Date: Fri, 26 Jun 92 11:26:38 PDT
Message-Id: <9603.709583198 at hpindvh.cup.hp.com>
From: Marjo Mercado <marjo at hpindsy.cup.hp.com>
Steve Alexander <stevea at i88.isc.com> writes:
>It seems to me that this text is already present. I quote:
> If a "type" is not followed by a VALUE (e.g., by
> another VAR or an IAC) then that variable is undefined. If a
> VALUE is immediately followed by a "type" or IAC, then the vari-
> able is defined, but has no value.
>I guess it should say VAR, USERVAR, or IAC instead of just VAR or IAC.
>The rest is equivalent I think.
Agree. Please go ahead and reword it as:
If a "type" is not followed by a VALUE (e.g., by
another VAR, USERVAR or IAC SE) then that variable is
undefined. If a VALUE is immediately followed by a "type" or
IAC SE, then the variable is defined, but has no value.
>I don't see why not.
Thanks.
>What specifically is wrong with the "status" section?
According to The Guidelines to Authors of Internet Drafts
<1id-guidelines.txt>,
"All Internet Draft should include a section containing the following
verbatim statement:
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a ``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil,
nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au
to learn the current status of any Internet Draft.
"
If you agree, then this should apply to all the other drafts.
Thanks,
Marjo Mercado
Hewlett-Packard Company
(408) 447-2826
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07642;
26 Jun 92 15:30 EDT
Received: from wdl1.wdl.loral.com by NRI.Reston.VA.US id aa25938;
26 Jun 92 15:30 EDT
Received: by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA02238; Fri, 26 Jun 92 11:21:26 -0700
Received: from mwunix.mitre.org by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA02232; Fri, 26 Jun 92 11:21:13 -0700
Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA24621; Fri, 26 Jun 92 14:18:31 -0400
Received: from loghost.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA11104; Fri, 26 Jun 92 13:10:21 EDT
Resent-Message-Id: <9206261710.AA11104 at smiley.mitre.org.stc>
Received: from mwunix.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA06112; Thu, 25 Jun 92 02:25:23 EDT
Received: from gateway.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA09485; Thu, 25 Jun 92 02:23:03 -0400
Return-Path: <owner-ietf at ISI.EDU>
Received: from venera.isi.edu by gateway.mitre.org (5.61/SMI-2.2)
id AA23411; Thu, 25 Jun 92 02:24:23 -0400
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21294>; Wed, 24 Jun 1992 13:14:03 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA21289>; Wed, 24 Jun 1992 13:13:58 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa12366;
24 Jun 92 16:10 EDT
To: ietf at isi.edu
Reply-To: ietf-rsvp at NRI.Reston.VA.US
From: ietf-rsvp at NRI.Reston.VA.US
Subject: 24TH IETF: DRAFT AGENDA: July 13-17, 1992/Boston
Date: Wed, 24 Jun 92 16:10:49 -0400
Message-Id: <9206241610.aa12366 at IETF.NRI.Reston.VA.US>
Resent-To: tsig at wdl1.wdl.loral.com
Resent-Date: Fri, 26 Jun 92 13:10:21 -0400
Resent-From: "Jeffrey A. Edelheit" <edelheit at smiley.mitre.org>
Sender: tsig-request at wdl1.wdl.loral.com
==================================================================
>>> Submissions to the tsig list: tsig at wdl1.wdl.loral.com
>>> Additions/deletions/questions: tsig-request at wdl1.wdl.loral.com
>>> Archive Server: listserv at wdl1.wdl.loral.com
==================================================================
Below is the latest DRAFT of the Agenda for the 24th Internet
Engineering Task Force. This version is also available via ftp,
cd ietf, get 0mtg-agenda.txt.
Agenda of the Twenty-Fourth IETF - as of 6/24/92 11:00am
(July 13-17, 1992)
MONDAY, July 13, 1992
8:00-9:00 am IETF Registration and Continental Breakfast
9:00-9:30 am Introductions
9:30-12:00 noon Morning Sessions
APP Internet SMTP Extensions WG (smtpext)
(John Klensin/MIT)
INT IP over Appletalk WG (appleip) (John Veizades/Apple)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
OPS Network Status Reports (netstat) (Gene Hastings/PSC)
OSI OSI Directory Services WG (osids)
(Steve Hardcastle-Kille/ISODE)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG Open Shortest Path First IGP WG (ospf)
(John Moy/Proteon)
SEC Security Area Advisory Group (saag)
(Stephen Crocker/TIS)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF New Internet Routing and Addressing
Architecture BOF (nimrod) (Noel Chiappa)
BOF Remote Conferencing BOF (remconf)(Jack Drescher/MCNC
and Ari Ollikainen/LLNL)
INT IP over Appletalk WG (appleip) (John Veizades/Apple)
OSI OSI Directory Services WG (osids)
(Steve Hardcastle-Kille/ISODE)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Network Access Server Requirements WG (nasreq) WG
(Allan Rubens)
TSV Domain Name System WG (dns) (Mike Reilly/DEC)
USV Internet School Networking WG (isn)
(John Clement/EDUCOM, Connie Stout/TheNet and
Art St. George/UNM)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
BOF Email Requirements BOF (mailreq) (Russ Hobby/UCDavis)
BOF IP Routing for Wireless/Mobile Hosts BOF (moblhost)
(Steve Deering/Xerox)
BOF SNMP Security Implementors BOF (snmpseci)
(Keith McCloghrie/Hughes and Jim Galvin/TIS)
OPS Benchmarking Methodology WG (bmwg)
(Scott Bradner/Harvard)
OSI MHS-DS WG (mhsds) (Kevin Jordan/CDC and
Harald Alvestrand/SINTEF DELAB)
OSI Network OSI Operations WG (noop) (Sue Hares/Merit)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC TSIG/IETF Coordination Meeting
TSV Service Location Protocol WG (svrloc)
(John Veizades/Apple)
TUESDAY, July 14, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am IETF Technical Presentations
o ``The Futures of the Internet'' (Mitch Kapor/EFF)
9:30-12:00 noon TSIG Plenary Session
9:30-12:00 noon Morning Sessions
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF Routing Requirements Checklist BOF (rreqlist)
(Pushpendra Mohta/CERFnet)
APP Network Database WG (netdata) (Daisy Shen/IBM)
APP Telnet WG (telnet)
(Steve Alexander/INTERACTIVE Systems)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
INT Point-to-Point Protocol Extensions WG (pppext)
(Brian Lloyd/Consultant)
MGT FDDI MIB WG (fddimib) (Jeff Case/UTenn)
MGT Internet Accounting WG (acct) (Cyndi Mills/BBN
and Gregory Ruth/BBN)
OSI MHS-DS WG (mhsds) (Kevin Jordan/CDC and
Harald Alvestrand/SINTEF DELAB)
SEC Common Authentication Technology WG (cat)
(John Linn/DEC)
USV User Documents WG (userdoc2) (Ellen Hoffman/UMich
and Lenore Jackson/NASA)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF Host Resources MIB BOF (hostmib)
(Steve Waldbusser/CMU)
OPS Operational Statistics WG (opstat)
(Phill Gross/ANS and Bernhard Stockman/SUNET)
OSI MIME-MHS Interworking WG (mimemhs)
(Steve Thompson/SoftSwitch)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Common Authentication Technology WG (cat)
(John Linn/DEC)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV Internet User Glossary WG (userglos)
(Tracy LaQuey Parker/UTexas and Gary Malkin/Xylogics)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
BOF IDRP for IP over IP BOF (ipidrp) (Sue Hares/Merit)
BOF IP Security BOF (ipsec) (Steve Crocker/TIS)
OPS Operational Statistics WG (opstat)
(Phill Gross/ANS and Bernhard Stockman/SUNET)
OSI SNMP over a Multi-protocol Internet WG (mpsnmp)
(Ted Brunner/Bellcore)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tnfs) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess)(Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV Internet User Glossary WG (userglos)
(Tracy LaQuey Parker/UTexas and Gary Malkin/Xylogics)
7:00-10:00 pm Evening Sessions
BOF Internet Society Q&A (isoc) (Vint Cerf/CNRI)
BOF Uninterruptable Power Supply BOF (upsmib)
(Jeff Case/UTenn and Bob Stewart/Xyplex)
OPS BGP Deployment and Application WG (bgpdepl)
(Jessica Yu/Merit)
OSI Network OSI Operations WG (noop) (Sue Hares/Merit)
RTG Multicast Extensions to OSPF WG (mospf)
(Steve Deering/Xerox PARC)
SEC TCP Client Identity Protocol WG (ident)
(Mike StJohns/DOD)
WEDNESDAY, July 15, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am Technical Presentations
o ``Pip: The `P' Internet Protocol''
(Paul Tsuchiya/Bellcore)
9:30-12:00 noon Morning Sessions
INT IP over ATM WG (atm) (Bob Hinden/Sun)
INT Point-to-Point Protocol Extensions WG (pppext)
(Brian Lloyd/Consultant)
MGT Chassis MIB WG (chassis) (Jeff Case/UTenn and
Bob Stewart/Xyplex)
MGT DS1/DS3 MIB WG (trunkmib) (Fred Baker/ACC and
Tracy Cox/Bellcore)
OSI Office Document Architecture WG (oda)
(Peter Kirstein/UCL)
RTG Inter-Domain Policy Routing WG (idpr)
(Martha Steenstrup/BBN)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Trusted Network File Systems WG (tnfs) (Fred Glover/DEC)
USV User Services WG (uswg) (Joyce Reynolds/ISI)
Breaks Coffee available throughout morning.
1:30-3:30 pm Afternoon Sessions I
BOF Remote Conferencing BOF (remconf) (Jack Drescher/MCNC
and Ari Ollikainen/LLNL)
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT Token Ring Remote Monitoring WG (trmon)
(Mike Erlinger/Lexcel)
OPS BGP Deployment and Application WG (bgpdepl)
(Jessica Yu/Merit)
OSI X.400 Operations WG (x400ops)
(Alf Hansen/SINTEF DELAB)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
RTG RIP Version II WG (ripv2) (Gary Malkin/Xylogics)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
USV Internet Anonymous FTP Archives WG (iafa)
(Peter Deutsch/McGill and Alan Emtage/McGill)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Afternoon Sessions II
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT IEEE 802.3 Hub MIB WG (hubmib) (Keith McCloghrie/Hughes
and Donna McMaster/SynOptics)
OPS User Connectivity Problems WG (ucp) (Dan Long/BBN)
OSI X.400 Operations WG (x400ops) (Alf Hansen/SINTEF DELAB)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Commercial Internet Protocol Security Option WG (cipso)
(Ron Sharp/ATT)
TSG Trusted Administration WG (tadmin) (Jeff Edelheit/MITRE)
TSG Trusted Sessions WG (tsess) (Julie LeMoine/MITRE)
TSG Trusted X WG (txwg) (Mark Smith/ATT)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
USV Network Information Services Infrastructure WG (nisi)
(April Marine/SRI and Pat Smith/Merit)
7:00-10:00pm Evening Session
BOF Authorization and Access Control BOF (aac)
(Clifford Neuman/ISI)
BOF A New Internet Protocol BOF (pip)
(Paul Tsuchiya/Bellcore)
BOF Directory Resources Engineering Group BOF (dregs)
(Joan Gargano/UCDavis and Joyce K. Reynolds/ISI)
BOF Simple Management Protocol (SMP) Framework BOF
(smpframe) (Marshall Rose/DBC)
BOF Perspectives on the Next Generation of the NSFnet
(nsfnet)(Laura Breeden/FARNET)
THURSDAY, July 16, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30 am Technical Presentations
o ``DARPA Research Testbed Network'' (Bob Braden/ISI)
9:30-12:00 noon TSIG Plenary
9:30-12:00 noon Morning Sessions
BOF IP Address Encapsulation BOF (ipae)
(Bob Hinden/Sun and Dave Crocker/TBO)
INT Dynamic Host Configuration WG (dhc)
(Ralph Droms/Bucknell)
MGT Bridge MIB WG (bridge) (Fred Baker/ACC)
OPS User Connectivity Problems WG (ucp) (Dan Long/BBN)
RTG Inter-Domain Policy Routing WG (idpr)
(Martha Steenstrup/BBN)
RTG IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
SEC Privacy-Enhanced Electronic Mail WG (pem)
(Steve Kent/BBN)
TSV Audio/Video Transport WG (avt) (Stephen Casner/ISI)
Breaks Coffee available throughout the morning.
1:30-3:30 pm Afternoon Sessions I
APP Network Database WG (netdata) (Daisy Shen/IBM)
BOF IP Routing for Wireless/Mobile Hosts BOF (moblhost)
(Steve Deering/Xerox)
BOF TCP/UDP over CLNP BOF (tuc) (Peter Ford and Ross Callon)
MGT Internet Accounting WG (acct) (Cyndi Mills/BBN
and Gregory Ruth/BBN)
MGT X.25 Management Information Base WG (x25mib)
(Dean Throop/Data General)
OPS Network Joint Management WG (njm) (Gene Hastings/PSC)
SEC Security Area Advisory Group (saag)
(Stephen Crocker/TIS)
USV Directory Information Services Infrastructure WG (disi)
(Chris Weider/Merit)
3:30-4:00 pm Break (Refreshments provided)
4:00-6:00 pm Technical Presentations
FRIDAY, July 17, 1992
8:30-9:00 am Continental Breakfast
9:00-9:30am Technical Presentations
9:30-12:00pm Summary Reports
APP Applications Area (Russ Hobby/UC Davis)
INT Internet Area (Noel Chiappa and
Philip Almquist/Consultant)
MGT Network Management Area (Chuck Davin/MIT)
OPS Operations Area (Susan Estrada/CERFnet, Phill Gross/ANS,
Bernhard Stockman/SUNET)
OSI OSI Integration Area (Erik Huizer/SURFnet and
David Piscitello/Bellcore)
RTG Routing Area (Bob Hinden/Sun)
SEC Security Area (Steve Crocker/TIS)
TSV Transport and Services Area
(David Borman/Cray Research)
USV User Services Area (Joyce K. Reynolds/ISI)
12:00 pm Concluding Remarks (Phill Gross/ANS)
12:30 pm Adjourn
Key to Abbreviations
APP Applications Area
BOF Birds of a Feather Session
INT Internet Area
MGT Network Management Area
OSI OSI Integration Area
OPS Operational Requirements Area
RTG Routing Area
SEC Security Area
TSG Trusted Sytems Interoperability Group (TSIG)
TSV Transport and Services Area
USV User Services Area
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08371;
26 Jun 92 17:23 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa01330;
26 Jun 92 17:24 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA10062>; Fri, 26 Jun 1992 07:12:26 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA09988>; Fri, 26 Jun 1992 07:10:30 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04149;
26 Jun 92 10:06 EDT
From: Internet Engineering Steering Group <iesg-secretary at NRI.Reston.VA.US>
To: Bob Braden -- IAB Executive Director <braden at isi.edu>,
Internet Activities Board <iab at isi.edu>
Cc: Internet Engineering Task Force <ietf at isi.edu>
Subject: Protocol Action: BGP NEXT-HOP-SNPA Attribute to be removed from
consideration as a Proposed Standard
Date: Fri, 26 Jun 92 10:06:07 -0400
Sender: gvaudre at NRI.Reston.VA.US
Message-Id: <9206261006.aa04149 at IETF.NRI.Reston.VA.US>
Recommendation:
After discussion with the IAB, the protocol document authors, and the
IPLPDN working group, the IESG has decided to withdraw the
recommendation made December 1991.
Rationale:
The purpose of the NEXT_HOP attribute is for one border gateway A to
tell another border gateway B the local network address of the
approriate next hop border gateway C (where C might
equal A) should be used as the next hop on the path to the
destinations advertised in the UPDATE containing the NEXT_HOP
attribute.
The IAB had a few comments on specific aspects of this new BGP
attribute. In reviewing these questions, it become apparent to the
IESG that this protocol no longer has the necessary constituency for
a Proposed Standard. There is no indication that the BGP NEXT_HOP
Attribute has or will be implemented. After the recommendation to the
IAB was sent, new mechanism were proposed and are now being developed
in the IPLPDN Working Group that will likely provide the
functionality of the BGP NEXT_HOP Attribute.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08419;
26 Jun 92 17:35 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa01801;
26 Jun 92 17:36 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA09527>; Fri, 26 Jun 1992 06:58:25 -0700
Received: from amway.ch.apollo.hp.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA09520>; Fri, 26 Jun 1992 06:58:16 -0700
Message-Id: <199206261358.AA09520 at venera.isi.edu>
Received: from mapcar.ch.apollo.hp.com by amway.ch.apollo.hp.com id <AA18955 at amway.ch.apollo.hp.com> Fri, 26 Jun 92 09:55:58 EDT
Received: by mapcar.ch.apollo.hp.com id <AA07657 at mapcar.ch.apollo.hp.com>; Fri, 26 Jun 92 09:55:48 EDT
From: Nathaniel Mishkin <mishkin at apollo.hp.com>
Date: Fri, 26 Jun 92 09:55:47 EDT
Subject: Re: Sun RPC program IDs
To: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Cc: ietf at isi.edu
In-Reply-To: vjs at rhyolite.wpd.sgi.com (Vernon Schryver), Thu, 25 Jun 92 10:00:21 -0600
[[When this conversation starts to approach the general appeal of the
recent RFCs-in-Postscript discussion, please someone slap me in the
face...]]
The size of the unique ID which labels the service provider is not
interesting.
The problem is in the necessarily centrally administrated, globally
unique naming of services with names that humans and their agents
can handle.
While your points not entirely wrong, there are some factors that
you're not accounting for.
Consider that when a server exports (registers) its location into some
rendezvous service (e.g., the Apollo Global Location Broker [GLB] or
the DCE Cell Directory Service [CDS]) it is useful to try to make it
the case as often as possible that the export operation is, in effect,
a no-op because an identical entry already exists in the rendezvous
service's database. When the rendezvous service is replicated--as
undoubtedly it should be--such "no-op exports" allow the service to avoid
contacting all the replicas (peers) to propagate the database update.
If servers use their dynamically generated IP port number as part of
their identifier, propagation can't be avoided. If they use a Sun RPC
program ID as part of their identifier, they must get such an ID allocated
to them (i.e., no distributed administration).
Another problem we're trying to deal with is that we don't want software
vendors shipping software in binary form with the string "phonebook"
(or "telnet") embedded in it because it may conflict with another piece
of software that uses the same name for a different purpose (i.e., to
identify a service with different characteristics). I haven't addressed
your "human-sensible names" point yet, but at least at the lowest level,
using unique IDs for this purpose helps ensure that some client won't
accidentally bind with a server that doesn't really export the interface
the client is looking for. (What we're trying to avoid is analogous
to the mess that would ensue if, say, you tried to FTP to a host's telnet
port. I would really like it if my RPC system told the client "I think
you're in trouble here fella" if the client bound to the wrong server,
rather than just doing something unpredictable. Clearly one can go out
of one's way to make things break even with a unique ID based system,
but it's harder to do so as long as you follow some fairly simple
rules--which, BTW, don't require contacting a central authority.)
Let's consider your human-sensible name point. Clearly, people want
supply names like "phonebook" and not unique IDs. This is the role of
DCE's CDS. (The CDS supports a distributed, replicated, hierarchical
name space where names looks a lot like UNIX pathnames and nodes can
hold arbitrary property/value pairs.) Suppose I have to install two
incompatible "phonebook" services (one each from say, TelCoA and TelCoB)
into my environment. I can't prevent this. The user community just
happens to want these two different services (that presumably offer some
different services). The administrator who installs the two services
must pick two distinct and human-useful CDS names for the two services
(e.g., "/.:/phonebook/TelCoA" and "/.:/phonebook/TelCoB") and publicize
those names in the user community. The servers are configured to
"export" themselves under these names when they start. The user client
program accepts the server name (or reads it from a user's configuration
file) when the client starts and applies the "import" operation on the
name to yield an "RPC binding handle" on which it can make a remote call
to the server.
There's no magic here. The point is that (a) names are chosen in a way
that makes sense to the user/administrator, who is responsible for
maintaining his/her name space in a sensible, understandable, and
duplicate-free fashion, and not by the service writer, but (b) even if
the user/admin screws up, since the underlying system is based on UUIDs,
it is robust against such screwups.
Note that UUIDs also play a more significant role in the human-sensible
rendezvous process when the DCE RPC/CDS "profile" facility is used.
Profiles are a way of mapping interface UUIDs into CDS pathnames. A
profile is stored in a CDS namespace entry as an identifiable
property/value pair. The "import" operation (which takes an interface
UUID and CDS pathname as input) knows how to process profiles. The named
profile is searched for a matching UUID and associated pathname that
is found becomes the input to a recusive invocation of "import". A profile
can be shared among users (e.g., all the users in my work group might
share the same one). You can think of a profile as being like a UNIX
shell script that sets the PATH variable, that is common to a group of
users, and that is read in by each user's ".profile" file.
To see how the profile facility comes together, one more fact is required:
if "import" is supplied a NULL input CDS pathname, it picks up a CDS
pathname from a well-known environment variable. The recommended thing
for users to do is make the value of this environment variable be the
CDS pathname of the user's (or the user's group's) profile. The
recommended thing for client applications to do is:
binding_handle = import(NULL, my_service_UUID);
my_service_lookup(binding_handle, ...);
(There's a way in DCE RPC to make it so that the client can even avoid
coding up the call to "import" and in dealing with binding handles
altogether--it appears in the client stub.)
The upshot of this is that (a) the application itself embeds only unique
IDs which can be generated in a distributed fashion and not any name
that might clash with another application, and (b) the user gets control
over what servers are used (as a function of his/her environment and
namespace layout) but doesn't have to repeatedly specify this information
as input to the client program.
There's a whole other spin on the rendezvous process that's more "object
oriented" (as opposed to the "service-oriented" scheme above). I think
the O-O schemes are actually more practical and scalable, but my point
for right now has been the value of unique IDs in identifying services
and also I've taken up enough space for now.
You didn't mentioned the big problem with the current incarnation
of DCE, which is it's incredible size, and that it is still not
complete. I won't repeat what I know of that problem, since no one
who has not watched an attempted port would believe me.
I'm not going to tell anyone that the current DCE is a bed of roses.
It *is* large, but it also does a lot of valuable stuff. You don't have
to take all of it (and hence what you use may not be so large). Porting
it is not trivial, but pieces or all of it is running on a variety of
platforms (OSF/1, VMS, ULTRIX, SunOS, Apollo DOMAIN, IBM AIX and probably
others). It appears to have solid commitment from a number of vendors
and meta-vendors (HP, DEC, IBM, OSF, UI, USL); even Sun has indicated
that it will fall under their "federated network services" (or whatever
they call it) banner. The important point of this is not the political
one; rather it's that even though the current system is not problem-free,
it's likely to survive and get better.
-- Nat Mishkin
Distributed Object Computing Program / East
Hewlett-Packard Company
mishkin at apollo.hp.com
-------
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08563;
26 Jun 92 17:54 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa02493;
26 Jun 92 17:54 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA11488>; Fri, 26 Jun 1992 07:44:20 -0700
Received: from rfi.radiomail.net by venera.isi.edu (5.65c/5.65+local-6)
id <AA11482>; Fri, 26 Jun 1992 07:44:17 -0700
Received: by rfi.radiomail.net; id AA04966; Fri, 26 Jun 92 07:35:12 -0700
Message-Id: <9206261435.AA04966 at rfi.radiomail.net>
Received: from protools.com by melonville.mpk.ca.us with CCGW-1.6(920621); Fri, 26 Jun 92 06:28:28
From: Robert_Graham at protools.com
Date: 26 Jun 92 07:36
To: ietf at isi.edu
Subject: Re: Sun RPC program IDs
ProTools makes a product that, among other things, does protocol analysis
(we are probably more known for our RMON implementation).
In order to best decode Sun RPC, we should have these IDs (that we can't get).
Could people send me (private mail, not to this group!) IDs used by their
companies? I will then publish them appropriately (attach to the list
of vendor IDs/EtherTypes probably).
Rob. Graham
ProTools, Inc.
rob at protools.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08694;
26 Jun 92 18:24 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03901;
26 Jun 92 18:25 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA10000>; Fri, 26 Jun 1992 07:10:37 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA09993>; Fri, 26 Jun 1992 07:10:34 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04168;
26 Jun 92 10:06 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-crocker-ip-encaps-00.txt
Date: Fri, 26 Jun 92 10:06:54 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206261006.aa04168 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : A Proposal for IP Address Encapsulation (IPAE): A
Compatible Version of IP with Large Addresses
Author(s) : R. Hinden, D. Crocker
Filename : draft-crocker-ip-encaps-00.txt
Pages : 20
The Internet currently is seeking a means of providing for long-term
growth by increasing the amount of address space that is available for
hosts and by decreasing the amount of table storage that is required
for routers. One solution to these problems is a direct upgrade to a
new version of IP. Another is to switch to use of a new protocol such
as CLNP which has provisions for a larger and more hierarchical
address space. Both require very substantial disruption to the IP
installed base. This proposal describes an alternative which
minimizes overall disruption and, in fact, entirely eliminates a
significant portion of it.
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-ip-encaps-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-crocker-ip-encaps-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa08817;
26 Jun 92 19:08 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08813;
26 Jun 92 19:08 EDT
Received: from timbuk.cray.com by NRI.Reston.VA.US id aa05509;
26 Jun 92 19:08 EDT
Received: from hemlock.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA07098; Fri, 26 Jun 92 18:08:48 CDT
Received: by hemlock.cray.com
id AA20198; 4.1/CRI-5.5; Fri, 26 Jun 92 18:08:46 CDT
Received: from timbuk.cray.com by hemlock.cray.com
id AA20194; 4.1/CRI-5.5; Fri, 26 Jun 92 18:08:45 CDT
Received: from laidbak.i88.isc.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA07089; Fri, 26 Jun 92 18:08:39 CDT
Received: from ozzy.i88.isc.com by laidbak.i88.isc.com with SMTP
(5.65/isc-mail-gw/5/18/92) id AA06168; Fri, 26 Jun 92 18:08:29 -0500
Received: from localhost by ozzy.i88.isc.com (4.1/SMI-4.1)
id AA04131; Fri, 26 Jun 92 18:08:24 CDT
Message-Id: <9206262308.AA04131 at ozzy.i88.isc.com>
To: telnet-ietf at timbuk.cray.com
Subject: Latest Environment option draft
Date: Fri, 26 Jun 92 18:08:23 -0500
From: Steve Alexander <stevea at i88.isc.com>
Here's one based on the latest feedbak from Marjo along with one minor
spelling correction. I've updated the status sections of the other drafts
as well, but none of them have any other changes so I'm not resending them.
-- Steve
Network Working Group Internet Engineering Task Force
Internet-Draft Telnet Working Group
D. Borman, Editor
Cray Research, Inc.
June 1992
Telnet Environment Option
Status of this Memo
This document is an Internet Draft. Internet Drafts are working |
documents of the Internet Engineering Task Force (IETF), its Areas, |
and its Working Groups. Note that other groups may also distribute |
working documents as Internet Drafts. |
Internet Drafts are draft documents valid for a maximum of six |
months. Internet Drafts may be updated, replaced, or obsoleted by |
other documents at any time. It is not appropriate to use Internet |
Drafts as reference material or to cite them other than as a "working |
draft" or "work in progress." |
Please check the I-D abstract listing contained in each Internet |
Draft directory to learn the current status of this or any other |
Internet Draft.
1. Command Names and Codes
ENVIRON 36
IS 0
SEND 1
INFO 2
VAR 0
VALUE 1
ESC 2
USERVAR 3
2. Command Meanings
IAC WILL ENVIRON
The sender of this command is willing to send environment vari-
ables.
IAC WONT ENVIRON
Telnet Working Group Expires December 1992 [Page 1]
Internet-Draft Telnet Environment Option June 1992
The sender of this command refuses to send environment variables.
IAC DO ENVIRON
The sender of this command is willing to receive environment vari-
ables.
IAC DONT ENVIRON
The sender of this command refuses to accept environment vari-
ables.
IAC SB ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE
The sender of this command requests that the remote side send its
environment variables. The "type" may be either VAR or USERVAR,
to indicate either well known or user variable names. Only the
side that is DO ENVIRON may initiate a SEND command. If a list of
variables is specified, then only those variables should be sent.
If no list is specified, then the default environment, of both
well known and user defined variables, should be sent. If one of
the variables has no name, then all the variables of that type
(well known or user defined) in the default environment should be
sent.
IAC SB ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
... ] ] IAC SE
The sender of this command is sending environment variables. This
command is sent in response to a SEND request. Only the side that
is WILL ENVIRON may send an IS command. The "type"/VALUE pairs
must be returned in the same order as the SEND request specified
them, and there must be a response for each "type ..." explicitly
requested. The "type" will be VAR or USERVAR. Multiple environ-
ment variables may be sent. The characters following a "type" up
to the next "type" or VALUE specify the variable name. The char-
acters following a VALUE up to the next "type" specify the value
of the variable. If a "type" is not followed by a VALUE (e.g., by
another VAR, USERVAR, or IAC SE) then that variable is undefined. |
If a VALUE is immediately followed by a "type" or IAC, then the
variable is defined, but has no value. If an IAC is contained
between the IS and the IAC SE, it must be sent as IAC IAC. If a
variable or a value contains a VAR, it must be sent as ESC VAR.
If a variable or a value contains a USERVAR, it must be sent as
ESC USERVAR. If a variable or a value contains a VALUE, it must
be sent as ESC VALUE. If a variable or a value contains an ESC,
it must be sent as ESC ESC.
IAC SB ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
... ] ] IAC SE
Telnet Working Group Expires December 1992 [Page 2]
Internet-Draft Telnet Environment Option June 1992
The sender of this command is sending information about environ-
ment variables that have changed. It is identical to the IS com-
mand, except that the command is INFO instead of IS. Only the
side that is WILL ENVIRON may send an INFO command. The INFO com-
mand is not to be used to send initial information; the SEND/IS
sequence is to be used for that. The INFO command is to be used
to propagate changes in environment variables, and may be spon-
taneously generated.
3. Default Specification
The default specification for this option is
WONT ENVIRON
DONT ENVIRON
meaning there will not be any exchange of environment information.
4. Motivation
Many operating systems have startup information and environment vari-
ables that contain information that should be propagated to remote
machines when Telnet connections are established. Rather than create
a new Telnet option each time someone comes up with some new informa-
tion that they need propagated through a Telnet session, but that the
Telnet session itself doesn't really need to know about, this generic
information option can be used.
5. Well Known Variables
USER This variable is used to transmit the user or account
name that the client wishes to log into on the remote
system. The format of the value the USER variable is
system dependent, as determined by the remote system.
JOB This variable is used to transmit the job ID that the
client wishes to use when logging into the remote system.
The format of the value the JOB variable is system depen-
dent, as determined by the remote system.
ACCT This variable is used to transmit the account ID that the
client wishes to use when logging into the remote system.
The format of the value the ACCT variable is system
dependent, as determined by the remote system.
PRINTER This variable is used to identify the default location
for printer output. Because there does not currently ex-
ist a standard way of naming a printer on a network, the
format of this variable is currently undefined.
Telnet Working Group Expires December 1992 [Page 3]
Internet-Draft Telnet Environment Option June 1992
SYSTEMTYPE This is used to transmit the type of operating system on
the system that sends this variable. It value is identi-
cal to the value of the SYSTEM (SYST) command in FTP [2].
The format of the value shall have as its first word one
of the system names listed in the current version of the
Assigned Numbers document [3].
DISPLAY This variable is used to transmit the X display location
of the client. The format for the value of the DISPLAY
variable is:
<host>:<dispnum>[.<screennum>]
This information is identical to the information passed
using the Telnet X-DISPLAY-LOCATION option. If both the
DISPLAY environment variable, and the X-DISPLAY-LOCATION
option[4] are received, and they contain conflicting in-
formation, the most recently received information re-
ceived should be used.
Because it is impossible to anticipate all variables that users may
wish to exchange, the USERVAR type is provided to allow users to
transmit arbitrary variable/value pairs. The use of an additional
type allows implementations to distinguish between values derived
by the remote host software and values supplied by the user.
Paranoid implementations will most likely treat both types with an
equal level of distrust. The results of a name-space collision
between a well-known and a user variable are implementation specif-
ic.
6. Implementation Rules
WILL and DO are used only at the beginning of the connection to ob-
tain and grant permission for future negotiations.
Once the two hosts have exchanged a WILL and a DO, the sender of
the DO ENVIRON is free to request that environment variables be
sent. Only the sender of the DO may send requests (IAC SB ENVIRON
SEND IAC SE) and only the sender of the WILL may transmit actual
environment information (via the IAC SB ENVIRON IS ... IAC SE com-
mand). Though this option may be used at anytime throughout the
life of the telnet connection, the exchange of environment informa-
tion will usually happen at the startup of the connection. This is
because many operating systems only have mechanisms for propagating
environment information at process creation, so the information is
needed before the user logs in.
The receiving host is not required to put all variables that it re-
ceives into the environment. For example, if the client should
send across USERVAR "TERM" VALUE "xterm" as an environment vari-
able, and the TERMINAL-TYPE [1] option has already been used to
Telnet Working Group Expires December 1992 [Page 4]
Internet-Draft Telnet Environment Option June 1992
determine the terminal type, the server may safely ignore the TERM
variable. Also, some startup information may be used in other
ways; for example, the values for "USER", "ACCT" and "PROJ" values
might be used to decide which account to log into, and might never
be put into the users environment. In general, if the server has
already determined the value of an environment variable by some
more accurate means, or if it does not understand a variable name,
it may ignore the value sent in the ENVIRON option. The server may
also prefer to just put all unknown information into the users en-
vironment. This is the suggested method of implementation, because
it allows the user the most flexibility.
The following is an example of use of the option:
Host1 Host2
IAC DO ENVIRON
IAC WILL ENVIRON
[ Host1 is now free to request environment information ]
IAC SB ENVIRON SEND VAR "USER"
VAR "ACCT" VAR USERVAR IAC SE
[ The server has now explicitly asked for the USER and ACCT
variables, the default set of well known environment variables,
and the default set of user defined variables. Note that the
client includes the USER information twice; once because it was
explicitly asked for, and once because it is part of the
default environment. ]
IAC SB ENVIRON IS VAR "USER"
VALUE "joe" VAR "ACCT" VALUE
"kernel" VAR "USER" VALUE "joe"
VAR "DISPLAY" VALUE "foo:0.0"
USERVAR "SHELL" VALUE "/bin/csh"
IAC SE
It is legal for a client to respond with an empty environment (no |
data between the IAC SB and IAC SE) when no well-defined or user |
variables are currently defined. For example: |
IAC SB ENVIRON IS IAC SB |
is a valid response to any of the following: |
IAC SB ENVIRON SEND IAC SB |
IAC SB ENVIRON SEND VAR IAC SB |
IAC SB ENVIRON SEND USERVAR IAC SB |
IAC SB ENVIRON SEND VAR USERVAR IAC SB |
(The last example is equivalent to the first...) |
It is expected that any implementation that supports the Telnet EN-
VIRON option will support all of this specification.
Telnet Working Group Expires December 1992 [Page 5]
Internet-Draft Telnet Environment Option June 1992
7. Security Concerns
It is important for an implementor of the ENVIRON option to under-
stand the interaction of setting options and the login/authentication
process. Specifically careful analysis should be done to determine
which variables are "safe" to set prior to having the client login.
An example of a bad choice would be permitting a variable to be
changed that allows an intruder to circumvent or compromise the
login/authentication program itself.
8. References
[1] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP |
Software, Inc., February 1989.
[2] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC
959, ISI, October 1985
[3] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1060, ISI,
March 1990
[4] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie
Mellon University, March 1989.
Author's Address
David A. Borman, Editor
Cray Research, Inc.
655F Lone Oak Drive
Eagan, MN 55123
Phone: (612) 452-6650
Mailing List: telnet-ietf at CRAY.COM
EMail: dab at CRAY.COM
Chair's Address
The working group can be contacted via the current chair:
Steve Alexander
INTERACTIVE Systems Corporation
1901 North Naper Boulevard
Naperville, IL 60563-8895
Phone: (708) 505-9100 x256
EMail: stevea at isc.com
Telnet Working Group Expires December 1992 [Page 6]
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08942;
26 Jun 92 19:51 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06735;
26 Jun 92 19:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA13032>; Fri, 26 Jun 1992 08:22:35 -0700
Received: from timbuk.cray.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA13027>; Fri, 26 Jun 1992 08:22:32 -0700
Received: from pecan31.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA11076; Fri, 26 Jun 92 10:21:11 CDT
Received: by pecan31.cray.com
id AA10361; 4.1/CRI-5.6; Fri, 26 Jun 92 10:21:10 CDT
From: "John A. Reinart" <reinart at pecan.cray.com>
Message-Id: <9206261521.AA10361 at pecan31.cray.com>
Subject: Re: porting DCE (WAS: Sun RPC program IDs)
To: ietf at isi.edu
Date: Fri, 26 Jun 92 10:21:08 CDT
X-Mailer: ELM [version 2.3 PL11b-CRI]
In-Reply-To: <9206251600.AA26341 at rhyolite.wpd.sgi.com>; from "Vernon Schryver" at Jun 25, 92 10:00 am
> That part of the Apollo scheme is irrelevant to the issue at hand.
>
> Right now, today, we have globally unique, distributedly administrated ID's
> for programs. In the Internet suite, they are the (IP address, Port
> number) pair.
But isn't there still central administration involved to ensure global
uniqueness? That is, either you have to be assigned a well known port
number, or you have to be assigned a Sun RPC program number. Otherwise,
there's nothing to guarantee uniqueness. Or am I missing your point?
> You didn't mentioned the big problem with the current incarnation of DCE,
> which is it's incredible size, and that it is still not complete. I won't
> repeat what I know of that problem, since no one who has not watched an
> attempted port would believe me.
Oh come on, it's not fair to slip a comment like that in without elaborating.
Besides, hasn't DCE already been ported to several machines including
Sun SPARCstation, IBM RS/6000, DEC PMAX, HP Apollo and PA series...?
>
> Vernon Schryver, vjs at sgi.com
>
--
John Reinart
Cray Research, Inc. VOICE (612) 683-5329
655F Lone Oak Drive FAX (612) 683-5599
Eagan, MN 55121 EMAIL reinart at cray.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09367;
26 Jun 92 21:02 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09004;
26 Jun 92 21:02 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA12987>; Fri, 26 Jun 1992 08:21:27 -0700
Received: from timbuk.cray.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA12982>; Fri, 26 Jun 1992 08:21:23 -0700
Received: from pecan31.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag)
id AA10965; Fri, 26 Jun 92 10:20:00 CDT
Received: by pecan31.cray.com
id AA10352; 4.1/CRI-5.6; Fri, 26 Jun 92 10:19:59 CDT
From: "John A. Reinart" <reinart at pecan.cray.com>
Message-Id: <9206261519.AA10352 at pecan31.cray.com>
Subject: Re: How do they do that? (DCE RPC)
To: ietf at isi.edu
Date: Fri, 26 Jun 92 10:19:57 CDT
X-Mailer: ELM [version 2.3 PL11b-CRI]
> The ieee 802 address in a DCE RPC interface uuid has *nothing* to do
> with the network address of a server; it's just part of what makes the
> uuid unique.
>
> In DCE RPC, each "interface" (a collection of remote operations,
> roughly equivalent to a Sun RPC "program"), has a uuid assigned to it
> when it is first defined; it appears in the interface definition
> source file, and is compiled, as a constant, into the RPC stubs, and
> thus, into any program using the interface.
>
> A server registers itself with the DCE RPC endpoint mapper (in NCS
> 1.x, this was the "local location broker") when it starts up. The
> endpoint mapper, like portmap, listens on a single well-known port
> (per address family). Until the client learns the port number, it
> directs requests to the mapper's well-known port.
>
> [There is also a name service in DCE which can be used to locate the
> host on which a service is running. In the case of a multi-homed, or
> multi-protocol, host, the server can register multiple (network layer,
> not MAC layer) addresses in the DCE name service; the client gets to
> pick which one it wants to use.]
>
> This has some definite advantages for developers... If I want to
> create a simple distributed application prototype using DCE, and run
> it on ten or twenty machines at my site, I don't need to either (a)
> pick a port that nobody else is using and hope that nobody else starts
> using it "for real", or (b) go through the trouble of getting a port
> number offcially assigned to something which may just be a throwaway
> prototype. Instead, I just run uuidgen, paste the output into a new
> interface definition source file, and start developing the
> application.
>
> Note that DCE interfaces can use well known ports; the default,
> however, is to just use a dynamically assigned port, and rendezvous
> through the endpoint mapper.
>
> - Bill
Bill,
DCE's uuid generation mechanism is certainly much more "developer
friendly" than any centrally administered approach (like Sun RPC
program numbers.)
I'd like to know more about the DCE name service. Is there a mechanism
to ensure global uniqueness within the name service as well? Or is that
unnecessary because the uuid interface mapping takes care of it?
--
John Reinart
Cray Research, Inc. VOICE (612) 683-5329
655F Lone Oak Drive FAX (612) 683-5599
Eagan, MN 55121 EMAIL reinart at cray.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09474;
26 Jun 92 21:39 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09786;
26 Jun 92 21:40 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20176>; Fri, 26 Jun 1992 10:43:55 -0700
From: Joyce Reynolds <jkrey at isi.edu>
Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA20163>; Fri, 26 Jun 1992 10:43:44 -0700
Date: Fri, 26 Jun 1992 10:42:21 -0700
Posted-Date: Fri, 26 Jun 1992 10:42:21 -0700
Message-Id: <199206261742.AA01213 at akamai.isi.edu>
Received: by akamai.isi.edu (5.65c/4.0.3-4)
id <AA01213>; Fri, 26 Jun 1992 10:42:21 -0700
To: ietf at isi.edu, rfc-dist at nic.ddn.mil
Subject: RFC1338 on Supernetting
Cc: jkrey at isi.edu
A new Request for Comments is now available in online RFC libraries.
RFC 1338:
Title: Supernetting: an Address Assignment and
Aggregation Strategy
Author: V. Fuller, T. Li, J. Yu, & K. Varadhan
Mailbox: vaf at Stanford.EDU, tli at cisco.com, jyy at merit.edu,
kannan at oar.net
Pages: 20
Characters: 47,975
Updates/Obsoletes: none
This memo discusses strategies for address assignment of the existing
IP address space with a view to conserve the address space and stem
the explosive growth of routing tables in default-route-free routers
run by transit routing domain providers.
This memo provides information for the Internet community. It does not
specify an Internet standard. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at NRI.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.
RFCs can be obtained via FTP from FTP.NISC.SRI.COM, NIS.NSF.NET,
NISC.JVNC.NET, VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or 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 NIC at NIC.DDN.MIL. 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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
======================================================================
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09552;
26 Jun 92 22:02 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10299;
26 Jun 92 22:02 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20794>; Fri, 26 Jun 1992 10:59:20 -0700
Received: from Sun.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA20789>; Fri, 26 Jun 1992 10:59:16 -0700
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA23312; Fri, 26 Jun 92 10:57:54 PDT
Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1)
id AA05055; Fri, 26 Jun 92 10:57:53 PDT
Received: from camilla.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1)
id AA06292; Fri, 26 Jun 92 10:57:33 PDT
Date: Fri, 26 Jun 92 10:57:33 PDT
Message-Id: <9206261757.AA06292 at b5mail.Eng.Sun.COM>
Received: by camilla.Eng.Sun.COM (4.1/SMI-4.1)
id AA03618; Fri, 26 Jun 92 10:57:47 PDT
From: Abhijit Khale <Abhijit.Khale at eng.sun.com>
Sender: khale at b5mail.eng.sun.com
To: ietf at isi.edu
Subject: RPC program IDs (DCE/ONC): naming
Reply-To: Abhijit.Khale at eng.sun.com
X-Organization: Distributed Computing Technology Group, Sun Microsystems
>From: mishkin at apollo.hp.com (Nathaniel Mishkin)
>To my (biased) way of thinking, this whole discussion of allocation of
>Sun RPC program IDs just makes it clear that schemes based on a centrally
>administered and relatively small space of IDs are bad for identifying
>distributed services.
By that definition, most of the allocations made by the IANA (from IP
multicast addresses to well known ports) would be a "bad idea". Also, the
"small space" of Sun RPC program IDs is not all that small. I'd be very
surprised if more than 5 % of it is used currently, and it should certainly
last far longer than the IP address space :-).
>[ About DCE RPC uuids] The downside is that they're 128
>bits long, but I think I'd take that over the administrative hassles.
In ONC RPC, a portion of the program number space is for services that are
being developed only for local use at a certain site. Such program numbers
dont need to be registered with Sun. Anyone who wishes to write such a
program can use a number in that space. And there is also a portion reserved
for transient program numbers ...
Also, theres no particular "administrative hassle" in getting a new program
number from Sun. For those with email access, it should involve no more than
writing up a few lines in an email message and sending it to Sun.
>From: sommerfeld at apollo.hp.com
>This has some definite advantages for developers... If I want to
>create a simple distributed application prototype using DCE, and run
>it on ten or twenty machines at my site, I don't need to either (a)
>pick a port that nobody else is using and hope that nobody else starts
>using it "for real", or (b) go through the trouble of getting a port
>number offcially assigned to something which may just be a throwaway
The "local" program number range in ONC RPC is meant to provide equivalent
service.
>From: vjs at rhyolite.wpd.sgi.com (Vernon Schryver)
>The problem is in the necessarily centrally administrated, globally unique
>naming of services with names that humans and their agents can handle.
>Yes, there is the location broker, but that is the same in formal senses as
>the portmapper. You, the programmer or end user, must specify the name of
>the service you want performed. The location broker does provide some nice
>flexibility in that naming, but ultimately, some human must decide which
>service gets the name "phonebook" (and in the Apollo scheme which servers
>provide it--an advantage in my opinion). Simply replacing the global
>"phonebook" with a zillion different 48-bit or 128-bit ID's doesn't do
>anyone any good. Some mechanism must ensure that the service named
>"phonebook" provided by the server on my machine is functionally the same
>as service named "phonebook" provided by the server on your machine. The
>old Apollo NCS Mendelbrot demo is an excellent case in point.
Exactly. Regardless of what naming and resource location service you use
(portmapper, location broker, NIS+, CDS, X.500, DNS), there still needs to
be a way to register a service uniquely. For that, some administrative
co-ordination is still required. If this registration is to take place only
in your local "domain" ( the definition of a domain here is dependent on the
name/resource location service), the effort involved should be minimal. If
something has to be registered "globally" (once again, this depends on
what the name service calls "globally" : for hierarchical name spaces
this can be even more general), more administrative overhead may be
required. But this is necessary to prevent clashes and for consistency. You
dont want two services which refer to different things to use the same name.
To give an example, an IP address is (currently anyway) globally unique, so
it is necessary to obtain it globally. This task is simplified by the fact
that blocks of IP addresses (otherwise known as network numbers :-) can
be obtained at one time. Port numbers, by contrast are only unique on a
machine. But for consistency, its necessary that well-known port numbers
refer to the same service (25 for smtp. 23 for telnet).
Note that you can push this problem one level higher (and maybe obtain
more human friendly names) by adding indirection. Thats exactly what
the ONC portmapper does, by keeping a binding of <program, version> -->
port number (or Transport Endpoint for non TCP/IP transports). This enables
services to pick a port number dynamically, but it just pushes the problem one
level higher, in that the program number space now needs to be administered.
The DNS performs a similar function in mapping more user friendly names
to IP addresses (but it doesnt remove the need for administering the IP
address space, since that is used for routing).
Abhijit
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09572;
26 Jun 92 22:16 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10529;
26 Jun 92 22:16 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21674>; Fri, 26 Jun 1992 11:19:04 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA21622>; Fri, 26 Jun 1992 11:17:09 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07034;
26 Jun 92 14:02 EDT
From: Internet Engineering Steering Group <iesg-secretary at NRI.Reston.VA.US>
To: Bob Braden -- IAB Executive Director <braden at isi.edu>,
Internet Activities Board <iab at isi.edu>
Cc: Internet Engineering Task Force <ietf at isi.edu>
Cc: IAB Standard Administrator <IAB-STDS at isi.edu>
Subject: Protocol Action: IDPR to Proposed Standard
Date: Fri, 26 Jun 92 14:02:22 -0400
Sender: gvaudre at NRI.Reston.VA.US
Message-Id: <9206261402.aa07034 at IETF.NRI.Reston.VA.US>
Recommendation:
The IESG recommends that the InterDomain Policy Routing (IDPR)
Protocol be elevated to Proposed Standard Status.
IDPR is define in the Internet Drafts:
o <draft-ietf-idpr-architecture-04> "An Architecture for Inter-Domain
Policy Routing"
and
o <draft-ietf-idpr-specv1-02> "Inter-Domain Policy
Routing Protocol Specification: Version1"
An overview document is available as Internet Drafts
<draft-ietf-idpr-summary-00> "IDPR as a Proposed Standard".
IDPR is the product of the IDPR Working Group of the IETF.
Abstract:
IDPR was developed to fill a perceived need (see RFCs 1092,1102,
1104, 1124, and 1125) - that of policy-based routing in a large
internet. While there are other inter-domain routing procedures
that are designed for large internets, only IDPR offers the
potential for full policy routing. The routes constructed with IDPR
can account for the transit service providers access restrictions,
qualities of service, and charging for service. These routes can
also account for individual source requirements in terms of service,
cost, and access restrictions.
Technical Summary:
IDPR meets the requirements for a Proposed Standard Routing Protocol
as documented in RFC 1264, "Internet Routing Protocol
Standardization Criteria". It is a complete and reasonably
understood and stable specification that has been validated by
initial implementation experience.
IDPR is compatible with the Interdomain/Intradomain routing
architecture of the Internet. IDPR can be deployed in an
incremental manner and without conflict with currently deployed
routing protocols. The deployment of IDPR is a step toward support
of a larger more complex Internet. This deployment is not in
conflict with the ongoing efforts to select and develop the next
generation routing and addressing architecture and associated
protocols.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09620;
26 Jun 92 22:50 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11262;
26 Jun 92 22:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA24982>; Fri, 26 Jun 1992 12:36:36 -0700
Received: from mwunix.mitre.org by venera.isi.edu (5.65c/5.65+local-6)
id <AA24974>; Fri, 26 Jun 1992 12:36:31 -0700
Return-Path: <shirey at smiley.mitre.org>
Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA29145; Fri, 26 Jun 92 15:31:56 -0400
Received: from loghost.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA13297; Fri, 26 Jun 92 15:34:11 EDT
Message-Id: <9206261934.AA13297 at smiley.mitre.org.stc>
To: "Dr. Edward Levinson (GC-ACCURATE|COURTESY)\
<levinson at pica.army.mil>" <levinson at pica.army.mil>
Cc: mail-server at nisc.sri.com, IETF <ietf at isi.edu>, shirey at smiley.mitre.org
Subject: Re: ID ACTION:draft-ietf-netdata-netdata-03.txt
In-Reply-To: Your message of "Fri, 26 Jun 92 09:51:08 EDT."
<9206260952.aa27554 at COR3.PICA.ARMY.MIL>
Date: Fri, 26 Jun 92 15:34:10 -0400
From: shirey at smiley.mitre.org
Could you please be a little more careful addressing your mail? The
IETF list is damn big!
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09880;
27 Jun 92 0:18 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13159; 27 Jun 92 0:19 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA26462>; Fri, 26 Jun 1992 13:04:11 -0700
Received: from ZIPPY.LCS.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA26457>; Fri, 26 Jun 1992 13:04:08 -0700
Received: by zippy.lcs.mit.edu
id AA29919; Fri, 26 Jun 92 16:04:23 -0400
Date: Fri, 26 Jun 92 16:04:23 -0400
From: Tim Berners-Lee <timbl at zippy.lcs.mit.edu>
Message-Id: <9206262004.AA29919 at zippy.lcs.mit.edu>
To: ietf-udi at merit.edu, ietf at isi.edu, nir at nxoc01.cern.ch,
www-talk at nxoc01.cern.ch
Subject: IETF BOF on Universal Document Identifiers
Cc: erik.huizer at surfnet.nl, mdavies at NRI.Reston.VA.US
Universal Document Identifiers UDI BOF
Time: Monday 13th July 1992 1:30 pm
Chair: Tim Berners-Lee
Background document: file://info.cern.ch/pub/www/doc/udi2.ps
Aim: To define some clear decisions to be made by a small WG to be
formed. A skeleton charter for such a working group is appended,
and may be discussed at the BOF. The overall aim is to standardize
on one unifying printable representation for names and addresses of
retrievable objects in existing and future name and address spaces.
Those who have not been following the discussion are asked to read the
background document first. An archive of some of the discussion is
available as file://info.cern.ch/pub/www/doc/udi/discussion.mbox .
The BOF will avoid philosophy and a discussion of the differences
between names and addresses, or the relative merits of different naming
schemes, or the combination of names in different spaces recommended to
refer to an object. If new schemes are required, a separate effort
may be forked off to create them.
_________________________________________________________________
Provisional Charter:
To define a printable string syntax to the allow
1. The expression of the address on the network of any
accesable object using existing information retrieval protocols;
2. The expression of the name of any object held in
a directory system or unique naming space on the network;
3. The distinction to be made easily in the syntax
between such protocols and directories and name spaces;
4. New protocols, directories and naming schemes to be included as
and when they are developed.
The aim of the working group is to further the exchange of information
between people and applications using the network by allowing an
unambiguous reference to be cited to accessible units of information.
The working group will build on experience with existing information retrieval
protocols and will not invent new protocols or name spaces. The working
group will note the properties of established name and address spaces.
Deliverable:
A Document describing:
Overall syntax, character sets and limitations
Formats for addresses of:-
FTP files and directories
WAIS documents and databases
HTTP objects
NNTP newsgroups and articles
Gopher items.
Standards track.
B Appendices to document A for x500 distinguished name spaces
C Appendices to document A for selected established
unique identifier name spaces. (possible separate parallel
working group).
Milestones:
Define at BOF.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10204;
27 Jun 92 0:56 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14061; 27 Jun 92 0:57 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA20988>; Fri, 26 Jun 1992 11:03:43 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA20981>; Fri, 26 Jun 1992 11:03:35 -0700
Received: from KRAMDEN.ACF.NYU.EDU by NRI.Reston.VA.US id aa21367;
26 Jun 92 13:49 EDT
Received: from LOCALHOST by KRAMDEN.ACF.NYU.EDU (5.61/1.34)
id AA20685; Fri, 26 Jun 92 17:49:37 GMT
Message-Id: <9206261749.AA20685 at KRAMDEN.ACF.NYU.EDU>
To: ietf at NRI.Reston.VA.US, comp-protocols-tcp-ip at ucbvax.berkeley.edu
Cc: brnstnd at nyu.edu
Subject: informal notice of two IESG decisions
Date: Fri, 26 Jun 92 13:49:27 +0100
From: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>
This message has 25 sections, each quite short but together a lot to
take in. Sorry for the length. Why so much? Because I'm exposing a
year-long pattern of corruption within the IESG. I now have a large
collection of electronic, verbal, and written evidence that the IESG has
blatantly violated several requirements in RFC 1310. These abuses are
documented below. (Skip to pattern ^25 for the quick summary.)
1. Reason for the informal notice
RFC 1310 states that anyone can submit a standardization proposal to the
IETF Chairman or an appropriate IETF Area Director, who in turn lets the
IESG review the proposal. RFC 1310 outlines a few procedures for dealing
with tricky proposals---for example, commissioning a special review
committee, or creating a working group for ``evaluation and refinement''
of the protocol spec. It then says: ``The IESG shall determine whether a
specification satisfies the applicable criteria for the recommended
action (see Sections 3.2 and 3.3 of this document) and shall communicate
its findings to the IETF to permit a final review by the general Internet
community.'' RFC 1310 goes on to say that the notification is by email
to the IETF list.
2. The informal notice
On 15 July 1991 I submitted a protocol specification to Steve Crocker,
requesting that it be published as a Proposed Standard RFC. At the time
the protocol in question, which came into existence in early 1990 and
was derived from a much older protocol, did not have a distinguishing
name; I have recently begun calling the protocol ``TAP.'' (This, like
``TELNET,'' is a capitalized name, not an abbreviation for some official
name.) Anyway, Crocker is the IETF Security Area Director. Phill Gross,
the IETF Chairman, informed me in May that Crocker had rejected my
request in March.
On 18 April 1992 I requested of Gross that a newer, pruned-down TAP
specification be published as a Proposed Standard RFC (or at least that
a working group be created to discuss it). Gross informed me in mid-May
that the IESG had just rejected my request, primarily because TAP has
the same function as a still-not-yet-defined protocol named Ident,
currently stuck in the Ident WG. (It is worth noting that the Ident WG
chairman, Mike StJohns, has refused to allow discussion of TAP on the
Ident list, although he does not deny that TAP is within the Ident
charter.)
3. Comments about the notice
According to RFC 1310, the IESG was required to notify the IETF mailing
list of the two decisions listed above, to permit community review. It
appears that the IESG failed to do so, hence violating both the letter
and the spirit of this rule. If in fact the IESG sent out timely
notifications which I missed, I'm sorry; I asked the IESG recently
whether such notifications had been sent, and I received no response.
The remainder of this message gives you further information about the
protocol in question and its history within the IAB. Everything I say
here (except, in some cases, my comments about what I was thinking at a
given time) can be verified from the transcripts of my dealings with the
IAB, which I plan to publish in SIGCOMM CCR, or from other objectively
verifiable sources. You will be forced to wonder, as you read through
these progressively more and more damning pieces of evidence, whether
the IESG is attempting to take control of the IAB standards series away
from the community. Why else would it keep its decisions secret, and
violate RFC 1310 in the many other ways documented below?
4. Chronology I: early history
TAP came into existence in February 1990. I took the dead protocol
documented in RFC 931 and implemented a variant of it. I distributed the
result in my ``auth'' package, which never really caught on. A year
later I distributed ``authd,'' a new TAP implementation which did catch
on because of various technical features. authd serves TCP port 113; in
effect it announces ``username shmoe connected from this host's TCP port
12345 to host H's TCP port 7654'' to anyone on host H who asks about
those port numbers. (It can be used for things other than usernames,
though, just as finger can be used to transmit weather information.)
Three client TAP implementations (for BSD talk, NNTP, and SMTP) were
distributed in early 1991. I began to worry about ways to guarantee
future interoperability. In June I documented the TAP protocol, along
with the existing applications and some suggested applications, in RFC
format. I also commented extensively on the exact security added by TAP.
On 15 July, as noted above, I submitted the document to Crocker for
publication as a Proposed Standard RFC.
5. Chronology II: Delay Period 1 (15 July to 14 September)
After my submission I was told nothing for two months. I sent Crocker a
list of some sites running TAP. Then Crocker wrote back: ``Naw, two
months is not unreasonable. The time has been used for coordination...
There is moderate agreement that this should indeed go on the standards
track. However, the wording about the relationship to security needs to
be changed. It's one thing for hosts to supply information about the
user associated with a particular connection, but it's another matter to
assert that this information supplied is particularly trustworthy or
strongly related to security. You get first crack at fixing up the
document. If you need clarification of the issues, we can set up a
dialog.'' That was 14 September.
Nowhere in the security section did I assert that the information
supplied was in particularly trustworthy or strongly related to
security, and I did not understand what changes Crocker wanted me to
make, or who the ``we'' was. I told Crocker so on 15 September. I asked
exactly what wording he considered inaccurate, misleading, or
incomplete, and said: ``Since I don't understand which statements you're
objecting to, I guess I need clarification. Dialogue with whom?'' (As I
learned later, ``we'' meant some subset of the SAAG group.)
6. Chronology III: Delay Period 2 (15 September to 20 November)
Crocker did not respond to my request for further information, and
didn't come through on ``we can set up a dialog.'' I sent messages to
him on 3 October and 19 October attempting to elicit a response. He
didn't respond until 20 November, more than four months after my
submission. In those four months, the ball was in Crocker's court every
day except 14 September.
In the meantime the world continued to turn. Peter Eriksson wrote a new
implementation; unfortunately there was an interoperability problem. I
heard about the problem from Simon Leunen. By 4 November, Peter had
fixed the problem and read through the TAP specification. The
specification would not have permitted the problem if it had been
available to Peter. In mid-November I created the rfc931-users list
``for people who want to use RFC 931 to solve problems.'' The list
quickly swelled past 100 subscribers, and Peter's ``pauthd'' continued
to grow in popularity.
7. Chronology IV: technical discussion
On 20 November Crocker finally gave me some indication of what he (and
apparently some SAAG members) didn't like about the document. I
responded with a list of ten issues, on most of which we seemed to
agree. Crocker responded on 22 November: ``I think we're in basic
agreement, modulo detailed discussion over what words are in the RFC
regarding security and the name of the protocol.'' (He had mentioned
that the current name---``Authentication Server,'' just like RFC 931---
was, in the eyes of the SAAG, inappropriate; this was one of the issues
I listed.)
At the end of November I sent some initial messages to the rfc931-users
list. Discussion ensued on the security section of my document. This
discussion continued, in various threads on rfc931-users and the SAAG
list, through the beginning of January. During that time I produced
several revisions of my document in response to SAAG criticism.
On 2 January Jim Galvin of SAAG sent me a message, reminding me of the
name-change issue raised in late November. ``It is the opinion of those
SAAG members who have been carefully tracking this effort that the
protocol should be renamed as the "Identity Server" (or something
similar)... If you agree you will need to revise your document
accordingly, after which we will push it on to the "standards track" as
expeditiously as possible.''
I asked rfc931-users whether the name change would be okay, and how we'd
deal with the problems of changing the name of an established protocol.
The answers were satisfactory, so I agreed.
On 4 January I made a new draft available; it had the new name
``Identity Server'' and addressed various security concerns. There was
no further discussion. I waited for Galvin to live up to his statement
``we will push it on to the "standards track" as expeditiously as
possible.''
8. Chronology V: Delay Period 3 (4 January to 8 March)
There was no discussion after my 4 January draft. On 15 January, six
months after the submission, I sent Crocker, Galvin, Jeff Schiller, and
StJohns a message. I pointed out that I had addressed the issues raised.
I reminded them of Galvin's 2 January promise. Galvin immediately wrote
back and promised a response within a week.
On 22 January Galvin wrote back saying two things. ``First, the
reviewers have not reached consensus on how to respond to the review.
Until we do there is nothing that can be said at this time.'' Second, he
told me about the existence of Internet-Drafts and recommended that I
submit my document as an I-D. On 25 January I wrote back complaining
about the delay and the lack of feedback. But there was nothing I could
do: the ball was in ``the reviewers'' court and the reviewers weren't
telling me anything.
I wrote to Galvin on 6 February. ``You have stretched my patience beyond
its limits. Are there any remaining problems with my RFC 931 revision?
If so, then for the last month you've been concealing them from me. Is
my RFC 931 revision going to be published, NOW? If not, then you are
censoring a supposedly open document series. Is my RFC 931 revision
going to be published as a proposed standard protocol, to become a
recommended standard by December if there is no objection from the
community? If not, then the IETF is costing thousands of system
administrators many thousands of hours of time and effort tracking
system crackers. Is my RFC 931 revision going to be published as is,
with none of the insane editing that marred RFC 1143? If not, then the
IETF is violating copyright.''
I asked for a quick response. I quoted the section of RFC 1200 where the
IAB ``strongly recommends'' that people use its standards process ``to
maximize interoperability.'' I implied that this was a lie: ``When push
comes to shove, the IAB doesn't want to even begin standardizing a
protocol which isn't its own pet project---even if hundreds of sites
around the Internet are using that protocol.''
I hoped that if I reminded Galvin of the IAB's promises to the community
then he would wake up and start acting in accordance with those
promises. I received no response. Around this time I found Vint Cerf's
December draft of what is now RFC 1310. I was pleased to see that the
draft made quite a few statements about the IAB standards process which
were in line with how I thought the process should work.
So on 9 February I sent an informal complaint to Vint Cerf about SAAG's
handling of TAP. I emphasized how, according to his draft of RFC 1310,
TAP was in perfect shape to become a Proposed Standard. Cerf
acknowledged receipt of my message but didn't respond. I complained to
him again on 2 March. I didn't receive any other messages from the IAB
or its suborganizations in the meantime---except for a private e-mail
exchange with Steve Kent in mid-February which confirmed my beliefs
about why the SAAG was censoring TAP. (In the exchange Kent admitted
that his comments were out of date; he didn't raise any specific
objections to my document; and he didn't come through on any of the
IAB's promises. He did imply that he considers himself an ``important
individual'' [his words] in the standardization process.)
Summary of the three two-month delay periods: For a total of six months
out of eight, people acknowledged my messages, promised responses, even
admitted that the ball was in their court, but didn't tell me anything
and didn't live up to their explicit promises---let alone the promises
in RFC 1200 and RFC 1310. During this time the IAB accomplished nothing.
9. Chronology VI: post-Cerf summary
On 8 March Vint Cerf finally responded to my complaints. ``It would be a
loss if you gave up at this point since I had thought progress was being
made at last.'' (Huh? It had been two months since Galvin had promised
to move TAP along the standards track. Absolutely no progress was made,
and Galvin didn't come through.) ``The impression I have is that the
fundamental questions revolve around how to characterize the services of
the protocol proposed. In particular, the degree to which one could or
should trust the results from any particular host that responds.''
(Absolutely. No disagreement here.)
Although Cerf wasn't formally running the IAB at that point, it was
amazing how quickly things moved once he got involved. Days after Cerf
``thought progress was being made at last'' Mike StJohns sent out an
extensive revision of the TAP spec, claiming that his rewrite reflected
SAAG's concerns (which had been kept completely hidden since 4 January).
After this things got very complicated, and I won't try to give a
complete play-by-play account of what's happened between then and now.
The following sections have just a few highlights.
10. Historical summary: the pure TAP spec
On 12 March it struck me that there had been essentially no disagreement
on the technical aspects of TAP. So, I thought, why not split the
document into two pieces: a pure TAP protocol description, and a
discussion of security and applications?
The next day I distributed the pure (``wimpy'') TAP spec. I stated my
high hopes that the pure spec would be acceptable to SAAG---after all,
it didn't make any claims about security and didn't talk about any
applications. It just defined the protocol. The new security section
said essentially ``This document makes absolutely no guarantees about
security.''
Beyond minor wording changes and a couple of extra technical notes that
spec hasn't changed. Several people (including Vint Cerf) have stated
their comfort with the document. The only technical objection raised is
that the (ridiculously simple) grammar is expressed verbally rather than
with a BNF; I've stated that I'd be glad to include a BNF if someone
wants to do the work of writing one, but apparently nobody's seen a real
need to do this.
It is this spec which was the subject of my 18 April request to the
IESG. (You can get the most recent published revision as
draft-bernstein-tap-00.txt from any I-D directory.) As noted in
section 2, Gross informed me in mid-May that the IESG had just rejected
my request, primarily because TAP has the same function as Ident.
11. Historical summary: cutting me out of the process
As you will recall, there was my draft from 4 January, then StJohns's
11 March rewrite with a radically different security section, then my
13 March pure revision with the security section removed entirely.
On 16 March Steve Crocker sent me a message: ``You said in your note to
Vint that you want your latest revision to be considered an official
submission. I think we skipped a step. I saw Mike's draft and I saw
your response, but I didn't see any dialog indicating discussion and
reconciliation. It's not evident to me that your submission meets the
requirement for consensus.''
What a load of crap. First of all, except in the security section,
StJohns's draft was essentially the same as mine; and the whole point of
my rewrite was that we should split off the security section into a
separate document. So what exactly was there the lack of consensus on?
The only person who's refused to admit that splitting off the security
section is a good idea is Ted Ts'o, who also refuses to admit that TAP
has a constituency or that Kerberos is less than 100% secure. (Will the
sun rise tomorrow, Ts'o?) Given that StJohns's changes were in sections
that no longer appeared in the document, what was there to discuss?
Second, every accusation that I had ``skipped a step'' can be thrown
back at StJohns. To imitate Crocker: ``I saw my January draft and I
saw Mike's extensive rewrite, but I didn't see any dialog indicating
discussion and reconciliation.'' It is StJohns who didn't check his
rewrite with anybody, who didn't have any history of agreement on his
document. Why can IAB flunkies make any changes they want without
checking with the community, then accuse *me* of not seeking out
consensus?
To make a long story short, by 18 March Steve Crocker had announced that
Mike StJohns was now running ``the effort.'' He excused this exercise of
dictatorship---which he didn't even check with SAAG---by saying ``It has
become evident that these discussions are not converging.''
I leave it to you, my readers, to evaluate the truth of Crocker's
statement. The technical discussions which weren't converging were the
security discussions---and it wasn't my fault that, after January 4,
nobody in SAAG could find a single thing to complain about in my draft.
At this time the discussions still haven't converged; Mike StJohns has
adopted the policy of ignoring them entirely, on the grounds that I am
supposedly the only one disagreeing with SAAG. Other people have
explicitly stated the same disagreements but StJohns still has the same
policy.
Anyone involved in those first eight months of TAPgate knew that the
security section was the only thing holding TAP back. Nearly every
message dealing with technical aspects of TAP was on security issues.
My solution was to let the TAP protocol specification proceed by
admitting that we didn't know what to say about security. Crocker's
``solution'' was to cut me out of the process---and use StJohns's
security section, which certainly isn't anywhere near consensus.
On 18 April, immediately after my second formal request to the IESG
(actually, right after I denied Crocker's right to exercise his personal
authority and reject the request, since it was directed at Phill Gross),
Crocker removed me from the SAAG mailing list. I hadn't sent any
messages to the SAAG list in a while; outside the TAP efforts I had
contributed an idea (which I think was accepted) to a mail-checking
protocol and hadn't said much else on the list. Yet Crocker came up with
a lie and threw me off the list. (``Open processes depend on the good
will of the participants. There is a line between pursuit of honest
differences of opinion and determination to interfere with the work of
the group. In my opinion, your efforts are not constructive, and I have
removed you from the SAAG mailing list.'')
I requested to be put back on. I had thought that the SAAG was an open
list---an official IETF list, in fact. But Crocker refused. It turned
out that Galvin, who had added me to the list originally, works for
Crocker. What excuse is there for such an exercise of personal control
over IAB business? Why do these people think they have the God-given
right to run the Internet any way they damn well please? I never
interfered with SAAG business, and I have five SAAG mailing list
recipients willing to swear to this in court, in case personal SAAG
archives aren't enough.
12. Historical summary: copyright issues
I had mentioned copyright on 6 February. RFC 1143 had been extensively
modified immediately before publication, in violation of copyright law;
I didn't want this to happen again. In March, after an attempt by a
certain IAB flunky to steal my writing, I pointed out once again the
automatic existence of copyright. On 29 March I offered to place my
document into the public domain; several times before that I offered to
transfer copyright to IAB the moment after my document was published.
13. Historical summary: tone issues
Cerf and Crocker complained about the ``tone'' of the first pure
revision of the TAP spec. I asked them repeatedly exactly what they were
talking about. They didn't say for over a week, though I did hazard a
guess which turned out to be correct. After they told me I removed the
statements in question. Why weren't they specific in the first place?
Kent and Ts'o have thrice stated that certain passages are not in
conformance with ``RFC style.'' I---and others---have asked what this
style is and where it's documented, as well as for examples of the
style, as well as for some explanation of how the passages would have to
be changed so that they have the proper style. Neither Kent nor Ts'o has
elaborated---yet they continue to claim that various passages are
inconsistent with ``RFC style.''
14. Historical summary: mailing list issues
I created the rfc931-users mailing list in November, chartered to serve
the users of the protocol. (I now regret my mistake in not choosing the
name TAP last year and creating a tap-users list.) During March Crocker
and others sent messages to the list which, in my judgment and in the
judgment of various readers of the list, were not appropriate for the
list. I repeatedly told Crocker to stop abusing the list.
Crocker stated in mid-March that rfc931-users was the ``official mailing
list'' for ``this effort.'' Yet he didn't explain how the effort had
suddenly become official, or how it had suddenly acquired a mailing
list---in particular, a mailing list with an entirely different charter.
I thought that official IAB actions were announced on the IETF list. He
also stated for the first time that he ``required'' a mailing list ``for
every effort.'' He had never brought up this requirement before.
15. Historical summary: cutting TAP out of the process
By late March, in response to my complaints about the abuse of the
rfc931-users list, Crocker had created an official list: ident. For a
few days after that people on both sides of the issues were happily
discussing the TAP spec. I kept a public list of open issues; a few
minor issues were raised and a few were resolved. (The character set
issue, for example, was brought up for the first time.) I estimate that,
with a week more of work, we would have had a perfectly satisfactory
spec which nobody would have objected to.
Then the floor fell out. On 29 March Mike StJohns sent a message to the
rfc931-users and ident lists. ``The "ident" protocol - where we are and
where we're going... Attached at the end of this note is a redraft of
rfc931, hopefully reflecting the current implementation state of the
protocol. This draft with subsequent changes if any is what will be
moved onto the standards track... Mr Bernsteins draft has been removed
from consideration for cause - primarily due to his threats to assert
copyright. His draft will not be considered further as a contribution to
the standards process... we had come to an impasse with Dan and this
looks like the only way to get the effort moving.'' (This, after six
months of inexcusable delay on Crocker's part.)
Again, I leave it to you, my readers, to judge StJohns's actions. I
recently ran a survey of the ident list: apparently StJohns didn't check
with *anybody* in the group before cutting TAP out.
After StJohns' exercise of dictatorship the Ident group was created as a
formal IETF WG, chartered to ``define a protocol'' to transmit certain
information. It's been going for nearly three months now. There's still
a security section, and there are still huge open issues surrounding
that section. StJohns recently took it upon himself to invent extensions
to the protocol, as usual without checking with anybody. (According to
his much more complex, and implementation-free, protocol definition,
UNIX usernames are limited to 8 characters. What a surprise for users of
UNIX systems allowing longer usernames. Why would someone add this sort
of idiotic limitation to a protocol, if not in an attempt to damage the
protocol irreparably?)
16. Standards process issue: perversion of requests
On 15 July 1991 I requested that the IAB move a protocol along the
standards track. As indicated above, the request was (apparently)
refused in March by Steve Crocker, though this refusal was not announced
for review by the IETF community, in clear violation of RFC 1310.
Anyway, Crocker sent me at least two messages along these lines: ``You
asked that we move this protocol forward. We are doing that, via the
Ident effort. What are you complaining about?'' He tried to act
similarly in response to my April 18 request, though he had no right to
do so, as my request was directed at the IETF Chairman.
It's easy to answer Crocker's question. Many of TAP's users believe that
the current Ident draft (1) does not reflect current practice; (2) has
not achieved consensus, or even come close; (3) is far too complex; (4)
has some unacceptable restrictions in the security section; (5) contains
false and misleading information. If it weren't for these flaws we
probably wouldn't be complaining.
But the larger issue is that Crocker has perverted my requests into
something other than what they are. When I ask, following RFC 1310, that
something be moved along the standards track, I expect my request to be
evaluated the way RFC 1310 says it should be, and either accepted or
denied on that basis. I'm not asking that some vague ``effort'' be set
up to standardize a roughly similar protocol, or even the same protocol;
I'm asking that this protocol spec be standardized right now. It is a
perversion of the request to interpret it as something other than what
it is.
I believe that RFC 1310 should explicitly deny the IESG the right to
pervert requests. If the IESG wants to say ``We deny your request, on
the basis of the following criteria in RFC 1310: ... By the way, you
might want to set up a working group to try to put together a better
protocol definition,'' then that's fine. But the IESG should not have
the right to wilfully misinterpret requests in pursuit of its own goals.
If it has no reason to refuse a request then it must accept the request.
In the meantime we should all recognize that Crocker's actions were not
sanctioned by RFC 1310.
17. Standards process issue: copyright
The copyright issue is, from a factual point of view, a non-issue in
this case. I've offered to put my document into the public domain. We
should all recognize that Crocker and StJohns are lying when they claim
anything like ``There are unacceptable copyright restrictions on this
document.''
But there's a larger issue here. RFC 1310 does not list copyright
transfer as a condition for standards to be published. In fact, it
doesn't mention it even as something to be considered. After all, the
IAB has never required copyright transfer before, and under the Berne
convention (which is now U.S. law) there are some hundreds of RFCs which
are automatically copyrighted. So how can the IESG make decisons on the
basis of copyright? RFC 1310 simply does not condone the way that TAP
was removed from consideration.
I'm happy to see that copyright is now listed as an issue to be dealt
with in future RFC 1310 revisions. Certainly, although Crocker and
StJohns were overstepping their authority, there was a grain of reason
behind their incompetent handling of the copyright issue: the IAB can't
be expected to publish standards for the community if the community
doesn't have the right to revise the standard later. Perhaps the IAB
should require that every RFC be placed into the public domain the
moment it's published. The IAB can protect the sanctity of its document
series by trademarking the name ``RFC.''
18. Standards process issue: IETF notice
This deserves repetition: The IESG has, twice, violated RFC 1310's
explicit requirement that its decisions be announced for review by the
entire IETF. I believe that the IESG's failure demands further
requirements. The IESG should be required to summarize each and every
request it receives, immediately, for the IETF's information. We as a
community cannot permit the IESG to escape public review. TAP was
handled incompetently, including more than half a year of inexcusable
delay; why did the IESG try to keep its actions secret?
19. Standards process issue: the job of the IESG
Let's review the RFC 1310 quote on the IESG's job. ``The IESG shall
determine whether a specification satisfies the applicable criteria for
the recommended action (see Sections 3.2 and 3.3 of this document) and
shall communicate its findings to the IETF to permit a final review by
the general Internet community.''
Notice that the IESG is commissioned quite explicitly to decide whether
the request at hand satisfies certain criteria. The criteria in sections
3.2 and 3.3 are quite specific and quite short. They simply say what a
Proposed Standard is, what a Draft Standard is, and so on.
The IESG does *NOT* have the job of deciding between two competing
protocols: if both protocols fit the criteria in RFC 1310 sections 3.2
and 3.3 then both *MUST* be recommeded by the IESG. But I have Gross
recorded as saying that the IESG refused my 18 April request exactly
because, in the IESG's opinion, TAP would compete with Ident.
The IESG does *NOT* have the job of deciding things on the basis of its
hidden thoughts about what's good for the community. But that's exactly
what Steve Kent and Ted Ts'o say it should be doing: they say, for
example, that TAP should not be standardized because it does not have
security as strong as cryptographic protocols.
RFC 1310 does *NOT* sanction the IESG considering *ANY* criteria other
than those listed. But Crocker's refusal of my July 15, 1991 request was
explicitly based on such issues as copyright. And Gross stated that
``duplication of effort'' was the primary reason for the IESG's refusal
of my 18 April request. Even worse, Kent has implied that, even if the
IESG recommends that TAP become a Proposed Standard, he personally will
reject the TAP spec because of its ``style.''
I don't have any suggestions for how RFC 1310 should be modified to
handle these problems. The IESG has violated RFC 1310's rules so
blatantly that I see no recourse other than direct appeal to the
community.
20. Factual notes
The current TAP specification is stable and well-understood: about 85%
of it is word-for-word the same as a draft which has been available
since last June, and the rest is formality; also, the protocol which it
describes has not changed since February 1990. The spec and protocol are
technically competent: to put it simply, they *work*, and the spec says
exactly what's necessary to guarantee future interoperability. There are
multiple independent interoperable implementations with considerable
operational experience: for example, my authd, Peter Eriksson's pauthd,
and the popular wuarchive ftpd. The spec and protocol enjoy some public
support: I have published a list of literally hundreds of IP addresses
running the server, and I have statements from nine people asking the
IAB to get the spec published as an RFC. TAP is not only recognizably
useful in some parts of the Internet; it's being *used*---the statistics
for the NSFNET T1 backbone show many tens of thousands of TCP port 113
packets per month.
21. Is TAP appropriate for the standards track?
RFC 1310 states: ``In general, an Internet Standard is a specification
that is stable and well-understood, is technically competent, has
multiple, independent, and interoperable implementations with
operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet.''
So, given the facts noted in the last section, the TAP spec seems to
satisfy the characterization of Internet Standards in RFC 1310.
Certainly one could argue that ``only'' a couple hundred sites doesn't
constitute ``significant public support,'' or that the spec isn't
perfectly stable. But then again, I'm not asking that TAP become a
Standard yet---all I've been asking since last July is that this be
published as a Proposed Standard. RFC 1310 imposes nearly another year
delay before a Proposed Standard can advance through Draft Standard to
Standard; that'll be more than enough time for the public support and
stability and so on to become obvious.
22. Does TAP embody the goals of the standards process?
RFC 1310 identifies four goals of the procedures of the standards
process: high quality, prior implementation and testing, openness and
fairness, and timeliness. The first two goals were met in this case by
people working outside the IAB---but the goals of openness and fairness
and timeliness can be met only by the IAB. In this case the IAB fell
flat. Steve Crocker claimed in March that he requires a mailing list for
``every'' effort: so what was he doing between July and March with the
TAP effort? Delay Periods 1, 2, and 3 add up to six whole months during
which Crocker did nothing.
23. Does TAP need a working group?
RFC 1310 states: ``In most cases, a specification resulting from an
effort that took place outside of an IETF Working Group context will be
submitted to an appropriate Working Group for evaluation and refinement;
if necessary, an appropriate Working Group will be created.'' This isn't
always applicable, and I don't think there's any need for a TAP group;
but I still suggested this as an option in my 18 April request. The IESG
didn't take this option.
Remember the request perversion issue. If the IESG does create a working
group for TAP then it had better be in conformance with RFC 1310---it
had better be a group to ``evaluate and refine'' the TAP spec. Another
group like Ident, chartered to ``define a protocol,'' simply doesn't cut
it. Ident does not satisfy the IESG's obligations towards TAP.
24. Does TAP satisfy RFC 1310's criteria for being a Proposed Standard?
The IESG's job was to answer the question of this section's title. It
didn't live up to its duties so I'll address the question. RFC 1310
states: ``The entry-level maturity for the standards track is "Proposed
Standard". A Proposed Standard specification is generally stable, has
resolved known design choices, is believed to be well-understood, has
received significant community review, and appears to enjoy enough
community interest to be considered valuable.'' It also states one extra
criterion: ``A Proposed Standard should have no known technical
omissions with respect to the requirements placed upon it.''
The TAP spec---and the protocol it documents---are, as noted above,
quite stable and well-understood, and enjoy more than enough community
interest to be considered valuable. It has received far more community
review than the vast majority of IAB standards efforts, by virtue of
having been incorporated into a number of widely distributed programs.
I resolved all design choices a year ago, and the protocol I defined
then has not been shown to have any technical problems. (I don't claim
that every decision I've made is necessarily optimal, though on the
basis of the last year of protocol development and discussion I do
believe I made good decisions; I claim only that the choices have been
resolved. That's the criterion listed in RFC 1310.) As for technical
omissions, the TAP spec omits nothing. It contains all features
necessary to satisfy the requirements placed on it by its users. (And
there are no requirements placed on this protocol from the outside; it's
not as if TAP was designed to fill the IAB's stated need for a protocol
to do anything in particular. It just transmits uninterpreted octet
strings from one host to another.)
So TAP meets every single criterion in RFC 1310 for being published as a
Proposed Standard. I see no excuse for the IESG to have failed to accept
it---if, that is, the IESG had actually considered the criteria it was
supposed to consider, rather than shirking its duties in violation of
RFC 1310.
RFC 1310 goes further. ``Usually, neither implementation nor operational
experience is required for the designation of a specification as a
Proposed Standard. However, such experience is highly desirable, and
will usually represent a strong argument in favor of a Proposed Standard
designation.''
So not only does TAP meet the criteria for being a Proposed Standard. It
also has both an implementation and operational experience. So if the
IESG had any doubts about TAP, it should have been swayed by the
strong argument that TAP is a protocol *in use*! In fact, TAP has
*multiple* interoperable implementations---more implementations than
most existing Proposed Standards. How strong does this argument have to
be before the IESG gives in?
Note that the TAP spec is, at this point, solely a Technical
Specification, with only a very broad statement of its domain of
applicability. It does not include an Applicability Statement. So it
gets only a maturity level like ``Proposed Standard,'' not a requirement
level like ``Recommended.'' I didn't realize this until I read RFC 1310.
25. What now?
TAP is fully ready to be published as a Proposed Standard. The current
draft is technically sound; now that the security discussions have been
replaced by a disclaimer, there's little if any argument over the
document. Yet---for almost twelve whole months---SAAG and IESG have
refused to let TAP proceed through the standards process.
Permit me to speculate a bit. I think I know why Crocker, Kent, et al.
don't like TAP. They have a shining vision of global cryptographic
authentication. If we had that sort of security on the Internet then
nobody would find TAP useful. But exactly the opposite is true: TAP is
the best in its class right now, and hundreds of people are using it.
Crocker et al. don't like being reminded that their vision is little
more than a far-off dream. If they let TAP be standardized then they'd
be admitting to the whole Internet community that it'll be years before
their vision becomes reality.
Unfortunately for them they weren't able to find any good reason to hold
TAP back. So they started acting unfairly. Let's review the examples
documented above, in roughly increasing order of unfairness:
(A) During a total of six months---Delay Periods 1, 2, and 3---Crocker
and friends did nothing in public and said nothing.
(B) Crocker cut me out of the process, with the excuses that I was
supposedly ignoring a document (which had appeared less than a week
before), and that the discussions weren't converging (as if that were my
fault).
(C) StJohns has adopted the policy of ignoring my objections to the
security section of his document, with the excuse that I am supposedly
the only one raising objections (although other people have supported my
position).
(D) Crocker suddenly declared in March that the rfc931-users list was an
``official mailing list'' for ``this effort''; what a surprise for the
readers of the list. How can something be ``official'' if it hasn't even
been announced on the IETF list?
(E) Crocker claimed in March that he ``required'' a mailing list ``for
every effort''; he had never brought up this requirement in the eight
months before that.
(F) StJohns threw the TAP spec out of consideration at the end of March,
despite the fact that people on both sides of the issues were discussing
it at the time. His excuse was copyright.
(G) The Ident group, which was supposedly created in response to my
request from eight months before, was not chartered to handle that
request.
(H) According to Phill Gross, Crocker refused my 15 July 1991 request
sometime in March. He didn't announce this on the IETF list for
community review.
(I) The IESG refused my 18 April 1992 request in May. They did not
announce this on the IETF list for community review.
(J) The IESG decided between two competing protocols (and then decided
in favor of the vapor protocol).
(K) Crocker's refusal of my July 1991 request was based on such issues
as copyright, not on any technical issues. (And it was a personal
refusal, not one espoused by the relevant working groups.)
(L) The IESG's refusal of my April 1992 request was based primarily on
the issue of ``duplication of effort.''
Scary list, isn't it? To support these unfair actions they engaged in
lies, some of which are documented above (examples: ``we can set up a
dialog'' [Crocker], ``we will push it on to the "standards track" as
expeditiously as possible'' [Galvin, speaking for SAAG], the response
``within a week'' in January [Galvin], ``your efforts are not
constructive'' [Crocker]), and petty exercises of personal power (e.g.,
throwing me off the SAAG list [Crocker]). But words don't hurt; what
hurts is that the IESG has, for a year, censored a perfectly good
protocol, and caused documented cases of interoperability problems and
loss of time and money.
Fortunately I have two weapons to combat the unfair actions of the IESG.
My first weapon is RFC 1310, the IAB's official documentation of its
standards process. With RFC 1310 I can stop shouting ``unfair'' and
start shouting ``fraud.'' RFC 1310 describes exactly what the IESG
*should* have done in response to my requests, and what criteria the
IESG should have considered. By those criteria TAP passes with flying
colors---it's got a larger constituency, more public review, better
consensus, better technical development than the vast majority of
existing Proposed Standards, and multiple interoperable implementations
to boot. Although it's tricky to use e-mail as evidence, I'm seriously
considering suing the IAB for fraud on the basis of the IESG's flagrant
violations of RFC 1310.
My second weapon, my much more powerful weapon, is the will of the
community. Some of you out there must be shaking your heads in
disbelief, saying ``I never thought the IESG would betray the community
in this way!'' We all lose when the IESG doesn't follow its own rules,
ignores its own criteria, and then tries to hide its mistakes from the
community---especially when the result is outright censorship of a
protocol which *needs* to be documented in the standard series to
prevent interoperability problems.
I beg you, my reader: Say what you think. You don't have to trust my
summaries: the transcripts of TAPgate are a matter of public record. You
can do an incredible amount of good by raising your voice in outrage at
the IESG's attempt to wrest control of the standards series away from
the community. Pass around copies of this message, tell other people to
read it, send your opinions or suggestions to the tcp-ip or ietf lists,
talk about TAPgate at IETF meetings, tell me what you think (and please
say if you wouldn't mind my quoting you---every bit helps). Pick up the
TAP spec (draft-bernstein-tap-00.txt) and read it. FTP some of the
implementation work (thanks to Peter Eriksson) from ftp.lysator.liu.se.
And remember that this is a long message: just because you've made it
through doesn't mean other people will, even though they might be very
interested. Summarize, quote, complain. (Also make sure that Crocker
can't get away with denying what happened---please publicize any
relevant behind-the-scenes claims by summarizing them on the IETF list.)
It is time to force the IESG back into the position of serving the
Internet community rather than secretly directing its future. RFC 1310
makes clear that the Internet Engineering Steering Group must always
check its actions with the community, and derives its power from the
will of the community. *We* have final say. We can start by giving TAP
the fair and open treatment it deserves. I wish we hadn't lost a year---
we'll still have to wait another year for TAP to advance from Proposed
Standard to Standard. But maybe it'll be worth it if we make sure that
these abuses don't happen again.
---Dan Bernstein, brnstnd at nyu.edu, 26 June 1992
(These are personal opinions. I have no official affiliation with NYU.)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10255;
27 Jun 92 1:58 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15297; 27 Jun 92 1:59 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA29819>; Fri, 26 Jun 1992 14:07:53 -0700
Received: from KRAMDEN.ACF.NYU.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA29799>; Fri, 26 Jun 1992 14:07:40 -0700
Received: from LOCALHOST by KRAMDEN.ACF.NYU.EDU (5.61/1.34)
id AA29513; Fri, 26 Jun 92 21:06:12 GMT
Message-Id: <9206262106.AA29513 at KRAMDEN.ACF.NYU.EDU>
To: ietf at isi.edu
Cc: brnstnd at nyu.edu
Subject: informal notice of two IESG decisions
Date: Fri, 26 Jun 92 17:06:06 +0100
From: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>
This message has 25 sections, each quite short but together a lot to
take in. Sorry for the length. Why so much? Because I'm exposing a
year-long pattern of corruption within the IESG. I now have a large
collection of electronic, verbal, and written evidence that the IESG has
blatantly violated several requirements in RFC 1310. These abuses are
documented below. (Skip to pattern ^25 for the quick summary.)
1. Reason for the informal notice
RFC 1310 states that anyone can submit a standardization proposal to the
IETF Chairman or an appropriate IETF Area Director, who in turn lets the
IESG review the proposal. RFC 1310 outlines a few procedures for dealing
with tricky proposals---for example, commissioning a special review
committee, or creating a working group for ``evaluation and refinement''
of the protocol spec. It then says: ``The IESG shall determine whether a
specification satisfies the applicable criteria for the recommended
action (see Sections 3.2 and 3.3 of this document) and shall communicate
its findings to the IETF to permit a final review by the general Internet
community.'' RFC 1310 goes on to say that the notification is by email
to the IETF list.
2. The informal notice
On 15 July 1991 I submitted a protocol specification to Steve Crocker,
requesting that it be published as a Proposed Standard RFC. At the time
the protocol in question, which came into existence in early 1990 and
was derived from a much older protocol, did not have a distinguishing
name; I have recently begun calling the protocol ``TAP.'' (This, like
``TELNET,'' is a capitalized name, not an abbreviation for some official
name.) Anyway, Crocker is the IETF Security Area Director. Phill Gross,
the IETF Chairman, informed me in May that Crocker had rejected my
request in March.
On 18 April 1992 I requested of Gross that a newer, pruned-down TAP
specification be published as a Proposed Standard RFC (or at least that
a working group be created to discuss it). Gross informed me in mid-May
that the IESG had just rejected my request, primarily because TAP has
the same function as a still-not-yet-defined protocol named Ident,
currently stuck in the Ident WG. (It is worth noting that the Ident WG
chairman, Mike StJohns, has refused to allow discussion of TAP on the
Ident list, although he does not deny that TAP is within the Ident
charter.)
3. Comments about the notice
According to RFC 1310, the IESG was required to notify the IETF mailing
list of the two decisions listed above, to permit community review. It
appears that the IESG failed to do so, hence violating both the letter
and the spirit of this rule. If in fact the IESG sent out timely
notifications which I missed, I'm sorry; I asked the IESG recently
whether such notifications had been sent, and I received no response.
The remainder of this message gives you further information about the
protocol in question and its history within the IAB. Everything I say
here (except, in some cases, my comments about what I was thinking at a
given time) can be verified from the transcripts of my dealings with the
IAB, which I plan to publish in SIGCOMM CCR, or from other objectively
verifiable sources. You will be forced to wonder, as you read through
these progressively more and more damning pieces of evidence, whether
the IESG is attempting to take control of the IAB standards series away
from the community. Why else would it keep its decisions secret, and
violate RFC 1310 in the many other ways documented below?
4. Chronology I: early history
TAP came into existence in February 1990. I took the dead protocol
documented in RFC 931 and implemented a variant of it. I distributed the
result in my ``auth'' package, which never really caught on. A year
later I distributed ``authd,'' a new TAP implementation which did catch
on because of various technical features. authd serves TCP port 113; in
effect it announces ``username shmoe connected from this host's TCP port
12345 to host H's TCP port 7654'' to anyone on host H who asks about
those port numbers. (It can be used for things other than usernames,
though, just as finger can be used to transmit weather information.)
Three client TAP implementations (for BSD talk, NNTP, and SMTP) were
distributed in early 1991. I began to worry about ways to guarantee
future interoperability. In June I documented the TAP protocol, along
with the existing applications and some suggested applications, in RFC
format. I also commented extensively on the exact security added by TAP.
On 15 July, as noted above, I submitted the document to Crocker for
publication as a Proposed Standard RFC.
5. Chronology II: Delay Period 1 (15 July to 14 September)
After my submission I was told nothing for two months. I sent Crocker a
list of some sites running TAP. Then Crocker wrote back: ``Naw, two
months is not unreasonable. The time has been used for coordination...
There is moderate agreement that this should indeed go on the standards
track. However, the wording about the relationship to security needs to
be changed. It's one thing for hosts to supply information about the
user associated with a particular connection, but it's another matter to
assert that this information supplied is particularly trustworthy or
strongly related to security. You get first crack at fixing up the
document. If you need clarification of the issues, we can set up a
dialog.'' That was 14 September.
Nowhere in the security section did I assert that the information
supplied was in particularly trustworthy or strongly related to
security, and I did not understand what changes Crocker wanted me to
make, or who the ``we'' was. I told Crocker so on 15 September. I asked
exactly what wording he considered inaccurate, misleading, or
incomplete, and said: ``Since I don't understand which statements you're
objecting to, I guess I need clarification. Dialogue with whom?'' (As I
learned later, ``we'' meant some subset of the SAAG group.)
6. Chronology III: Delay Period 2 (15 September to 20 November)
Crocker did not respond to my request for further information, and
didn't come through on ``we can set up a dialog.'' I sent messages to
him on 3 October and 19 October attempting to elicit a response. He
didn't respond until 20 November, more than four months after my
submission. In those four months, the ball was in Crocker's court every
day except 14 September.
In the meantime the world continued to turn. Peter Eriksson wrote a new
implementation; unfortunately there was an interoperability problem. I
heard about the problem from Simon Leunen. By 4 November, Peter had
fixed the problem and read through the TAP specification. The
specification would not have permitted the problem if it had been
available to Peter. In mid-November I created the rfc931-users list
``for people who want to use RFC 931 to solve problems.'' The list
quickly swelled past 100 subscribers, and Peter's ``pauthd'' continued
to grow in popularity.
7. Chronology IV: technical discussion
On 20 November Crocker finally gave me some indication of what he (and
apparently some SAAG members) didn't like about the document. I
responded with a list of ten issues, on most of which we seemed to
agree. Crocker responded on 22 November: ``I think we're in basic
agreement, modulo detailed discussion over what words are in the RFC
regarding security and the name of the protocol.'' (He had mentioned
that the current name---``Authentication Server,'' just like RFC 931---
was, in the eyes of the SAAG, inappropriate; this was one of the issues
I listed.)
At the end of November I sent some initial messages to the rfc931-users
list. Discussion ensued on the security section of my document. This
discussion continued, in various threads on rfc931-users and the SAAG
list, through the beginning of January. During that time I produced
several revisions of my document in response to SAAG criticism.
On 2 January Jim Galvin of SAAG sent me a message, reminding me of the
name-change issue raised in late November. ``It is the opinion of those
SAAG members who have been carefully tracking this effort that the
protocol should be renamed as the "Identity Server" (or something
similar)... If you agree you will need to revise your document
accordingly, after which we will push it on to the "standards track" as
expeditiously as possible.''
I asked rfc931-users whether the name change would be okay, and how we'd
deal with the problems of changing the name of an established protocol.
The answers were satisfactory, so I agreed.
On 4 January I made a new draft available; it had the new name
``Identity Server'' and addressed various security concerns. There was
no further discussion. I waited for Galvin to live up to his statement
``we will push it on to the "standards track" as expeditiously as
possible.''
8. Chronology V: Delay Period 3 (4 January to 8 March)
There was no discussion after my 4 January draft. On 15 January, six
months after the submission, I sent Crocker, Galvin, Jeff Schiller, and
StJohns a message. I pointed out that I had addressed the issues raised.
I reminded them of Galvin's 2 January promise. Galvin immediately wrote
back and promised a response within a week.
On 22 January Galvin wrote back saying two things. ``First, the
reviewers have not reached consensus on how to respond to the review.
Until we do there is nothing that can be said at this time.'' Second, he
told me about the existence of Internet-Drafts and recommended that I
submit my document as an I-D. On 25 January I wrote back complaining
about the delay and the lack of feedback. But there was nothing I could
do: the ball was in ``the reviewers'' court and the reviewers weren't
telling me anything.
I wrote to Galvin on 6 February. ``You have stretched my patience beyond
its limits. Are there any remaining problems with my RFC 931 revision?
If so, then for the last month you've been concealing them from me. Is
my RFC 931 revision going to be published, NOW? If not, then you are
censoring a supposedly open document series. Is my RFC 931 revision
going to be published as a proposed standard protocol, to become a
recommended standard by December if there is no objection from the
community? If not, then the IETF is costing thousands of system
administrators many thousands of hours of time and effort tracking
system crackers. Is my RFC 931 revision going to be published as is,
with none of the insane editing that marred RFC 1143? If not, then the
IETF is violating copyright.''
I asked for a quick response. I quoted the section of RFC 1200 where the
IAB ``strongly recommends'' that people use its standards process ``to
maximize interoperability.'' I implied that this was a lie: ``When push
comes to shove, the IAB doesn't want to even begin standardizing a
protocol which isn't its own pet project---even if hundreds of sites
around the Internet are using that protocol.''
I hoped that if I reminded Galvin of the IAB's promises to the community
then he would wake up and start acting in accordance with those
promises. I received no response. Around this time I found Vint Cerf's
December draft of what is now RFC 1310. I was pleased to see that the
draft made quite a few statements about the IAB standards process which
were in line with how I thought the process should work.
So on 9 February I sent an informal complaint to Vint Cerf about SAAG's
handling of TAP. I emphasized how, according to his draft of RFC 1310,
TAP was in perfect shape to become a Proposed Standard. Cerf
acknowledged receipt of my message but didn't respond. I complained to
him again on 2 March. I didn't receive any other messages from the IAB
or its suborganizations in the meantime---except for a private e-mail
exchange with Steve Kent in mid-February which confirmed my beliefs
about why the SAAG was censoring TAP. (In the exchange Kent admitted
that his comments were out of date; he didn't raise any specific
objections to my document; and he didn't come through on any of the
IAB's promises. He did imply that he considers himself an ``important
individual'' [his words] in the standardization process.)
Summary of the three two-month delay periods: For a total of six months
out of eight, people acknowledged my messages, promised responses, even
admitted that the ball was in their court, but didn't tell me anything
and didn't live up to their explicit promises---let alone the promises
in RFC 1200 and RFC 1310. During this time the IAB accomplished nothing.
9. Chronology VI: post-Cerf summary
On 8 March Vint Cerf finally responded to my complaints. ``It would be a
loss if you gave up at this point since I had thought progress was being
made at last.'' (Huh? It had been two months since Galvin had promised
to move TAP along the standards track. Absolutely no progress was made,
and Galvin didn't come through.) ``The impression I have is that the
fundamental questions revolve around how to characterize the services of
the protocol proposed. In particular, the degree to which one could or
should trust the results from any particular host that responds.''
(Absolutely. No disagreement here.)
Although Cerf wasn't formally running the IAB at that point, it was
amazing how quickly things moved once he got involved. Days after Cerf
``thought progress was being made at last'' Mike StJohns sent out an
extensive revision of the TAP spec, claiming that his rewrite reflected
SAAG's concerns (which had been kept completely hidden since 4 January).
After this things got very complicated, and I won't try to give a
complete play-by-play account of what's happened between then and now.
The following sections have just a few highlights.
10. Historical summary: the pure TAP spec
On 12 March it struck me that there had been essentially no disagreement
on the technical aspects of TAP. So, I thought, why not split the
document into two pieces: a pure TAP protocol description, and a
discussion of security and applications?
The next day I distributed the pure (``wimpy'') TAP spec. I stated my
high hopes that the pure spec would be acceptable to SAAG---after all,
it didn't make any claims about security and didn't talk about any
applications. It just defined the protocol. The new security section
said essentially ``This document makes absolutely no guarantees about
security.''
Beyond minor wording changes and a couple of extra technical notes that
spec hasn't changed. Several people (including Vint Cerf) have stated
their comfort with the document. The only technical objection raised is
that the (ridiculously simple) grammar is expressed verbally rather than
with a BNF; I've stated that I'd be glad to include a BNF if someone
wants to do the work of writing one, but apparently nobody's seen a real
need to do this.
It is this spec which was the subject of my 18 April request to the
IESG. (You can get the most recent published revision as
draft-bernstein-tap-00.txt from any I-D directory.) As noted in
section 2, Gross informed me in mid-May that the IESG had just rejected
my request, primarily because TAP has the same function as Ident.
11. Historical summary: cutting me out of the process
As you will recall, there was my draft from 4 January, then StJohns's
11 March rewrite with a radically different security section, then my
13 March pure revision with the security section removed entirely.
On 16 March Steve Crocker sent me a message: ``You said in your note to
Vint that you want your latest revision to be considered an official
submission. I think we skipped a step. I saw Mike's draft and I saw
your response, but I didn't see any dialog indicating discussion and
reconciliation. It's not evident to me that your submission meets the
requirement for consensus.''
What a load of crap. First of all, except in the security section,
StJohns's draft was essentially the same as mine; and the whole point of
my rewrite was that we should split off the security section into a
separate document. So what exactly was there the lack of consensus on?
The only person who's refused to admit that splitting off the security
section is a good idea is Ted Ts'o, who also refuses to admit that TAP
has a constituency or that Kerberos is less than 100% secure. (Will the
sun rise tomorrow, Ts'o?) Given that StJohns's changes were in sections
that no longer appeared in the document, what was there to discuss?
Second, every accusation that I had ``skipped a step'' can be thrown
back at StJohns. To imitate Crocker: ``I saw my January draft and I
saw Mike's extensive rewrite, but I didn't see any dialog indicating
discussion and reconciliation.'' It is StJohns who didn't check his
rewrite with anybody, who didn't have any history of agreement on his
document. Why can IAB flunkies make any changes they want without
checking with the community, then accuse *me* of not seeking out
consensus?
To make a long story short, by 18 March Steve Crocker had announced that
Mike StJohns was now running ``the effort.'' He excused this exercise of
dictatorship---which he didn't even check with SAAG---by saying ``It has
become evident that these discussions are not converging.''
I leave it to you, my readers, to evaluate the truth of Crocker's
statement. The technical discussions which weren't converging were the
security discussions---and it wasn't my fault that, after January 4,
nobody in SAAG could find a single thing to complain about in my draft.
At this time the discussions still haven't converged; Mike StJohns has
adopted the policy of ignoring them entirely, on the grounds that I am
supposedly the only one disagreeing with SAAG. Other people have
explicitly stated the same disagreements but StJohns still has the same
policy.
Anyone involved in those first eight months of TAPgate knew that the
security section was the only thing holding TAP back. Nearly every
message dealing with technical aspects of TAP was on security issues.
My solution was to let the TAP protocol specification proceed by
admitting that we didn't know what to say about security. Crocker's
``solution'' was to cut me out of the process---and use StJohns's
security section, which certainly isn't anywhere near consensus.
On 18 April, immediately after my second formal request to the IESG
(actually, right after I denied Crocker's right to exercise his personal
authority and reject the request, since it was directed at Phill Gross),
Crocker removed me from the SAAG mailing list. I hadn't sent any
messages to the SAAG list in a while; outside the TAP efforts I had
contributed an idea (which I think was accepted) to a mail-checking
protocol and hadn't said much else on the list. Yet Crocker came up with
a lie and threw me off the list. (``Open processes depend on the good
will of the participants. There is a line between pursuit of honest
differences of opinion and determination to interfere with the work of
the group. In my opinion, your efforts are not constructive, and I have
removed you from the SAAG mailing list.'')
I requested to be put back on. I had thought that the SAAG was an open
list---an official IETF list, in fact. But Crocker refused. It turned
out that Galvin, who had added me to the list originally, works for
Crocker. What excuse is there for such an exercise of personal control
over IAB business? Why do these people think they have the God-given
right to run the Internet any way they damn well please? I never
interfered with SAAG business, and I have five SAAG mailing list
recipients willing to swear to this in court, in case personal SAAG
archives aren't enough.
12. Historical summary: copyright issues
I had mentioned copyright on 6 February. RFC 1143 had been extensively
modified immediately before publication, in violation of copyright law;
I didn't want this to happen again. In March, after an attempt by a
certain IAB flunky to steal my writing, I pointed out once again the
automatic existence of copyright. On 29 March I offered to place my
document into the public domain; several times before that I offered to
transfer copyright to IAB the moment after my document was published.
13. Historical summary: tone issues
Cerf and Crocker complained about the ``tone'' of the first pure
revision of the TAP spec. I asked them repeatedly exactly what they were
talking about. They didn't say for over a week, though I did hazard a
guess which turned out to be correct. After they told me I removed the
statements in question. Why weren't they specific in the first place?
Kent and Ts'o have thrice stated that certain passages are not in
conformance with ``RFC style.'' I---and others---have asked what this
style is and where it's documented, as well as for examples of the
style, as well as for some explanation of how the passages would have to
be changed so that they have the proper style. Neither Kent nor Ts'o has
elaborated---yet they continue to claim that various passages are
inconsistent with ``RFC style.''
14. Historical summary: mailing list issues
I created the rfc931-users mailing list in November, chartered to serve
the users of the protocol. (I now regret my mistake in not choosing the
name TAP last year and creating a tap-users list.) During March Crocker
and others sent messages to the list which, in my judgment and in the
judgment of various readers of the list, were not appropriate for the
list. I repeatedly told Crocker to stop abusing the list.
Crocker stated in mid-March that rfc931-users was the ``official mailing
list'' for ``this effort.'' Yet he didn't explain how the effort had
suddenly become official, or how it had suddenly acquired a mailing
list---in particular, a mailing list with an entirely different charter.
I thought that official IAB actions were announced on the IETF list. He
also stated for the first time that he ``required'' a mailing list ``for
every effort.'' He had never brought up this requirement before.
15. Historical summary: cutting TAP out of the process
By late March, in response to my complaints about the abuse of the
rfc931-users list, Crocker had created an official list: ident. For a
few days after that people on both sides of the issues were happily
discussing the TAP spec. I kept a public list of open issues; a few
minor issues were raised and a few were resolved. (The character set
issue, for example, was brought up for the first time.) I estimate that,
with a week more of work, we would have had a perfectly satisfactory
spec which nobody would have objected to.
Then the floor fell out. On 29 March Mike StJohns sent a message to the
rfc931-users and ident lists. ``The "ident" protocol - where we are and
where we're going... Attached at the end of this note is a redraft of
rfc931, hopefully reflecting the current implementation state of the
protocol. This draft with subsequent changes if any is what will be
moved onto the standards track... Mr Bernsteins draft has been removed
from consideration for cause - primarily due to his threats to assert
copyright. His draft will not be considered further as a contribution to
the standards process... we had come to an impasse with Dan and this
looks like the only way to get the effort moving.'' (This, after six
months of inexcusable delay on Crocker's part.)
Again, I leave it to you, my readers, to judge StJohns's actions. I
recently ran a survey of the ident list: apparently StJohns didn't check
with *anybody* in the group before cutting TAP out.
After StJohns' exercise of dictatorship the Ident group was created as a
formal IETF WG, chartered to ``define a protocol'' to transmit certain
information. It's been going for nearly three months now. There's still
a security section, and there are still huge open issues surrounding
that section. StJohns recently took it upon himself to invent extensions
to the protocol, as usual without checking with anybody. (According to
his much more complex, and implementation-free, protocol definition,
UNIX usernames are limited to 8 characters. What a surprise for users of
UNIX systems allowing longer usernames. Why would someone add this sort
of idiotic limitation to a protocol, if not in an attempt to damage the
protocol irreparably?)
16. Standards process issue: perversion of requests
On 15 July 1991 I requested that the IAB move a protocol along the
standards track. As indicated above, the request was (apparently)
refused in March by Steve Crocker, though this refusal was not announced
for review by the IETF community, in clear violation of RFC 1310.
Anyway, Crocker sent me at least two messages along these lines: ``You
asked that we move this protocol forward. We are doing that, via the
Ident effort. What are you complaining about?'' He tried to act
similarly in response to my April 18 request, though he had no right to
do so, as my request was directed at the IETF Chairman.
It's easy to answer Crocker's question. Many of TAP's users believe that
the current Ident draft (1) does not reflect current practice; (2) has
not achieved consensus, or even come close; (3) is far too complex; (4)
has some unacceptable restrictions in the security section; (5) contains
false and misleading information. If it weren't for these flaws we
probably wouldn't be complaining.
But the larger issue is that Crocker has perverted my requests into
something other than what they are. When I ask, following RFC 1310, that
something be moved along the standards track, I expect my request to be
evaluated the way RFC 1310 says it should be, and either accepted or
denied on that basis. I'm not asking that some vague ``effort'' be set
up to standardize a roughly similar protocol, or even the same protocol;
I'm asking that this protocol spec be standardized right now. It is a
perversion of the request to interpret it as something other than what
it is.
I believe that RFC 1310 should explicitly deny the IESG the right to
pervert requests. If the IESG wants to say ``We deny your request, on
the basis of the following criteria in RFC 1310: ... By the way, you
might want to set up a working group to try to put together a better
protocol definition,'' then that's fine. But the IESG should not have
the right to wilfully misinterpret requests in pursuit of its own goals.
If it has no reason to refuse a request then it must accept the request.
In the meantime we should all recognize that Crocker's actions were not
sanctioned by RFC 1310.
17. Standards process issue: copyright
The copyright issue is, from a factual point of view, a non-issue in
this case. I've offered to put my document into the public domain. We
should all recognize that Crocker and StJohns are lying when they claim
anything like ``There are unacceptable copyright restrictions on this
document.''
But there's a larger issue here. RFC 1310 does not list copyright
transfer as a condition for standards to be published. In fact, it
doesn't mention it even as something to be considered. After all, the
IAB has never required copyright transfer before, and under the Berne
convention (which is now U.S. law) there are some hundreds of RFCs which
are automatically copyrighted. So how can the IESG make decisons on the
basis of copyright? RFC 1310 simply does not condone the way that TAP
was removed from consideration.
I'm happy to see that copyright is now listed as an issue to be dealt
with in future RFC 1310 revisions. Certainly, although Crocker and
StJohns were overstepping their authority, there was a grain of reason
behind their incompetent handling of the copyright issue: the IAB can't
be expected to publish standards for the community if the community
doesn't have the right to revise the standard later. Perhaps the IAB
should require that every RFC be placed into the public domain the
moment it's published. The IAB can protect the sanctity of its document
series by trademarking the name ``RFC.''
18. Standards process issue: IETF notice
This deserves repetition: The IESG has, twice, violated RFC 1310's
explicit requirement that its decisions be announced for review by the
entire IETF. I believe that the IESG's failure demands further
requirements. The IESG should be required to summarize each and every
request it receives, immediately, for the IETF's information. We as a
community cannot permit the IESG to escape public review. TAP was
handled incompetently, including more than half a year of inexcusable
delay; why did the IESG try to keep its actions secret?
19. Standards process issue: the job of the IESG
Let's review the RFC 1310 quote on the IESG's job. ``The IESG shall
determine whether a specification satisfies the applicable criteria for
the recommended action (see Sections 3.2 and 3.3 of this document) and
shall communicate its findings to the IETF to permit a final review by
the general Internet community.''
Notice that the IESG is commissioned quite explicitly to decide whether
the request at hand satisfies certain criteria. The criteria in sections
3.2 and 3.3 are quite specific and quite short. They simply say what a
Proposed Standard is, what a Draft Standard is, and so on.
The IESG does *NOT* have the job of deciding between two competing
protocols: if both protocols fit the criteria in RFC 1310 sections 3.2
and 3.3 then both *MUST* be recommeded by the IESG. But I have Gross
recorded as saying that the IESG refused my 18 April request exactly
because, in the IESG's opinion, TAP would compete with Ident.
The IESG does *NOT* have the job of deciding things on the basis of its
hidden thoughts about what's good for the community. But that's exactly
what Steve Kent and Ted Ts'o say it should be doing: they say, for
example, that TAP should not be standardized because it does not have
security as strong as cryptographic protocols.
RFC 1310 does *NOT* sanction the IESG considering *ANY* criteria other
than those listed. But Crocker's refusal of my July 15, 1991 request was
explicitly based on such issues as copyright. And Gross stated that
``duplication of effort'' was the primary reason for the IESG's refusal
of my 18 April request. Even worse, Kent has implied that, even if the
IESG recommends that TAP become a Proposed Standard, he personally will
reject the TAP spec because of its ``style.''
I don't have any suggestions for how RFC 1310 should be modified to
handle these problems. The IESG has violated RFC 1310's rules so
blatantly that I see no recourse other than direct appeal to the
community.
20. Factual notes
The current TAP specification is stable and well-understood: about 85%
of it is word-for-word the same as a draft which has been available
since last June, and the rest is formality; also, the protocol which it
describes has not changed since February 1990. The spec and protocol are
technically competent: to put it simply, they *work*, and the spec says
exactly what's necessary to guarantee future interoperability. There are
multiple independent interoperable implementations with considerable
operational experience: for example, my authd, Peter Eriksson's pauthd,
and the popular wuarchive ftpd. The spec and protocol enjoy some public
support: I have published a list of literally hundreds of IP addresses
running the server, and I have statements from nine people asking the
IAB to get the spec published as an RFC. TAP is not only recognizably
useful in some parts of the Internet; it's being *used*---the statistics
for the NSFNET T1 backbone show many tens of thousands of TCP port 113
packets per month.
21. Is TAP appropriate for the standards track?
RFC 1310 states: ``In general, an Internet Standard is a specification
that is stable and well-understood, is technically competent, has
multiple, independent, and interoperable implementations with
operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet.''
So, given the facts noted in the last section, the TAP spec seems to
satisfy the characterization of Internet Standards in RFC 1310.
Certainly one could argue that ``only'' a couple hundred sites doesn't
constitute ``significant public support,'' or that the spec isn't
perfectly stable. But then again, I'm not asking that TAP become a
Standard yet---all I've been asking since last July is that this be
published as a Proposed Standard. RFC 1310 imposes nearly another year
delay before a Proposed Standard can advance through Draft Standard to
Standard; that'll be more than enough time for the public support and
stability and so on to become obvious.
22. Does TAP embody the goals of the standards process?
RFC 1310 identifies four goals of the procedures of the standards
process: high quality, prior implementation and testing, openness and
fairness, and timeliness. The first two goals were met in this case by
people working outside the IAB---but the goals of openness and fairness
and timeliness can be met only by the IAB. In this case the IAB fell
flat. Steve Crocker claimed in March that he requires a mailing list for
``every'' effort: so what was he doing between July and March with the
TAP effort? Delay Periods 1, 2, and 3 add up to six whole months during
which Crocker did nothing.
23. Does TAP need a working group?
RFC 1310 states: ``In most cases, a specification resulting from an
effort that took place outside of an IETF Working Group context will be
submitted to an appropriate Working Group for evaluation and refinement;
if necessary, an appropriate Working Group will be created.'' This isn't
always applicable, and I don't think there's any need for a TAP group;
but I still suggested this as an option in my 18 April request. The IESG
didn't take this option.
Remember the request perversion issue. If the IESG does create a working
group for TAP then it had better be in conformance with RFC 1310---it
had better be a group to ``evaluate and refine'' the TAP spec. Another
group like Ident, chartered to ``define a protocol,'' simply doesn't cut
it. Ident does not satisfy the IESG's obligations towards TAP.
24. Does TAP satisfy RFC 1310's criteria for being a Proposed Standard?
The IESG's job was to answer the question of this section's title. It
didn't live up to its duties so I'll address the question. RFC 1310
states: ``The entry-level maturity for the standards track is "Proposed
Standard". A Proposed Standard specification is generally stable, has
resolved known design choices, is believed to be well-understood, has
received significant community review, and appears to enjoy enough
community interest to be considered valuable.'' It also states one extra
criterion: ``A Proposed Standard should have no known technical
omissions with respect to the requirements placed upon it.''
The TAP spec---and the protocol it documents---are, as noted above,
quite stable and well-understood, and enjoy more than enough community
interest to be considered valuable. It has received far more community
review than the vast majority of IAB standards efforts, by virtue of
having been incorporated into a number of widely distributed programs.
I resolved all design choices a year ago, and the protocol I defined
then has not been shown to have any technical problems. (I don't claim
that every decision I've made is necessarily optimal, though on the
basis of the last year of protocol development and discussion I do
believe I made good decisions; I claim only that the choices have been
resolved. That's the criterion listed in RFC 1310.) As for technical
omissions, the TAP spec omits nothing. It contains all features
necessary to satisfy the requirements placed on it by its users. (And
there are no requirements placed on this protocol from the outside; it's
not as if TAP was designed to fill the IAB's stated need for a protocol
to do anything in particular. It just transmits uninterpreted octet
strings from one host to another.)
So TAP meets every single criterion in RFC 1310 for being published as a
Proposed Standard. I see no excuse for the IESG to have failed to accept
it---if, that is, the IESG had actually considered the criteria it was
supposed to consider, rather than shirking its duties in violation of
RFC 1310.
RFC 1310 goes further. ``Usually, neither implementation nor operational
experience is required for the designation of a specification as a
Proposed Standard. However, such experience is highly desirable, and
will usually represent a strong argument in favor of a Proposed Standard
designation.''
So not only does TAP meet the criteria for being a Proposed Standard. It
also has both an implementation and operational experience. So if the
IESG had any doubts about TAP, it should have been swayed by the
strong argument that TAP is a protocol *in use*! In fact, TAP has
*multiple* interoperable implementations---more implementations than
most existing Proposed Standards. How strong does this argument have to
be before the IESG gives in?
Note that the TAP spec is, at this point, solely a Technical
Specification, with only a very broad statement of its domain of
applicability. It does not include an Applicability Statement. So it
gets only a maturity level like ``Proposed Standard,'' not a requirement
level like ``Recommended.'' I didn't realize this until I read RFC 1310.
25. What now?
TAP is fully ready to be published as a Proposed Standard. The current
draft is technically sound; now that the security discussions have been
replaced by a disclaimer, there's little if any argument over the
document. Yet---for almost twelve whole months---SAAG and IESG have
refused to let TAP proceed through the standards process.
Permit me to speculate a bit. I think I know why Crocker, Kent, et al.
don't like TAP. They have a shining vision of global cryptographic
authentication. If we had that sort of security on the Internet then
nobody would find TAP useful. But exactly the opposite is true: TAP is
the best in its class right now, and hundreds of people are using it.
Crocker et al. don't like being reminded that their vision is little
more than a far-off dream. If they let TAP be standardized then they'd
be admitting to the whole Internet community that it'll be years before
their vision becomes reality.
Unfortunately for them they weren't able to find any good reason to hold
TAP back. So they started acting unfairly. Let's review the examples
documented above, in roughly increasing order of unfairness:
(A) During a total of six months---Delay Periods 1, 2, and 3---Crocker
and friends did nothing in public and said nothing.
(B) Crocker cut me out of the process, with the excuses that I was
supposedly ignoring a document (which had appeared less than a week
before), and that the discussions weren't converging (as if that were my
fault).
(C) StJohns has adopted the policy of ignoring my objections to the
security section of his document, with the excuse that I am supposedly
the only one raising objections (although other people have supported my
position).
(D) Crocker suddenly declared in March that the rfc931-users list was an
``official mailing list'' for ``this effort''; what a surprise for the
readers of the list. How can something be ``official'' if it hasn't even
been announced on the IETF list?
(E) Crocker claimed in March that he ``required'' a mailing list ``for
every effort''; he had never brought up this requirement in the eight
months before that.
(F) StJohns threw the TAP spec out of consideration at the end of March,
despite the fact that people on both sides of the issues were discussing
it at the time. His excuse was copyright.
(G) The Ident group, which was supposedly created in response to my
request from eight months before, was not chartered to handle that
request.
(H) According to Phill Gross, Crocker refused my 15 July 1991 request
sometime in March. He didn't announce this on the IETF list for
community review.
(I) The IESG refused my 18 April 1992 request in May. They did not
announce this on the IETF list for community review.
(J) The IESG decided between two competing protocols (and then decided
in favor of the vapor protocol).
(K) Crocker's refusal of my July 1991 request was based on such issues
as copyright, not on any technical issues. (And it was a personal
refusal, not one espoused by the relevant working groups.)
(L) The IESG's refusal of my April 1992 request was based primarily on
the issue of ``duplication of effort.''
Scary list, isn't it? To support these unfair actions they engaged in
lies, some of which are documented above (examples: ``we can set up a
dialog'' [Crocker], ``we will push it on to the "standards track" as
expeditiously as possible'' [Galvin, speaking for SAAG], the response
``within a week'' in January [Galvin], ``your efforts are not
constructive'' [Crocker]) and petty exercises of personal power (e.g.,
throwing me off the SAAG list [Crocker]). But words don't hurt; what
hurts is that the IESG has, for a year, censored a perfectly good
protocol, and caused documented cases of interoperability problems and
loss of time and money.
Fortunately I have two weapons to combat the unfair actions of the IESG.
My first weapon is RFC 1310, the IAB's official documentation of its
standards process. With RFC 1310 I can stop shouting ``unfair'' and
start shouting ``fraud.'' RFC 1310 describes exactly what the IESG
*should* have done in response to my requests, and what criteria the
IESG should have considered. By those criteria TAP passes with flying
colors---it's got a larger constituency, more public review, better
consensus, better technical development than the vast majority of
existing Proposed Standards, and multiple interoperable implementations
to boot. Although it's tricky to use e-mail as evidence, I'm seriously
considering suing the IAB for fraud on the basis of the IESG's flagrant
violations of RFC 1310.
My second weapon, my much more powerful weapon, is the will of the
community. Some of you out there must be shaking your heads in
disbelief, saying ``I never thought the IESG would betray the community
in this way!'' We all lose when the IESG doesn't follow its own rules,
ignores its own criteria, and then tries to hide its mistakes from the
community---especially when the result is outright censorship of a
protocol which *needs* to be documented in the standard series to
prevent interoperability problems.
I beg you, my reader: Say what you think. You don't have to trust my
summaries: the transcripts of TAPgate are a matter of public record. You
can do an incredible amount of good by raising your voice in outrage at
the IESG's attempt to wrest control of the standards series away from
the community. Pass around copies of this message, tell other people to
read it, send your opinions or suggestions to the tcp-ip or ietf lists,
talk about TAPgate at IETF meetings, tell me what you think (and please
say if you wouldn't mind my quoting you---every bit helps). Pick up the
TAP spec (draft-bernstein-tap-00.txt) and read it. FTP some of the
implementation work (thanks to Peter Eriksson) from ftp.lysator.liu.se.
And remember that this is a long message: just because you've made it
through doesn't mean other people will, even though they might be very
interested. Summarize, quote, complain. (Also make sure that Crocker
can't get away with denying what happened---please publicize any
relevant behind-the-scenes claims by summarizing them on the IETF list.)
It is time to force the IESG back into the position of serving the
Internet community rather than secretly directing its future. RFC 1310
makes clear that the Internet Engineering Steering Group must always
check its actions with the community, and derives its power from the
will of the community. *We* have final say. We can start by giving TAP
the fair and open treatment it deserves. I wish we hadn't lost a year---
we'll still have to wait another year for TAP to advance from Proposed
Standard to Standard. But maybe it'll be worth it if we make sure that
these abuses don't happen again.
---Dan Bernstein, brnstnd at nyu.edu, 26 June 1992
(These are personal opinions. I have no official affiliation with NYU.)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03037;
27 Jun 92 9:35 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07296; 27 Jun 92 9:36 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA19189>; Sat, 27 Jun 1992 00:54:18 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA19184>; Sat, 27 Jun 1992 00:54:14 -0700
Received: from akbar.cac.washington.edu by NRI.Reston.VA.US id aa01526;
27 Jun 92 3:52 EDT
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.26 ) id AA05285; Sat, 27 Jun 92 00:52:19 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
(NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA04924; Sat, 27 Jun 92 00:52:12 PDT
Date: Fri, 26 Jun 1992 23:56:17 -0700 (PDT)
From: Mark Crispin <MRC at panda.com>
Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: re: informal notice of two IESG decisions
To: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>
Cc: ietf at NRI.Reston.VA.US, comp-protocols-tcp-ip at ucbvax.berkeley.edu,
brnstnd at nyu.edu
In-Reply-To: <9206261749.AA20685 at KRAMDEN.ACF.NYU.EDU>
Message-Id: <MailManager.709628177.4795.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
In answer to Daniel J. Bernstein's megaflame against the IESG and request
for the opinions of others, I will state my opinions:
1. RFC-931 is a terrible idea, and by extension any idea based upon it is
a terrible idea as well. RFC-931 was useful in the ARPAnet and the Milnet,
where PSNs (formerly called IMPs) dictated addressing. This is not the world
in which we live today. RFC-931 was a half-assed non-solution, and in today's
world it is not a solution at all. The best thing that can be done to RFC-931
and all ideas based upon it is to bury it.
2. It is the height of sleeze for Daniel Bernstein to babble about
copyright with regard to Internet RFC's. It is disgusting and disgraceful,
and reflects a fundamental lack of character in Bernstein.
3. Equally deplorable is Bernstein's throwing of a public temper tantrum
against Mike StJohns. Mike is the *author* of the original RFC-931. Simple
courtesy, which Bernstein lacks as well as character, dictates that Mike have
the say in the disposition of RFC-931. Such courtesy to authors has not
always been shown in the IETF, but that does not excuse discourtesy when it
occurs.
In recent months, Bernstein has been clogging mailing lists and
newsgroups touting his garbage. He repeatedly bad-mouths the efforts of
others, e.g. PEM. Nor can he tolerate criticism; when I labelled RFC-931 on
the alt.security newsgroup as being a non-solution, Bernstein responded with
abusive invective.
Bernstein claims to have `exposed corruption within the IESG.' In fact,
what Bernstein has exposed are:
a) the reasons why Daniel J. Bernstein is a total loser
b) the reasons why the IESG did the right thing in rejecting his demands
c) the invaluable and often thankless task the IESG does in filtering wheat
from the chaff.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03427;
27 Jun 92 14:11 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11862;
27 Jun 92 14:12 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA24046>; Sat, 27 Jun 1992 07:42:49 -0700
Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by venera.isi.edu (5.65c/5.65+local-6)
id <AA24039>; Sat, 27 Jun 1992 07:42:43 -0700
Received: from localhost (localhost.ARPA) by dbc.mtview.ca.us (4.1/3.1.090690)
id AA21740; Sat, 27 Jun 92 07:40:28 PDT
To: Mark Crispin <panda.com!MRC at ucbvax.berkeley.edu>
Cc: tcp-ip at nic.ddn.mil, ietf at isi.edu
Reply-To: ietf at isi.edu
Subject: Re: informal notice of two IESG decisions
In-Reply-To: Your message of "27 Jun 1992 06:56:17 GMT."
<MailManager.709628177.4795.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 27 Jun 1992 07:40:27 -0700
Message-Id: <21739.709656027 at dbc.mtview.ca.us>
From: Marshall Rose <mrose at dbc.mtview.ca.us>
Mark - I'm afraid that I'm in total agreement with you on this topic.
(Readers interested in historical trivia should note that this is only
the second time in the last twelve years when I've agreed with anything
said by Crispin.)
Although the Internet community has had a long tradition of hearing the
voice of the lone dissenter, this means that we must be able to
distinguish between legitimate criticism and total nonsense. Based on
my observations and interactions in this rfc931bis matter over the last
four months, I agree totally with the sentiment expressed in your
message; i.e., Bernstein's message entirely falls into the category of
total nonsense.
I am perhaps the most vocal critic of the Internet standardization
process; as I use very accessible forms to air my complaints. However,
based on my experience in this situation, I have to firmly support the
IESG's behavior. (I should also applaud Mike St. Johns for putting up
with Bernstein for so long. He is clearly a more charitable person than I.)
/mtr
ps: I long for the good old days of the Internet community, the time
when "community" obviously had some higher meaning than it does now.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04847;
28 Jun 92 5:51 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa28572; 28 Jun 92 5:52 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA12855>; Sat, 27 Jun 1992 23:57:15 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA12849>; Sat, 27 Jun 1992 23:57:10 -0700
Received: from taunivm.tau.ac.il by NRI.Reston.VA.US id aa26071;
28 Jun 92 2:55 EDT
Received: from VM.BIU.AC.IL by TAUNIVM.TAU.AC.IL (IBM VM SMTP V2R1)
with BSMTP id 7603; Sun, 28 Jun 92 09:55:10 IST
X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender.
Received: from VM.BIU.AC.IL (HANK) by VM.BIU.AC.IL (Mailer R2.07) with BSMTP id
3136; Sun, 28 Jun 92 09:53:54 IST
Date: Sun, 28 Jun 92 09:25:26 IST
From: Hank Nussbacher <HANK%VM.BIU.AC.IL at taunivm.tau.ac.il>
Subject: Re: informal notice of two IESG decisions
To: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>,
ietf at NRI.Reston.VA.US, comp-protocols-tcp-ip at ucbvax.berkeley.edu
Cc: brnstnd at nyu.edu
In-Reply-To: Message of Fri, 26 Jun 92 13:49:27 +0100 from
<brnstnd at kramden.acf.nyu.edu>
Message-Id: <9206280255.aa26071 at NRI.Reston.VA.US>
A few points/questions:
1) Even suppose everything you are saying is correct, then if we look to
"what is best for the community" it is to stop this bickering and get an RFC
published. That is what ident is doing. Or are you more interested in seeing
your name on the RFC then in seeing the RFC published?
2) In section #13 you discussed the matter of tone. If your long notice
(which I did read from beginning to end) is any indication of the tone of
your proposed RFCs or notes, then I understand why the entire IESG is
against you.
3) You state you are not afffiliated with NYU. What exactly do you do and
who do you work for? This would give me a better chance to determine whether
you have any vested interests in which way the RFC goes.
4) I haven't been living in the USA for the past 10 years but your system
is called kramden. Isn't that from the Honeymooners? Ralph ("To the moon,
Norton!") Kramden?
And I thought I was gonna be kind of bored at the IETF :-)
Oh by the way, feel free to quote me on anything from section #4 above.
Hank Nussbacher
Israel
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05425;
28 Jun 92 20:00 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12492;
28 Jun 92 20:01 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA02553>; Sun, 28 Jun 1992 13:28:18 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA02549>; Sun, 28 Jun 1992 13:28:17 -0700
Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by quark.isi.edu (5.65c/5.61+local-6)
id <AA14996>; Sun, 28 Jun 1992 12:12:00 -0700
Received: from localhost (localhost.ARPA) by dbc.mtview.ca.us (4.1/3.1.090690)
id AA06305; Sun, 28 Jun 92 12:09:56 PDT
To: "Daniel J. Bernstein" <KRAMDEN.ACF.NYU.EDU!brnstnd at ucbvax.berkeley.edu>
Cc: tcp-ip at nic.ddn.mil, ietf at isi.edu
Reply-To: ietf at isi.edu
Subject: Re: informal notice of two IESG decisions
In-Reply-To: Your message of "28 Jun 1992 11:11:50 GMT."
<9206281611.AA00969 at KRAMDEN.ACF.NYU.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 28 Jun 1992 12:09:55 -0700
Message-Id: <6304.709758595 at dbc.mtview.ca.us>
From: Marshall Rose <mrose at dbc.mtview.ca.us>
I believe that your response pretty much validates the position taken by
Crispin, Nussbacher, myself (and many others). I thank you for your
response; you have argued my case more forcefully than I would be able
to do so in a public form.
/mtr
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05455;
28 Jun 92 20:37 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13140;
28 Jun 92 20:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA02644>; Sun, 28 Jun 1992 13:30:09 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA02639>; Sun, 28 Jun 1992 13:30:06 -0700
Received: from bells.cs.ucl.ac.uk by quark.isi.edu (5.65c/5.61+local-6)
id <AA14936>; Sun, 28 Jun 1992 12:01:12 -0700
Message-Id: <199206281901.AA14936 at quark.isi.edu>
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.22888-0 at bells.cs.ucl.ac.uk>; Sun, 28 Jun 1992 19:59:37 +0100
To: Internet Engineering Steering Group <iesg-secretary at NRI.Reston.VA.US>
Cc: Bob Braden -- IAB Executive Director <braden at isi.edu>,
Internet Activities Board <iab at isi.edu>,
Internet Engineering Task Force <ietf at isi.edu>
Subject: Re: Protocol Action: BGP NEXT-HOP-SNPA Attribute to be removed from
consideration as a Proposed Standard
In-Reply-To: Your message of "Fri, 26 Jun 92 10:06:07 EDT." <9206261006.aa04149 at IETF.NRI.Reston.VA.US>
Date: Sun, 28 Jun 92 19:59:24 +0100
From: Paul Tsuchiya <P.Tsuchiya at cs.ucl.ac.uk>
>
> Recommendation:
>
> After discussion with the IAB, the protocol document authors, and the
> IPLPDN working group, the IESG has decided to withdraw the
> recommendation made December 1991.
I would like to add that the main reason this work is being dropped
is because the shortcut routing technique solves the same problem
in a much more general way.
PT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05598;
28 Jun 92 22:38 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15395;
28 Jun 92 22:39 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA04534>; Sun, 28 Jun 1992 14:20:48 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA18777>; Sun, 28 Jun 1992 09:14:01 -0700
Received: from KRAMDEN.ACF.NYU.EDU by NRI.Reston.VA.US id aa04039;
28 Jun 92 12:11 EDT
Received: from LOCALHOST by KRAMDEN.ACF.NYU.EDU (5.61/1.34)
id AA00969; Sun, 28 Jun 92 16:11:56 GMT
Message-Id: <9206281611.AA00969 at KRAMDEN.ACF.NYU.EDU>
To: ietf at NRI.Reston.VA.US, comp-protocols-tcp-ip at ucbvax.berkeley.edu
Cc: brnstnd at nyu.edu
Subject: Re: informal notice of two IESG decisions
Date: Sun, 28 Jun 92 12:11:50 +0100
From: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>
I have a few comments on the messages from Mark, Marshall, and Hank. My
next message will be at the end of this week, summarizing the responses
I've received at that point. I hope we have an explanation---and an
apology to the community---from the IESG by that time.
Let me note at the start that this is by no means a case of ``the lone
dissenter.'' Steve March, Jim Meyering, Piotr Nestorow, Samuel Lam, and
Peter Eriksson, for example, have asked Steve Crocker to move my
document along the standards track. Even Vint Cerf expressed his
personal comfort with the TAP spec in March. And the protocol we're
talking about here is listed as the 72nd highest user of the NSFNet T1
backbone last month---well over 100000 packets, far above many Proposed
Standards. So why the censorship?
Marshall, you say that you ``firmly support'' the IESG's actions. So you
can explain to the IETF why the IESG kept two decisions secret, rather
than communicating them to the IETF list for final review by the
community as required by RFC 1310? And you can explain to the IETF why
the IESG based those decisions on such criteria as ``duplication of
effort,'' rather than upon the criteria which it is required to consider
by RFC 1310? We're waiting.
Or are you simply annoyed because I said SNMP wasn't so trivial to
implement---and because I criticized a document with your name on it?
Reality check: You've been cooperating with StJohns through the four
months you've been involved with Ident. In fact your name is with
StJohns on one of the Ident documents, and you can't tolerate criticism
of anything you do. Because of your position here you can't be trusted,
and your ``support'' of the IESG is meaningless without a solid
explanation of why they abused their position within the community. It's
real sweet to hear that you and Mark are in bed together for the first
time in twelve years, but that doesn't make either of you right.
Mark, if you don't understand TAP, you can feel free not to use it.
There are hundreds of people and a growing number of applications which
use it. Why don't we have the right to document the protocol we use in
the IAB's standards series?
StJohns is indeed the author of RFC 931, which I based TAP on. But he
disclaimed the protocol years ago. ``I wrote RFC931 and its predecessor
as an intellectual exercise...'' He doesn't even *use* the protocol
which he's now in charge of standardizing. Jon Kamens said, two years
ago: ``Anecdote time. The last time our Kerberos team talked to the NIC
about getting an official port for Kerberos, Mike StJohns (the guy who
wrote RFC 931) said (somewhat jokingly) something to the effect of,
"Well, why don't you just use the auth port? We'll never use it for
anything, after all -- it was a bad idea." ''
Hank, you suggest moving ident along. I for one don't see why we should
waste time trying to fix the 73 problems I (and others) have pointed out
with the current ident spec, when the TAP spec is perfectly good as is.
Ident has made absolutely no progress on the most important issue,
namely the auditing restriction. Several people have objected to the
restriction and given examples where the restriction is damaging. Yet
StJohns continues to ignore the issue.
Besides, Ident is *not the same protocol* as TAP: the existing TAP
implementations don't comply with the current Ident draft in several
important ways. How dare you stifle a protocol in use at hundreds of
sites in favor of a vapor protocol which isn't even compatible?
As for tone, Hank, why don't you pick up draft-bernstein-tap-00.txt
instead of making wild guesses about it? Do you really think Vint Cerf
would express his personal comfort with a document if he didn't like the
tone? And, since you ask, I'm a number theorist (currently factoring
2^488+1, if you're curious), and have no interest in TAP beyond the
obvious. What I want here is to document the protocol so that we don't
have any future interoperability problems!
Finally, Mark, before you use the words ``sleeze'' [sic] and ``loser,''
consider yourself. You seem to have made quite a few enemies who are all
too willing to talk about details of your former marital situation. Do
you really think it's wise to accuse me of using ``abusive invective''
in a discussion where you repeatedly called me ``clueless''? I've never
promised to be Mr. Nice Guy, and if push comes to shove you have a lot
more to lose. I suggest that you restrict your comments to the issues at
hand. (I've never criticized PEM on any basis except that it's
vaporware, by the way.)
I want to know why the IESG failed to make decisions on the basis of the
criteria in RFC 1310. I want to know why the IESG kept those decisions
secret from the community. I've spent months trying to settle this
quietly with Cerf, Chapin, Gross, Crocker, StJohns, et al. I've reminded
each of them repeatedly of what RFC 1310 says and asked how it justifies
their actions. I get nothing but silence, even over the phone. I'm sick
of the silence.
---Dan
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10551;
29 Jun 92 14:26 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12097;
29 Jun 92 14:27 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00672>; Mon, 29 Jun 1992 07:37:49 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA00668>; Mon, 29 Jun 1992 07:37:46 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07644;
29 Jun 92 10:31 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-hubmib-mib-03.txt
Date: Mon, 29 Jun 92 10:31:20 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206291031.aa07644 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
IEEE 802.3 Hub MIB Working Group of the IETF.
Title : Definitions of Managed Objects for IEEE 802.3
Repeater Devices
Author(s) : Donna McMaster, Keith McCloghrie
Filename : draft-ietf-hubmib-mib-03.txt
Pages : 47
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 IEEE 802.3 10 Mb/second baseband repeaters, sometimes
referred to as "hubs."
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-hubmib-mib-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-hubmib-mib-03.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa11939;
29 Jun 92 15:59 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa17263;
29 Jun 92 16:00 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00680>; Mon, 29 Jun 1992 07:37:52 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA00673>; Mon, 29 Jun 1992 07:37:48 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07662;
29 Jun 92 10:31 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-x25mib-x25packet-04.txt
Date: Mon, 29 Jun 92 10:31:52 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206291031.aa07662 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
X.25 Management Information Base Working Group of the IETF.
Title : SNMP MIB extension for the X.25 Packet Layer
Author(s) : Dean Throop
Filename : draft-ietf-x25mib-x25packet-04.txt
Pages : 75
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing the Packet Layer of
X.25. The objects defined here, along with the objects in the "SNMP
MIB extension for LAPB" and the "Definitions of Managed Objects for
RS-232-like Hardware Devices", combine to allow management of an X.25
protocol stack.
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-x25mib-x25packet-04.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-x25mib-x25packet-04.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13065;
29 Jun 92 17:34 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa22639;
29 Jun 92 17:35 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05158>; Mon, 29 Jun 1992 09:11:23 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA05154>; Mon, 29 Jun 1992 09:11:21 -0700
Received: from xap.xyplex.com by NRI.Reston.VA.US id aa05856;
29 Jun 92 12:04 EDT
Received: by xap.xyplex.com id <AA20622 at xap.xyplex.com>; Mon, 29 Jun 92 11:47:11 -0500
Date: Mon, 29 Jun 92 11:47:11 -0500
Message-Id: <9206291647.AA20622 at xap.xyplex.com>
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: brnstnd at kramden.acf.nyu.edu
Cc: ietf at NRI.Reston.VA.US, comp-protocols-tcp-ip at ucbvax.berkeley.edu
In-Reply-To: "Daniel J. Bernstein"'s message of Sun, 28 Jun 92 12:11:50 +0100 <9206281611.AA00969 at KRAMDEN.ACF.NYU.EDU>
Subject: Re: informal notice of two IESG decisions
I suppose I shouldn't help continue a flame war, but resisting such temptation
has never been one of my strong points...
{ much deleted }
>Mark, if you don't understand TAP, you can feel free not to use it.
>There are hundreds of people and a growing number of applications which
>use it. Why don't we have the right to document the protocol we use in
>the IAB's standards series?
{ more deleted }
>Besides, Ident is *not the same protocol* as TAP: the existing TAP
>implementations don't comply with the current Ident draft in several
>important ways. How dare you stifle a protocol in use at hundreds of
>sites in favor of a vapor protocol which isn't even compatible?
{ yet more deleted}
Dan,
For the most part I'll confine my comments to the neighborhood of the above
snippets from your message. The personal attacks in all directions should
simply be ignored as inappropriate.
I haven't been involved in any of the dispute over the Ident protocol and only
marginally know what it's about, so I'm really speaking to meta-issues
involving people who I respect and a process that I believe works pretty well.
One of the jobs of the IAB and the IESG, whether it says so in RFC 1310 or
not, is to discourage ill-advised protocols. This can be very difficult and
sometimes subjective. When an opinion is based on intuition it can be very
difficult to defend, and this can lead to hiding behind more objective
procedures and delaying by process hoping the problem will go away. Perhaps
this happened, at least to some extent. I condone or defend doing things that
way. I'm simply proposing a possibility.
To get to the snippets, acceptance and use by lots of people does not make
something good. Standardization of a bad thing does not make it a good thing.
The majority is more often wrong than right. The Internet is not a democracy
and it shouldn't be. I have worked with many of the people you are accusing
of corruption and conspiracy. At worst, I believe they are guilty of not
being clear when they should have been.
A well-respected former boss of mine once observed that I'd rather be right
than president. I take that as a compliment. I'd rather be clear of word an
conscience, disliked, and considered by some to be high-handed and unfair,
than ambiguous, polite, and misunderstood. As long as I find agreement from a
few people who I respect, I'm satisfied.
My reading on this situation, based on what little I know of the technology
involved and the bit more I know about the people that have stood in its way,
is that the idea you're pushing shouldn't be on the standards track simply
because it's a bad idea. If lots of people want to use it and be happy with
it, I wouldn't mind seeing an informational RFC that helps them all do it the
same way. This is sort of a free country, and sort of a free network. I
believe people should be free to hurt themselves as long as I don't have to
pay to fix them and I haven't helped mislead them into feelings of false
security. With a warning that some people consider the technology potentially
harmful and misleading, documenting this protocol should be no less
appropriate as an RFC than humor and poetry
Bob
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13096;
29 Jun 92 17:36 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa22704;
29 Jun 92 17:37 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06243>; Mon, 29 Jun 1992 09:30:22 -0700
Received: from quark.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA06229>; Mon, 29 Jun 1992 09:30:16 -0700
Received: from NRI.RESTON.VA.US by quark.isi.edu (5.65c/5.61+local-6)
id <AA19588>; Mon, 29 Jun 1992 06:49:16 -0700
Received: from dg-rtp.rtp.dg.com by NRI.Reston.VA.US id aa29285;
29 Jun 92 9:41 EDT
Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto)
id AA17370; Mon, 29 Jun 1992 09:41:06 -0400
Received: by walrus (5.4.1/140.2)
id AA04013; Mon, 29 Jun 1992 09:38:36 -0400
Date: Mon, 29 Jun 1992 09:38:36 -0400
From: "Dean D. Throop" <throop at dg-rtp.dg.com>
Message-Id: <9206291338.AA04013 at walrus>
To: ietf at NRI.Reston.VA.US
Subject: Re: informal notice of two IESG decisions
> Message-Id: <9206281611.AA00969 at KRAMDEN.ACF.NYU.EDU>
> Subject: Re: informal notice of two IESG decisions
> Date: Sun, 28 Jun 92 12:11:50 +0100
> From: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>
>
...
> Marshall, you say that you ``firmly support'' the IESG's actions. So you
> can explain to the IETF why the IESG kept two decisions secret, rather
> than communicating them to the IETF list for final review by the
> community as required by RFC 1310? And you can explain to the IETF why
> the IESG based those decisions on such criteria as ``duplication of
> effort,'' rather than upon the criteria which it is required to consider
> by RFC 1310? We're waiting.
>
> Or are you simply annoyed because I said SNMP wasn't so trivial to
> implement---and because I criticized a document with your name on it?
> Reality check: You've been cooperating with StJohns through the four
> months you've been involved with Ident. In fact your name is with
> StJohns on one of the Ident documents, and you can't tolerate criticism
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> of anything you do. Because of your position here you can't be trusted,
> and your ``support'' of the IESG is meaningless without a solid
> explanation of why they abused their position within the community. It's
> real sweet to hear that you and Mark are in bed together for the first
> time in twelve years, but that doesn't make either of you right.
>
I objected to a restriction in a draft from Mike and Marshall
and the restriction was removed in the next revision. This
doesn't seem like intolerance to me.
Dean Throop throop at dg-rtp.dg.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13776;
29 Jun 92 19:18 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa25839;
29 Jun 92 19:19 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00680>; Mon, 29 Jun 1992 07:37:52 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA00673>; Mon, 29 Jun 1992 07:37:48 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07662;
29 Jun 92 10:31 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-x25mib-x25packet-04.txt
Date: Mon, 29 Jun 92 10:31:52 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9206291031.aa07662 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
X.25 Management Information Base Working Group of the IETF.
Title : SNMP MIB extension for the X.25 Packet Layer
Author(s) : Dean Throop
Filename : draft-ietf-x25mib-x25packet-04.txt
Pages : 75
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing the Packet Layer of
X.25. The objects defined here, along with the objects in the "SNMP
MIB extension for LAPB" and the "Definitions of Managed Objects for
RS-232-like Hardware Devices", combine to allow management of an X.25
protocol stack.
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-x25mib-x25packet-04.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-x25mib-x25packet-04.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa13976;
29 Jun 92 21:27 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa29129;
29 Jun 92 21:28 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07091>; Mon, 29 Jun 1992 09:41:09 -0700
From: Joyce Reynolds <jkrey at isi.edu>
Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA07080>; Mon, 29 Jun 1992 09:41:02 -0700
Date: Mon, 29 Jun 1992 09:39:21 -0700
Posted-Date: Mon, 29 Jun 1992 09:39:21 -0700
Message-Id: <199206291639.AA00346 at akamai.isi.edu>
Received: by akamai.isi.edu (5.65c/4.0.3-4)
id <AA00346>; Mon, 29 Jun 1992 09:39:21 -0700
To: ietf at isi.edu, rfc-dist at nic.ddn.mil
Subject: RFC1339 on Remote Mail Checking Protocol
Cc: jkrey at isi.edu
A new Request for Comments is now available in online RFC libraries.
RFC 1339:
Title: Remote Mail Checking Protocol
Author: S. Dorner & P. Resnick
Mailbox: s-dorner at uiuc.edu, resnick at cogsci.uiuc.edu
Pages: 5
Characters: 13,115
Updates/Obsoletes: none
This RFC defines a protocol to provide a mail checking service to be
used between a client and server pair. Typically, a small program on
a client workstation would use the protocol to query a server in
order to find out whether new mail has arrived for a specified user.
This memo defines an Experimental Protocol for the Internet community.
Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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 NRI.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.
RFCs can be obtained via FTP from FTP.NISC.SRI.COM, NIS.NSF.NET,
NISC.JVNC.NET, VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or 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 NIC at NIC.DDN.MIL. 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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
======================================================================
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa07419;
30 Jun 92 17:42 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa07415;
30 Jun 92 17:42 EDT
Received: from alpha.Xerox.COM by NRI.Reston.VA.US id aa28413;
30 Jun 92 17:43 EDT
Received: from lambda.parc.xerox.com ([13.2.116.36]) by alpha.xerox.com with SMTP id <12239>; Tue, 30 Jun 1992 14:40:20 PDT
Received: from alpha.xerox.com ([13.1.64.93]) by lambda.parc.xerox.com with SMTP id <58373>; Tue, 30 Jun 1992 14:38:57 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by alpha.xerox.com with SMTP id <12250>; Tue, 30 Jun 1992 14:38:26 PDT
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07328;
30 Jun 92 17:28 EDT
Mime-Version: 1.0
Content-Type: text/plain; Charset="us-ascii"
Org: Corp. for National Research Initiatives
Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: ietf at isi.edu
Cc: gvaudre at NRI.Reston.VA.US, mobile-ip at parc.xerox.com
Subject: WG ACTION: Mobile IP
Date: Tue, 30 Jun 1992 14:28:39 PDT
From: Greg Vaudreuil <gvaudre at NRI.Reston.VA.US>
Message-ID: <9206301728.aa07328 at IETF.NRI.Reston.VA.US>
A new working group has been formed in the Routing area. For more
information please contact the Working Group chairman, Steve Deering,
or the Routing Area Director, Bob Hinden <hinden at eng.sun.com>.
Greg Vaudreuil
IESG Secretary
Mobile IP Working Group (mobileip)
Charter
Chair(s):
Steve Deering <deering at parc.xerox.com>
Mailing lists:
General Discussion:mobile-ip at parc.xerox.com
To Subscribe: mobile-ip-request at parc.xerox.com
Archive: pub/mobile-ip/mail-archive at parcftp.xerox.com
Description of Working Group:
The Mobile IP Working Group is chartered to develop or adopt
architectures and protocols to support mobility within the Internet.
In the near term, protocols for supporting transparent host
``roaming'' among different subnetworks and different media (e.g.,
LANs, dial-up links, and wireless communication channels) shall be
developed and entered into the Internet Standards track. The work is
expected to consist mainly of new and/or revised protocols at the
(inter)network layer, but may also include proposed modifications to
higher-layer protocols (e.g., transport or directory). However, it
shall be a requirement that the proposed solutions allow mobile hosts
to interoperate with existing Internet systems.
Longer term, the Group may address, to the extent not covered by the
mobile host solutions, other types of internet mobility, such as
mobile subnets (e.g., a local network within a vehicle), or mobile
clusters of subnets (e.g., a collection of hosts, routers, and subnets
within a large vehicle, like a ship or spacecraft, or a collection of
wireless, mobile routers that provide a dynamically changing internet
topology).
Goals and Milestones:
Jul 92 Review and approve the Charter, making any changes deemed necessary.
Nov 92 Post an Internet Draft documenting the Mobile Hosts protocol.
Mar 93 Review the Charter of the Mobile IP Working Group for additional work
required to facilitate non-host mobility.
Mar 93 Submit the Mobile Host Protocol to the IESG as a Proposed Standard.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08284;
30 Jun 92 20:20 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03043;
30 Jun 92 20:21 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03231>; Tue, 30 Jun 1992 13:22:01 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA03209>; Tue, 30 Jun 1992 13:21:41 -0700
Received: from port13.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA05997; Tue, 30 Jun 92 16:19:17 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA16820; Tue, 30 Jun 92 13:18:20 PDT
Message-Id: <9206302018.AA16820 at aland.bbn.com>
To: ietf at isi.edu
Cc: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>
Subject: re: informal notice of two IESG decisions
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 30 Jun 92 13:18:19 -0700
Sender: craig at aland.bbn.com
[I'm going to also post this to tcp-ip since some debate is raging there
as well and cross postings appear not to be working].
I've read the notes on this subject in some puzzlement. I was part of the
IESG until about a year ago and helped with some early versions of 1310
and did not remember that the IESG had ever had any obligation to announce
decisions *not* to forward a standard.
So I went and re-read RFC 1310. My conclusion is that the clause cited:
``The IESG shall determine whether a specification satisfies the
applicable criteria for the recommended action (see Sections 3.2
and 3.3 of this document) and shall communicate its findings to the
IETF to permit a final review by the general Internet community.''
was only intended to imply that no document could be proposed as a standard
without public review, *not* that documents that were not to be promoted
should receive public review. (This is what I'd remembered).
Lest I be accused of reading text to conform to my faulty recollections, some
supporting notes:
* The document suggests that specifications satisfying the recommended
action will typically receive both e-mail review and be publicly
presented to the IETF plenary. Clearly there's no point in a review
much less a public presentation if a specification is being rejected.
* Sections 3.2 and 3.3 only indicate status possible for standards
(or past standards). Thus "to satisfy the applicable criteria" can
be read as meaning "if the document is deemed appropriate for
standardization."
* the paragraph at the end of 2.6 indicates that following IAB approval
of the IESG action, the I-D will be published as an RFC. Again,
the only IESG-IAB approved decisions that result in RFCs are positive
decisions.
So I think the right step here is to point out that the phrase about
recommendations should be clarified to indicate what happens to rejected
proposals. (I actually think that they *should not* be publicly announced,
except, perhaps at the request of the author. No point in embarassing hard
working folks if their proposal gets rejected, unless they request publicity).
Craig Partridge
PS: I'll note that the IESG also appears followed proper procedure on all
other issues. Mr. Bernstein submitted a document which after considerable
review and work by his community became an I-D (RFC 1310 sect 2.4 says
documents viewed as completed may become I-Ds). The IESG is entitled to
ask committees to review the I-D -- apparently they did (the SAAG).
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08398;
30 Jun 92 20:47 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03675;
30 Jun 92 20:47 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06443>; Tue, 30 Jun 1992 14:39:59 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA06438>; Tue, 30 Jun 1992 14:39:55 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07328;
30 Jun 92 17:28 EDT
Mime-Version: 1.0
Content-Type: text/plain; Charset="us-ascii"
Org: Corp. for National Research Initiatives
Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: ietf at isi.edu
Cc: gvaudre at NRI.Reston.VA.US, mobile-ip at parc.xerox.com
Subject: WG ACTION: Mobile IP
Date: Tue, 30 Jun 92 17:28:39 -0400
From: Greg Vaudreuil <gvaudre at NRI.Reston.VA.US>
Message-Id: <9206301728.aa07328 at IETF.NRI.Reston.VA.US>
A new working group has been formed in the Routing area. For more
information please contact the Working Group chairman, Steve Deering,
or the Routing Area Director, Bob Hinden <hinden at eng.sun.com>.
Greg Vaudreuil
IESG Secretary
Mobile IP Working Group (mobileip)
Charter
Chair(s):
Steve Deering <deering at parc.xerox.com>
Mailing lists:
General Discussion:mobile-ip at parc.xerox.com
To Subscribe: mobile-ip-request at parc.xerox.com
Archive: pub/mobile-ip/mail-archive at parcftp.xerox.com
Description of Working Group:
The Mobile IP Working Group is chartered to develop or adopt
architectures and protocols to support mobility within the Internet.
In the near term, protocols for supporting transparent host
``roaming'' among different subnetworks and different media (e.g.,
LANs, dial-up links, and wireless communication channels) shall be
developed and entered into the Internet Standards track. The work is
expected to consist mainly of new and/or revised protocols at the
(inter)network layer, but may also include proposed modifications to
higher-layer protocols (e.g., transport or directory). However, it
shall be a requirement that the proposed solutions allow mobile hosts
to interoperate with existing Internet systems.
Longer term, the Group may address, to the extent not covered by the
mobile host solutions, other types of internet mobility, such as
mobile subnets (e.g., a local network within a vehicle), or mobile
clusters of subnets (e.g., a collection of hosts, routers, and subnets
within a large vehicle, like a ship or spacecraft, or a collection of
wireless, mobile routers that provide a dynamically changing internet
topology).
Goals and Milestones:
Jul 92 Review and approve the Charter, making any changes deemed necessary.
Nov 92 Post an Internet Draft documenting the Mobile Hosts protocol.
Mar 93 Review the Charter of the Mobile IP Working Group for additional work
required to facilitate non-host mobility.
Mar 93 Submit the Mobile Host Protocol to the IESG as a Proposed Standard.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08654;
30 Jun 92 22:04 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa05483;
30 Jun 92 22:06 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05934>; Tue, 30 Jun 1992 14:29:02 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05928>; Tue, 30 Jun 1992 14:29:00 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07188;
30 Jun 92 17:19 EDT
Org: Corp. for National Research Initiatives
Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: ietf at isi.edu
Cc: gvaudre at NRI.Reston.VA.US, idrp-for-ip at merit.edu
Subject: WG ACTION: OSI IDRP for IP over IP
Date: Tue, 30 Jun 92 17:19:48 -0400
From: Greg Vaudreuil <gvaudre at NRI.Reston.VA.US>
Message-Id: <9206301719.aa07188 at IETF.NRI.Reston.VA.US>
A new Working Group has been formed in the Routing Area. For
more information please contact the Working Group chair Sue Hares, or
the Routing Area Director Bob Hinden <hinden at eng.sun.com>.
Greg Vaudreuil
IESG Secretary
OSI IDRP for IP over IP (ipidrp)
Charter
Chair(s):
Sue Hares <skh at merit.edu>
Mailing lists:
General Discussion:idrp-for-ip at merit.edu
To Subscribe: idrp-for-ip-request at merit.edu
Archive: merit.edu: /pub/archive/idrp
Description of Working Group:
The IDRP for IP over IP Working Group is chartered to standardize and promote
the use of IDRP (ISO Inter-Domain Routing Protocol) as a scalable inter-
autonomous system routing protocol capable of supporting Policy Based Routing
for TCP/IP internets. The objective is to take IDRP, as it is defined by ISO
standards, and to define backward compatible extensions and/or network
adaptation layers to enable this protocol to be used in the TCP/IP internets.
If any ISO standardization efforts overlap this area of work, it is intended
that the ISO work will supersede the standards proposed by this Group.
1) IDRP for IP over IP document (standards track)
This document contains the appropriate adaptations of the IDRP protocol
definition that enables it to be used as a protocol for exchange of
``inter-autonomous system information'' among routers to support
forwarding of IP packets across multiple autonomous systems.
2) IDRP MIB document (standards track)
This document contains the MIB Definitions for IDRP. These MIB
Definitions are done in two parts; IDRP General MIB, and IDRP for IP
MIB. An appendix is planned; IDRP For IP GDMO
3) IDRP - OSPF Interactions (standards track)
This document will specify the interactions between IDRP and OSPF.
This document will be based on a combination of BGP-OSPF interactions
document and IDRP - ISIS interaction document.
4) IDRP for IP Usage document (standards track)
Most of the IDRP for IP Usage will reference the CIDR (Supernetting
document) Internet Draft. Any additional terms or protocol definitions
needed for IDRP for IP will also be specified here.
Goals and Milestones:
Done IDRP for IP submitted for Internet Draft.
Jun 92 IDRP MIB document submitted for Internet Draft.
Jun 92 IDRP - OSPF Interactions document submitted for Internet Draft.
Jun 92 IDRP Usage document submitted for Internet Draft.
Nov 92 IDRP for IP submitted to the IESG for Proposed Standard.
Nov 92 IDRP Usage document submitted to the IESG for Proposed Standard.
Nov 92 IDPR MIB Submitted to the IESG for Proposed Standard.
Nov 92 IDRP - OSPF Interactions document submitted to the IESG for Proposed
Standard.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09012;
1 Jul 92 0:01 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08689; 1 Jul 92 0:02 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03231>; Tue, 30 Jun 1992 13:22:01 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA03209>; Tue, 30 Jun 1992 13:21:41 -0700
Received: from port13.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA05997; Tue, 30 Jun 92 16:19:17 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA16820; Tue, 30 Jun 92 13:18:20 PDT
Message-Id: <9206302018.AA16820 at aland.bbn.com>
To: ietf at isi.edu
Cc: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>
Subject: re: informal notice of two IESG decisions
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 30 Jun 92 13:18:19 -0700
Sender: craig at aland.bbn.com
[I'm going to also post this to tcp-ip since some debate is raging there
as well and cross postings appear not to be working].
I've read the notes on this subject in some puzzlement. I was part of the
IESG until about a year ago and helped with some early versions of 1310
and did not remember that the IESG had ever had any obligation to announce
decisions *not* to forward a standard.
So I went and re-read RFC 1310. My conclusion is that the clause cited:
``The IESG shall determine whether a specification satisfies the
applicable criteria for the recommended action (see Sections 3.2
and 3.3 of this document) and shall communicate its findings to the
IETF to permit a final review by the general Internet community.''
was only intended to imply that no document could be proposed as a standard
without public review, *not* that documents that were not to be promoted
should receive public review. (This is what I'd remembered).
Lest I be accused of reading text to conform to my faulty recollections, some
supporting notes:
* The document suggests that specifications satisfying the recommended
action will typically receive both e-mail review and be publicly
presented to the IETF plenary. Clearly there's no point in a review
much less a public presentation if a specification is being rejected.
* Sections 3.2 and 3.3 only indicate status possible for standards
(or past standards). Thus "to satisfy the applicable criteria" can
be read as meaning "if the document is deemed appropriate for
standardization."
* the paragraph at the end of 2.6 indicates that following IAB approval
of the IESG action, the I-D will be published as an RFC. Again,
the only IESG-IAB approved decisions that result in RFCs are positive
decisions.
So I think the right step here is to point out that the phrase about
recommendations should be clarified to indicate what happens to rejected
proposals. (I actually think that they *should not* be publicly announced,
except, perhaps at the request of the author. No point in embarassing hard
working folks if their proposal gets rejected, unless they request publicity).
Craig Partridge
PS: I'll note that the IESG also appears followed proper procedure on all
other issues. Mr. Bernstein submitted a document which after considerable
review and work by his community became an I-D (RFC 1310 sect 2.4 says
documents viewed as completed may become I-Ds). The IESG is entitled to
ask committees to review the I-D -- apparently they did (the SAAG).
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09369;
1 Jul 92 1:58 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11308; 1 Jul 92 2:00 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05973>; Tue, 30 Jun 1992 14:29:38 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05969>; Tue, 30 Jun 1992 14:29:34 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07235;
30 Jun 92 17:23 EDT
Mime-Version: 1.0
Content-Type: text/plain; Charset="us-ascii"
Org: Corp. for National Research Initiatives
Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: ietf at isi.edu
Cc: gvaudre at NRI.Reston.VA.US, hostmib at andrew.cmu.edu
Subject: WG ACTION: Host Resources MIB
Date: Tue, 30 Jun 92 17:23:46 -0400
From: Greg Vaudreuil <gvaudre at NRI.Reston.VA.US>
Message-Id: <9206301723.aa07235 at IETF.NRI.Reston.VA.US>
A new Working Group has been formed in the Network Management Area.
For more information, please contact the Working Group chair Steven
Waldbusser or the Network Management Area Director, Chuck Davin
<jrd at lcs.mit.edu>.
Greg Vaudreuil
IESG Secretary
Host Resources MIB (hostmib)
Charter
Chair(s):
Steven Waldbusser <waldbusser at andrew.cmu.edu>
Mailing lists:
General Discussion:hostmib at andrew.cmu.edu
To Subscribe: hostmib-request at andrew.cmu.edu
Archive:
Description of Working Group:
The Host Resources MIB Working Group is chartered to produce exactly
one document that defines SNMP MIB objects that instrument
characteristics common to all internet hosts. The goal of this work is
to address the urgent operational need in the internet community for
management of host systems. Owing to this urgency, the Working Group
will focus exclusively on the alignment of existing MIB technology in
order to achieve common solutions in a timely manner.
For purposes of this effort, the term ``internet host'' is construed to
mean any computer that communicates with other similar computers
attached to the internet and that is directly used by one or more human
beings. Although the work of the Group does not necessarily apply to
devices whose primary function is communications services (e.g.,
terminal servers, routers, bridges, monitoring equipment), such
relevance is not explicitly precluded. The single MIB produced shall
instrument attributes common to all internet hosts including, for
example, both personal computers and systems that run variants of
Unix.
The methodology of this Working Group is to focus entirely on the
alignment of existing, enterprise-specific MIBs for SNMP that are
relevant to its task. The Group will work towards its goal by
distillation and generalization of these existing MIBs into a single,
common MIB definition.
Owing to the urgent operational need for managing host systems, this
effort will not be comprehensive in scope. Rather, the MIB produced by
this Group will be confined to critical information about hardware and
software configuration, processor and memory use, and data storage
capacities, backup, and use.
Owing to the lack of a well-understood and accepted architecture, the
Working Group will not address in any way, mechanisms that could be used
to monitor or control the use of licensed software products.
All definitions produced by the Group will be consistent with the SNMP
network management framework and all other internet-standard MIBs for
SNMP. Wherever possible, the definitions produced will make use of or
align with relevant work in progress with chartered working groups of
the IETF. Also, wherever possible, the Working Group will take into
consideration pre-existing, stable work produced by other, accredited
standards bodies.
Goals and Milestones:
Jul 92 First Working Group meeting. Discuss the initial proposed document.
Sep 92 Post an Internet Draft describing the Host Resources MIB.
Oct 92 Hold an interim meeting to discuss the current document.
Nov 92 Meet at the IETF plenary to identify changes necessary for Working
Group closure.
Dec 92 Submit the Host Resources MIB to the IESG as a Proposed Standard.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02021;
1 Jul 92 5:17 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03278; 1 Jul 92 5:18 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA16896>; Tue, 30 Jun 1992 18:39:55 -0700
Received: from BBN.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA16892>; Tue, 30 Jun 1992 18:39:52 -0700
Message-Id: <199207010139.AA16892 at venera.isi.edu>
From: Lyman Chapin <Lyman at bbn.com>
Subject: Internet in the New Republic
To: iab at isi.edu, iesg at NRI.Reston.VA.US, ietf at isi.edu
Date: Tue, 30 Jun 92 17:00:44 EDT
Mail-System-Version: <BBN/MacEMail_v1.3.0 at BBN.COM>
Reading the latest issue of The New Republic, I found in the "Correspondence"
section the following letter, which is reproduced below exactly as it appears
in TNR (including the rendition of INTERNET in all-caps):
"I agree with TNR that as presented, Perot's electronic town meeting is not
a good idea. Interactive TV is still a mass communications approach with
most of the information flowing top-down. The problem is still that there
is little involvement by the citizen. My proposal is that Perot use net-
worked electronic mail. Many studies have shown the tremendous impact that
such networks as the INTERNET have had on the university and high-tech
communities. I believe that the proposed NREN (National Research and
Education Network) should have facilitating political involvement as one
of its objectives.
Jason Olasky
Rockville, Maryland"
So, are we ready for prime time, or what?
- Lyman
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02074;
1 Jul 92 6:44 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04891; 1 Jul 92 6:45 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03231>; Tue, 30 Jun 1992 13:22:01 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA03209>; Tue, 30 Jun 1992 13:21:41 -0700
Received: from port13.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA05997; Tue, 30 Jun 92 16:19:17 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA16820; Tue, 30 Jun 92 13:18:20 PDT
Message-Id: <9206302018.AA16820 at aland.bbn.com>
To: ietf at isi.edu
Cc: "Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu>
Subject: re: informal notice of two IESG decisions
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 30 Jun 92 13:18:19 -0700
Sender: craig at aland.bbn.com
[I'm going to also post this to tcp-ip since some debate is raging there
as well and cross postings appear not to be working].
I've read the notes on this subject in some puzzlement. I was part of the
IESG until about a year ago and helped with some early versions of 1310
and did not remember that the IESG had ever had any obligation to announce
decisions *not* to forward a standard.
So I went and re-read RFC 1310. My conclusion is that the clause cited:
``The IESG shall determine whether a specification satisfies the
applicable criteria for the recommended action (see Sections 3.2
and 3.3 of this document) and shall communicate its findings to the
IETF to permit a final review by the general Internet community.''
was only intended to imply that no document could be proposed as a standard
without public review, *not* that documents that were not to be promoted
should receive public review. (This is what I'd remembered).
Lest I be accused of reading text to conform to my faulty recollections, some
supporting notes:
* The document suggests that specifications satisfying the recommended
action will typically receive both e-mail review and be publicly
presented to the IETF plenary. Clearly there's no point in a review
much less a public presentation if a specification is being rejected.
* Sections 3.2 and 3.3 only indicate status possible for standards
(or past standards). Thus "to satisfy the applicable criteria" can
be read as meaning "if the document is deemed appropriate for
standardization."
* the paragraph at the end of 2.6 indicates that following IAB approval
of the IESG action, the I-D will be published as an RFC. Again,
the only IESG-IAB approved decisions that result in RFCs are positive
decisions.
So I think the right step here is to point out that the phrase about
recommendations should be clarified to indicate what happens to rejected
proposals. (I actually think that they *should not* be publicly announced,
except, perhaps at the request of the author. No point in embarassing hard
working folks if their proposal gets rejected, unless they request publicity).
Craig Partridge
PS: I'll note that the IESG also appears followed proper procedure on all
other issues. Mr. Bernstein submitted a document which after considerable
review and work by his community became an I-D (RFC 1310 sect 2.4 says
documents viewed as completed may become I-Ds). The IESG is entitled to
ask committees to review the I-D -- apparently they did (the SAAG).
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05330;
1 Jul 92 13:25 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa19193; 1 Jul 92 13:26 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03628>; Wed, 1 Jul 1992 06:50:58 -0700
Received: from postman.osf.org by venera.isi.edu (5.65c/5.65+local-6)
id <AA03616>; Wed, 1 Jul 1992 06:50:51 -0700
Received: from rose.osf.org by postman.osf.org (5.64+/OSF 1.0)
id AA25263; Wed, 1 Jul 92 09:45:44 -0400
Received: by rose.osf.org (5.65/4.7) id AA21105; Wed, 1 Jul 92 09:49:06 -0400
Date: Wed, 1 Jul 92 09:49:06 -0400
From: hartman at osf.org
Message-Id: <9207011349.AA21105 at rose.osf.org>
To: ietf at isi.edu
Subject: BOF announcement: OSF DCE
Hello IETF fans,
The OSF DCE team would like to invite attendees of the July IETF
meeting to a BOF scheduled for Tuesday evening. Since OSF is just
a few blocks away from the hotel (well, big blocks, anyway), our
technical people will be available in larger numbers than we can
typically spare for "remote" meetings. They can field questions
about DCE. We will also have some managers on hand (such as me)
to field questions about OSF itself. Hope to see you there,
Doug Hartman
DCE engineering director, OSF
hartman at osf.org
617 621 8818
BOF abstract:
Tuesday July 14 7-10 pm
BOF OSF Distributed Computing Environment (DCE)
(Doug Hartman/OSF)
The Open Software Foundation Distributed Computing Environment (OSF DCE)
--- ---- -------- ---------- ----------- --------- ----------- ---------
This BOF will give IETF attendees an opportunity to learn more about the
OSF organization and the DCE technology. OSF is a cooperative research
and development organization chartered under the National Cooperative
Research Act. OSF has delivered technologies such as the OSF/Motif
graphic user interface and the OSF/1 operating system. OSF's most
recent technology offering, the Distributed Computing Environment, will
be of primary interest to attendees. Since OSF is located in Cambridge,
we expect to have a number of OSF DCE engineers on hand for the BOF.
The OSF DCE provides a full function integrated platform for developing
networked applications. OSF DCE includes both a technology specification,
available for use by anyone (similar to an RFC), as well as a licensable
implementation of the system in ANSI C for computers using the UNIX
operating system. Many leading computer system manufacturers are
developing implementations of DCE for their computers. Target OS
platforms include OSF/1, AIX, UNIX SVR4, HP-UX, Solaris, Windows, VMS,
MVS, as well as others.
DCE provides services above the transport layer for use by applications.
[The DCE implementation is written for the Internet protocol suite, but
can be easily adapted to use OSI transport protocols.] DCE is based on
remote procedure calls, and provides servers and administrative
tools for network credential management, global namespace management,
and a distributed file system. All services are integrated with
threads, use consistent naming and security models, and are designed to
scale to enterprise configurations in heterogenous environments.
In this BOF, we will provide status to those familiar with OSF and
DCE, and introduce those unfamiliar with OSF and/or DCE to the
current state of our work. We also hope to clarify points which have
sometimes been confused regarding OSF's purpose, methodology and results
to date. OSF's membership now numbers more than 300 organizations which
work with OSF to deliver and enhance our system software offerings.
We hope to work with the IETF community in areas of common interest.
DCE relates to a number of IETF-relevant activities, including
work on Kerberos, X.500, DNS, as well as popular distributed systems
products such as NCS and AFS. We will clarify these relationships
in the BOF.
[OSF's Distributed Management Environment, or DME, will likely be
the subject of a future IETF BOF.]
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06474;
1 Jul 92 14:37 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa22615; 1 Jul 92 14:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05552>; Wed, 1 Jul 1992 07:41:19 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05547>; Wed, 1 Jul 1992 07:41:16 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa03991;
1 Jul 92 10:20 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-rekhter-ipaddress-guide-01.txt
Date: Wed, 01 Jul 92 10:20:49 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011020.aa03991 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Guidelines for IP Address Allocation
Author(s) : Y. Rekhter, T. Li
Filename : draft-rekhter-ipaddress-guide-01.txt
Pages : 18
This paper provides guidelines for allocating IP addresses in the
Internet. These guidelines are intended to play an important role in
steering the Internet towards the Address Assignment and Aggregating
Strategy.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-rekhter-ipaddress-guide-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-rekhter-ipaddress-guide-01.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa08673;
1 Jul 92 17:13 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa29759; 1 Jul 92 17:14 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05582>; Wed, 1 Jul 1992 07:41:33 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05577>; Wed, 1 Jul 1992 07:41:30 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04196;
1 Jul 92 10:36 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-dhc-vendext-00.txt
Date: Wed, 01 Jul 92 10:36:07 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011036.aa04196 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Dynamic Host Configuration Working Group of the IETF.
Title : DHCP Vendor Extensions
Author(s) : R. Droms
Filename : draft-ietf-dhc-vendext-00.txt
Pages : 5
The Dynamic Host Configuration Protocol (DHCP) passes network
configuration information to hosts on a TCP/IP network. This document
defines the vendor extenstions that may appear in the 'vend' field in
a DHCP message.
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-dhc-vendext-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-dhc-vendext-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09640;
1 Jul 92 18:35 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04117; 1 Jul 92 18:36 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05570>; Wed, 1 Jul 1992 07:41:28 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05565>; Wed, 1 Jul 1992 07:41:24 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04090;
1 Jul 92 10:31 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-telnet-remflow-cntrl-01.txt
Date: Wed, 01 Jul 92 10:31:12 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011031.aa04090 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
TELNET Working Group of the IETF.
Title : Telnet Remote Flow Control Option
Author(s) : C. Hedrick, D. Borman
Filename : draft-ietf-telnet-remflow-cntrl-01.txt
Pages : 5
This memo describes a method of remotely toggling flow control between
a user telnet process and the attached terminal. Only flow control of
data being transmitted from the telnet process to the terminal is
considered. Many systems will also allow flow control of data from
the terminal to the telnet process, however there is seldom need to
change this behavior repeatedly during the session.
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-telnet-remflow-cntrl-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-telnet-remflow-cntrl-01.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09996;
1 Jul 92 20:26 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07355; 1 Jul 92 20:27 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05558>; Wed, 1 Jul 1992 07:41:22 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05553>; Wed, 1 Jul 1992 07:41:19 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04030;
1 Jul 92 10:26 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-tsuchiya-pip-overview-01.txt, .ps
Date: Wed, 01 Jul 92 10:26:35 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011026.aa04030 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Pip Overview and Examples
Author(s) : Paul Tsuchiya
Filename : draft-tsuchiya-pip-overview-01.txt, .ps
Pages : 23
Pip is an internet protocol that scales efficiently encodes policy. It
facilitates many advanced features, such as mobility and multiple
defaults routing, and has a well-bounded routing table lookup, and is
therefore fast. Pip is proposed as an alternative to the two "medium
term" proposals that emerged from the Road (Routing and Addressing)
group to deal with the dual IP problems of scaling and address
depletion.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-tsuchiya-pip-overview-01.txt" or
"get draft-tsuchiya-pip-overview-01.ps"
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-tsuchiya-pip-overview-01.txt" or
"SEND internet-drafts/draft-tsuchiya-pip-overview-01.ps"
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10164;
1 Jul 92 21:36 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09510; 1 Jul 92 21:37 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05563>; Wed, 1 Jul 1992 07:41:24 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05559>; Wed, 1 Jul 1992 07:41:21 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04062;
1 Jul 92 10:28 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-dns-mibext-01.txt, .ps
Date: Wed, 01 Jul 92 10:28:30 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011028.aa04062 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Domain Name System Working Group of the IETF.
Title : DNS MIB Extensions
Author(s) : Jon Saperia
Filename : draft-ietf-dns-mibext-01.txt, .ps
Pages : 64
This memo defines a set of DNS (Domain Name System) extensions that
have been created for the Internet MIB. When used in conjunction with
the Structure of Management Information (RFC1155), the Management
Information Base for Network Management of TCP/IP-based internets (RFC
1213) and the Simple Network Management Protocol (RFC 1157), it will
be possible to provide integrated network management of DNS client and
server software in standard TCP/IP based environments. This document
was produced by the DNS working group.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-dns-mibext-01.txt" or
"get draft-ietf-dns-mibext-01.ps"
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-dns-mibext-01.txt" or
"SEND internet-drafts/draft-ietf-dns-mibext-01.ps"
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10207;
1 Jul 92 21:50 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09873; 1 Jul 92 21:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05576>; Wed, 1 Jul 1992 07:41:30 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05571>; Wed, 1 Jul 1992 07:41:28 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04168;
1 Jul 92 10:35 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-dhc-protocol-03.txt, .ps
Date: Wed, 01 Jul 92 10:35:20 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011035.aa04168 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Dynamic Host Configuration Working Group of the IETF.
Title : Dynamic Host Configuration Protocol
Author(s) : R. Droms
Filename : draft-ietf-dhc-protocol-03.txt, .ps
Pages : 26
The Dynamic Host Configuration Protocol (DHCP) provides
configuration parameters to Internet hosts. DHCP consists of
three components: a protocol for delivering host--specific
configuration parameters from a DHCP server to a host; a mechanism
for allocation of network addresses to hosts; and a protocol through
which a collection of DHCP servers can cooperatively allocate network
addresses from a shared pool of network 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-dhc-protocol-03.txt" or
"get draft-ietf-dhc-protocol-03.ps"
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-dhc-protocol-03.txt" or
"SEND internet-drafts/draft-ietf-dhc-protocol-03.ps"
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10275;
1 Jul 92 22:28 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10777; 1 Jul 92 22:29 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05576>; Wed, 1 Jul 1992 07:41:30 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05571>; Wed, 1 Jul 1992 07:41:28 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04168;
1 Jul 92 10:35 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-dhc-protocol-03.txt, .ps
Date: Wed, 01 Jul 92 10:35:20 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011035.aa04168 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Dynamic Host Configuration Working Group of the IETF.
Title : Dynamic Host Configuration Protocol
Author(s) : R. Droms
Filename : draft-ietf-dhc-protocol-03.txt, .ps
Pages : 26
The Dynamic Host Configuration Protocol (DHCP) provides
configuration parameters to Internet hosts. DHCP consists of
three components: a protocol for delivering host--specific
configuration parameters from a DHCP server to a host; a mechanism
for allocation of network addresses to hosts; and a protocol through
which a collection of DHCP servers can cooperatively allocate network
addresses from a shared pool of network 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-dhc-protocol-03.txt" or
"get draft-ietf-dhc-protocol-03.ps"
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-dhc-protocol-03.txt" or
"SEND internet-drafts/draft-ietf-dhc-protocol-03.ps"
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10297;
1 Jul 92 22:39 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11086; 1 Jul 92 22:40 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06039>; Wed, 1 Jul 1992 07:51:40 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA06034>; Wed, 1 Jul 1992 07:51:37 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04256;
1 Jul 92 10:39 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-dhc-bootp-00.txt
Date: Wed, 01 Jul 92 10:39:17 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011039.aa04256 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Dynamic Host Configuration Working Group of the IETF.
Title : Interoperation Between DHCP and BOOTP
Author(s) : R. Droms
Filename : draft-ietf-dhc-bootp-00.txt
Pages : 3
The Dynamic Host Configuration Protocol (DHCP) provides a superset
of the functions provided by the Bootstrap Protocol (BOOTP). Some
DHCP participants may not be configured so as to be compatible. This
document describes the interactions between DHCP and BOOTP network
participants and mechanisms for accommodating incompatibilities
between DHCP participants.
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-dhc-bootp-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-dhc-bootp-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10346;
1 Jul 92 23:00 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11608; 1 Jul 92 23:01 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA09742>; Wed, 1 Jul 1992 09:22:49 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA09737>; Wed, 1 Jul 1992 09:22:44 -0700
Date: Wed, 1 Jul 1992 09:20:47 -0700
Posted-Date: Wed, 1 Jul 1992 09:20:47 -0700
Message-Id: <199207011620.AA04526 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA04526>; Wed, 1 Jul 1992 09:20:47 -0700
To: craig at aland.bbn.com, ietf at isi.edu
Subject: re: informal notice of two IESG decisions
Cc: I at isi.edu, brnstnd at kramden.acf.nyu.edu
As the person responsible for putting together the final wording in
RFC-1310, I wish to affirm that Craig Partridge has correctly
interpreted the intent of the document. We will try to improve the
wording of the next version to remove some of the ambiguities...
Bob Braden
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10917;
2 Jul 92 0:51 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15013; 2 Jul 92 0:52 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA12891>; Wed, 1 Jul 1992 10:25:09 -0700
From: Joyce Reynolds <jkrey at isi.edu>
Received: from akamai.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA12867>; Wed, 1 Jul 1992 10:25:02 -0700
Date: Wed, 1 Jul 1992 10:23:22 -0700
Posted-Date: Wed, 1 Jul 1992 10:23:22 -0700
Message-Id: <199207011723.AA02180 at akamai.isi.edu>
Received: by akamai.isi.edu (5.65c/4.0.3-4)
id <AA02180>; Wed, 1 Jul 1992 10:23:22 -0700
To: ietf at isi.edu, rfc-dist at nic.ddn.mil
Subject: RFC1348 on DNS NSAP RRs
Cc: jkrey at isi.edu
A new Request for Comments is now available in online RFC libraries.
RFC 1348:
Title: DNS NSAP RRs
Author: B. Manning
Mailbox: bmanning at rice.edu
Pages: 4
Characters: 6,871
Updates: RFCs 1034, 1035
This RFC defines the format of two new Resource Records (RRs) for the
Domain Name System (DNS), and reserves corresponding DNS type mnemonic
and numerical codes. This format may be used with the any proposal
that has variable length addresses, but is targeted for CLNP use.
This memo assumes that the reader is familiar with the DNS.
This memo defines an Experimental Protocol for the Internet community.
Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" 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 NRI.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.
RFCs can be obtained via FTP from FTP.NISC.SRI.COM, NIS.NSF.NET,
NISC.JVNC.NET, VENERA.ISI.EDU, WUARCHIVE.WUSTL.EDU, SRC.DOC.IC.AC.UK,
FTP.CONCERT.NET, or 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 NIC at NIC.DDN.MIL. 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 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
======================================================================
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa11009;
2 Jul 92 1:14 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15497; 2 Jul 92 1:15 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA05576>; Wed, 1 Jul 1992 07:41:30 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA05571>; Wed, 1 Jul 1992 07:41:28 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa04168;
1 Jul 92 10:35 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-dhc-protocol-03.txt, .ps
Date: Wed, 01 Jul 92 10:35:20 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011035.aa04168 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Dynamic Host Configuration Working Group of the IETF.
Title : Dynamic Host Configuration Protocol
Author(s) : R. Droms
Filename : draft-ietf-dhc-protocol-03.txt, .ps
Pages : 26
The Dynamic Host Configuration Protocol (DHCP) provides
configuration parameters to Internet hosts. DHCP consists of
three components: a protocol for delivering host--specific
configuration parameters from a DHCP server to a host; a mechanism
for allocation of network addresses to hosts; and a protocol through
which a collection of DHCP servers can cooperatively allocate network
addresses from a shared pool of network 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-dhc-protocol-03.txt" or
"get draft-ietf-dhc-protocol-03.ps"
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-dhc-protocol-03.txt" or
"SEND internet-drafts/draft-ietf-dhc-protocol-03.ps"
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa11030;
2 Jul 92 1:22 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15619; 2 Jul 92 1:23 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA14691>; Wed, 1 Jul 1992 10:58:01 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA14686>; Wed, 1 Jul 1992 10:57:58 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05718;
1 Jul 92 13:48 EDT
Mime-Version: 1.0
Content-Type: text/plain; Charset="us-ascii"
To: IETF <ietf at isi.edu>
Cc: IESG at NRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at NRI.Reston.VA.US>
Subject: Last Call: IP over HIPPI to Proposed Standard
Date: Wed, 01 Jul 92 13:48:09 -0400
Sender: gvaudre at NRI.Reston.VA.US
Message-Id: <9207011348.aa05718 at IETF.NRI.Reston.VA.US>
The IESG has received a request from John Renwick and Andy Nicholson to
recommend the Internet Draft <draft-renwick-hippilan-02> as a Proposed
Standard. This document is an independent submission to the IESG. It
was initially posted as an Internet Draft on January 3rd, 1992 and has
been reviewed at a BOF Session at the San Diego IETF meeting.
The IESG plans to issue a recommendation after the IETF Plenary meeting
in Boston and solicts final comments on this elevation. Please send
any comments to the iesg at nri.reston.va.us, or ietf at isi.edu mailing
lists by July 20th.
Greg Vaudreuil
IESG Secretary
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02182;
2 Jul 92 2:51 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00679; 2 Jul 92 2:52 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA19953>; Wed, 1 Jul 1992 12:33:09 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA19947>; Wed, 1 Jul 1992 12:33:03 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa07156;
1 Jul 92 15:29 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-iplpdn-shortcutrouting-01.txt
Date: Wed, 01 Jul 92 15:29:31 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207011529.aa07156 at IETF.NRI.Reston.VA.US>
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
IP over Large Public Data Networks Working Group of the IETF.
Title : Shortcut Routing: Discovery and Routing over Large
Public Data Networks
Author(s) : P. Tsuchiya, J. Lawrence
Filename : draft-ietf-iplpdn-shortcutrouting-01.txt
Pages : 29
Various RFCs and Internet Drafts specify how to run IP or CLNP over
various public data network services. These documents specify the
encapsulation to be used, and sometimes specify protocol techniques to
aid in discovery and routing functions. None of the specifications,
however, solve the problem of discovery and routing in the full,
especially with respect to scaling. This RFC extends these
specifications by describing a general and scalable technique, called
shortcut routing, for discovery and routing of any connection-less
internet protocol over any switched data network (connectionless or
connection-oriented).
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-iplpdn-shortcutrouting-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-iplpdn-shortcutrouting-01.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02273;
2 Jul 92 3:49 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa01836; 2 Jul 92 3:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25373>; Wed, 1 Jul 1992 14:17:05 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA25350>; Wed, 1 Jul 1992 14:16:56 -0700
Date: Wed, 1 Jul 1992 14:14:59 -0700
Posted-Date: Wed, 1 Jul 1992 14:14:59 -0700
Message-Id: <199207012114.AA04651 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA04651>; Wed, 1 Jul 1992 14:14:59 -0700
To: ietf at isi.edu
Subject: IAB Protocol Action: Old Protocols to Historical Status
Cc: iab at isi.edu, iab-stds at isi.edu, iesg at isi.edu
The IAB has accepted the IESG recommendation that the following
protocols be moved to Historic status:
o RFC 734 "SUPDUP"
o RFC 913 "Simple File Transfer Protocol"
o RFC 953 "Hostname Server"
o RFC 1037 "NFILE - a file access protocol"
These protocols, which have been Proposed Standards longer than the
maximum 2 years, are not likely to advance in the near term and are
therefore being removed from the standards track.
Bob Braden
for the IAB
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02294;
2 Jul 92 3:55 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa01944; 2 Jul 92 3:57 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25787>; Wed, 1 Jul 1992 14:25:09 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA25758>; Wed, 1 Jul 1992 14:25:00 -0700
Date: Wed, 1 Jul 1992 14:23:04 -0700
Posted-Date: Wed, 1 Jul 1992 14:23:04 -0700
Message-Id: <199207012123.AA04665 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA04665>; Wed, 1 Jul 1992 14:23:04 -0700
To: ietf at isi.edu
Subject: IAB Protocol Action: PCMAIL to Informational
Cc: iab at isi.edu, iab-stds at isi.edu, iesg at isi.edu
The IAB has accepted the IESG recommendation that RFC 1056, "PCMAIL", be
moved off the Standards Track and be republished as an Informational
Protocol.
Rationale:
PCMAIL, published in June 1988, is one of several distributed mail
systems in use in the Internet. PCMAIL is widely used by a
community of users of a particular vendors software, but after 4
years as a Proposed Standard, it has not attained the level of
independent implementation experience required for Draft Standard.
Historical Status implies that the the protocol is not longer
recommended for use in the modern Internet. This is not the case
for PCMAIL and the IESG has recommended that is be classified as an
informational document as if it were a vendor proprietary protocol.
Bob Braden
for the IAB
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02897;
2 Jul 92 8:22 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08616; 2 Jul 92 8:23 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA04616>; Wed, 1 Jul 1992 17:34:00 -0700
Received: from gizmo.bellcore.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA04612>; Wed, 1 Jul 1992 17:33:57 -0700
Received: by gizmo.bellcore.com (5.61/1.34)
id AA05521; Wed, 1 Jul 92 20:32:17 -0400
Date: Wed, 1 Jul 92 20:32:17 -0400
From: Michael O'Dell <mo at gizmo.bellcore.com>
Message-Id: <9207020032.AA05521 at gizmo.bellcore.com>
To: ietf at isi.edu
Subject: 160-bit addresses
this is sheer madness. if you want to absolutely guarantee that
internetworking as we know it is excluded from the emerging
wireless technologies, go right ahead and mandate 160-bit addresses.
the only hope is that the wireless folks will infarc from sustained
laughter before they run us out of town on a rail, as we would
richly deserve.
this is too silly to be believed.
-Mike O'Dell
Resident Crank
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04352;
2 Jul 92 10:03 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13453; 2 Jul 92 10:04 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA29209>; Wed, 1 Jul 1992 15:40:19 -0700
Received: from MACE.LCS.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA29199>; Wed, 1 Jul 1992 15:40:14 -0700
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
id AA17969; Wed, 1 Jul 92 18:38:32 EDT
Message-Id: <9207012238.AA17969 at mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd at thyme.lcs.mit.edu>
To: Internet Engineering Task Force <ietf at isi.edu>
Cc: ltaylor at ginger.lcs.mit.edu
Subject: IETF Social Registration -- Last Chance
Date: Wed, 01 Jul 92 18:38:30 -0400
Sender: jrd at mace.lcs.mit.edu
Friends,
The last chance to register for the Monday night IETF social event
(see attached) is nearly upon us. We won't be able to accommodate any
registrations (via email or otherwise) that are not *received* here
before close of business, Wednesday, 8 July.
Please send email registrations to ltaylor at ginger.lcs.mit.edu. Postal
registration should be directed to the address below (remember to
account for the holidays).
Also, if you have registered previously to this posting and have not
received an email confirmation from either Lisa, Ted, or me, please
send email to ltaylor at ginger.lcs.mit.edu requesting that confirmation.
All aboard!
Lisa, Ted, and Chuck
B I T S A N D B I T E S
The IETF Social in Cambridge, Massachusetts
Monday, 13 July 1992
7:00 to 10:00 PM
The Monday night social event has become an enjoyable tradition at
plenary meetings of the Internet Engineering Task Force. The upcoming
plenary meeting in Cambridge during the week of 13--17 July will
continue that tradition.
Our social event for July should combine a pleasant evening of eating
and socializing with the opportunity to admire and play with the
artifacts of our computing and networking history. The venue for our
gathering will be
The Computer Museum
300 Congress Street
Boston, Massachusetts
Arrangements have been made for exclusive enjoyment of the museum by
those stepping out with us on Monday evening. Every nook and cranny of
this extensive collection of computing artifacts, interactive
exhibits, and nostalgic memorabilia will be open for view. Wandering
through this maze of familiar and unfamiliar computing technology with
new friends and old should be educational, relaxing, and fun.
But because all this fun can make a person hungry, arrangements have
also been made for refreshments to sustain us as we confabulate and
explore. Ample quantities of hors d'ouevres, finger foods, and edibles
of several kinds will be laid on at the museum to fortify us during
our visit. A full cash bar will also be available.
Sound too good to miss? We think so, too. To join your IETF friends in
what promises to be a delightful evening, please return the attached
registration form to the indicated address. The cost of this outing to
enthusiasts who register and pre-pay on or before June 15, 1992, will
be a modest 38 dollars per person. For those whose enthusiasm peaks
only as the occasion draws very near, the cost will be a somewhat less
modest 43 dollars per person.
Although the cost of this outing (for enthusiasts) is just a tad more
than that for previous IETF socials, we hope you won't thereby think
less of us as hosts and will correctly attribute any difference to the
high cost of Boston living.
We look forward to your company on Monday night!
Lisa, Ted, and Chuck
Massachusetts Institute of Technology
------- Cut Here -------------------------------------------------------
Registration Form
B I T S A N D B I T E S
The IETF Social in Cambridge, Massachusetts
Monday, 13 July 1992
7:00 to 10:00 PM
Your Name:
-------------------------------------------------------------
Your Mailing Address:
-------------------------------------------------------------
-------------------------------------------------------------
Your Electronic Mail Address:
------------------------------------------
Menu Preferences:
While we cannot guarantee individuals a particular menu, this
information may help us to lay the table in closer concert with our
guests' preferences. Check the relevant box(es):
[ ] I like lots of vegetables.
[ ] I don't like dairy products.
[ ] I eat anything.
Payment Options:
Please check those that apply and remit the total. Make checks payable
to "M. I. T. -- IETF Social Account." Attendance is limited to the
first 200 pre-paid registrations. Information on transportation to
the Museum is attached.
[ ] Latecomer Payment Option (after 15 June 1992) 43.00
[ ] Optional Round-trip Charter Bus Transportation 8.00
(See below for more details regarding options
for transportation to the Computer Museum.)
---------
TOTAL:
-------------
Please return this form, together with your payment to the address
below. We are not equipped to honor credit cards, major or otherwise.
Receipts and admission credentials will be distributed at the IETF
meeting.
IETF Social Registration
M.I.T. Laboratory for Computer Science, NE43-508
545 Technology Square
Cambridge, MA 02139
------------------------------------------------------------------------
Getting To and From
The Computer Museum
300 Congress Street
Boston, Massachusetts
The Institute and the conference hotel for the July IETF meeting are
located in Cambridge. The Computer Museum is located in Boston, a
nearby suburb of Cambridge. There are several ways to get from the
conference hotel to the museum and back again.
(1) The Computer Museum may be reached by private or rented
automobile. However, on-street parking for private automobiles is
very limited near the Computer Museum. Driving and parking in Boston
is an acquired taste, not necessarily recommended to visitors.
(2) The Computer Museum may be reached via the public transit system
("The T"). The museum is conveniently located about 2-3 blocks from
the South Station subway stop on the Red Line. The subway station that
is closest to the conference hotel is the Kendall Square station
(where Charlie paid his dime, as the song says). The subway ride is
only 3 stops (no changes).
The Hyatt runs a free shuttle van between the conference hotel and the
Kendall Square T station. For guests at the alternate hotel (the
Marriot), the T station is just outside the door. Although it may have
cost Charlie a dime to ride the T, it will cost you $1.70 round-trip.
It is also possible to walk between the Kendall Square T station and
the Hyatt hotel, although this course is for the more vigorous. The
route traverses the entire M.I.T. campus and requires perhaps 20
minutes. Maps will be available at the IETF meeting.
(3) The Computer Museum may be reached by taxi. The going rate from
the conference hotel to the museum is about eight or nine dollars, one
way.
(4) The Computer Museum may be reached by chartered bus, arranged by
your hosts at M.I.T. Bus transportation between the Hyatt hotel and
the museum will be arranged for those who pre-register and pre-pay for
this extra (and optional!) service. The cost is 8.00 per person (see
registration form). The bus service will be more or less continuous,
so that, to some limited extent, subscribers of the bus service will
be able to arrive and depart as they please.
####
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05122;
2 Jul 92 10:40 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15161; 2 Jul 92 10:41 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03022>; Wed, 1 Jul 1992 16:56:13 -0700
Received: from BBN.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA03010>; Wed, 1 Jul 1992 16:56:08 -0700
Message-Id: <199207012356.AA03010 at venera.isi.edu>
From: Lyman Chapin <lyman at bbn.com>
Subject: IAB proposal for CIDR and IPv7
To: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Date: Wed, 1 Jul 92 19:08:10 EDT
Mail-System-Version: <BBN/MacEMail_v1.3.0 at BBN.COM>
A summary of the IAB's proposals in response
to the work of the ROAD group.
----------------------------------------------------------------------
During its meeting in Kobe, Japan on June 18 and 19, the IAB
reviewed the draft report of the ROAD group concerning the
problems of "running out of IP network numbers" and "Internet
routing table size explosion", and a companion report from
the IESG of "IESG Deliberations on Routing and Addressing".
The IAB's analysis of the many possibilities suggested by these
two reports led it to the following conclusions, which are docu-
mented in an internet-draft entitled "IP Version 7":
1) The ROAD group's work, compiled over a period of four months,
makes it very clear that the problems of too few IP addresses
and too many Internet routes are real and immediate, and represent
a clear and present danger to the future successful growth of the
worldwide Internet. The IAB was therefore unable to agree with the
IESG recommendation to pursue an additional six-month program of
further analysis before deciding on a plan for dealing with the
ROAD problems. The detailed design, engineering, and deployment
work must begin now, and it is therefore imperative that the
efforts of the Internet community be focussed on a common goal.
2) The IETF should aggresively pursue the work to engineer CIDR
("classless inter-domain routing", described in RFC 1338),
including the extensions to the inter-AD routing protocols to
support variable-length masks/prefixes, and the associated
address administration paradigm.
3) Since CIDR postpones, but does not prevent, the eventual
exhaustion of the 32-bit IP address space, the IETF should
also aggressively pursue a detailed technical and organizational
plan for using CLNP (the OSI internetwork protocol defined by the
ISO 8473 standard, which uses 160-bit addresses) as the basis for
a new version of IP (which we have dubbed "IP version 7"), succeeding
over time the current version of IP (version 4) in the Internet. An
initial description of how CLNP could be used for this purpose within
the current TCP/IP architecture and with the existing Internet
applications is described in RFC 1347.
4) CLNP has larger addresses than IP, but like IP it lacks features
that are expected to be necessary to support future Internet appli-
cations and services. The IAB therefore also encourages the
pursuit of research in areas such as policy-based routing, route
preallocation and cacheing, and deterministic end-to-end QOS mainten-
ance (for real-time and other delay-variance sensitive traffic).
It is important to understand that (3) above does NOT mean "adopting
OSI" or "migrating to OSI" or "converting the Internet to use GOSIP
protocols". The IAB recommends only that a new version of IP (IPv7),
with much wider addresses and a more extensible header, be based on the
existing CLNP. IPv7 is intended to be deployed within the current Internet
TCP/IP architecture, not as part of an "OSI stack".
There are, of course, many issues that must be resolved before CIDR and
IPv7 can actually be deployed in the operational Internet. No one should
imagine that there is not still a great deal of work to be done, notwith-
standing the efforts that have already been expended by several of the
IETF working groups and by the members of the ROAD group over the past
year.
In recommending that the ROAD problems be addressed by a combination of
CIDR, IPv7, and further research, the IAB has deliberately chosen NOT to
recommend any of the possible alternatives, so as to present a single
focal point for the community consisting of what we believe to be the
best technical solutions to the problems. This should not be construed
as a blanket "condemnation" of the alternative proposals that have been
floated in various parts of the IETF. However, we believe that the normal
IETF process of "let a thousand [proposals] bloom", in which the "right
choice" emerges gradually and naturally from a dialectic of deployment and
experimentation, would in this case expose the community to too great a
risk that the Internet will drown in its own explosive success before
the process had run its course. The IAB does not take this step lightly,
nor without regard for the Internet traditions that are unavoidably
offended by it. We look forward to a lively discussion of these
conclusions during the upcoming IETF meeting in Boston.
- Lyman Chapin
IAB chair
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06250;
2 Jul 92 12:01 EDT
Received: from wdl1.wdl.loral.com by NRI.Reston.VA.US id aa18358;
2 Jul 92 12:02 EDT
Received: by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA15770; Thu, 2 Jul 92 07:57:56 -0700
Received: from mwunix.mitre.org by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA15764; Thu, 2 Jul 92 07:57:36 -0700
Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA20284; Thu, 2 Jul 92 10:54:54 -0400
Received: from loghost.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA16031; Thu, 2 Jul 92 10:57:07 EDT
Resent-Message-Id: <9207021457.AA16031 at smiley.mitre.org.stc>
Received: from mwunix.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA15930; Thu, 2 Jul 92 10:52:12 EDT
Received: from gateway.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA19868; Thu, 2 Jul 92 10:49:55 -0400
Return-Path: <owner-ietf at ISI.EDU>
Received: from venera.isi.edu by gateway.mitre.org (5.61/SMI-2.2)
id AA18709; Thu, 2 Jul 92 10:51:20 -0400
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA29209>; Wed, 1 Jul 1992 15:40:19 -0700
Received: from MACE.LCS.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA29199>; Wed, 1 Jul 1992 15:40:14 -0700
Received: from MACE.LCS.MIT.EDU by mace.LCS.MIT.EDU via TCP with SMTP
id AA17969; Wed, 1 Jul 92 18:38:32 EDT
Message-Id: <9207012238.AA17969 at mace.LCS.MIT.EDU>
From: "James R. (Chuck) Davin" <jrd at thyme.lcs.mit.edu>
To: Internet Engineering Task Force <ietf at isi.edu>
Cc: ltaylor at ginger.lcs.mit.edu
Subject: IETF Social Registration -- Last Chance
Date: Wed, 01 Jul 92 18:38:30 -0400
Resent-To: tsig at wdl1.wdl.loral.com
Resent-Date: Thu, 02 Jul 92 10:57:07 -0400
Resent-From: "Jeffrey A. Edelheit" <edelheit at smiley.mitre.org>
Sender: tsig-request at wdl1.wdl.loral.com
==================================================================
>>> Submissions to the tsig list: tsig at wdl1.wdl.loral.com
>>> Additions/deletions/questions: tsig-request at wdl1.wdl.loral.com
>>> Archive Server: listserv at wdl1.wdl.loral.com
==================================================================
Friends,
The last chance to register for the Monday night IETF social event
(see attached) is nearly upon us. We won't be able to accommodate any
registrations (via email or otherwise) that are not *received* here
before close of business, Wednesday, 8 July.
Please send email registrations to ltaylor at ginger.lcs.mit.edu. Postal
registration should be directed to the address below (remember to
account for the holidays).
Also, if you have registered previously to this posting and have not
received an email confirmation from either Lisa, Ted, or me, please
send email to ltaylor at ginger.lcs.mit.edu requesting that confirmation.
All aboard!
Lisa, Ted, and Chuck
B I T S A N D B I T E S
The IETF Social in Cambridge, Massachusetts
Monday, 13 July 1992
7:00 to 10:00 PM
The Monday night social event has become an enjoyable tradition at
plenary meetings of the Internet Engineering Task Force. The upcoming
plenary meeting in Cambridge during the week of 13--17 July will
continue that tradition.
Our social event for July should combine a pleasant evening of eating
and socializing with the opportunity to admire and play with the
artifacts of our computing and networking history. The venue for our
gathering will be
The Computer Museum
300 Congress Street
Boston, Massachusetts
Arrangements have been made for exclusive enjoyment of the museum by
those stepping out with us on Monday evening. Every nook and cranny of
this extensive collection of computing artifacts, interactive
exhibits, and nostalgic memorabilia will be open for view. Wandering
through this maze of familiar and unfamiliar computing technology with
new friends and old should be educational, relaxing, and fun.
But because all this fun can make a person hungry, arrangements have
also been made for refreshments to sustain us as we confabulate and
explore. Ample quantities of hors d'ouevres, finger foods, and edibles
of several kinds will be laid on at the museum to fortify us during
our visit. A full cash bar will also be available.
Sound too good to miss? We think so, too. To join your IETF friends in
what promises to be a delightful evening, please return the attached
registration form to the indicated address. The cost of this outing to
enthusiasts who register and pre-pay on or before June 15, 1992, will
be a modest 38 dollars per person. For those whose enthusiasm peaks
only as the occasion draws very near, the cost will be a somewhat less
modest 43 dollars per person.
Although the cost of this outing (for enthusiasts) is just a tad more
than that for previous IETF socials, we hope you won't thereby think
less of us as hosts and will correctly attribute any difference to the
high cost of Boston living.
We look forward to your company on Monday night!
Lisa, Ted, and Chuck
Massachusetts Institute of Technology
------- Cut Here -------------------------------------------------------
Registration Form
B I T S A N D B I T E S
The IETF Social in Cambridge, Massachusetts
Monday, 13 July 1992
7:00 to 10:00 PM
Your Name:
-------------------------------------------------------------
Your Mailing Address:
-------------------------------------------------------------
-------------------------------------------------------------
Your Electronic Mail Address:
------------------------------------------
Menu Preferences:
While we cannot guarantee individuals a particular menu, this
information may help us to lay the table in closer concert with our
guests' preferences. Check the relevant box(es):
[ ] I like lots of vegetables.
[ ] I don't like dairy products.
[ ] I eat anything.
Payment Options:
Please check those that apply and remit the total. Make checks payable
to "M. I. T. -- IETF Social Account." Attendance is limited to the
first 200 pre-paid registrations. Information on transportation to
the Museum is attached.
[ ] Latecomer Payment Option (after 15 June 1992) 43.00
[ ] Optional Round-trip Charter Bus Transportation 8.00
(See below for more details regarding options
for transportation to the Computer Museum.)
---------
TOTAL:
-------------
Please return this form, together with your payment to the address
below. We are not equipped to honor credit cards, major or otherwise.
Receipts and admission credentials will be distributed at the IETF
meeting.
IETF Social Registration
M.I.T. Laboratory for Computer Science, NE43-508
545 Technology Square
Cambridge, MA 02139
------------------------------------------------------------------------
Getting To and From
The Computer Museum
300 Congress Street
Boston, Massachusetts
The Institute and the conference hotel for the July IETF meeting are
located in Cambridge. The Computer Museum is located in Boston, a
nearby suburb of Cambridge. There are several ways to get from the
conference hotel to the museum and back again.
(1) The Computer Museum may be reached by private or rented
automobile. However, on-street parking for private automobiles is
very limited near the Computer Museum. Driving and parking in Boston
is an acquired taste, not necessarily recommended to visitors.
(2) The Computer Museum may be reached via the public transit system
("The T"). The museum is conveniently located about 2-3 blocks from
the South Station subway stop on the Red Line. The subway station that
is closest to the conference hotel is the Kendall Square station
(where Charlie paid his dime, as the song says). The subway ride is
only 3 stops (no changes).
The Hyatt runs a free shuttle van between the conference hotel and the
Kendall Square T station. For guests at the alternate hotel (the
Marriot), the T station is just outside the door. Although it may have
cost Charlie a dime to ride the T, it will cost you $1.70 round-trip.
It is also possible to walk between the Kendall Square T station and
the Hyatt hotel, although this course is for the more vigorous. The
route traverses the entire M.I.T. campus and requires perhaps 20
minutes. Maps will be available at the IETF meeting.
(3) The Computer Museum may be reached by taxi. The going rate from
the conference hotel to the museum is about eight or nine dollars, one
way.
(4) The Computer Museum may be reached by chartered bus, arranged by
your hosts at M.I.T. Bus transportation between the Hyatt hotel and
the museum will be arranged for those who pre-register and pre-pay for
this extra (and optional!) service. The cost is 8.00 per person (see
registration form). The bus service will be more or less continuous,
so that, to some limited extent, subscribers of the bus service will
be able to arrive and depart as they please.
####
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06614;
2 Jul 92 12:49 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa20447; 2 Jul 92 12:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA10917>; Wed, 1 Jul 1992 20:37:25 -0700
Received: from cs.columbia.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA10913>; Wed, 1 Jul 1992 20:37:22 -0700
Received: from minetta.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP
id AA04051; Wed, 1 Jul 1992 23:35:34 -0400
Received: by minetta.cs.columbia.edu (4.1/SMI-4.1+)
id AA13790; Wed, 1 Jul 92 23:35:33 EDT
Date: Wed, 1 Jul 92 23:35:33 EDT
From: John Ioannidis <ji at minetta.cs.columbia.edu>
Message-Id: <9207020335.AA13790 at minetta.cs.columbia.edu>
To: ietf at isi.edu
Subject: Ride from NYC to Boston
Sender: John Heldenprogrammer Ioannidis <ji at cs.columbia.edu>
Reply-To: ji at cs.columbia.edu
Organization: Columbia University Department of Computer Science
X-Date: 13 Messidor An CC
Hello,
Is anyone driving from the Greater New York Metropolitan Area to
Boston for the 24th IETF, on Sunday 7/12? Mind if I tag along?
Naturally, I'll share gas, tolls, and driving time.
Thanks,
/ji
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09338;
2 Jul 92 20:06 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08142; 2 Jul 92 20:07 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA23258>; Thu, 2 Jul 1992 06:04:04 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA23252>; Thu, 2 Jul 1992 06:04:00 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa03321;
2 Jul 92 8:51 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mimemhs-mapping-00.txt
Date: Thu, 02 Jul 92 08:51:24 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207020851.aa03321 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
MIME-MHS Interworking Working Group of the IETF.
Title : Mapping between X.400 and RFC-822 Message Bodies
Author(s) : H. Alvestrand, S. Hardcastle-Kille, R. Miles, M. Rose,
S. Thompson
Filename : draft-ietf-mimemhs-mapping-00.txt
Pages : 14
Abstract not provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mimemhs-mapping-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-mimemhs-mapping-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09369;
2 Jul 92 20:13 EDT
Received: from wdl1.wdl.loral.com by NRI.Reston.VA.US id aa08270;
2 Jul 92 20:14 EDT
Received: by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA29482; Wed, 1 Jul 92 11:41:04 -0700
Received: from mwunix.mitre.org by wdl1.wdl.loral.com (5.61+++/WDL-3.11)
id AA29446; Wed, 1 Jul 92 11:40:57 -0700
Received: from smiley.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA12379; Wed, 1 Jul 92 14:38:28 -0400
Received: from loghost.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA04955; Wed, 1 Jul 92 14:40:40 EDT
Resent-Message-Id: <9207011840.AA04955 at smiley.mitre.org.stc>
Received: from mwunix.mitre.org by smiley.mitre.org.stc (4.1/SMI-4.1)
id AA02871; Wed, 1 Jul 92 14:25:36 EDT
Received: from gateway.mitre.org by mwunix.mitre.org (5.61/SMI-2.2)
id AA11481; Wed, 1 Jul 92 14:23:17 -0400
Return-Path: <owner-ietf at ISI.EDU>
Received: from venera.isi.edu by gateway.mitre.org (5.61/SMI-2.2)
id AA10324; Wed, 1 Jul 92 14:24:36 -0400
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03628>; Wed, 1 Jul 1992 06:50:58 -0700
Received: from postman.osf.org by venera.isi.edu (5.65c/5.65+local-6)
id <AA03616>; Wed, 1 Jul 1992 06:50:51 -0700
Received: from rose.osf.org by postman.osf.org (5.64+/OSF 1.0)
id AA25263; Wed, 1 Jul 92 09:45:44 -0400
Received: by rose.osf.org (5.65/4.7) id AA21105; Wed, 1 Jul 92 09:49:06 -0400
Date: Wed, 1 Jul 92 09:49:06 -0400
From: hartman at osf.org
Message-Id: <9207011349.AA21105 at rose.osf.org>
To: ietf at isi.edu
Subject: BOF announcement: OSF DCE
Resent-To: tsig at wdl1.wdl.loral.com
Resent-Date: Wed, 01 Jul 92 14:40:38 -0400
Resent-From: "Jeffrey A. Edelheit" <edelheit at smiley.mitre.org>
Sender: tsig-request at wdl1.wdl.loral.com
==================================================================
>>> Submissions to the tsig list: tsig at wdl1.wdl.loral.com
>>> Additions/deletions/questions: tsig-request at wdl1.wdl.loral.com
>>> Archive Server: listserv at wdl1.wdl.loral.com
==================================================================
Hello IETF fans,
The OSF DCE team would like to invite attendees of the July IETF
meeting to a BOF scheduled for Tuesday evening. Since OSF is just
a few blocks away from the hotel (well, big blocks, anyway), our
technical people will be available in larger numbers than we can
typically spare for "remote" meetings. They can field questions
about DCE. We will also have some managers on hand (such as me)
to field questions about OSF itself. Hope to see you there,
Doug Hartman
DCE engineering director, OSF
hartman at osf.org
617 621 8818
BOF abstract:
Tuesday July 14 7-10 pm
BOF OSF Distributed Computing Environment (DCE)
(Doug Hartman/OSF)
The Open Software Foundation Distributed Computing Environment (OSF DCE)
--- ---- -------- ---------- ----------- --------- ----------- ---------
This BOF will give IETF attendees an opportunity to learn more about the
OSF organization and the DCE technology. OSF is a cooperative research
and development organization chartered under the National Cooperative
Research Act. OSF has delivered technologies such as the OSF/Motif
graphic user interface and the OSF/1 operating system. OSF's most
recent technology offering, the Distributed Computing Environment, will
be of primary interest to attendees. Since OSF is located in Cambridge,
we expect to have a number of OSF DCE engineers on hand for the BOF.
The OSF DCE provides a full function integrated platform for developing
networked applications. OSF DCE includes both a technology specification,
available for use by anyone (similar to an RFC), as well as a licensable
implementation of the system in ANSI C for computers using the UNIX
operating system. Many leading computer system manufacturers are
developing implementations of DCE for their computers. Target OS
platforms include OSF/1, AIX, UNIX SVR4, HP-UX, Solaris, Windows, VMS,
MVS, as well as others.
DCE provides services above the transport layer for use by applications.
[The DCE implementation is written for the Internet protocol suite, but
can be easily adapted to use OSI transport protocols.] DCE is based on
remote procedure calls, and provides servers and administrative
tools for network credential management, global namespace management,
and a distributed file system. All services are integrated with
threads, use consistent naming and security models, and are designed to
scale to enterprise configurations in heterogenous environments.
In this BOF, we will provide status to those familiar with OSF and
DCE, and introduce those unfamiliar with OSF and/or DCE to the
current state of our work. We also hope to clarify points which have
sometimes been confused regarding OSF's purpose, methodology and results
to date. OSF's membership now numbers more than 300 organizations which
work with OSF to deliver and enhance our system software offerings.
We hope to work with the IETF community in areas of common interest.
DCE relates to a number of IETF-relevant activities, including
work on Kerberos, X.500, DNS, as well as popular distributed systems
products such as NCS and AFS. We will clarify these relationships
in the BOF.
[OSF's Distributed Management Environment, or DME, will likely be
the subject of a future IETF BOF.]
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab09448;
2 Jul 92 20:28 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08741; 2 Jul 92 20:30 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA23263>; Thu, 2 Jul 1992 06:04:06 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA23259>; Thu, 2 Jul 1992 06:04:03 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa03349;
2 Jul 92 8:53 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mimemhs-body-equival-00.txt
Date: Thu, 02 Jul 92 08:53:21 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207020853.aa03349 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
MIME-MHS Interworking Working Group of the IETF.
Title : Equivalences between 1988 X.400 and RFC-822 Message
Bodies
Author(s) : H. Alvestrand, S. Thomspon
Filename : draft-ietf-mimemhs-body-equival-00.txt
Pages : 22
Abstract not provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-mimemhs-body-equival-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-mimemhs-body-equival-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09538;
2 Jul 92 20:37 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08937; 2 Jul 92 20:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA23268>; Thu, 2 Jul 1992 06:04:08 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA23264>; Thu, 2 Jul 1992 06:04:06 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa03371;
2 Jul 92 8:54 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-cox-sonetmib-00.txt
Date: Thu, 02 Jul 92 08:54:57 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207020854.aa03371 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Definitions of Managed Objects for the SONET
Interface Type
Author(s) : Tracy Cox, Kaj Tesink
Filename : draft-ietf-cox-sonetmib-00.txt
Pages : 109
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 SONET objects. This document is a companion document with
Definitions of Managed Objects for the DS1 and DS3 Interface Types,
RFC1232 and RFC1233.
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-cox-sonetmib-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-cox-sonetmib-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09793;
2 Jul 92 21:37 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10392; 2 Jul 92 21:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA26060>; Thu, 2 Jul 1992 07:36:34 -0700
Received: from taunivm.tau.ac.il by venera.isi.edu (5.65c/5.65+local-6)
id <AA26052>; Thu, 2 Jul 1992 07:36:24 -0700
Message-Id: <199207021436.AA26052 at venera.isi.edu>
Received: from VM.TAU.AC.IL by TAUNIVM.TAU.AC.IL (IBM VM SMTP V2R1)
with BSMTP id 5600; Thu, 02 Jul 92 17:34:39 IST
X-Delivery-Notice: SMTP MAIL FROM does not correspond to sender.
Received: from VM.TAU.AC.IL (HANK) by VM.TAU.AC.IL (Mailer R2.07) with BSMTP id
9262; Thu, 02 Jul 92 17:34:37 IST
Date: Thu, 02 Jul 92 17:18:58 IST
From: Hank Nussbacher <HANK%VM.TAU.AC.IL at taunivm.tau.ac.il>
Subject: Re: 160-bit addresses
To: Michael O'Dell <mo at gizmo.bellcore.com>, ietf at isi.edu
In-Reply-To: Your message of Wed, 1 Jul 92 20:32:17 -0400
On Wed, 1 Jul 92 20:32:17 -0400 you said:
>this is sheer madness. if you want to absolutely guarantee that
>internetworking as we know it is excluded from the emerging
>wireless technologies, go right ahead and mandate 160-bit addresses.
>the only hope is that the wireless folks will infarc from sustained
>laughter before they run us out of town on a rail, as we would
>richly deserve.
>
>this is too silly to be believed.
Suppose the 32 bit address was classless. That means 4,294,967,296 addresses.
We are currently at 900,000 and claim address exhaustion. Suppose we hit
similar problems with any other new scheme we might go with. That means we
need an address space 4500x the size we truly need. Now let us see what
size we really do need. If we continue to grow as we have over the past 5
years from 5000 hosts to over 900,000 hosts, we can expect a similar
growth rate of 200x over the next 5 years: 180,000,000 addresses. Suppose
we wanted to be on the safe size and allocate enough addresses for the next
20 years so we don't hit this problem again in the short term. Might as
well allocate an address for every person alive. But some people might
have more than one address. Especially in the future where personal
communications becomes readily available. PSI already delivers email
to your beeper (I believe the company is called RAM). The phone system
in the USA is based on a 9 digit number. If we think worldwide we need
to look at 12 digit phone/identity numbers. Add in the 4500x waste
factor and we need to design an address space of about 4,500,000,000,000,000.
That comes to somewhere around 2**52.
You are right. We don't need 160 bits. We can make do with 52 bits.
Now what?
>
> -Mike O'Dell
> Resident Crank
Hank Nussbacher
Israel
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09839;
2 Jul 92 22:01 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10828; 2 Jul 92 22:02 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA28424>; Thu, 2 Jul 1992 08:28:30 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA28415>; Thu, 2 Jul 1992 08:28:25 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05674;
2 Jul 92 11:22 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-ipxcp-01.txt
Date: Thu, 02 Jul 92 11:22:09 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207021122.aa05674 at IETF.NRI.Reston.VA.US>
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 : IPX PPP Internetwork Packet Exchange Control
Protocol [IPXCP]
Author(s) : Michael Allen
Filename : draft-ietf-pppext-ipxcp-01.txt
Pages : 5
The Point-to-Point Protocol (PPP) provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links. PPP also defines an extensible Link Control Protocol, and
proposes a family of Network Control Protocols (NCPs) for
establishing and configuring different network-layer protocols.
This document defines the NCP for establishing and configuring the IPX
protocol over PPP and MUST be used in conjunction with the
Informational RFC "Novell IPX Over Various WAN Media", June 1992,
Michael Allen.
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-ipxcp-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-ietf-pppext-ipxcp-01.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09946;
2 Jul 92 22:44 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11901; 2 Jul 92 22:45 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA29055>; Thu, 2 Jul 1992 08:39:36 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA29050>; Thu, 2 Jul 1992 08:39:34 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05805;
2 Jul 92 11:32 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-iab-ipversion7-00.txt
Date: Thu, 02 Jul 92 11:31:57 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207021132.aa05805 at IETF.NRI.Reston.VA.US>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This is a document from the Internet
Architecture Board.
Title : IP Version 7
Author(s) : Bob Braden
Filename : draft-iab-ipversion7-00.txt
Pages : 14
Internet growth has created serious problems of address space
consumption and routing information explosion. A solution to these
problems requires a new version of the Internet Protocol, which we
call IP version 7 ("IPv7"). This memo presents architectural
guidelines that any IPv7 should meet. It then discusses how an IPv7
based upon the OSI CLNP protocol would meet these requirements, and
presents the reasons for the IAB's preference for this solution.
Finally, it makes a three-part recommendation: (1) proceed at full
speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3)
continue to pursue research in advanced routing and other future
extensions of the Internet architecture.
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-ipversion7-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-iab-ipversion7-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09998;
2 Jul 92 23:11 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12458; 2 Jul 92 23:12 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA01685>; Thu, 2 Jul 1992 09:25:59 -0700
Received: from bells.cs.ucl.ac.uk by venera.isi.edu (5.65c/5.65+local-6)
id <AA01679>; Thu, 2 Jul 1992 09:25:55 -0700
Message-Id: <199207021625.AA01679 at venera.isi.edu>
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.06821-0 at bells.cs.ucl.ac.uk>; Thu, 2 Jul 1992 17:23:23 +0100
To: big-internet at munnari.oz.au, ietf at isi.edu, road at lanl.gov
Subject: Re: IAB proposal for CIDR and IPv7
In-Reply-To: Your message of "Wed, 01 Jul 92 19:08:10 EDT." <9207012354.20234 at munnari.oz.au>
Date: Thu, 02 Jul 92 17:22:58 +0100
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
>3) Since CIDR postpones, but does not prevent, the eventual
> exhaustion of the 32-bit IP address space, the IETF should
> also aggressively pursue a detailed technical and organizational
> plan for using CLNP (the OSI internetwork protocol defined by the
> ISO 8473 standard, which uses 160-bit addresses) as the basis for
silence = shocked disbelief?
here is a paraphrase of what i sent about this to some of the lists...
...several people asked if i could send it to a wider group...
CIDR i like.
CLNP is premature...and probably a step backwards
it also is introducing a policy which is NOT in line with starting new
Internet Standard Initiatives on a level playing field, since only some
vendors (very few end system vendors, slightly more router vendors) provide
CLNP bundled...
Do you want to see the political equation?
IPv7 = DECNET Phase 5?
jon
p.s. PIP and Nimrod and other initiatives come from less partisan
sources.
p.p.s i have no particluar axe to grind except to see the best
technical and logistically acceptable solution for internet health
and growth
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab10251;
3 Jul 92 0:00 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13471; 3 Jul 92 0:01 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07502>; Thu, 2 Jul 1992 11:24:19 -0700
Received: from gizmo.bellcore.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA07498>; Thu, 2 Jul 1992 11:24:16 -0700
Received: by gizmo.bellcore.com (5.61/1.34)
id AA06767; Thu, 2 Jul 92 14:22:36 -0400
Date: Thu, 2 Jul 92 14:22:36 -0400
From: Michael O'Dell <mo at gizmo.bellcore.com>
Message-Id: <9207021822.AA06767 at gizmo.bellcore.com>
To: ietf at isi.edu
Subject: why 160-bit addresses are daft....
Cc: jnc at ginger.lcs.mit.edu
I got some mail suggesting that I explain why 160-bit addresses
are the kiss-of-death for wireless computing.
Well, do the math.
The radios we can get now are about 9600 bits/second, and with a LOT of
luck, they may go as fast as 32kbits sometime in the next several years.
infrared may be faster, and microcell radios like Xerox has may
reach megabit speeds sometime (assuming they are ever products),
but some of us want to use our technology on the existing systems.
160 bits x 2 (src and dest) = 320 bits
addresses + 32 bit overhead + 32 bits checksum = 384 bits of HEADER,
not including UDP, TCP or a few bytes of real data. so, add another
160 bits or so of protocol header and a modicum of data and you get
544 bits of raw packet, plus another 40 bits of link framing and
we are up to
584 bits per packet
9600bps raw channel, running at 50% efficiency (assuming some kind
of csma/ca) give 4800 bits/second of raw bandwidth
Now 4800/584 = 8 packets per second, or about, MAYBE 80 BYTES PER SECOND
of real data.
by comparison, AX.25 running on the same link might deliver 400 BYTES/SECOND,
or over FIVE times as much usable data.
this is deadly! 20% channel efficiency is indefensible.
arguments about how wonderful it is to be able to address
every link in a graph fully connecting every subatomic particle
in the known universe simply will not cut it (160 is not quite
enough, but is is close). this is not "sparse assignment" - it
is pure sloth.
Note - double the 4800 back to 9600 for slip or ppp performance
over existing modems and you get 160 vs 800 - the ratio is still the same.
Processor and memory may be free these days (for some purposes),
and some folks may be able to afford T1 to their houses, and
maybe your grandkids may live to see ISDN in some form or another,
but we cannot, in all good conscience, go off and do something
which will result in this kind of horrific inefficiency.
Proceed on this and we will surely lose any credibility we have left.
I reassert, gentlefolks, that 160 bit addresses is raving lunacy.
-Mike O'Dell
Resident Crank with a 9600 baud modem
Bellcore?? Bellcore isn't allowed opinions - these be mine.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa10721;
3 Jul 92 0:54 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14779; 3 Jul 92 0:56 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA08486>; Thu, 2 Jul 1992 11:44:05 -0700
Received: from NRI.RESTON.VA.US by venera.isi.edu (5.65c/5.65+local-6)
id <AA08482>; Thu, 2 Jul 1992 11:44:02 -0700
Received: from Angband.Stanford.EDU by NRI.Reston.VA.US id aa25251;
2 Jul 92 14:39 EDT
Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0)
id AA21790; Thu, 2 Jul 92 11:38:48 -0700
Date: Wed, 1 Jul 92 11:26:19 EDT
From: William Allen Simpson <bsimpson at angband.stanford.edu>
Message-Id: <491.bsimpson at angband.stanford.edu>
To: ietf at NRI.Reston.VA.US, comp-protocols-tcp-ip at ucbvax.berkeley.edu
Reply-To: bsimpson at angband.stanford.edu
Subject: Re: informal notice of two IESG decisions
"Daniel J. Bernstein" <brnstnd at kramden.acf.nyu.edu> complains of problems
with the IETF standardization process.
You are complaining when you only had to wait 4-6 months? Be glad you
aren't working on the Point-to-Point Protocols, a *multi-protocol*
effort. We had to wait nearly two years between publications of the
basic protocol, even though there were serious bugs in the specification
that had been corrected in later drafts within months.
So, I really don't think you have anything to complain about time-wise.
We are still waiting for the PPP Authentication Protocols to pass
through review. Anything that goes through SAAG takes forever. Yes,
they keep asking for assurance that this is the be-all and end-all of
secure protocols, even when we say that it's not intended to be, right
in the document. And they have a strong father-knows-best attitude.
But they are doing their darndest in a tricky field with conflicting
goals of current practicality versus future prediction. And I've always
found them willing to explain their goals and concepts (at great length).
These are true believers! This is their life's work! That results in
the usual conflicts between religious adherants.
All I can advise is public patience, and privately "working them over
with a rubber hose", as our esteemed working group chair put it recently.
The passing of copyright to the IAB was in the preliminary drafts of
the standardization document, and people like me asked them to take it
out. If you publish a specification (in any form), I believe that all
it takes is a reference to your prior work, and anyone can come up with
a revision. There has been a long IETF history of just such revisions
(and consternation of the original authors).
The copyright question arose in the context of restricting who could
re-print a specification, and whether some company might want control
of, or fees for, use of the document or something described in the
document. I am of the "religious" persuasion that the Internet should
*not* publish or standardize on anything with such controls or fees.
Most RFCs are the result of the effort of groups of people. The
putative author is just the editor for the group, and in my experience
is merely the contact who has agreed to handle the grunt work. I've
contributed significant amounts of text to RFCs that bear someone else's
name. Don't let your ego get in the way of getting things done.
The review process has too many levels. I'm a guy who actually stands
up and calls for *abolishing* the IAB. The IESG is trying to be too
many things to too many people, and in my observation, spends far too
much time talking about process than actually making decisions. It has
no real power except delay and "recommendation". Some recommendations
may be made based on the author's eye-color, so far as I can tell (in
reality, based on a very ingrained old-boy network). Most of the time,
the process seems to spin its wheels.
I agree that both negative and positive decisions should be published,
as well as the scheduling of the time for making the decision. This
has started with the "last call", but is not yet strictly followed.
I *want* them to make decisions about the Internet. There is chaos
otherwise.
In your case, be thankful that at least action has been taken. Now you
know, and can go on to other things.
Bill_Simpson at um.cc.umich.edu
bsimpson at ray.lloyd.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01753;
3 Jul 92 3:14 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa01194; 3 Jul 92 3:16 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21880>; Thu, 2 Jul 1992 16:34:38 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA21863>; Thu, 2 Jul 1992 16:34:28 -0700
Date: Thu, 2 Jul 1992 16:32:30 -0700
Posted-Date: Thu, 2 Jul 1992 16:32:30 -0700
Message-Id: <199207022332.AA04998 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA04998>; Thu, 2 Jul 1992 16:32:30 -0700
To: big-internet at munnari.oz.au, craig at aland.bbn.com, iab at isi.edu,
iesg at NRI.Reston.VA.US, ietf at isi.edu, road at lanl.gov
Subject: Re: IPv7 (CLNP) a mistake
First, adopting CLNP means buying into the ISO standards process.
Craig,
This just is simply not true. Please see the Internet Draft that is
trying to get out of CNRI..
Bob
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01989;
3 Jul 92 4:07 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa02236; 3 Jul 92 4:08 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA14623>; Thu, 2 Jul 1992 13:42:35 -0700
Received: from IETF.nri.reston.VA.US ([132.151.1.35]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA14618>; Thu, 2 Jul 1992 13:42:32 -0700
Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08251;
2 Jul 92 16:31 EDT
To: IETF <ietf at isi.edu>
From: Internet-Drafts at NRI.Reston.VA.US
Reply-To: Internet-Drafts at NRI.Reston.VA.US
Subject: ID ACTION:draft-iab-ipversion7-00.txt
Date: Thu, 02 Jul 92 16:31:07 -0400
Sender: cclark at NRI.Reston.VA.US
Message-Id: <9207021631.aa08251 at IETF.NRI.Reston.VA.US>
THIS IS A RE-SEND ANNOUNCEMENT WITH CORRECTION MADE.
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the
Internet Architecture Board.
Title : IP Version 7
Author(s) : Internet Architecture Board
Filename : draft-iab-ipversion7-00.txt
Pages : 14
Internet growth has created serious problems of address space
consumption and routing information explosion. A solution to these
problems requires a new version of the Internet Protocol, which we
call IP version 7 ("IPv7"). This memo presents architectural
guidelines that any IPv7 should meet. It then discusses how an IPv7
based upon the OSI CLNP protocol would meet these requirements, and
presents the reasons for the IAB's preference for this solution.
Finally, it makes a three-part recommendation: (1) proceed at full
speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3)
continue to pursue research in advanced routing and other future
extensions of the Internet architecture.
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-ipversion7-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/draft-iab-ipversion7-00.txt".
For questions, please mail to internet-drafts at nri.reston.va.us.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02085;
3 Jul 92 5:37 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03870; 3 Jul 92 5:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22412>; Thu, 2 Jul 1992 16:47:40 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA22298>; Thu, 2 Jul 1992 16:45:11 -0700
Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11716>; Thu, 2 Jul 1992 16:43:15 PDT
Received: by redwing.parc.xerox.com id <57234>; Thu, 2 Jul 1992 16:43:05 -0700
Date: Thu, 2 Jul 1992 16:43:02 PDT
Sender: Lixia Zhang <lixia at parc.xerox.com>
From: Lixia Zhang <lixia at parc.xerox.com>
Reply-To: lixia at parc.xerox.com
To: Craig Partridge <craig at aland.bbn.com>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: Re: IPv7 (CLNP) a mistake
In-Reply-To: Your message of Thu, 2 Jul 1992 16:08:29 -0700
Message-Id: <CMM.0.88.710120582.lixia at parc.xerox.com>
> In short, CLNP as IPv7 seems destined to be a technical step backwards
> and to place a severe crimp on protocol innovation at a time when we
> need to innovate.
I agree with this statement with my both hands up.
For decisions this big, I'm shocked to see that IAB made the move
without holding an open hearing period for opinions from the internet
community.
I would like to hear how other people think about this.
Lixia
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02361;
3 Jul 92 8:49 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07753; 3 Jul 92 8:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21125>; Thu, 2 Jul 1992 16:14:37 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA21086>; Thu, 2 Jul 1992 16:13:13 -0700
Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA07627; Thu, 2 Jul 92 19:09:29 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA28811; Thu, 2 Jul 92 16:08:29 PDT
Message-Id: <9207022308.AA28811 at aland.bbn.com>
To: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: IPv7 (CLNP) a mistake
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 02 Jul 92 16:08:29 -0700
Sender: craig at aland.bbn.com
I've read the IAB announcement, RFC 1347 and the Internet Draft, and am
afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea.
First, adopting CLNP means buying into the ISO standards process.
While the Kobe announcement states that choosing CLNP is "not choosing OSI,"
it is the case that we'd be choosing to make the network layer of the Internet
protocol suite the same as the OSI protocol suite. As such, we have
to face the painful reality that any future changes that the Internet
community wishes to see in the network layer will require ISO approval too.
ISO and the Internet community have radically different views about
the standards making process (e.g. testing before standardizing, whether
to bill for standards, and the like). Indeed, the Internet community
decided not to join up with ANSI/ISO a few years ago because both
communities felt there were incompatibilities in their processes.
Now we're proposing to buy into the ISO process to manage our network layer.
We'll all have to learn the detailed workings of the ISO process if
we want to change the network layer -- and since it requires some
number of meetings to be ANSI/ISO accredited, we'd better all start
attending those meetings now (in addition to our IETF meetings) so
we can be prepared to defend our ideas in the ISO process. Do we
really want to pass much (all?) of our control over the Internet
network layer to a process that the Internet community finds
incompatible?
(I've heard at least one person suggest that if ISO doesn't like
Internet-proposed changes, we'll just publish our own version of CLNP.
Ignoring ISO copyright issues about issuing a modified ISO spec [which
may or may not prove to big deal], I don't buy this idea. First, why
even call this new network layer CLNP unless we believe we mean to keep
in sync. Second, having an Internet and an ISO CLNP means that vendors
will have to support two versions of CLNP, which they won't like.
Consider how much folks already complain about the different GOSIPs.
We'll find ourselves in a tremendous vise to harmonize with ISO. We've
tried that twice before, with CMIP over TCP and IS-IS. In one case,
the idea was a complete flop but only after a waste of some years of
effort. In neither case was the process pleasant. I don't think we
want more of these kinds of problems.).
Second, CLNP deals with only *one* of the several issues facing IP, namely
address depletion. At the same time, it forces us to take a giant step
back on other issues. CLNP does *not* support multicasting. There
are proposals in the works to add it -- but that means CLNP is about five
years behind IP on this topic. IP multicast is working now and it has
taken a lot of effort -- it is in products (Solaris 2.0) and in
BSD (4.4 and mods are available for 4.3). We're making good progress
on mobile host support. Some experimental implementations under
IP are getting heavy use. We'll have to go back to the CLNP drawing
board on those projects too. Ideas to support multimedia applications are
fast becoming reality (witness the recent IETF multicasts on the
Internet). If we buy CLNP we'll have to wait a few years for ISO
to approve those extensions. With the exception of a brief mentions
about leaving space for options and making sure that multicast will
somehow be supported, the various documents don't address this issue.
In short, CLNP as IPv7 seems destined to be a technical step backwards
and to place a severe crimp on protocol innovation at a time when we
need to innovate. (Some folks have expressed concern that the rise in
voice and multimedia on the Internet will stress IP *this* year. To my
knowledge, no one has tried running voice over CLNP). Are we so sure
that we should choose CLNP with all its limitations, especially now that
CIDR gives us a bit of breathing room in which to think? Are we so sure
CLNP is the right decision that we shouldn't even consider developing at
least one other approach in parallel, just in case we discover CLNP
really is a tar baby?
Craig
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02472;
3 Jul 92 9:21 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08751; 3 Jul 92 9:22 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA24445>; Thu, 2 Jul 1992 17:39:01 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA24438>; Thu, 2 Jul 1992 17:38:49 -0700
Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA13691; Thu, 2 Jul 92 20:36:27 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA29438; Thu, 2 Jul 92 17:35:28 PDT
Message-Id: <9207030035.AA29438 at aland.bbn.com>
To: braden at isi.edu
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: re: IPv7 (CLNP) a mistake
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 02 Jul 92 17:35:27 -0700
Sender: craig at aland.bbn.com
> First, adopting CLNP means buying into the ISO standards process.
>
> Craig,
>
> This just is simply not true. Please see the Internet Draft that is
> trying to get out of CNRI..
Bob:
I read the ID very carefully before sending my earlier note. I believe
that the key paragraph is:
The IAB proposal is to adopt the CLNP protocol specification and
packet formats for IPv7. The eventual consequence of this decision
will be the publication, at some point in the future, of a complete
IPv7 specification that is functionally and syntactically compatible
with CLNP (defined by the second edition of the ISO 8473 standard,
published in 1992). The intent is to run the existing and future
Internet transport protocols -- in particular, TCP and UDP -- above
IPv7. This would let us benefit from the larger addresses of CLNP
while maintaining the present Internet architecture, without inventing
a new protocol specification and without losing change control. We
must of course avoid gratuitous changes, but the IAB/IETF must be able
to make any changes that are necessary for successful deployment,
operation, and evolution of IPv7. In the longer term, the use of CLNP
will contribute to the inevitable convergence of the OSI and TCP/IP
protocol suites in the Internet (IAB/IETF) context.
In short we will adopt CLNP (an ISO protocol); we wish to be
"functionally and syntactically" compatible and to "converge" with OSI;
and want to be able to make "changes ... necessary for successful,
deployment, operation, and evolution of IPv7." If we want to make changes
and still be compatible with and converge with OSI, we'll have to convince
ISO to go along, which means we have to work in the ISO standards process.
So we've bought into the ISO process (for the network layer).
Craig
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02750;
3 Jul 92 10:24 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10058; 3 Jul 92 10:25 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA26215>; Thu, 2 Jul 1992 18:40:24 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA26141>; Thu, 2 Jul 1992 18:38:30 -0700
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11551>; Thu, 2 Jul 1992 18:36:38 PDT
Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <22277>; Thu, 2 Jul 1992 18:36:27 -0700
To: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: Re: IPv7 (CLNP) a mistake
Date: Thu, 2 Jul 1992 18:36:18 PDT
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <92Jul2.183627pdt.22277 at skylark.parc.xerox.com>
I share Craig's dismay with the IAB's decision.
In addition to the real and serious problems that Craig raises concerning
change control over the fundamental protocol of the Internet, I am concerned
about technical and procedural aspects of the IAB decision.
Technically, changing from IP to CLNP means trading addresses that are
too short for address that are too long (yeah, I know, memory and
bandwidth keep getting cheaper, but it's a shame to fill it up with
a bunch of bytes that just say who got to allocate the next bunch of
bytes, not to mention all the null padding), plus a checksum that's more
expensive to compute in software and a bunch of non-32-bit-aligned
fields that are more expensive to parse. If I understand the transition
plan, it also means adding an entirely new set of router-to-router and
host-to-router protocols to all of the boxes in the Internet, in addition
to the IP-based protocols already present, which will have a significant
cost, not only in terms of computing and network resources, but more
importantly in terms of the manageability of the Internet and the training
of its users and maintainers.
If all we want is bigger addresses (and that's all that CLNP gives us),
it would be far better just to make the minimal changes to IPv4 and
its routing protocols to carry bigger addresses, in such a way that much
of the existing routing, management, and "cultural" infrastructure can be
retained. The recent proposals by Hinden & Crocker and by Zheng Wang
appear to be viable examples of that approach.
On the other hand, if we are going to make a change of the magnitude
of that suggested, let's get something more out of it than just bigger
addresses. As Craig pointed out, the Internet is just starting to
see an explosion of new applications and services -- it's not just
telnet, FTP, and email any more. We need a more capable infrastructure,
not just a more scalable one. This is an exciting period of creative
activity in the Internet; it would be a real shame to derail (and
possibly smother) that activity in a small-gain, big-pain transition
to CLNP.
Procedurally, I am dismayed at the undemocratic and closed nature of the
decision making process, and of the haste with which such a major decision
was made. I understand the need for immediate action on the CIDR front;
however, given the reprieve of CIDR, I am not convinced that the IP address
space will run out so soon that there is no time for an open evaluation of
the longer-term alternatives, and possibly even a building of concensus in
the community. I thought the IESG recommendation of a six-month evaluation
period was very sensible; instead, we got a decision handed down from a
closed IAB meeting, based on the work of the closed ROAD group. (I was a
member of the ROAD group, invited to participate after I discovered its
existence by accident and asked what was going on.) I also am not
convinced that the ROAD group had sufficient time to evaluate the
alternatives. For example, Bob Hinden came up with his particular
encapsulation scheme part way through the ROAD activity, and it has
evolved considerably since the last ROAD meeting, addressing most of its
previously-identified shortcomings. Another example is Paul Tsuchiya's
PIP proposal, which has emerged since ROAD. I hope the IAB will explain
why it deemed it necessary to endorse CLNP in the midst of active
development of less disruptive alternatives (e.g., the Hinden scheme) and
more capable alternatives (e.g., PIP).
Steve Deering
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02963;
3 Jul 92 11:23 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11638; 3 Jul 92 11:25 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00738>; Thu, 2 Jul 1992 20:59:38 -0700
Received: from is.rice.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA00683>; Thu, 2 Jul 1992 20:57:54 -0700
Received: from san-miguel.is.rice.edu by is.rice.edu (AA03751); Thu, 2 Jul 92 22:56:07 CDT
Received: by san-miguel.is.rice.edu (AA13241); Thu, 2 Jul 92 22:56:05 CDT
From: William Manning <bmanning at is.rice.edu>
Message-Id: <9207030356.AA13241 at san-miguel.is.rice.edu>
Subject: Re: IPv7 (CLNP) a mistake
To: "Milo S. Medin" <medin at nsipo.nasa.gov>
Date: Thu, 2 Jul 92 22:56:03 CDT
Cc: craig at aland.bbn.com, big-internet at munnari.oz.au, iab at isi.edu,
iseg at NRI.Reston.VA.US, ietf at isi.edu, road at lanl.gov
In-Reply-To: <9207030239.AA18618 at cincsac.arc.nasa.gov>; from "Milo S. Medin" at Jul 2, 92 7:39 pm
X-Mailer: ELM [version 2.3 PL11]
Ok,
So the IAB proposal is flawed. It seems that every other proposal
that has been cussed in the big-internet forum over the last few months
is flawed as well. Some proposals seem to be easier to implement than others,
while some will take significant time. What seems to be lacking in all
the verbage being tossed around are plans to provide implementations and
agreements to build testbeds for these implementations.
I understand that it may be a heinous thought, but we could use the
net to actually build and test some of these ideas. Yes, it may impact
"production" services but after all, this is (at least in the US) still a
research, development and educational network. (At least thats how I read
the NSF AUP). Recent questions about the structure of the Internet seems
to point out that it is no longer an IP only network.
What is the phrase... time to fish or cut bait. I, for one, would
like to see something related to implementation planning for some of the
various drafts. I think that we could persuade our regional to help with
some of the proposals... we are already experimenting with CLNP, and we could
work with either the CIDR or C# plans, (as long as GSI will hand out the
address blocks) as long as we can get others to help out. When can we
see something on PIP/PIPE/Nimrod, other than architectural plans? It will
be interesting to see if we can "prove" the IAB wrong, rather than casting
aspersions.
--
Regards,
Bill Manning bmanning at rice.edu PO Box 1892
713-285-5415 713-527-6099 Houston, Texas
R.U. (o-kome) 77251-1892
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa02991;
3 Jul 92 11:31 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa11824; 3 Jul 92 11:33 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA28595>; Thu, 2 Jul 1992 19:42:32 -0700
Received: from cincsac.arc.nasa.gov by venera.isi.edu (5.65c/5.65+local-6)
id <AA28590>; Thu, 2 Jul 1992 19:42:28 -0700
Received: Thu, 2 Jul 92 19:39:44 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T)
Message-Id: <9207030239.AA18618 at cincsac.arc.nasa.gov>
To: Craig Partridge <craig at aland.bbn.com>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: Re: IPv7 (CLNP) a mistake
In-Reply-To: Your message of "Thu, 02 Jul 92 16:08:29 PDT."
<9207022308.AA28811 at aland.bbn.com>
Date: Thu, 02 Jul 92 19:39:43 -0700
From: "Milo S. Medin" (NASA ARC NSI Office) <medin at nsipo.nasa.gov>
I totally agree with Craig. There are a number of problems with trying
to base an IPv7 on CLNP in the manner that the IAB is trying to do. First
off, if you really didn't want to buy into the ISO standards process,
routing protocols, ES-IS, etc, you ought to have taken the CLNP packet
format, renamed all the fields, and then proclaimed the output IPv7.
This would have the effect you are looking for, having compatibility
of packet format, but being independent in other areas. By saying you
are basing the protocol on CLNP, you cause everyone to bring along all
the baggage they associate with OSI.
Another problem is that how addressing in this new scheme will work.
There is rightly a large amount of opposition to using real OSI delegated
NSAP's, for a number of technical reasons, but if the perception of them being
OSI addresses exists, all the baroque procedures for acquiring NSAP addresses
may try to be applied, causing even more confusion. In the US, this is just
plain complicated; overseas, it can often be the case that the existing Internet
activists in that country are in direct opposition to the official
NSAP authorities, such as PTT's. Confusion will reign, and it won't be
pretty. And the very people the IAB and IETF are trying to support will
be hurt.
Additionally, with such an RFC published, the marketing arms of the various
OSI vendors (which have been rather quiet in the past couple of years) will
go into high gear, going into Government labs and commercial organizations,
pitting fumeware against real TCP/IP products, and telling potential
customers that the Internet is now transitioning to OSI protocols, and how
they should be ahead of the power curve and skip the TCP/IP step completely,
thereby depriving the customer of working products, and the IP vendor
of deserved revenue. It's not that the IAB proposal says this will happen
in so many words, but a cursory reading of the document, and the quote
that Craig cited certainly will support this sort of viewpoint.
I could go on, but the real problem is how the process is working. If the
area directors of the IESG who are intimately working and wrestling with the
issues feel that making the choice about what the future of the IP protocol
ought to be is unclear, then the IAB ought to listen to that and act
accordingly. Many of these issues are hard problems. They do not go
away just because you use CLNP. When the IAB tells them that the IAB knows
what's best - better than the best minds in this arena know, they are on
very dangerous ground.
It should be pointed out that the IAB has no real authority, and never really
has had any (maybe they have even less now since being absorbed by the ISOC).
The IAB doesn't direct, it leads. And the ability of it to lead is based on
the respect and confidence of the R&D, vendor, and user communities. When the
IAB moves in this rather high-handed fashion, it erodes any leadership it
has, and simply compromises it's ability to push forward with any strategy. If
one looks back at history, the IAB has been most successful when it embraced
excellent technical standards, with real experience in prototyping and testing,
with the support of the technical and user communities. It has been an
utter failure when trying to advance less well defined proposals that
are not consistent with the Internet community's traditions and corporate
wisdom (CMOT comes to mind as an example).
I have many technical concerns with this approach, but I fear that any
discussion about the proposal's merits and faults will be secondary to the
manner which the IAB chose to push this approach. In my opinion, the IAB has
seriously undermined it's ability to advance and implement this strategy
by destroying it's own credibility as a leader. The CLNP proposal will
now have the tarbaby of a perceived powergrab associated with it, and is
unlikely to move forward. The IAB may well succeed in getting this RFC
advanced, but nobody will care. The IETF will continue to make progress
in other approaches, prototyping and testing, and real solutions will
eventually come forth and be deployed. Leadership is earned, and once
damaged is very difficult to rebuild.
This area, the scaling of the Internet (address depletion is a red herring,
the real issue is scaling), is an area where progress can ONLY be made
by rational debate, technical leadership and consensus building. By attempting
to cram this approach down the technical community's throat, the IAB has
undermined all these goals, and has made it harder for progress in ANY
approach to be made, which is perhaps the most tragic aspect of this whole
sad affair. This action isn't in the best traditions of the Internet, though
I fear it may in fact be setting a new trend.
Thanks,
Milo
PS Usual disclaimers about not representing the Government apply...
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03199;
3 Jul 92 13:02 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03193;
3 Jul 92 13:02 EDT
Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa13888;
3 Jul 92 13:03 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA19606; Fri, 3 Jul 92 12:31:06 EDT
Received: from zoo.utoronto.ca by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA19602; Fri, 3 Jul 92 12:30:52 EDT
Message-Id: <9207031630.AA19602 at dimacs.rutgers.edu>
From: henry at zoo.toronto.edu
Date: Fri, 3 Jul 92 12:30:38 EDT
To: ietf at isi.edu
Cc: ietf-822 at dimacs.rutgers.edu
Subject: folklore etc.
Mark Crispin wrote (in the 822 list, regarding a MIME problem):
> As an example, consider that years after the bug in an ancient version of
>BSD was fixed, we still have to worry about handling MAIL FROM commands in
>SMTP that are missing the host name, or that have colon delimiters in the at-
>domain-list instead of commas. This isn't documented in SMTP; rather, it's
>in the folklore of how you get your SMTP server to be interoperable...
A procedural thought on this: it Sure Would Be Nice if some of the people
who have been exposed to things like this sat down and wrote a few
Informational RFCs *documenting* some of this folklore. One of the most
infuriating things about implementing some of the Internet protocols is
running across these bits of important information that aren't written
down *anywhere*, apparently on the assumption that anyone who needs to
know them already does. Not so.
While there is no substitute for interoperability testing, such testing
should be significantly quicker and less painful if people didn't have
to rediscover problems that others have known about for years (but have
never bothered to write down).
Henry Spencer at U of Toronto Zoology
henry at zoo.toronto.edu utzoo!henry
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03209;
3 Jul 92 13:12 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14109; 3 Jul 92 13:13 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06402>; Thu, 2 Jul 1992 23:58:43 -0700
Received: from Angband.Stanford.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA06398>; Thu, 2 Jul 1992 23:58:39 -0700
Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0)
id AA22184; Thu, 2 Jul 92 23:56:40 -0700
Date: Fri, 3 Jul 92 02:39:58 EDT
From: William Allen Simpson <bsimpson at angband.stanford.edu>
Message-Id: <505.bsimpson at angband.stanford.edu>
To: ietf at isi.edu
Cc: big-internet at munnari.oz.au
Reply-To: bsimpson at angband.stanford.edu
Subject: Re: IAB proposal for CIDR and IPv7
Two administrative discrepencies:
1) When I went to read this fine document, I discovered that it
consisted of an index of the directory on nnsc.nsf.net. The same
file was also at ftp.nisc.sri.com. Hopefully, this will be fixed.
(Debra Legare emailed me a separate copy when I reported the error.)
2) I uploaded and just finished re-reading RFC994, which I hadn't
looked at in a very long time. The effect of the NLPID listed in
that document when sending over current links will appear to be IP
version 8, not 7.
7.2.2 Network Layer Protocol Identifier
The value of this field is set to binary 1000 0001 to identify this
Network Layer protocol as ISO 8473, Protocol for Providing the
Connectionless- mode Network Service. The value of this field is set
to binary 0000 0000 to identify the Inactive Network Layer protocol
subset.
Or are we getting a new NLPID value "0111 xxxx" and defining our own
IP/CLNP hybrid?
Bill_Simpson at um.cc.umich.edu
bsimpson at ray.lloyd.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03223;
3 Jul 92 13:12 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14119; 3 Jul 92 13:13 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA06665>; Fri, 3 Jul 1992 00:10:26 -0700
Received: from GINGER.LCS.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA06659>; Fri, 3 Jul 1992 00:10:20 -0700
Received: by ginger.lcs.mit.edu
id AA23454; Fri, 3 Jul 92 03:03:02 -0400
Date: Fri, 3 Jul 92 03:03:02 -0400
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9207030703.AA23454 at ginger.lcs.mit.edu>
To: bmanning at is.rice.edu, medin at nsipo.nasa.gov
Subject: Re: IPv7 (CLNP) a mistake
Cc: big-internet at munnari.oz.au, craig at aland.bbn.com, iab at isi.edu,
ietf at isi.edu, iseg at NRI.Reston.VA.US, road at lanl.gov
I, for one, would like to see something related to implementation
planning for some of the various drafts. ... When can we see
something on .../Nimrod, other than architectural plans?
As you may recall, I made and appeal to the IETF mailng list at the
start of June, for help in making Nimrod happen (i.e. detailed engineering
design, protocol specs, test implementation and field trials), I received a
number of responses; thanks to everyone who responded.
It seems that a group at BBN, among them Martha Steenstrup, chair of
the IDPR WG of the IETF, represents the most appropriate group to work with on
this. Their experience with Source Routed Link State routing architectures,
gained during the IDPR work, makes them a natural fit to work with on Nimrod.
Many of the key radical ideas of Nimrod are also in IDPR, and
experience gained with IDPR will be of great value with Nimrod. In some sense,
IDPR can be viewed as "phase 0" of Nimrod, and the work done on IDPR will be
used, and of substantial value, in allowing Nimrod to hit the ground running.
Nothing is definite yet: we are discussing how to proceed, and there
is no certainty that we will get any funding to make any of this happen,
although obviously I have high hopes.
If this work should proceed, it will definitely be in the context of
an IETF WG, which will be open to all in the usual manner. Exactly when this
will all be happening, I'm not sure; I would like to see things move along
quickly, but this depends on funding.
Noel
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03744;
3 Jul 92 14:39 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16728; 3 Jul 92 14:40 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07210>; Fri, 3 Jul 1992 00:32:25 -0700
Received: from vm.gmd.de by venera.isi.edu (5.65c/5.65+local-6)
id <AA07205>; Fri, 3 Jul 1992 00:32:20 -0700
Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5771;
Fri, 03 Jul 92 09:30:01 MET
Received: by DEARN (Mailer R2.08) id 6856; Fri, 03 Jul 92 09:30:00 MET
Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE
id 7729 for MOD-IETF at SEARN.SUNET.SE; Fri, 3 Jul 1992 09:28:26 +0200
Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id
2897; Fri, 03 Jul 92 09:25:34 +0200
Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP;
Fri, 03 Jul 92 09:25:28 +0200
Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<14920-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 09:27:03 +0200
Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<12282-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 02:49:20 +0200
Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id
<03538-0 at relay.surfnet.nl>; Fri, 3 Jul 1992 02:49:16 +0200
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09513; 2 Jul
92 20:36 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09509; 2 Jul
92 20:36 EDT
Received: from uu2.psi.com by NRI.Reston.VA.US id aa08896; 2 Jul 92 20:37 EDT
Received: from port10.mv.pub-ip.psi.net by uu2.psi.com
(5.65b/4.0.071791-PSI/PSINet) id AA13691; Thu, 2 Jul 92 20:36:27 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA29438; Thu,
2 Jul 92 17:35:28 PDT
Return-Path: <iesg-request at IETF.NRI.Reston.VA.US>
Message-Id: <9207030035.AA29438 at aland.bbn.com>
To: BSMTP <mod-ietf at dfn.dbp.de>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: re: IPv7 (CLNP) a mistake
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 02 Jul 92 17:35:27 -0700
Sender: owner-mod-ietf at searn.sunet.se
> First, adopting CLNP means buying into the ISO standards process.
>
> Craig,
>
> This just is simply not true. Please see the Internet Draft that is
> trying to get out of CNRI..
Bob:
I read the ID very carefully before sending my earlier note. I believe
that the key paragraph is:
The IAB proposal is to adopt the CLNP protocol specification and
packet formats for IPv7. The eventual consequence of this decision
will be the publication, at some point in the future, of a complete
IPv7 specification that is functionally and syntactically compatible
with CLNP (defined by the second edition of the ISO 8473 standard,
published in 1992). The intent is to run the existing and future
Internet transport protocols -- in particular, TCP and UDP -- above
IPv7. This would let us benefit from the larger addresses of CLNP
while maintaining the present Internet architecture, without inventing
a new protocol specification and without losing change control. We
must of course avoid gratuitous changes, but the IAB/IETF must be able
to make any changes that are necessary for successful deployment,
operation, and evolution of IPv7. In the longer term, the use of CLNP
will contribute to the inevitable convergence of the OSI and TCP/IP
protocol suites in the Internet (IAB/IETF) context.
In short we will adopt CLNP (an ISO protocol); we wish to be
"functionally and syntactically" compatible and to "converge" with OSI;
and want to be able to make "changes ... necessary for successful,
deployment, operation, and evolution of IPv7." If we want to make changes
and still be compatible with and converge with OSI, we'll have to convince
ISO to go along, which means we have to work in the ISO standards process.
So we've bought into the ISO process (for the network layer).
Craig
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03744;
3 Jul 92 14:39 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16728; 3 Jul 92 14:40 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07210>; Fri, 3 Jul 1992 00:32:25 -0700
Received: from vm.gmd.de by venera.isi.edu (5.65c/5.65+local-6)
id <AA07205>; Fri, 3 Jul 1992 00:32:20 -0700
Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5771;
Fri, 03 Jul 92 09:30:01 MET
Received: by DEARN (Mailer R2.08) id 6856; Fri, 03 Jul 92 09:30:00 MET
Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE
id 7729 for MOD-IETF at SEARN.SUNET.SE; Fri, 3 Jul 1992 09:28:26 +0200
Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id
2897; Fri, 03 Jul 92 09:25:34 +0200
Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP;
Fri, 03 Jul 92 09:25:28 +0200
Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<14920-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 09:27:03 +0200
Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<12282-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 02:49:20 +0200
Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id
<03538-0 at relay.surfnet.nl>; Fri, 3 Jul 1992 02:49:16 +0200
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09513; 2 Jul
92 20:36 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09509; 2 Jul
92 20:36 EDT
Received: from uu2.psi.com by NRI.Reston.VA.US id aa08896; 2 Jul 92 20:37 EDT
Received: from port10.mv.pub-ip.psi.net by uu2.psi.com
(5.65b/4.0.071791-PSI/PSINet) id AA13691; Thu, 2 Jul 92 20:36:27 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA29438; Thu,
2 Jul 92 17:35:28 PDT
Return-Path: <iesg-request at IETF.NRI.Reston.VA.US>
Message-Id: <9207030035.AA29438 at aland.bbn.com>
To: BSMTP <mod-ietf at dfn.dbp.de>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: re: IPv7 (CLNP) a mistake
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 02 Jul 92 17:35:27 -0700
Sender: owner-mod-ietf at searn.sunet.se
> First, adopting CLNP means buying into the ISO standards process.
>
> Craig,
>
> This just is simply not true. Please see the Internet Draft that is
> trying to get out of CNRI..
Bob:
I read the ID very carefully before sending my earlier note. I believe
that the key paragraph is:
The IAB proposal is to adopt the CLNP protocol specification and
packet formats for IPv7. The eventual consequence of this decision
will be the publication, at some point in the future, of a complete
IPv7 specification that is functionally and syntactically compatible
with CLNP (defined by the second edition of the ISO 8473 standard,
published in 1992). The intent is to run the existing and future
Internet transport protocols -- in particular, TCP and UDP -- above
IPv7. This would let us benefit from the larger addresses of CLNP
while maintaining the present Internet architecture, without inventing
a new protocol specification and without losing change control. We
must of course avoid gratuitous changes, but the IAB/IETF must be able
to make any changes that are necessary for successful deployment,
operation, and evolution of IPv7. In the longer term, the use of CLNP
will contribute to the inevitable convergence of the OSI and TCP/IP
protocol suites in the Internet (IAB/IETF) context.
In short we will adopt CLNP (an ISO protocol); we wish to be
"functionally and syntactically" compatible and to "converge" with OSI;
and want to be able to make "changes ... necessary for successful,
deployment, operation, and evolution of IPv7." If we want to make changes
and still be compatible with and converge with OSI, we'll have to convince
ISO to go along, which means we have to work in the ISO standards process.
So we've bought into the ISO process (for the network layer).
Craig
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03828;
3 Jul 92 14:49 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16976; 3 Jul 92 14:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07204>; Fri, 3 Jul 1992 00:32:20 -0700
Received: from vm.gmd.de by venera.isi.edu (5.65c/5.65+local-6)
id <AA07200>; Fri, 3 Jul 1992 00:32:12 -0700
Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5770;
Fri, 03 Jul 92 09:30:00 MET
Received: by DEARN (Mailer R2.08) id 6855; Fri, 03 Jul 92 09:29:59 MET
Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE
id 7729 for MOD-IETF at SEARN.SUNET.SE; Fri, 3 Jul 1992 09:28:26 +0200
Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id
2897; Fri, 03 Jul 92 09:25:34 +0200
Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP;
Fri, 03 Jul 92 09:25:28 +0200
Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<14920-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 09:27:03 +0200
Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<12282-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 02:49:20 +0200
Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id
<03538-0 at relay.surfnet.nl>; Fri, 3 Jul 1992 02:49:16 +0200
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09513; 2 Jul
92 20:36 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09509; 2 Jul
92 20:36 EDT
Received: from uu2.psi.com by NRI.Reston.VA.US id aa08896; 2 Jul 92 20:37 EDT
Received: from port10.mv.pub-ip.psi.net by uu2.psi.com
(5.65b/4.0.071791-PSI/PSINet) id AA13691; Thu, 2 Jul 92 20:36:27 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA29438; Thu,
2 Jul 92 17:35:28 PDT
Return-Path: <iesg-request at IETF.NRI.Reston.VA.US>
Message-Id: <9207030035.AA29438 at aland.bbn.com>
To: BSMTP <MABOGEN at vm.gmd.de>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: re: IPv7 (CLNP) a mistake
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 02 Jul 92 17:35:27 -0700
Sender: owner-mod-ietf at searn.sunet.se
> First, adopting CLNP means buying into the ISO standards process.
>
> Craig,
>
> This just is simply not true. Please see the Internet Draft that is
> trying to get out of CNRI..
Bob:
I read the ID very carefully before sending my earlier note. I believe
that the key paragraph is:
The IAB proposal is to adopt the CLNP protocol specification and
packet formats for IPv7. The eventual consequence of this decision
will be the publication, at some point in the future, of a complete
IPv7 specification that is functionally and syntactically compatible
with CLNP (defined by the second edition of the ISO 8473 standard,
published in 1992). The intent is to run the existing and future
Internet transport protocols -- in particular, TCP and UDP -- above
IPv7. This would let us benefit from the larger addresses of CLNP
while maintaining the present Internet architecture, without inventing
a new protocol specification and without losing change control. We
must of course avoid gratuitous changes, but the IAB/IETF must be able
to make any changes that are necessary for successful deployment,
operation, and evolution of IPv7. In the longer term, the use of CLNP
will contribute to the inevitable convergence of the OSI and TCP/IP
protocol suites in the Internet (IAB/IETF) context.
In short we will adopt CLNP (an ISO protocol); we wish to be
"functionally and syntactically" compatible and to "converge" with OSI;
and want to be able to make "changes ... necessary for successful,
deployment, operation, and evolution of IPv7." If we want to make changes
and still be compatible with and converge with OSI, we'll have to convince
ISO to go along, which means we have to work in the ISO standards process.
So we've bought into the ISO process (for the network layer).
Craig
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04084;
3 Jul 92 15:22 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa17884; 3 Jul 92 15:24 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07443>; Fri, 3 Jul 1992 00:47:29 -0700
Received: from vm.gmd.de by venera.isi.edu (5.65c/5.65+local-6)
id <AA07437>; Fri, 3 Jul 1992 00:47:21 -0700
Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5822;
Fri, 03 Jul 92 09:45:09 MET
Received: by DEARN (Mailer R2.08) id 7543; Fri, 03 Jul 92 09:45:08 MET
Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE
id 7820 for MOD-IETF at SEARN.SUNET.SE; Fri, 3 Jul 1992 09:43:40 +0200
Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id
3082; Fri, 03 Jul 92 09:41:52 +0200
Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP;
Fri, 03 Jul 92 09:41:49 +0200
Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<15173-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 09:34:31 +0200
Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<12701-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 04:44:14 +0200
Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id
<03625-0 at relay.surfnet.nl>; Fri, 3 Jul 1992 04:44:10 +0200
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09930; 2 Jul
92 22:39 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09926; 2 Jul
92 22:39 EDT
Received: from cincsac.arc.nasa.gov by NRI.Reston.VA.US id aa11724; 2 Jul 92
22:40 EDT
Return-Path: <iesg-request at IETF.NRI.Reston.VA.US>
Original-Received: Thu,
2 Jul 92 19:39:44 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov
(4.1/1.5T)
Pp-Warning: Illegal Received field on preceding line
Message-Id: <9207030239.AA18618 at cincsac.arc.nasa.gov>
To: BSMTP <MABOGEN at vm.gmd.de>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: Re: IPv7 (CLNP) a mistake
In-Reply-To: Your message of "Thu,
02 Jul 92 16:08:29 PDT." <9207022308.AA28811 at aland.bbn.com>
Date: Thu, 02 Jul 92 19:39:43 -0700
From: "Milo S. Medin" (NASA ARC NSI Office) <medin at nsipo.nasa.gov>
Sender: owner-mod-ietf at searn.sunet.se
I totally agree with Craig. There are a number of problems with trying
to base an IPv7 on CLNP in the manner that the IAB is trying to do. First
off, if you really didn't want to buy into the ISO standards process,
routing protocols, ES-IS, etc, you ought to have taken the CLNP packet
format, renamed all the fields, and then proclaimed the output IPv7.
This would have the effect you are looking for, having compatibility
of packet format, but being independent in other areas. By saying you
are basing the protocol on CLNP, you cause everyone to bring along all
the baggage they associate with OSI.
Another problem is that how addressing in this new scheme will work.
There is rightly a large amount of opposition to using real OSI delegated
NSAP's, for a number of technical reasons, but if the perception of them being
OSI addresses exists, all the baroque procedures for acquiring NSAP addresses
may try to be applied, causing even more confusion. In the US, this is just
plain complicated; overseas, it can often be the case that the existing Internet
activists in that country are in direct opposition to the official
NSAP authorities, such as PTT's. Confusion will reign, and it won't be
pretty. And the very people the IAB and IETF are trying to support will
be hurt.
Additionally, with such an RFC published, the marketing arms of the various
OSI vendors (which have been rather quiet in the past couple of years) will
go into high gear, going into Government labs and commercial organizations,
pitting fumeware against real TCP/IP products, and telling potential
customers that the Internet is now transitioning to OSI protocols, and how
they should be ahead of the power curve and skip the TCP/IP step completely,
thereby depriving the customer of working products, and the IP vendor
of deserved revenue. It's not that the IAB proposal says this will happen
in so many words, but a cursory reading of the document, and the quote
that Craig cited certainly will support this sort of viewpoint.
I could go on, but the real problem is how the process is working. If the
area directors of the IESG who are intimately working and wrestling with the
issues feel that making the choice about what the future of the IP protocol
ought to be is unclear, then the IAB ought to listen to that and act
accordingly. Many of these issues are hard problems. They do not go
away just because you use CLNP. When the IAB tells them that the IAB knows
what's best - better than the best minds in this arena know, they are on
very dangerous ground.
It should be pointed out that the IAB has no real authority, and never really
has had any (maybe they have even less now since being absorbed by the ISOC).
The IAB doesn't direct, it leads. And the ability of it to lead is based on
the respect and confidence of the R&D, vendor, and user communities. When the
IAB moves in this rather high-handed fashion, it erodes any leadership it
has, and simply compromises it's ability to push forward with any strategy. If
one looks back at history, the IAB has been most successful when it embraced
excellent technical standards, with real experience in prototyping and testing,
with the support of the technical and user communities. It has been an
utter failure when trying to advance less well defined proposals that
are not consistent with the Internet community's traditions and corporate
wisdom (CMOT comes to mind as an example).
I have many technical concerns with this approach, but I fear that any
discussion about the proposal's merits and faults will be secondary to the
manner which the IAB chose to push this approach. In my opinion, the IAB has
seriously undermined it's ability to advance and implement this strategy
by destroying it's own credibility as a leader. The CLNP proposal will
now have the tarbaby of a perceived powergrab associated with it, and is
unlikely to move forward. The IAB may well succeed in getting this RFC
advanced, but nobody will care. The IETF will continue to make progress
in other approaches, prototyping and testing, and real solutions will
eventually come forth and be deployed. Leadership is earned, and once
damaged is very difficult to rebuild.
This area, the scaling of the Internet (address depletion is a red herring,
the real issue is scaling), is an area where progress can ONLY be made
by rational debate, technical leadership and consensus building. By attempting
to cram this approach down the technical community's throat, the IAB has
undermined all these goals, and has made it harder for progress in ANY
approach to be made, which is perhaps the most tragic aspect of this whole
sad affair. This action isn't in the best traditions of the Internet, though
I fear it may in fact be setting a new trend.
Thanks,
Milo
PS Usual disclaimers about not representing the Government apply...
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04281;
3 Jul 92 15:51 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa19090; 3 Jul 92 15:52 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07449>; Fri, 3 Jul 1992 00:47:36 -0700
Received: from vm.gmd.de by venera.isi.edu (5.65c/5.65+local-6)
id <AA07444>; Fri, 3 Jul 1992 00:47:29 -0700
Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5823;
Fri, 03 Jul 92 09:45:11 MET
Received: by DEARN (Mailer R2.08) id 7544; Fri, 03 Jul 92 09:45:09 MET
Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE
id 7820 for MOD-IETF at SEARN.SUNET.SE; Fri, 3 Jul 1992 09:43:40 +0200
Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id
3082; Fri, 03 Jul 92 09:41:52 +0200
Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP;
Fri, 03 Jul 92 09:41:49 +0200
Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<15173-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 09:34:31 +0200
Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<12701-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 04:44:14 +0200
Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id
<03625-0 at relay.surfnet.nl>; Fri, 3 Jul 1992 04:44:10 +0200
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09930; 2 Jul
92 22:39 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09926; 2 Jul
92 22:39 EDT
Received: from cincsac.arc.nasa.gov by NRI.Reston.VA.US id aa11724; 2 Jul 92
22:40 EDT
Return-Path: <iesg-request at IETF.NRI.Reston.VA.US>
Original-Received: Thu,
2 Jul 92 19:39:44 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov
(4.1/1.5T)
Pp-Warning: Illegal Received field on preceding line
Message-Id: <9207030239.AA18618 at cincsac.arc.nasa.gov>
To: BSMTP <mod-ietf at dfn.dbp.de>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: Re: IPv7 (CLNP) a mistake
In-Reply-To: Your message of "Thu,
02 Jul 92 16:08:29 PDT." <9207022308.AA28811 at aland.bbn.com>
Date: Thu, 02 Jul 92 19:39:43 -0700
From: "Milo S. Medin" (NASA ARC NSI Office) <medin at nsipo.nasa.gov>
Sender: owner-mod-ietf at searn.sunet.se
I totally agree with Craig. There are a number of problems with trying
to base an IPv7 on CLNP in the manner that the IAB is trying to do. First
off, if you really didn't want to buy into the ISO standards process,
routing protocols, ES-IS, etc, you ought to have taken the CLNP packet
format, renamed all the fields, and then proclaimed the output IPv7.
This would have the effect you are looking for, having compatibility
of packet format, but being independent in other areas. By saying you
are basing the protocol on CLNP, you cause everyone to bring along all
the baggage they associate with OSI.
Another problem is that how addressing in this new scheme will work.
There is rightly a large amount of opposition to using real OSI delegated
NSAP's, for a number of technical reasons, but if the perception of them being
OSI addresses exists, all the baroque procedures for acquiring NSAP addresses
may try to be applied, causing even more confusion. In the US, this is just
plain complicated; overseas, it can often be the case that the existing Internet
activists in that country are in direct opposition to the official
NSAP authorities, such as PTT's. Confusion will reign, and it won't be
pretty. And the very people the IAB and IETF are trying to support will
be hurt.
Additionally, with such an RFC published, the marketing arms of the various
OSI vendors (which have been rather quiet in the past couple of years) will
go into high gear, going into Government labs and commercial organizations,
pitting fumeware against real TCP/IP products, and telling potential
customers that the Internet is now transitioning to OSI protocols, and how
they should be ahead of the power curve and skip the TCP/IP step completely,
thereby depriving the customer of working products, and the IP vendor
of deserved revenue. It's not that the IAB proposal says this will happen
in so many words, but a cursory reading of the document, and the quote
that Craig cited certainly will support this sort of viewpoint.
I could go on, but the real problem is how the process is working. If the
area directors of the IESG who are intimately working and wrestling with the
issues feel that making the choice about what the future of the IP protocol
ought to be is unclear, then the IAB ought to listen to that and act
accordingly. Many of these issues are hard problems. They do not go
away just because you use CLNP. When the IAB tells them that the IAB knows
what's best - better than the best minds in this arena know, they are on
very dangerous ground.
It should be pointed out that the IAB has no real authority, and never really
has had any (maybe they have even less now since being absorbed by the ISOC).
The IAB doesn't direct, it leads. And the ability of it to lead is based on
the respect and confidence of the R&D, vendor, and user communities. When the
IAB moves in this rather high-handed fashion, it erodes any leadership it
has, and simply compromises it's ability to push forward with any strategy. If
one looks back at history, the IAB has been most successful when it embraced
excellent technical standards, with real experience in prototyping and testing,
with the support of the technical and user communities. It has been an
utter failure when trying to advance less well defined proposals that
are not consistent with the Internet community's traditions and corporate
wisdom (CMOT comes to mind as an example).
I have many technical concerns with this approach, but I fear that any
discussion about the proposal's merits and faults will be secondary to the
manner which the IAB chose to push this approach. In my opinion, the IAB has
seriously undermined it's ability to advance and implement this strategy
by destroying it's own credibility as a leader. The CLNP proposal will
now have the tarbaby of a perceived powergrab associated with it, and is
unlikely to move forward. The IAB may well succeed in getting this RFC
advanced, but nobody will care. The IETF will continue to make progress
in other approaches, prototyping and testing, and real solutions will
eventually come forth and be deployed. Leadership is earned, and once
damaged is very difficult to rebuild.
This area, the scaling of the Internet (address depletion is a red herring,
the real issue is scaling), is an area where progress can ONLY be made
by rational debate, technical leadership and consensus building. By attempting
to cram this approach down the technical community's throat, the IAB has
undermined all these goals, and has made it harder for progress in ANY
approach to be made, which is perhaps the most tragic aspect of this whole
sad affair. This action isn't in the best traditions of the Internet, though
I fear it may in fact be setting a new trend.
Thanks,
Milo
PS Usual disclaimers about not representing the Government apply...
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04281;
3 Jul 92 15:51 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa19090; 3 Jul 92 15:52 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA07449>; Fri, 3 Jul 1992 00:47:36 -0700
Received: from vm.gmd.de by venera.isi.edu (5.65c/5.65+local-6)
id <AA07444>; Fri, 3 Jul 1992 00:47:29 -0700
Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5823;
Fri, 03 Jul 92 09:45:11 MET
Received: by DEARN (Mailer R2.08) id 7544; Fri, 03 Jul 92 09:45:09 MET
Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE
id 7820 for MOD-IETF at SEARN.SUNET.SE; Fri, 3 Jul 1992 09:43:40 +0200
Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id
3082; Fri, 03 Jul 92 09:41:52 +0200
Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP;
Fri, 03 Jul 92 09:41:49 +0200
Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<15173-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 09:34:31 +0200
Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id
<12701-0 at survis.surfnet.nl>; Fri, 3 Jul 1992 04:44:14 +0200
Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id
<03625-0 at relay.surfnet.nl>; Fri, 3 Jul 1992 04:44:10 +0200
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09930; 2 Jul
92 22:39 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09926; 2 Jul
92 22:39 EDT
Received: from cincsac.arc.nasa.gov by NRI.Reston.VA.US id aa11724; 2 Jul 92
22:40 EDT
Return-Path: <iesg-request at IETF.NRI.Reston.VA.US>
Original-Received: Thu,
2 Jul 92 19:39:44 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov
(4.1/1.5T)
Pp-Warning: Illegal Received field on preceding line
Message-Id: <9207030239.AA18618 at cincsac.arc.nasa.gov>
To: BSMTP <mod-ietf at dfn.dbp.de>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: Re: IPv7 (CLNP) a mistake
In-Reply-To: Your message of "Thu,
02 Jul 92 16:08:29 PDT." <9207022308.AA28811 at aland.bbn.com>
Date: Thu, 02 Jul 92 19:39:43 -0700
From: "Milo S. Medin" (NASA ARC NSI Office) <medin at nsipo.nasa.gov>
Sender: owner-mod-ietf at searn.sunet.se
I totally agree with Craig. There are a number of problems with trying
to base an IPv7 on CLNP in the manner that the IAB is trying to do. First
off, if you really didn't want to buy into the ISO standards process,
routing protocols, ES-IS, etc, you ought to have taken the CLNP packet
format, renamed all the fields, and then proclaimed the output IPv7.
This would have the effect you are looking for, having compatibility
of packet format, but being independent in other areas. By saying you
are basing the protocol on CLNP, you cause everyone to bring along all
the baggage they associate with OSI.
Another problem is that how addressing in this new scheme will work.
There is rightly a large amount of opposition to using real OSI delegated
NSAP's, for a number of technical reasons, but if the perception of them being
OSI addresses exists, all the baroque procedures for acquiring NSAP addresses
may try to be applied, causing even more confusion. In the US, this is just
plain complicated; overseas, it can often be the case that the existing Internet
activists in that country are in direct opposition to the official
NSAP authorities, such as PTT's. Confusion will reign, and it won't be
pretty. And the very people the IAB and IETF are trying to support will
be hurt.
Additionally, with such an RFC published, the marketing arms of the various
OSI vendors (which have been rather quiet in the past couple of years) will
go into high gear, going into Government labs and commercial organizations,
pitting fumeware against real TCP/IP products, and telling potential
customers that the Internet is now transitioning to OSI protocols, and how
they should be ahead of the power curve and skip the TCP/IP step completely,
thereby depriving the customer of working products, and the IP vendor
of deserved revenue. It's not that the IAB proposal says this will happen
in so many words, but a cursory reading of the document, and the quote
that Craig cited certainly will support this sort of viewpoint.
I could go on, but the real problem is how the process is working. If the
area directors of the IESG who are intimately working and wrestling with the
issues feel that making the choice about what the future of the IP protocol
ought to be is unclear, then the IAB ought to listen to that and act
accordingly. Many of these issues are hard problems. They do not go
away just because you use CLNP. When the IAB tells them that the IAB knows
what's best - better than the best minds in this arena know, they are on
very dangerous ground.
It should be pointed out that the IAB has no real authority, and never really
has had any (maybe they have even less now since being absorbed by the ISOC).
The IAB doesn't direct, it leads. And the ability of it to lead is based on
the respect and confidence of the R&D, vendor, and user communities. When the
IAB moves in this rather high-handed fashion, it erodes any leadership it
has, and simply compromises it's ability to push forward with any strategy. If
one looks back at history, the IAB has been most successful when it embraced
excellent technical standards, with real experience in prototyping and testing,
with the support of the technical and user communities. It has been an
utter failure when trying to advance less well defined proposals that
are not consistent with the Internet community's traditions and corporate
wisdom (CMOT comes to mind as an example).
I have many technical concerns with this approach, but I fear that any
discussion about the proposal's merits and faults will be secondary to the
manner which the IAB chose to push this approach. In my opinion, the IAB has
seriously undermined it's ability to advance and implement this strategy
by destroying it's own credibility as a leader. The CLNP proposal will
now have the tarbaby of a perceived powergrab associated with it, and is
unlikely to move forward. The IAB may well succeed in getting this RFC
advanced, but nobody will care. The IETF will continue to make progress
in other approaches, prototyping and testing, and real solutions will
eventually come forth and be deployed. Leadership is earned, and once
damaged is very difficult to rebuild.
This area, the scaling of the Internet (address depletion is a red herring,
the real issue is scaling), is an area where progress can ONLY be made
by rational debate, technical leadership and consensus building. By attempting
to cram this approach down the technical community's throat, the IAB has
undermined all these goals, and has made it harder for progress in ANY
approach to be made, which is perhaps the most tragic aspect of this whole
sad affair. This action isn't in the best traditions of the Internet, though
I fear it may in fact be setting a new trend.
Thanks,
Milo
PS Usual disclaimers about not representing the Government apply...
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04548;
3 Jul 92 16:30 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04542;
3 Jul 92 16:30 EDT
Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa20126;
3 Jul 92 16:31 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA21306; Fri, 3 Jul 92 15:52:23 EDT
Received: from akbar.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA21302; Fri, 3 Jul 92 15:52:21 EDT
Received: from Fuurinkan-Koukou.Panda.COM by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.26 ) id AA16511; Fri, 3 Jul 92 12:52:08 -0700
Date: Fri, 3 July 1992 12:51:30 -0700
From: Mark Crispin <MRC at panda.com>
To: henry at zoo.toronto.edu
Subject: Re: folklore etc.
Cc: ietf at isi.edu, ietf-822 at dimacs.rutgers.edu
Message-Id: <Mailstrom.B51.64978.15089.MRC at Panda.COM>
In-Reply-To: Your message <9207031630.AA19602 at dimacs.rutgers.edu> of Fri, 3
Jul 92 12:30:38 EDT
Content-Type: TEXT/plain; charset=US-ASCII
I don't think there is much hope for getting such folklore
documented, since there is a serious embarassment issue to
consider. Much of this folklore involves dealing with bugs
that should have become extinct years ago. A significant
subset of these consist of problems that could have been
readily addressed by minor modifications to the protocol
specification, but which for political reasons never
happened.
For example, RFC-822 implementations which expect the BNF
for `specials' to work as documented are in for a shock in
the real world. You end up with two sets of `specials'; one
which you use to generate RFC-822 and another which you use
to parse. The same thing is happening now with MIME, in
spite of my (evidentally futile) attempts to nip it in the
bud.
The old saw of `be liberal in what you accept, be
conservative in what you generate' hides a great many sins.
It is easier, I think, to recite this than it is to admit to
our past (and present) mistakes.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04744;
3 Jul 92 17:01 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa21103; 3 Jul 92 17:03 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA09625>; Fri, 3 Jul 1992 02:21:43 -0700
Received: from Angband.Stanford.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA09621>; Fri, 3 Jul 1992 02:21:41 -0700
Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0)
id AA22593; Fri, 3 Jul 92 02:19:42 -0700
Date: Fri, 3 Jul 92 04:29:36 EDT
From: William Allen Simpson <bsimpson at angband.stanford.edu>
Message-Id: <506.bsimpson at angband.stanford.edu>
To: ietf at isi.edu
Cc: big-internet at munnari.oz.au
Reply-To: bsimpson at angband.stanford.edu
Subject: Re: why 160-bit addresses are daft....
> Note - double the 4800 back to 9600 for slip or ppp performance
> over existing modems and you get 160 vs 800 - the ratio is still the same.
>
> I reassert, gentlefolks, that 160 bit addresses is raving lunacy.
>
> -Mike O'Dell
> Resident Crank with a 9600 baud modem
>
I originally got involved with IETF because of PPP, to get dialup IP
addresses and VJ header compression. I'm in the Merit regional, and
they have 1200 and 2400 bps service all over this state (Michigan). The
links in the "backbone" are 9600. Internally, the maximum unfragmented
packet size is 240 bytes.
So, you can see that big headers are not what we want here. Someday,
there may be header compression for CLNP. Otherwise, I'm quite sure
that I won't be using CLNP for a long, long, long time.
Be that as it may, the real lunacy is the autocratic fashion in which
the decision was made. The big-internet group has been debating for
quite a while. The IESG area directors hadn't reached a consensus.
Yet, the newly re-constituted IAB took it upon themselves to make a
decision, in an inaccessible meeting, without a recommendation from the
people who will actually do the work!
May I suggest that we engage in a Boston tradition: let's dump the IAB
in the harbor.
With ISO books attached.
Bill_Simpson at um.cc.umich.edu
bsimpson at ray.lloyd.com
- resident curmudgeon with 2400 bps modem
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab04970;
3 Jul 92 17:52 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa22116; 3 Jul 92 17:53 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA11522>; Fri, 3 Jul 1992 05:57:06 -0700
Received: from att.att.com (att-out.att.com) by venera.isi.edu (5.65c/5.65+local-6)
id <AA11518>; Fri, 3 Jul 1992 05:57:03 -0700
Message-Id: <199207031257.AA11518 at venera.isi.edu>
Date: Fri, 3 Jul 92 08:54 EDT
From: Tony DeSimone <tds at hoserve.att.com>
Sender: Antonio_DeSimone at att.com
To: mo at gizmo.bellcore.com
Cc: ietf at isi.edu, jnc at ginger.lcs.mit.edu
Subject: Re: why 160-bit addresses are daft....
In-Reply-To: <9207021822.AA06767 at gizmo.bellcore.com>
References: <9207021822.AA06767 at gizmo.bellcore.com>
Reply-To: Tony DeSimone <tds at hoserve.att.com>
>>>>> On Thu, 2 Jul 92 14:22:36 -0400, mo at gizmo.bellcore.com (Michael O'Dell) said:
Michael> The radios we can get now are about 9600 bits/second, and
Michael> with a LOT of luck, they may go as fast as 32kbits sometime
Michael> in the next several years. infrared may be faster, and
Michael> microcell radios like Xerox has may reach megabit speeds
Michael> sometime (assuming they are ever products), but some of us
Michael> want to use our technology on the existing systems.
Not that I disagree with the rest of the posting, but multimegabit RF
LANs exit as products today. The Columbia mobile networking work, for
example, uses NCR's WaveLAN product, which operates at 2 mb/s in the
900MHz ISM (Part 15) band, using csma/ca.
Anyway, some people think 32-bit addresses are too big for 2.4 kb
links, which led to compresses slip (which I like to call
virtual-circuit TCP/IP, just to raise the temperature of the
discussion :-)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab05011;
3 Jul 92 17:57 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa22223; 3 Jul 92 17:59 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA12268>; Fri, 3 Jul 1992 06:58:11 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA12261>; Fri, 3 Jul 1992 06:58:03 -0700
Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA00167; Fri, 3 Jul 92 09:55:37 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA00944; Fri, 3 Jul 92 06:53:44 PDT
Message-Id: <9207031353.AA00944 at aland.bbn.com>
To: bmanning at is.rice.edu
Cc: big-internet at munnari.oz.au, iab at isi.edu, ietf at isi.edu,
iseg at NRI.Reston.VA.US, road at lanl.gov
Subject: Re: IPv7 (CLNP) a mistake
In-Reply-To: Your message of Fri, 03 Jul 92 03:03:02 -0400.
<9207030703.AA23454 at ginger.lcs.mit.edu>
Reply-To: Craig Partridge <craig at aland.bbn.com>
Date: Fri, 03 Jul 92 06:53:43 -0700
From: Craig Partridge <craig at aland.bbn.com>
I, for one, would like to see something related to implementation
planning for some of the various drafts. ... When can we see
something ... other than architectural plans?
I think you'll see publicly available implementations of IPAE by early
fall. A survey of the necessary changes to the BSD code has been done
and with the exception of fixing up the BSD library routines (not to
be confused with the system call interface), the changes are entirely
straightforward, and mostly trivial, and completely invisible to the
user.
Craig
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05319;
3 Jul 92 19:49 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa24619; 3 Jul 92 19:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA14769>; Fri, 3 Jul 1992 08:05:44 -0700
Received: from relay.surfnet.nl ([130.161.180.100]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA14762>; Fri, 3 Jul 1992 08:05:39 -0700
Received: from erasmus.rare.nl by relay.surfnet.nl with SMTP (PP)
id <09153-0 at relay.surfnet.nl>; Fri, 3 Jul 1992 17:03:33 +0200
Received: by erasmus.rare.nl (4.1/4.31) id AA09648; Fri, 3 Jul 92 17:03:32 +0200
Date: Fri, 3 Jul 92 17:03:32 +0200
From: Tim Dixon <dixon at rare.nl>
Message-Id: <9207031503.AA09648 at erasmus.rare.nl>
To: ietf at isi.edu, mo at gizmo.bellcore.com
Subject: Re: Defeat snatched from the jaws of Victory...
Cc: big-internet at munnari.oz.au
What is the logical deduction about IP from the following two
loudest complaints about the IAB decision?
a) CLNP is a useless part of a useless protocol suite
b) CLNP is too similar to IP
Yes, you've got it! Amusing, but unhelpful.
Almost as amusing as the various implications that if the IAB sees a
round wheel lying on the ground it isn't allowed to use it without first
making sure the IETF doesn't prefer it square.
Actually, I suspect that the IAB decision is, at best, only marginally
relevant to the problems, imagined or real, of the Internet. However,
that is considerably more relevant than most of the reaction.
Tim
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05370;
3 Jul 92 20:00 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa24822; 3 Jul 92 20:01 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA11975>; Fri, 3 Jul 1992 06:48:08 -0700
Received: from gizmo.bellcore.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA11971>; Fri, 3 Jul 1992 06:48:06 -0700
Received: by gizmo.bellcore.com (5.61/1.34)
id AA07608; Fri, 3 Jul 92 09:46:10 -0400
Date: Fri, 3 Jul 92 09:46:10 -0400
From: Michael O'Dell <mo at gizmo.bellcore.com>
Message-Id: <9207031346.AA07608 at gizmo.bellcore.com>
To: ietf at isi.edu
Subject: Defeat snatched from the jaws of Victory...
Cc: big-internet at munnari.oz.au
This is VERY bad bongos.
While the technical and procedural failings of the IAB'sCLNP decision are
bad enough, the political repercussions could well end the Internet
as we now now it.
The reports I've be told from the latest OSI Upper Level Protocols
working group meeting indicate that the the body responsible for the
7-layer mistake now admits it has been a complete failure and they
largely decided to retarget their efforts to TCP/IP because of its
pervasiveness. (IE, they'd like to see their efforts used.) That's
thowing in the the towel by any metric. In short, we were really winning.
Now, the IAB annouces that the Internet should adopt part of the
7-layer mistake. What kind of message does this send? It means that
once the network can fully route CLNP traffic there will no longer be
any reason for the TCP/IP stack to exist. The market place won't
support wide-scale use of two non-interoperating environments and the
computer vendors will start pushing like hell to recover their OSI
investments. Political Correctness will exert itself as well.
It is also a kiss-of-death for all the emerging internet technology companies.
The OSI marketting droids will have a field-day with this.
If this decision stands (or is honored with any weight), we will have
witnessed the death of two major forces for technical excellence this
year: the Internet and CSRG at Berkeley. [Note that I didn't say they
always achieved the goal, but that they were honestly striving for it
without overly-much regard to political maneuvering and marketplace
jerrymandering by large vendors.]
Gee, I hope this is all wrong.
-Mike O'Dell
Bellcore?? Bellcore isn't allowed opinions, and they wouldn't want
these if they were.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05445;
3 Jul 92 20:14 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa25054; 3 Jul 92 20:15 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA11610>; Fri, 3 Jul 1992 06:07:00 -0700
Received: from mhs-relay.cs.wisc.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA11606>; Fri, 3 Jul 1992 06:06:46 -0700
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/;
Relayed; Fri, 3 Jul 1992 08:04:50 +0000
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Fri, 3 Jul 1992 08:04:43 +0000
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Fri, 3 Jul 1992 08:04:40 +0000
Date: Fri, 3 Jul 1992 08:04:40 +0000
X400-Originator: Alf.Hansen at delab.sintef.no
X400-Recipients: ietf at ISI.edu
X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;920703150440]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 2715
From: Alf Hansen <Alf.Hansen at delab.sintef.no>
Message-Id: <2715*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/C=no/@MHS>
To: ietf <ietf at isi.edu>
Subject: IETF X.400 OPS WG, Draft agenda, Boston.
------------------------------ Start of body part 1
Folks,
Hope to see some of you there.
Best regards,
Alf H
------------------------------ Start of body part 2
Call for 5th meeting in the IETF X.400 Operations Working Group,
IETF, Boston, Massachusetts, U.S.A.
From: Alf Hansen
Date: 07/02/92
MEETING TIME:
WEDNESDAY, July 15, 1992 1:30-3:30 pm 1st session
3:30-4:00 pm Break
4:00-6:00 pm 2nd session
HOTEL/MEETING SITE: Hyatt Regency Cambridge
Overlooking Boston
575 Memorial Drive
Cambridge, MA 02139
Phone: (617) 492-1234 {fax: (617) 491-6906}
CI 4:00 p.m.; CO 12:00 p.m.
250 Rooms reserved until June 12, 1992
$99.00/single; $99.00/double (please add 9.7% tax)
Specify: IETF or 24th Internet Engineering Task Force
General:
The concrete goals of this meeting is
1) to review documents (1st session).
2) to get a better understanding on how the Internet X.400 service
should be organized (in the U.S.) next year (2nd session).
The relevant documents and how they can be obtained:
Those marked as INTERNET-DRAFT, are available by anonymous FTP.
Login with the username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get filename".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/filename".
For questions, please mail to internet-drafts at nri.reston.va.us.
Those marked as UWISC are available via anonymous ftp from the
directory ~ftp/pub/ on mhs-relay.cs.wisc.edu (128.105.8.53).
DOCUMENTS:
OPS-1: Hansen/Hagens:
"Operational Requirements for X.400 Management Domains in the
GO-MHS Community", Revision: 1.13, June 19, 1992.
INTERNET-DRAFT, filename: draft-ietf-x400ops-mgtdomains-01.txt
UWISC, filenames: ietf/prmdreq.v1-13.ps (postscript)
ietf/prmdreq.v1-13.txt (text)
Please note that the dates on the UWISC versions are a few days
later that the official INTERNET-DRAFT version.
OPS-2: A.B. Bonito/C. Allocchio/S. Giordano:
"Using the Internet DNS to maintain RFC987/RFC1148
Address Mapping Tables and X.400 Routing Informations"
I will distribute my latest version: March 1992. Claudio:
Is there a later version? If so, can you distribute it?
Why is this not in the INTERNET-DRAFT archive?
OPS-3: Eppenberger:
"Routing coordination for X.400 MHS services within a
multi protocol / multi network environment", March 3 1992.
INTERNET-DRAFT, filename: draft-ietf-x400ops-mhs-service-00.txt
OPS-4: Claudio Allocchio:
"Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)",
March 2nd, 1992.
INTERNET-DRAFT: draft-ietf-x400ops-mapmail-00.txt
OPS-5: Harald Tveit Alvestrand:
"X.400 use of extended character sets", June 18, 1992.
INTERNET-DRAFT, filename: draft-ietf-x400ops-charactersets-00.txt
OPS-6: COSINE-MHS Project Team:
"Address mapping table update procedures".
Will there be a document to distribute before the Boston meeting?
Please come prepared to the meeting.
Provisional agenda
==================
1ST SESSION, Documents.
1. Welcome. 10 min
-----------
Secretary, roll call of delegates, agenda.
2. Review of revised charter. 10 min
-----------------------------
Revised Charter has been distributed. Discussion.
I would enjoy to hear if IESG and/or RTC could report from
progress in the integration process of RARE and IETF groups.
3. Action list from San Diego. 20 min
------------------------------
Short review of status for each item and report from each action:
John Sherburne (SPRINT) will work with Tony Genovese to figure out how US
can provide an MTA that has X.25 connectivity.
Urs will ask the COSINE MHS Project Team to submit the address mapping
table procedures as a draft RFC.
Stef - Start a discussion on X.400 OPS and WG1 lists about ADMD name in
the US. See section 3.1.2.
Alf will send the updated charter to the list.
Claudio will produce a draft document that will propose a method for using
DNS to store X.400 to RFC 822 mapping and routing.
Claudio will follow up the MAIL 11 mapping document.
Harald will follow up the International Character set document.
4. Review of documents. 1 hr 20 min
-----------------------
OPS-1: Has been updated according to comments from last meeting.
Status: Internet Draft. Ready for status change?
OPS-2: This is not yet an official Internet Draft. Will it be?
Is there progress to report from the experimental implementations?
Claudio?
OPS-3: This is a stable document.
Status: Internet Draft. Has it been moved to "experimental RFC"
status as recommended in San Diego?
OPS-4: No updates noted since last meeting.
Status: Internet Draft. Is it ready for status change?
OPS-5: This is a new document,
Status: Internet Draft. Harald presents. Review.
OPS-6: I have not seen this document yet. Perhaps it will be
distributed before the meeting.
2ND SESSION, Organizational issues.
5. Status on X.400 operations. 35 min
------------------------------
Allan Cargille, UWisc (Internet X.400 project) reports on project
status and future plans.
Perhaps a COSINE MHS Project Team member can report on COSINE MHS
status, and furture plans for the post-COSINE period(?)
6. RFC 1327 (was 1148bis) gateway tracking. 15 min
-------------------------------------------
It has been proposed that this WG should keep track of existing
gateways between the SMTP world and the X.400 world. The background
for this is that it seems to be many strange behaving gateways
out there, causing strange things to happen send from an end-user's
point of view.
Discussion and recommendation.
7. Major operational problem. 15 min
-----------------------------
Identification of ONE major operational problem that has not yet
been handled good enough by ourselves or other WGs.
Proposals for actions to speed up the solusion to THIS (and only
THIS) major problem.
Candidates: Lack of one global RFC 822/X.400 SA address mapping, The manual
mapping table procedures, The interpretation of the "1148gate" table,
Character sets, New body parts, Service organization, Connectivity
to public e-mail service providers, there are more ...
Is it possible to agree on what the most major problem is, and start
solving it in a new way?
8. Future U.S. Internet X.400 organization. 35 min
-------------------------------------------
Is there a proposal on how X.400 in the U.S. Internet should be
organized such that the operational requirements will be met in
a most effective way?
Discussion and recommendation.
9. Summary of conclusions and actions. 5 min
---------------------------------------
The secretary presents the action list.
10. A(ny) O(ther) B(usiness) and plan for next meetings. 5 min
--------------------------------------------------------
Next meeting: When is the next IETF?
------------------------------ End of body part 2
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05590;
3 Jul 92 21:34 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa26777; 3 Jul 92 21:35 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA15589>; Fri, 3 Jul 1992 08:41:20 -0700
Received: from chx400.switch.ch by venera.isi.edu (5.65c/5.65+local-6)
id <AA15585>; Fri, 3 Jul 1992 08:41:15 -0700
X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/;
Relayed; Fri, 3 Jul 1992 17:39:13 +0200
X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed;
Fri, 3 Jul 1992 17:38:41 +0200
Date: Fri, 3 Jul 1992 17:38:41 +0200
X400-Originator: Eppenberger at switch.ch
X400-Recipients: ietf at ISI.edu
X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;920703173841]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 732
From: Urs Eppenberger <Eppenberger at switch.ch>
Message-Id: <732*/S=Eppenberger/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>
To: ietf <ietf at isi.edu>
Subject: Messages abot 'Re: IPv7 (CLNP) a mistake'
If all the flames sent around about these items would have been
C-code implementing the proposed solutions, then we could start
using it operationally now.
Urs.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05625;
3 Jul 92 21:51 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa27013; 3 Jul 92 21:52 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA14094>; Fri, 3 Jul 1992 07:45:41 -0700
Received: from sayshell.umd.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA14088>; Fri, 3 Jul 1992 07:45:35 -0700
Received: by sayshell.umd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0)
id AA09329; Fri, 3 Jul 92 10:43:15 EDT
Message-Id: <9207031443.AA09329 at sayshell.umd.edu>
To: lixia at parc.xerox.com
Cc: Craig Partridge <craig at aland.bbn.com>, big-internet at munnari.oz.au,
iab at isi.edu, iesg at NRI.Reston.VA.US, ietf at isi.edu, road at lanl.gov
Reply-To: "Louis A. Mamakos" <louie at ni.umd.edu>
Subject: Re: IPv7 (CLNP) a mistake
In-Reply-To: Your message of "Thu, 02 Jul 92 16:43:02 PDT."
<CMM.0.88.710120582.lixia at parc.xerox.com>
Date: Fri, 03 Jul 92 10:43:14 -0400
From: "Louis A. Mamakos" <louie at sayshell.umd.edu>
I sure seems to me that a proposed change with such extensive impact
on the operational aspect of the Internet should have the benefit of
considerable open discussion and comment. We cannot afford to "look
before we leap" in this instance.
I have heard enough dissent over just the 160 bit addresses to make me
wary without even commenting on some of the other aspects of the
proposal. Personally, I'm not too keen on variable length addresses,
nor do I consider them an advantage. Since the new architecture looks
to be more dependent on directory services than the the old, I'm
particularly concerned about low bandwidth connected hosts where
header compression alogrithms won't do any good with UDP-like queries.
In any case, most of the document seems reasonable until we get to
section 5. "THE WAY FORWARD":
In order to guarantee the survival of the Internet, work should start
now on the various items detailed in this document. Delaying by a few
more months in order to gather more information would be very unlikely
to help us make a decision, and would encourage people to spend their
time crafting arguments for why CLNP is or is not a better solution
than some alternative, rather than working on the detailed
specification of how CLNP can be used as the basis for IPv7 and
resolving the technical questions (particularly in the area of address
administration and the effect on existing application software) that
must be answered in order to specify a deployment plan for IPv7.
However real and pressing our current problems are, we must afford a
few more months for more "public" comment and review on this proposal
before commiting significant resources along a particular line of work
and a particular architecture. The cost of failure is just too high.
There are too many viewpoints which may not have been considered by the
group crafting this proposal; Mike O'Dell brings one to the table which
may or may not have been addressed.
Personally, I'd like to hear arguments for why CLNP is or is not a
better solution than alternatives (such as Hinden and Crocker's IPAE).
One internet draft crafted by the IAB is not sufficiently compelling
for me, and seems to fly in the face of the consensus building process
the Internet community (well, it once really was a community) has
mostly successfully used in the past.
Louis Mamakos
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05736;
3 Jul 92 22:53 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa28631; 3 Jul 92 22:54 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA16721>; Fri, 3 Jul 1992 09:31:39 -0700
Received: from GINGER.LCS.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA16716>; Fri, 3 Jul 1992 09:31:34 -0700
Received: by ginger.lcs.mit.edu
id AA24914; Fri, 3 Jul 92 12:29:53 -0400
Date: Fri, 3 Jul 92 12:29:53 -0400
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9207031629.AA24914 at ginger.lcs.mit.edu>
To: bsimpson at angband.stanford.edu, ietf at isi.edu
Subject: Re: informal notice of two IESG decisions
Cc: jnc at ginger.lcs.mit.edu
I agree that both negative and positive decisions should be published,
Every negative decisions? Certainly, any negative decision on a
submission by a WG, but what about the random little documents that come in
'over the transom', as book editors call it?
I'm not opposed in principle, but I fear that the IETF would quickly
grow bored with sorting through all the rejections, and consequent mail on the
IETF list, for ones that might be important...
I mean, if anyone really feels he has been done down by the 'IETF
bureacrats', he can do as Mr. Bernstein did, and avail himself of the IETF
mailing list..
Noel
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05785;
3 Jul 92 23:10 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa29485; 3 Jul 92 23:11 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA15428>; Fri, 3 Jul 1992 08:32:50 -0700
Received: from munnari.OZ.AU by venera.isi.edu (5.65c/5.65+local-6)
id <AA15421>; Fri, 3 Jul 1992 08:32:41 -0700
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA22286; Sat, 4 Jul 1992 01:30:41 +1000 (from kre)
To: Tim Dixon <dixon at rare.nl>
Cc: ietf at isi.edu, mo at gizmo.bellcore.com, big-internet at munnari.oz.au
Subject: Re: Defeat snatched from the jaws of Victory...
In-Reply-To: Your message of Fri, 03 Jul 92 17:03:32 +0200.
<9207031503.AA09648 at erasmus.rare.nl>
Date: Sat, 04 Jul 92 01:30:32 +1000
Message-Id: <19158.710177432 at munnari.oz.au>
From: Robert Elz <kre at munnari.oz.au>
Date: Fri, 3 Jul 92 17:03:32 +0200
From: dixon at rare.nl (Tim Dixon)
Message-ID: <9207031503.AA09648 at erasmus.rare.nl>
a) CLNP is a useless part of a useless protocol suite
b) CLNP is too similar to IP
Yes, you've got it! Amusing, but unhelpful.
While expressed that way the arguments may appear amusing,
they're not at all.
(a) points out that the decision may risk embroiling the
Internet in a political mess that no-one wants, no matter
how hard we try to stay out of it by protesting our independance.
(b) indicates that while CLNP will take a massive effort to
deploy, the actual benefit in doing that might not be nearly
as much as it would appear at first glance, and that this step
may not end up actually lasting long before another radical
change is needed.
General feeling has been that only one more major change can
be supported in the Internet - certainly only one more in the
forseeable future, after that inertia will simply be too much
to overcome, and nothing more than tinkering around the edges
will really be possible.
The IAB's decision has gone against this as well, they're
actually planning for two radical revisions, CLNP, and then
something later once a choice has been made, to add policy
routing, etc, which CLNP won't give.
kre
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05830;
3 Jul 92 23:20 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa00411; 3 Jul 92 23:22 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA16425>; Fri, 3 Jul 1992 09:18:40 -0700
Received: from GINGER.LCS.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA16420>; Fri, 3 Jul 1992 09:18:34 -0700
Received: by ginger.lcs.mit.edu
id AA24803; Fri, 3 Jul 92 12:16:29 -0400
Date: Fri, 3 Jul 92 12:16:29 -0400
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9207031616.AA24803 at ginger.lcs.mit.edu>
To: dixon at rare.nl, ietf at isi.edu, mo at gizmo.bellcore.com
Subject: Re: Defeat snatched from the jaws of Victory...
Cc: big-internet at munnari.oz.au, jnc at ginger.lcs.mit.edu
What is the logical deduction about IP from the following two
loudest complaints about the IAB decision?
a) CLNP is a useless part of a useless protocol suite
b) CLNP is too similar to IP
Exactly. It was a conclusion similar to the conclusion of this line
of thought that lead me to point out to what then known as the Internet
Working Group (the predecessor to the IAB/IETF complex) at a presentation at
ISI in about 1981 that the IP architecture:
i) had made some non-optimal choices (which I don't see as indicative of a
poor design process, since everyone was still very much feeling their way back
then) about confusing things like addresses and host identifiers, and in
fact had proabbly left out a layer of naming at the packet level
ii) was probably obsolescent as a result of this aspect of the design, and
would benefit greatly from being redone at some point
Thus, you have the mental framework on hand in which I first looked at a copy
of the CLNP spec (I don't recall exactly when, but it was in the earily 80's),
and upon making the observation you have labelled b), realized CLNP was
neither fish (IP/TCP interoperable) nor fowl (a design which righted some of
the fundamental errors of IP).
Well, it's all water under the bridge know. I guess the point is that
that the two observations you have listed above lead me to exactly the same
conclusion: both IP and CLNP are obsolescent. I somehow doubt this was your
point, though...
Almost as amusing as the various implications that
In a telecon on this matter, I was rebuked (and rightly so) by Lyman
for being funny about this. Now, I agree, sometimes things are so desparate
you can be funny, or scream, but being funny can be taken the wrong way,
so let's be sparing with it in public debate, everyone, OK?
if the IAB sees a round wheel lying on the ground it isn't allowed
to use it without first making sure the IETF doesn't prefer it square.
Exactly. If you really think otherwise, you don't appreciate
organically the IETF process, which is embodied not so much in our written
rules, (which reflect, not create, the original reality created by
experience), but in the character and attitudes of our members.
"Our ordinary citizens, though occupied with the pursuits of industry,
are still fair judges of public matters; for, unlike any other nation, ... we
Athenians are able to judge at all events if we cannot originate, and instead
of looking on discussion as a stumbling block in the way of action, we think
it an indispensable preliminary to any wise action at all."
--Pericles, given in Thucydides, "Peloponnesian War", Tr. Crawley.
Noel
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05972;
4 Jul 92 0:22 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa01903; 4 Jul 92 0:23 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA16745>; Fri, 3 Jul 1992 09:32:28 -0700
Received: from zoo.toronto.edu (zoo.utoronto.ca) by venera.isi.edu (5.65c/5.65+local-6)
id <AA16739>; Fri, 3 Jul 1992 09:32:22 -0700
Message-Id: <199207031632.AA16739 at venera.isi.edu>
From: henry at zoo.toronto.edu
Date: Fri, 3 Jul 92 12:30:38 EDT
To: ietf at isi.edu
Cc: ietf-822 at dimacs.rutgers.edu
Subject: folklore etc.
Mark Crispin wrote (in the 822 list, regarding a MIME problem):
> As an example, consider that years after the bug in an ancient version of
>BSD was fixed, we still have to worry about handling MAIL FROM commands in
>SMTP that are missing the host name, or that have colon delimiters in the at-
>domain-list instead of commas. This isn't documented in SMTP; rather, it's
>in the folklore of how you get your SMTP server to be interoperable...
A procedural thought on this: it Sure Would Be Nice if some of the people
who have been exposed to things like this sat down and wrote a few
Informational RFCs *documenting* some of this folklore. One of the most
infuriating things about implementing some of the Internet protocols is
running across these bits of important information that aren't written
down *anywhere*, apparently on the assumption that anyone who needs to
know them already does. Not so.
While there is no substitute for interoperability testing, such testing
should be significantly quicker and less painful if people didn't have
to rediscover problems that others have known about for years (but have
never bothered to write down).
Henry Spencer at U of Toronto Zoology
henry at zoo.toronto.edu utzoo!henry
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06056;
4 Jul 92 0:50 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa02434; 4 Jul 92 0:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA16884>; Fri, 3 Jul 1992 09:39:27 -0700
Received: from EAGLE.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA16878>; Fri, 3 Jul 1992 09:39:20 -0700
Received: from [137.103.1.220] by Eagle.MIT.EDU with SMTP
id AA02078; Fri, 3 Jul 92 12:37:33 EDT
Message-Id: <9207031637.AA02078 at Eagle.MIT.EDU>
Date: Fri, 3 Jul 1992 12:43:34 -0500
To: ietf at isi.edu, members at farnet.org
From: breeden at farnet.org
Subject: FARNET BOF on IINREN plans
FARNET, the Federation of American Research Networks, is holding a BOF at
the upcoming IETF meeting, on Wednesday evening, July 15, from 7-10 PM.
The subject of the BOF is the NSF plan for the evolution of the Interim
Interagency NREN and related draft solicitation for the next phase of the
NSFNET. FARNET is holding a workshop just before the IETF meeting to
discuss these documents. The BOF will inform IETFers about the workshop
and will permit additional discussion of the issues (such as the effect of
a NAP-based architecture on the current Internet service providers and NREN
constituencies).
A number of active IETF working group members will be in attendance at the
workshop, and we welcome the opportunity for further interaction with IETF
participants. FYI, the deadline for comments to NSF on the draft
solicitation is August 3. Copies of the solicitation and the
Aiken-Ford-Braun paper on the IINREN may be obtained as follows:
From host nic.merit.edu, in directory 'cise/recompete'
From host expres.cise.nsf.gov, in directory 'recompete'
More information about FARNET is available on host farnet.org, in the
'farnet' directories.
M&Ms will be served at the BOF.
Laura Breeden
Executive Director
FARNET
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa06148;
4 Jul 92 1:27 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06142;
4 Jul 92 1:27 EDT
Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa03007;
4 Jul 92 1:29 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA23909; Sat, 4 Jul 92 01:00:53 EDT
Received: from cider.cisco.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA23905; Sat, 4 Jul 92 01:00:50 EDT
Received: by cider.cisco.com; Fri, 3 Jul 92 22:00:36 -0700
Date: Fri, 3 Jul 92 22:00:36 PDT
From: William Chops Westfield <billw at cider.cisco.com>
To: henry at zoo.toronto.edu
Cc: ietf at isi.edu, ietf-822 at dimacs.rutgers.edu
Subject: Re: folklore etc.
In-Reply-To: Your message of Fri, 3 Jul 92 12:30:38 EDT
Message-Id: <CMM.0.90.2.710226036.billw at cider.cisco.com>
..it Sure Would Be Nice if some of the people who have been
exposed to things like this sat down and wrote a few
Informational RFCs *documenting* some of this folklore. One of
the most infuriating things about implementing some of the
Internet protocols is running across these bits of important
information that aren't written down *anywhere*, apparently on
the assumption that anyone who needs to know them already does.
Well, the "Host Requirments" RFCs documented some of it, and tried to
legislate the rest of it out of existancs. Unfortunately, that doesn't
seem to have worked.
BillW
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06188;
4 Jul 92 1:37 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03183; 4 Jul 92 1:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA18808>; Fri, 3 Jul 1992 11:09:49 -0700
Received: from ray.lloyd.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA18769>; Fri, 3 Jul 1992 11:08:18 -0700
Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016)
id AA01695; Fri, 3 Jul 92 11:06:16 PDT
Date: Fri, 3 Jul 92 11:06:16 PDT
From: Brian Lloyd <brian at lloyd.com>
Message-Id: <9207031806.AA01695 at ray.lloyd.com>
To: craig at aland.bbn.com
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
In-Reply-To: Craig Partridge's message of Thu, 02 Jul 92 16:08:29 -0700 <9207022308.AA28811 at aland.bbn.com>
Subject: IPv7 (CLNP) a mistake
Reply-To: brian at lloyd.com
Could someone please set me straight. I thought that IPv7 as proposed
by the IAB would be an attempt to take what has been learned from CLNP
and apply it to a new protocol/packet format. From this point of view
IPv7 is not CLNP. It is a new protocol/packet format that is based on
knowledge gleaned from both IP and CLNP, therefore, since we are
trying to create a new protocol that meets the needs of the Internet
there is no rational reason to participate in either the ISO or the
CCITT standards process.
Like many of you I also subscribe to the school of thought that the
standards organizations tend to throw a lot of excess baggage into
their protocols (the kitchen sink school of protocol design :-).
On the other hand, just because you throw in lots of useless things
doesn't mean that you don't toss in the occasional useful feature as
well. Old saying, "even a blind hog finds an acorn occasionally."
Think of CLNP as a [not-so] grand experiment from which we can learn
and improve. Is this not the Internet Way; to try something, learn
from it, and then use the experience to improve the protocol? From
that point of view CLNP is merely a first cut. So a new protocol
-based- on CLNP (and IP) might not be a bad idea as long as we are not
talking slavish adherence to ISO excessiveness.
Brian Lloyd, WB6RQN Lloyd & Associates
Principal and Network Architect 3420 Sudbury Road
brian at lloyd.com Cameron Park, CA 95682
voice (916) 676-1147 -or- (415) 725-1392
P.S. Seems to me that this might be a good opportunity to bury the
hatchet (no, not in each other's skulls) and let the ISORMites
seriously participate in the development of CLNP-II (nicknamed IPv7
but they'll know it is really an improved and streamlined CLNP). [;-)
* 0.5]
B
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06212;
4 Jul 92 1:45 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03325; 4 Jul 92 1:47 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA19467>; Fri, 3 Jul 1992 11:38:59 -0700
Received: from uu2.psi.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA19459>; Fri, 3 Jul 1992 11:38:52 -0700
Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet)
id AA18643; Fri, 3 Jul 92 14:36:23 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA02858; Fri, 3 Jul 92 11:35:22 PDT
Message-Id: <9207031835.AA02858 at aland.bbn.com>
To: Brian Lloyd <brian at lloyd.com>
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: re: IPv7 (CLNP) a mistake
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Fri, 03 Jul 92 11:35:21 -0700
Sender: craig at aland.bbn.com
Brian:
See my note to Bob Braden of yesterday. The goal is to adopt ISO CLNP
and to keep in harmony (the exact words are "functionally compatible" and
"convergent") with ISO CLNP. IPv7 is CLNP by another name.
Craig
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa06257;
4 Jul 92 1:56 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03541; 4 Jul 92 1:58 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA19907>; Fri, 3 Jul 1992 11:58:00 -0700
Received: from usc.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA19903>; Fri, 3 Jul 1992 11:57:57 -0700
Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA26731;
Fri, 3 Jul 92 11:56:02 PDT
Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA09861;
Fri, 3 Jul 92 11:56:02 PDT
Date: Fri, 3 Jul 92 11:56:02 PDT
Message-Id: <9207031856.AA09861 at caldera.usc.edu>
From: Deborah Estrin <estrin at usc.edu>
Sender: estrin%caldera.usc.edu at usc.edu
To: deering at parc.xerox.com
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
In-Reply-To: Steve Deering's message of Thu, 2 Jul 1992 18:36:18 PDT <92Jul2.183627pdt.22277 at skylark.parc.xerox.com>
Subject: Re: IPv7 (CLNP) a mistake
Reply-To: estrin at usc.edu
I have to second Steve's comments about the timing question.
That question needs to be answered before any of the ones i mentioned in my
prev message, namely "WHy doesn't CIDR give us just a bit of breathing room in
which to spend n months evaluating the alternatives with the attention
this issue deserves?".
THere might be a reasonable answer to this, but I cant come up with it
first hand...
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00403;
4 Jul 92 3:35 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa01801; 4 Jul 92 3:36 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21230>; Fri, 3 Jul 1992 12:53:59 -0700
Received: from akbar.cac.washington.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA21226>; Fri, 3 Jul 1992 12:53:55 -0700
Received: from Fuurinkan-Koukou.Panda.COM by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.26 ) id AA16511; Fri, 3 Jul 92 12:52:08 -0700
Date: Fri, 3 July 1992 12:51:30 -0700
From: Mark Crispin <MRC at panda.com>
To: henry at zoo.toronto.edu
Subject: Re: folklore etc.
Cc: ietf at isi.edu, ietf-822 at dimacs.rutgers.edu
Message-Id: <Mailstrom.B51.64978.15089.MRC at Panda.COM>
In-Reply-To: Your message <9207031630.AA19602 at dimacs.rutgers.edu> of Fri, 3
Jul 92 12:30:38 EDT
Content-Type: TEXT/plain; charset=US-ASCII
I don't think there is much hope for getting such folklore
documented, since there is a serious embarassment issue to
consider. Much of this folklore involves dealing with bugs
that should have become extinct years ago. A significant
subset of these consist of problems that could have been
readily addressed by minor modifications to the protocol
specification, but which for political reasons never
happened.
For example, RFC-822 implementations which expect the BNF
for `specials' to work as documented are in for a shock in
the real world. You end up with two sets of `specials'; one
which you use to generate RFC-822 and another which you use
to parse. The same thing is happening now with MIME, in
spite of my (evidentally futile) attempts to nip it in the
bud.
The old saw of `be liberal in what you accept, be
conservative in what you generate' hides a great many sins.
It is easier, I think, to recite this than it is to admit to
our past (and present) mistakes.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00492;
4 Jul 92 5:27 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa03296; 4 Jul 92 5:28 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21325>; Fri, 3 Jul 1992 12:56:10 -0700
Received: from TGV.COM (HQ.TGV.COM) by venera.isi.edu (5.65c/5.65+local-6)
id <AA21321>; Fri, 3 Jul 1992 12:56:07 -0700
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Fri, 3 Jul 92 12:52:54 PDT
Received: from karl.lvs.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA00969; Fri, 3 Jul 92 12:53:59 PDT
Date: Fri, 3 Jul 92 12:53:59 PDT
Message-Id: <9207031953.AA00969 at mel-brooks.empirical.com>
To: mo at gizmo.bellcore.com
Subject: Re: 160-bit addresses
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at mel-brooks.tgv.com>
Reply-To: karl at tgv.com
Cc: ietf at isi.edu
Sender: karl at mel-brooks.tgv.com
Repository: empirical.com
Originating-Client: lvs.empirical.com
I agree that big addresses (160 bits) are madness.
Protocol designers ought to have some concept of how computers work
and what sort of data sizes are efficient and what sizes are not.
Table lookups are slow enough without the key size being many
multiples of machine register size.
And variable size anything (e.g. NSAPs and ASN.1/BER) is an
invitatation to poor performance because you often are reduced to a
byte-by-byte examination of your packet before you can even use it.
There are the purists who would insist that we ought not pay any
attention to the underlying processor capabilities. That, however,
is stupid. That path leads to OSI.
--karl---
(Institutional Iconoclast)
> this is sheer madness. if you want to absolutely guarantee that
> internetworking as we know it is excluded from the emerging
> wireless technologies, go right ahead and mandate 160-bit addresses.
> the only hope is that the wireless folks will infarc from sustained
> laughter before they run us out of town on a rail, as we would
> richly deserve.
>
> this is too silly to be believed.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00528;
4 Jul 92 6:02 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04052; 4 Jul 92 6:03 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA21332>; Fri, 3 Jul 1992 12:56:52 -0700
Received: from TGV.COM (HQ.TGV.COM) by venera.isi.edu (5.65c/5.65+local-6)
id <AA21305>; Fri, 3 Jul 1992 12:55:24 -0700
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Fri, 3 Jul 92 12:53:32 PDT
Received: from karl.lvs.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA01043; Fri, 3 Jul 92 12:54:39 PDT
Date: Fri, 3 Jul 92 12:54:39 PDT
Message-Id: <9207031954.AA01043 at mel-brooks.empirical.com>
To: lixia at parc.xerox.com
Subject: Re: IPv7 (CLNP) a mistake
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at mel-brooks.tgv.com>
Reply-To: karl at tgv.com
Cc: craig at aland.bbn.com, big-internet at munnari.oz.au, iab at isi.edu,
iesg at NRI.Reston.VA.US, ietf at isi.edu, road at lanl.gov
Sender: karl at mel-brooks.tgv.com
Repository: empirical.com
Originating-Client: lvs.empirical.com
I agree with Lixia. There are a number of problems with our current
IP protocol, only one of which is the address size.
There are many useful ideas we can glean from CLNP (I personally like
non-segmenting nets), but the pain of a wholesale transition to CLNP
would not be offset by the relatively small increment in capability.
I, personally, like many of the ideas in NIMROD. I, like most of us,
don't have the foggiest notion, however, how they might be
implemented.
And I certainly want to make sure that whatever protocol we do adopt
avoids performance stupidies like variable size fields, critical data
at indeterminate offsets, checksums at the beginning or middle of the
packet, and overly-huge addresses.
And there is nothing in CLNP (or IP) to make life pleasant for
nomadic devices. [However, I am becomming increasingly convinced
that nomadic operation is more a concern for applications and
applications protocols than it is for the network layer and ancillary
routing protocols.]
Remember, that we are talking about the protocol that happens with
each packet as it passes through each router. That means it happens
*many* times per second, making little inefficiencies into a big
overhead.
--karl--
> > In short, CLNP as IPv7 seems destined to be a technical step backwards
> > and to place a severe crimp on protocol innovation at a time when we
> > need to innovate.
>
> I agree with this statement with my both hands up.
>
> For decisions this big, I'm shocked to see that IAB made the move
> without holding an open hearing period for opinions from the internet
> community.
>
> I would like to hear how other people think about this.
>
> Lixia
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00550;
4 Jul 92 6:05 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa04148; 4 Jul 92 6:06 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22764>; Fri, 3 Jul 1992 14:03:35 -0700
Received: from MITVMA.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA22760>; Fri, 3 Jul 1992 14:03:32 -0700
Message-Id: <199207032103.AA22760 at venera.isi.edu>
Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2)
with BSMTP id 4267; Fri, 03 Jul 92 17:02:10 EDT
Received: from SMCVAX.BITNET (KUMQUAT) by MITVMA.MIT.EDU (Mailer R2.08 R208004)
with BSMTP id 3888; Fri, 03 Jul 92 17:02:08 EDT
Date: Fri, 3 Jul 92 10:50 EDT
From: "Gary C. Kessler, +1 802-879-3375" <KUMQUAT%SMCVAX.BITNET at mitvma.mit.edu>
Subject: Re: 160-bit addresses
To: HANK%VM.TAU.AC.IL at taunivm.tau.ac.il, mo at gizmo.bellcore.com, ietf at isi.edu
X-Vms-To: IN%"HANK%VM.TAU.AC.IL at TAUNIVM.TAU.AC.IL"
If the calculations are correct, 92 bits (or therabouts) would allow us
to address all the atoms in the solar system...
/kessler
Gary C. Kessler
Colchester, VT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00601;
4 Jul 92 6:55 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa05292; 4 Jul 92 6:56 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA19735>; Fri, 3 Jul 1992 11:49:57 -0700
Received: from usc.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA19731>; Fri, 3 Jul 1992 11:49:54 -0700
Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA26503;
Fri, 3 Jul 92 11:46:28 PDT
Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA09841;
Fri, 3 Jul 92 11:46:28 PDT
Date: Fri, 3 Jul 92 11:46:28 PDT
Message-Id: <9207031846.AA09841 at caldera.usc.edu>
From: Deborah Estrin <estrin at usc.edu>
Sender: estrin%caldera.usc.edu at usc.edu
To: lixia at parc.xerox.com
Cc: craig at aland.bbn.com, big-internet at munnari.oz.au, iab at isi.edu,
iesg at NRI.Reston.VA.US, ietf at isi.edu, road at lanl.gov
In-Reply-To: Lixia Zhang's message of Thu, 2 Jul 1992 16:43:02 PDT <CMM.0.88.710120582.lixia at parc.xerox.com>
Subject: Re: IPv7 (CLNP) a mistake
Reply-To: estrin at usc.edu
It sounds as if :
1. The IAB needs to explain why it believes we can
adopt CLNP format and still have change control.
2. Those who have experience with CLNP need to convince us that
progress/solutions for multicast, mobility, etc developed for IP are
TECHNICALLY portable; IF we can assume that 1 makes them politically portable.
3. Someone from the IAB needs to summarize why the
alternatives available today were not found to be viable. eg. what
aspects of an IP encapsulation scheme are too risky to assume a robust
system wide implementation and deployment in the timeframe required.
The CLNP folks (not only from digital but other places) claim
experience running CLNP and it seems that the IAB felt a somewhat
"conservative", i.e. low risk, strategy was essential. Do you disagree
with a) their assessment of the risk of other schemes, b) the risk of
CLNP, or c) their making the conservative choice?
Finally, I was not able to attend the San Diego IETF but I **thought**
that the CLNP based scheme was put forth at that time and that community
discussion was requested. But this could be a misperception on my
part. Is it?
D.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00741;
4 Jul 92 7:38 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06005; 4 Jul 92 7:40 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA23194>; Fri, 3 Jul 1992 14:24:20 -0700
Received: from regal.cisco.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA23175>; Fri, 3 Jul 1992 14:22:57 -0700
Received: by regal.cisco.com; Fri, 3 Jul 92 14:21:11 -0700
Date: Fri, 3 Jul 92 14:21:11 -0700
From: Dino Farinacci <dino at cisco.com>
Message-Id: <9207032121.AA11816 at regal.cisco.com>
To: mak at merit.edu
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
In-Reply-To: mak at merit.edu's message of Fri, 03 Jul 92 16:32:46 -0400 <9207032032.AA06542 at home.merit.edu>
Subject: IPv7
>> We would like to express our strong support for the decision
>> made by the IAB with respect to adopting CLNP as the basis for
>> V7 of the Internet Protocol.
My sentiments exactly. Note the phrase "as the basis for V7".
Was not OSPF based on IS-IS, was not SNMP based on ASN.1. Is not
IDRP based on BGP. Is not CLNS multicasting based on Deering's work.
These are all protocols/technologies. Let's use any of them to our
advantage.
>> The decision made by the IAB clearly demonstrated that the
>> the IAB was able to go beyond parochial arguments (TCP/IP vs
>> CLNP), and make its judgements based on practical and pragmatic
>> considerations.
I agree.
Dino
P.S. There is relief, nothing new is based on RIP :-)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00755;
4 Jul 92 7:41 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06034; 4 Jul 92 7:42 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22725>; Fri, 3 Jul 1992 14:01:57 -0700
Received: from merit.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA22719>; Fri, 3 Jul 1992 14:01:53 -0700
Return-Path: <mak at merit.edu>
Received: from home.merit.edu by merit.edu (5.65/1123-1.0)
id AA12475; Fri, 3 Jul 92 16:59:21 -0400
Received: by home.merit.edu (4.1/client-0.9)
id AA06542; Fri, 3 Jul 92 16:32:48 EDT
From: mak at merit.edu
Message-Id: <9207032032.AA06542 at home.merit.edu>
To: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
Subject: IPv7
Date: Fri, 03 Jul 92 16:32:46 -0400
We would like to express our strong support for the decision
made by the IAB with respect to adopting CLNP as the basis for
V7 of the Internet Protocol.
It is high time to acknowledge that the Internet involves
significant investment from the computer industry (both
within the US and abroad), and provides production services
to an extremely large and diverse population of users. Such
and environment dictates that decisions about critical aspects
of the Internet should lean towards conservatism, and should
clearly steer away from proposals whose success is predicated
on some future research.
While other than CLNP proposals may on the surface sound tempting,
the Internet community should not close its eyes to plain
reality -- namely that at the present moment these proposals are nothing
more than just proposals; with no implementations, no experience,
and in few cases strong dependencies on future research and funding.
Resting the Internet future on such foundation creates and
unjustifiable risk for the whole Internet community.
The decision made by the IAB clearly demonstrated that the
the IAB was able to go beyond parochial arguments (TCP/IP vs
CLNP), and make its judgements based on practical and pragmatic
considerations.
Yakov Rekhter (IBM Corporation)
Mark Knopper (Merit Network)
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00825;
4 Jul 92 8:24 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa06748; 4 Jul 92 8:25 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22567>; Fri, 3 Jul 1992 13:55:47 -0700
Received: from ftp.com (babyoil.ftp.com) by venera.isi.edu (5.65c/5.65+local-6)
id <AA22486>; Fri, 3 Jul 1992 13:54:16 -0700
Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP
id AA08999; Fri, 3 Jul 92 16:56:52 -0400
Date: Fri, 3 Jul 92 16:56:52 -0400
Message-Id: <9207032056.AA08999 at ftp.com>
To: big-internet at munnari.oz.au
Subject: If TUBA is the answer, it must be a very silly question...
From: leo j mclaughlin iii <ljm at ftp.com>
Reply-To: ljm at ftp.com
Cc: iab at isi.edu, iesg at NRI.Reston.VA.US, ietf at isi.edu, road at lanl.gov
Sender: ljm at ftp.com
Repository: babyoil.ftp.com
Originating-Client: leather-lace.ftp.com
At the IETF in San Diego, the ROAD 'WG meetings' wrestled with the question
of what problems we were trying to solve. As I recall, three items stood
above all else:
1) Building toward a long term future in which network nodes became
cheap, mobile, and plentiful. A future in which everything from
one's toaster to one's wristwatch/alarm was on the network.
2) Creating the routing infrastructure to handle the sort of network
traffic and complexity such a future will bring. 10 to the 9th
networks was the number most frequently mentioned.
3) Allow existing hosts and networks to work as well as possible for as
long as possible. All our experience in trying to upgrade existing
implementations shows that for whatever reasons the installed
base is extremely resistant to change.
Having read the draft, I do not understand how a transition strategy which
views CLNP as IPv7 as a replacement for IPv4 hopes to meet these problems.
1) Cheap -- Implementation experience has shown that CLNP is unsuccessful
as a solution for cheap end nodes. Even where it has been divorced
from the OSI upper layers and installed by edict (e.g. MAP/TOP
using NetBIOS over TP4 over CLNP) it is being replaced by TCP/IP
because of CLNP's performance penalties in both size and throughput.
Mobile -- While it might be possible to transfer the work done in
mobile hosts, dynamic addressing, and multi-cast to CLNP it is
exceedingly doubtful that the attempt to change the basic
infrastructure of the internet would hasten the deployment of such
technologies.
Plentiful -- Neither TUBA nor IPAE will probably be able to deal with
truly large values of plentiful and this is acknowledged by both
documents. However, TUBA requires that every host and every network
on the Internet be significantly modified in order to reach that
intermediate state.
2) Most of the arguments about 'Plentiful' can be applied here as well.
However, it can also be noted that our router implementation experience
has shown that the variable length addressing structure of CLNP makes
it suboptimal for high speed routers.
3) Though the internet draft has some words to the contrary, TUBA seems
to ignore the importance of maintaining compatibility with existing
systems. Today we have an infrastructure that delicately balances
between ARP, proxy ARP, RARP, BOOTP, IP, ICMP, RIP, other routing
protocols, and the many and varied applications of the Internet. To
seek to substantially modify that infrastructure -- and to mandate
that change within a short timeframe -- is extraordinarily foolish.
enjoy,
leo j mclaughlin iii
ljm at ftp.com
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00881;
4 Jul 92 8:57 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07324; 4 Jul 92 8:58 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA24163>; Fri, 3 Jul 1992 15:05:12 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA24158>; Fri, 3 Jul 1992 15:05:09 -0700
Date: Fri, 3 Jul 1992 15:03:12 -0700
Posted-Date: Fri, 3 Jul 1992 15:03:12 -0700
Message-Id: <199207032203.AA05199 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA05199>; Fri, 3 Jul 1992 15:03:12 -0700
To: bsimpson at angband.stanford.edu, ietf at isi.edu
Subject: Re: why 160-bit addresses are daft....
Cc: big-internet at munnari.oz.au
So, you can see that big headers are not what we want here. Someday,
there may be header compression for CLNP.
Bill,
So, let's make it someday very soon. Certainly, you are right:
without acceptable header compression, IPv7 would be a loser over low
bandwidth paths.
Bob Braden
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00912;
4 Jul 92 9:21 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa07758; 4 Jul 92 9:22 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA23736>; Fri, 3 Jul 1992 14:45:03 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA23730>; Fri, 3 Jul 1992 14:44:54 -0700
Date: Fri, 3 Jul 1992 14:42:56 -0700
Posted-Date: Fri, 3 Jul 1992 14:42:56 -0700
Message-Id: <199207032142.AA05142 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA05142>; Fri, 3 Jul 1992 14:42:56 -0700
To: craig at aland.bbn.com
Subject: re: IPv7 (CLNP) a mistake
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
In short we will adopt CLNP (an ISO protocol); we wish to be
"functionally and syntactically" compatible and to "converge" with OSI;
and want to be able to make "changes ... necessary for successful,
deployment, operation, and evolution of IPv7." If we want to make changes
and still be compatible with and converge with OSI, we'll have to convince
ISO to go along, which means we have to work in the ISO standards process.
So we've bought into the ISO process (for the network layer).
Craig
Craig,
An argument that came up repeatedly in IAB discussions was the
objection that adapting (note the "a") CLNP was a case of trying to
have our cake and eat it too. Well, yes. And I believe we can.
If and where CLNP does not work, let's fix it. There is nobody --
except ourselves -- who can stop us from succeeding. In the
quotation you cite, convergence with OSI is clearly labelled as a
long-term goal, not a requirement for IPv7. The primary
requirement for IPv7 is to work in the global Internet. We
do not have to ask anyone's permission.
I think it also says that the IAB/IETF should adopt an address
format appropriate for the Internet. A lot of us share the
suspicion that this will NOT be any of the existing NSAP formats.
How about real-time? My view is that real-time is still research.
It's coming, but we have to expand the address space on a shorter
timeframe. We don't have enough faith in the CIDR approach to bet
our Internet on it. I hope that replacing the 60 byte limit on IP
headers with a 254 byte limit will help us to do initial real-time
work, using options.
How about multicasting? The document says (clearly, I hope) that
there must be no regression of functionality, and it specifically
mentions multicast. It was my understanding that CLNP multicast
along the IP multicast model was a done deal, except for a logjam
created by the OSI standards process. That logjam is irrelevant to
the IETF. Let's do it.
Above all, "Don't panic!"
Bob.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00947;
4 Jul 92 9:55 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08285; 4 Jul 92 9:56 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA22234>; Fri, 3 Jul 1992 13:41:22 -0700
Received: from ray.lloyd.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA22190>; Fri, 3 Jul 1992 13:39:55 -0700
Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016)
id AA01877; Fri, 3 Jul 92 13:37:57 PDT
Date: Fri, 3 Jul 92 13:37:57 PDT
From: Brian Lloyd <brian at lloyd.com>
Message-Id: <9207032037.AA01877 at ray.lloyd.com>
To: craig at aland.bbn.com
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
In-Reply-To: Craig Partridge's message of Fri, 03 Jul 92 11:35:21 -0700 <9207031835.AA02858 at aland.bbn.com>
Subject: IPv7 (CLNP) a mistake
Reply-To: brian at lloyd.com
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Fri, 03 Jul 92 11:35:21 -0700
Sender: craig at aland.bbn.com
Brian:
See my note to Bob Braden of yesterday. The goal is to adopt ISO CLNP
and to keep in harmony (the exact words are "functionally compatible" and
"convergent") with ISO CLNP. IPv7 is CLNP by another name.
Craig
I saw it after I made my posting. I am not now quite as enamored of
the idea as I originally was. Going with CLNP verbatim implies that
we go along with the braindamaged way that ISO wants to assign
addresses. In that case I think that CLNP is a bad idea. Rolling
something new that borrows from the good features of IP and CLNP but
does away with their respective warts is a good thing. Going with
CLNP en toto just doesn't seem worth the pain.
Brian Lloyd, WB6RQN Lloyd & Associates
Principal and Network Architect 3420 Sudbury Road
brian at lloyd.com Cameron Park, CA 95682
voice (916) 676-1147 -or- (415) 725-1392
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa00969;
4 Jul 92 10:08 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa08511; 4 Jul 92 10:10 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA24317>; Fri, 3 Jul 1992 15:13:56 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA24310>; Fri, 3 Jul 1992 15:13:48 -0700
Date: Fri, 3 Jul 1992 15:11:50 -0700
Posted-Date: Fri, 3 Jul 1992 15:11:50 -0700
Message-Id: <199207032211.AA05238 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA05238>; Fri, 3 Jul 1992 15:11:50 -0700
To: brian at lloyd.com, craig at aland.bbn.com
Subject: re: IPv7 (CLNP) a mistake
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov
From craig at aland.bbn.com Fri Jul 3 11:43:45 1992
To: brian at lloyd.com (Brian Lloyd)
Cc: big-internet at munnari.oz.au, iab at ISI.EDU, iesg at nri.reston.va.us,
ietf at ISI.EDU, road at lanl.gov
Subject: re: IPv7 (CLNP) a mistake
Reply-To: Craig Partridge <craig at aland.bbn.com>
From: Craig Partridge <craig at aland.bbn.com>
Date: Fri, 03 Jul 92 11:35:21 -0700
Sender: craig at aland.bbn.com
Brian:
See my note to Bob Braden of yesterday. The goal is to adopt ISO CLNP
and to keep in harmony (the exact words are "functionally compatible" and
"convergent") with ISO CLNP. IPv7 is CLNP by another name.
Craig
Craig,
I hate to keep saying this, but your statement is incorrect.
Bob Braden
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01028;
4 Jul 92 10:48 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09158; 4 Jul 92 10:49 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25116>; Fri, 3 Jul 1992 15:50:01 -0700
Received: from regal.cisco.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA25111>; Fri, 3 Jul 1992 15:49:58 -0700
Received: by regal.cisco.com; Fri, 3 Jul 92 15:48:18 -0700
Date: Fri, 3 Jul 92 15:48:18 -0700
From: Dino Farinacci <dino at cisco.com>
Message-Id: <9207032248.AA12287 at regal.cisco.com>
To: braden at isi.edu
Cc: bsimpson at angband.stanford.edu, ietf at isi.edu, big-internet at munnari.oz.au
In-Reply-To: braden at ISI.EDU's message of Fri, 3 Jul 1992 15:03:12 -0700 <199207032203.AA05199 at braden.isi.edu>
Subject: why 160-bit addresses are daft....
>> So, let's make it someday very soon. Certainly, you are right:
>> without acceptable header compression, IPv7 would be a loser over low
>> bandwidth paths.
Did anyone realize that a CLNP header with IP-address sized addresses
gives you a header (without fragmentation) of 19 bytes in length.
9 bytes - fixed header
5 bytes - Source address
5 bytes - Destination address
---
19
No one said that IPv7 had to use GOSIP addresses. And from what I'm
hearing, we don't want to. The IETF decides on the address length it
wants to go with (note 5 bytes above - a address length byte included).
Regarding byte alignment, when we switch a packet:
1) We need to look at version.
IP - offset byte 0
CLNP - offset byte 2
2) We need to look at TTL.
IP - offset byte 8
CLNP - offset byte 3
3) We need to look at the checksum.
IP - offset byte 10 (2 bytes)
CLNP - offset byte 5 (2 bytes)
Pretty much the same processing (IETF could move the type byte to the
end of the fixed header so the checksum is on even byte boundary)
except for CLNP needs to look at NLPID to see if is truly a CLNS
packet and the type byte to determine it is not an Error PDU.
Regarding checksum algorithm.
1) Fletcher (OSI) checksum is slower because it is byte oriented.
IP is word oriented and everyone does it on longword boundaries.
Don't forget, this is only on the header, we're talking 20-30
bytes.
Regarding addresses:
1) Will take longer with IPv7 because we are *required* to make them
longer. So it is going to cost you something (but your getting
something for it).
OSI might be *big* but CLNP itself is not really any bigger than IP.
Dino
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01056;
4 Jul 92 10:57 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa09537; 4 Jul 92 10:58 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA24958>; Fri, 3 Jul 1992 15:41:17 -0700
From: Bob Braden <braden at isi.edu>
Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA24950>; Fri, 3 Jul 1992 15:41:11 -0700
Date: Fri, 3 Jul 1992 15:39:14 -0700
Posted-Date: Fri, 3 Jul 1992 15:39:14 -0700
Message-Id: <199207032239.AA05283 at braden.isi.edu>
Received: by braden.isi.edu (5.65c/4.0.3-4)
id <AA05283>; Fri, 3 Jul 1992 15:39:14 -0700
To: ietf at isi.edu
Subject: IAB Protocol Action: TFTP to Standard
Cc: iab at isi.edu, iesg at isi.edu
The IAB has accepted the IESG recommendation that the Internet Draft
<draft-ietf-iesg-tftp-00> "THE TFTP PROTOCOL (REVISION 2)" be published
as a Standard for the Internet.
This revision of the TFTP specification corrects known bugs with fixes
documented in the Host Requirements RFC-1123. TFTP is widely
implemented and deployed for system booting, and it is considered
operationally stable. Because of its wide acceptance, it is being
advanced to Standard despite its complete lack of security mechanisms.
Bob Braden
for the IAB
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01076;
4 Jul 92 11:03 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01070;
4 Jul 92 11:03 EDT
Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa09610;
4 Jul 92 11:04 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA25663; Sat, 4 Jul 92 10:37:48 EDT
Received: from GINGER.LCS.MIT.EDU by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA25659; Sat, 4 Jul 92 10:37:46 EDT
Received: by ginger.lcs.mit.edu
id AA00392; Sat, 4 Jul 92 10:37:42 -0400
Date: Sat, 4 Jul 92 10:37:42 -0400
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9207041437.AA00392 at ginger.lcs.mit.edu>
To: henry at zoo.toronto.edu, ietf at isi.edu
Subject: Re: folklore etc.
Cc: ietf-822 at dimacs.rutgers.edu, jnc at ginger.lcs.mit.edu
I looked in section 5 of the Host Requirements RFC (RFC-1123)
to see if this problem was addressed, but it doesn't seem to be spoken
to explicitly. (I assume you already checked 1123)?
It is known that both Host and Router Requirements documents
need a going over, and the Router one is basically done; perhaps it
is time to brush off the HR's as well?
Noel
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01137;
4 Jul 92 11:52 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10460; 4 Jul 92 11:54 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25700>; Fri, 3 Jul 1992 16:21:00 -0700
Received: from bellcore.bellcore.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA25690>; Fri, 3 Jul 1992 16:20:54 -0700
Received: from gizmo.bellcore.com by bellcore.bellcore.com (5.61/1.34)
id AA02551; Fri, 3 Jul 92 19:19:00 -0400
Message-Id: <9207032319.AA02551 at bellcore.bellcore.com>
To: mak at merit.edu
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, road at lanl.gov, mo at gizmo.bellcore.com
Subject: Re: IPv7
In-Reply-To: Your message of "Fri, 03 Jul 92 16:32:46 EDT."
<9207032032.AA06542 at home.merit.edu>
Date: Fri, 03 Jul 92 19:18:58 -0400
From: mo at gizmo.bellcore.com
I hardly see how the IAB suggestion is founded in any more real-world
experience than anything else being examined. And it clearly suffers
from at least one debilitating problem - squanderously-large addresses.
Holding up the mantle of conservativism is hardly a vote for this
half-baked CLNP approach. I may be Politically Correct, but it isn't
technically supportable.
-Mike
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01151;
4 Jul 92 11:55 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10509; 4 Jul 92 11:56 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25762>; Fri, 3 Jul 1992 16:24:19 -0700
Received: from bellcore.bellcore.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA25754>; Fri, 3 Jul 1992 16:24:15 -0700
Received: from gizmo.bellcore.com by bellcore.bellcore.com (5.61/1.34)
id AA02575; Fri, 3 Jul 92 19:22:30 -0400
Message-Id: <9207032322.AA02575 at bellcore.bellcore.com>
To: Dino Farinacci <dino at cisco.com>
Cc: braden at isi.edu, bsimpson at angband.stanford.edu, ietf at isi.edu,
big-internet at munnari.oz.au, mo at gizmo.bellcore.com
Subject: Re: why 160-bit addresses are daft....
In-Reply-To: Your message of "Fri, 03 Jul 92 15:48:18 PDT."
<9207032248.AA12287 at regal.cisco.com>
Date: Fri, 03 Jul 92 19:22:29 -0400
From: mo at gizmo.bellcore.com
Sorry, but when I read the document is said that IPv7 would use 20-byte
addresses. Variable length addresses make the router folks nutso
(and with good cause).
-Mike
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01212;
4 Jul 92 12:16 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa10921; 4 Jul 92 12:17 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA23627>; Fri, 3 Jul 1992 14:38:43 -0700
Received: from mhs-relay.cs.wisc.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA23622>; Fri, 3 Jul 1992 14:38:36 -0700
X400-Received: by mta mhs-relay.cs.wisc.edu in /PRMD=XNREN/ADMD= /C=US/;
Relayed; Fri, 3 Jul 1992 16:36:37 +0000
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Fri, 3 Jul 1992 16:36:30 +0000
X400-Received: by /PRMD=uninett/ADMD= /C=no/; Relayed;
Fri, 3 Jul 1992 16:36:27 +0000
Date: Fri, 3 Jul 1992 16:36:27 +0000
X400-Originator: Alf.Hansen at delab.sintef.no
X400-Recipients: ietf at ISI.edu
X400-Mts-Identifier: [/PRMD=uninett/ADMD= /C=no/;920703233627]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 2723
From: Alf Hansen <Alf.Hansen at delab.sintef.no>
Message-Id: <2723*/G=Alf/S=Hansen/OU=delab/O=sintef/PRMD=uninett/C=no/@MHS>
To: ietf at isi.edu
Subject: IETF X.400 OPS WG, Draft agenda, Boston.
------------------------------ Start of body part 1
Folks,
Hope to see some of you there.
Best regards,
Alf H
------------------------------ Start of body part 2
Call for 5th meeting in the IETF X.400 Operations Working Group,
IETF, Boston, Massachusetts, U.S.A.
From: Alf Hansen
Date: 07/02/92
MEETING TIME:
WEDNESDAY, July 15, 1992 1:30-3:30 pm 1st session
3:30-4:00 pm Break
4:00-6:00 pm 2nd session
HOTEL/MEETING SITE: Hyatt Regency Cambridge
Overlooking Boston
575 Memorial Drive
Cambridge, MA 02139
Phone: (617) 492-1234 {fax: (617) 491-6906}
CI 4:00 p.m.; CO 12:00 p.m.
250 Rooms reserved until June 12, 1992
$99.00/single; $99.00/double (please add 9.7% tax)
Specify: IETF or 24th Internet Engineering Task Force
General:
The concrete goals of this meeting is
1) to review documents (1st session).
2) to get a better understanding on how the Internet X.400 service
should be organized (in the U.S.) next year (2nd session).
The relevant documents and how they can be obtained:
Those marked as INTERNET-DRAFT, are available by anonymous FTP.
Login with the username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get filename".
Internet-Drafts directories are located at:
o East Coast (US)
Address: nnsc.nsf.net (128.89.1.178)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND internet-drafts/filename".
For questions, please mail to internet-drafts at nri.reston.va.us.
Those marked as UWISC are available via anonymous ftp from the
directory ~ftp/pub/ on mhs-relay.cs.wisc.edu (128.105.8.53).
DOCUMENTS:
OPS-1: Hansen/Hagens:
"Operational Requirements for X.400 Management Domains in the
GO-MHS Community", Revision: 1.13, June 19, 1992.
INTERNET-DRAFT, filename: draft-ietf-x400ops-mgtdomains-01.txt
UWISC, filenames: ietf/prmdreq.v1-13.ps (postscript)
ietf/prmdreq.v1-13.txt (text)
Please note that the dates on the UWISC versions are a few days
later that the official INTERNET-DRAFT version.
OPS-2: A.B. Bonito/C. Allocchio/S. Giordano:
"Using the Internet DNS to maintain RFC987/RFC1148
Address Mapping Tables and X.400 Routing Informations"
I will distribute my latest version: March 1992. Claudio:
Is there a later version? If so, can you distribute it?
Why is this not in the INTERNET-DRAFT archive?
OPS-3: Eppenberger:
"Routing coordination for X.400 MHS services within a
multi protocol / multi network environment", March 3 1992.
INTERNET-DRAFT, filename: draft-ietf-x400ops-mhs-service-00.txt
OPS-4: Claudio Allocchio:
"Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)",
March 2nd, 1992.
INTERNET-DRAFT: draft-ietf-x400ops-mapmail-00.txt
OPS-5: Harald Tveit Alvestrand:
"X.400 use of extended character sets", June 18, 1992.
INTERNET-DRAFT, filename: draft-ietf-x400ops-charactersets-00.txt
OPS-6: COSINE-MHS Project Team:
"Address mapping table update procedures".
Will there be a document to distribute before the Boston meeting?
Please come prepared to the meeting.
Provisional agenda
==================
1ST SESSION, Documents.
1. Welcome. 10 min
-----------
Secretary, roll call of delegates, agenda.
2. Review of revised charter. 10 min
-----------------------------
Revised Charter has been distributed. Discussion.
I would enjoy to hear if IESG and/or RTC could report from
progress in the integration process of RARE and IETF groups.
3. Action list from San Diego. 20 min
------------------------------
Short review of status for each item and report from each action:
John Sherburne (SPRINT) will work with Tony Genovese to figure out how US
can provide an MTA that has X.25 connectivity.
Urs will ask the COSINE MHS Project Team to submit the address mapping
table procedures as a draft RFC.
Stef - Start a discussion on X.400 OPS and WG1 lists about ADMD name in
the US. See section 3.1.2.
Alf will send the updated charter to the list.
Claudio will produce a draft document that will propose a method for using
DNS to store X.400 to RFC 822 mapping and routing.
Claudio will follow up the MAIL 11 mapping document.
Harald will follow up the International Character set document.
4. Review of documents. 1 hr 20 min
-----------------------
OPS-1: Has been updated according to comments from last meeting.
Status: Internet Draft. Ready for status change?
OPS-2: This is not yet an official Internet Draft. Will it be?
Is there progress to report from the experimental implementations?
Claudio?
OPS-3: This is a stable document.
Status: Internet Draft. Has it been moved to "experimental RFC"
status as recommended in San Diego?
OPS-4: No updates noted since last meeting.
Status: Internet Draft. Is it ready for status change?
OPS-5: This is a new document,
Status: Internet Draft. Harald presents. Review.
OPS-6: I have not seen this document yet. Perhaps it will be
distributed before the meeting.
2ND SESSION, Organizational issues.
5. Status on X.400 operations. 35 min
------------------------------
Allan Cargille, UWisc (Internet X.400 project) reports on project
status and future plans.
Perhaps a COSINE MHS Project Team member can report on COSINE MHS
status, and furture plans for the post-COSINE period(?)
6. RFC 1327 (was 1148bis) gateway tracking. 15 min
-------------------------------------------
It has been proposed that this WG should keep track of existing
gateways between the SMTP world and the X.400 world. The background
for this is that it seems to be many strange behaving gateways
out there, causing strange things to happen send from an end-user's
point of view.
Discussion and recommendation.
7. Major operational problem. 15 min
-----------------------------
Identification of ONE major operational problem that has not yet
been handled good enough by ourselves or other WGs.
Proposals for actions to speed up the solusion to THIS (and only
THIS) major problem.
Candidates: Lack of one global RFC 822/X.400 SA address mapping, The manual
mapping table procedures, The interpretation of the "1148gate" table,
Character sets, New body parts, Service organization, Connectivity
to public e-mail service providers, there are more ...
Is it possible to agree on what the most major problem is, and start
solving it in a new way?
8. Future U.S. Internet X.400 organization. 35 min
-------------------------------------------
Is there a proposal on how X.400 in the U.S. Internet should be
organized such that the operational requirements will be met in
a most effective way?
Discussion and recommendation.
9. Summary of conclusions and actions. 5 min
---------------------------------------
The secretary presents the action list.
10. A(ny) O(ther) B(usiness) and plan for next meetings. 5 min
--------------------------------------------------------
Next meeting: When is the next IETF?
------------------------------ End of body part 2
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01329;
4 Jul 92 13:32 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12239; 4 Jul 92 13:33 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA25180>; Fri, 3 Jul 1992 15:53:39 -0700
Received: from windsail.nersc.gov ([128.55.192.131]) by venera.isi.edu (5.65c/5.65+local-6)
id <AA25176>; Fri, 3 Jul 1992 15:53:37 -0700
Received: by windsail.nersc.gov (4.1/LLNL-1.18)
id AA03129; Fri, 3 Jul 92 15:51:39 PDT
Date: Fri, 3 Jul 92 15:51:39 PDT
From: Joe Ramus <ramus at windsail.nersc.gov>
Message-Id: <9207032251.AA03129 at windsail.nersc.gov>
To: ietf at isi.edu
Subject: Message Flood
PLEASE have Mercy upon us. People need to use caution when
broadcasting messages to every mailing list in sight. I am getting
several copies of some messages.
I have attached just one example below. This guy sent the same message
at least twice and used the same Cc: list each time.
---------------------------------------------------------------
>>
>> To: BSMTP <MABOGEN at vm.gmd.de>
>> Cc: big-internet at munnari.oz.au, iab at ISI.EDU, iesg at NRI.Reston.VA.US,
>> ietf at ISI.EDU, road at lanl.gov
>> Subject: Re: IPv7 (CLNP) a mistake
>> In-Reply-To: Your message of "Thu, 02 Jul 92 16:08:29 PDT."
<9207022308.AA28811 at aland.bbn.com>
>> Date: Thu, 02 Jul 92 19:39:43 -0700
>> From: "Milo S. Medin" (NASA ARC NSI Office) <medin at nsipo.nasa.gov>
>> Sender: owner-mod-ietf at searn.sunet.se
>>
>> I totally agree with Craig. There are a number of problems with trying
>> to base an IPv7 on CLNP in the manner that the IAB is trying to do. First
>> off, if you really didn't want to buy into the ISO standards process,
>> routing protocols, ES-IS, etc, you ought to have taken the CLNP packet
>> format, renamed all the fields, and then proclaimed the output IPv7.
>>
>> ------------------------------------------------------------------------------
>>
>> To: BSMTP <mod-ietf at dfn.dbp.de>
>> Cc: big-internet at munnari.oz.au, iab at ISI.EDU, iesg at NRI.Reston.VA.US,
>> ietf at ISI.EDU, road at lanl.gov
>> Subject: Re: IPv7 (CLNP) a mistake
>> In-Reply-To: Your message of "Thu, 02 Jul 92 16:08:29 PDT."
<9207022308.AA28811 at aland.bbn.com>
>> Date: Thu, 02 Jul 92 19:39:43 -0700
>> From: "Milo S. Medin" (NASA ARC NSI Office) <medin at nsipo.nasa.gov>
>> Sender: owner-mod-ietf at searn.sunet.se
>>
>> I totally agree with Craig. There are a number of problems with trying
>> to base an IPv7 on CLNP in the manner that the IAB is trying to do. First
>> off, if you really didn't want to buy into the ISO standards process,
>> routing protocols, ES-IS, etc, you ought to have taken the CLNP packet
>> format, renamed all the fields, and then proclaimed the output IPv7.
>>
>> ------------------------------------------------------------------------------
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01397;
4 Jul 92 14:06 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa12882; 4 Jul 92 14:07 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA27936>; Fri, 3 Jul 1992 17:41:16 -0700
Received: from upeksa.sdsc.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA27931>; Fri, 3 Jul 1992 17:41:14 -0700
Received: Fri, 3 Jul 1992 17:39:30 -0700 by upeksa.sdsc.edu (AIX/1.6)
From: Hans-Werner Braun <hwb at upeksa.sdsc.edu>
Message-Id: <9207040039.AA18849 at upeksa.sdsc.edu>
Subject: Re: why 160-bit addresses are daft....
To: Dino Farinacci <dino at cisco.com>
Date: Fri, 3 Jul 92 17:39:29 PDT
Cc: ietf at isi.edu, big-internet at munnari.oz.au
In-Reply-To: <9207032248.AA12287 at regal.cisco.com>; from "Dino Farinacci" at Jul 3, 92 3:48 pm
Dino:
> No one said that IPv7 had to use GOSIP addresses. And from what I'm
> hearing, we don't want to. The IETF decides on the address length it
> wants to go with (note 5 bytes above - a address length byte included).
I would make your comment even stronger. The Internet community, including the
IAB, will have to critically depend on the IETF to define the appropriate
addressing structure (including length). That requires serious work, and the
experience of the people having been involved in both IP and CLNP networking
will be imperative here.
Hans-Werner
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01417;
4 Jul 92 14:15 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13015; 4 Jul 92 14:16 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA00209>; Fri, 3 Jul 1992 19:22:23 -0700
Received: from GINGER.LCS.MIT.EDU by venera.isi.edu (5.65c/5.65+local-6)
id <AA00195>; Fri, 3 Jul 1992 19:22:18 -0700
Received: by ginger.lcs.mit.edu
id AA28756; Fri, 3 Jul 92 22:20:29 -0400
Date: Fri, 3 Jul 92 22:20:29 -0400
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9207040220.AA28756 at ginger.lcs.mit.edu>
To: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
ietf at isi.edu, mak at merit.edu, road at lanl.gov
Subject: Re: IPv7
Cc: jnc at ginger.lcs.mit.edu
and should clearly steer away from proposals whose success
is predicated on some future research
I guess we will have to make do with existing resource allocation and
congestion control mechanisms, since this is still an area of substantial
research at the moment.
While other than CLNP proposals may on the surface sound tempting,
... at the present moment these proposals are nothing more than just
proposals; with no implementations, no experience
Oh, so I assume you are hereby excluding TUBA, which as far as I know,
has not been implemented and tested yet? Exactly how many implementations are
there, and how widespread is the test deployment, of TCP over CLNP?
able to go beyond parochial arguments (TCP/IP vs CLNP)
I seem to be hearing you say that the arguments of some of those who
think this is a bad idea are based on parochialism? I guess it doesn't
surprise me to hear you say this; the real technical arguments that some
people have as to why CLNP is not the answer (no security architecture, no
auto-configuration architecture, no resource allocation architecture, etc,
etc, etc) seem to have passed you by.
You know, Yakov, not all of the people who aren't in favor of CLNP
oppose it just because we love TCP/IP. Just conceivably there are real
technical issues we care about; some of us even want to get rid of *IP*
because of those issues..
Noel
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01506;
4 Jul 92 14:46 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13578; 4 Jul 92 14:48 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03640>; Fri, 3 Jul 1992 22:02:28 -0700
Received: from cider.cisco.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA03635>; Fri, 3 Jul 1992 22:02:25 -0700
Received: by cider.cisco.com; Fri, 3 Jul 92 22:00:36 -0700
Date: Fri, 3 Jul 92 22:00:36 PDT
From: William Chops Westfield <billw at cider.cisco.com>
To: henry at zoo.toronto.edu
Cc: ietf at isi.edu, ietf-822 at dimacs.rutgers.edu
Subject: Re: folklore etc.
In-Reply-To: Your message of Fri, 3 Jul 92 12:30:38 EDT
Message-Id: <CMM.0.90.2.710226036.billw at cider.cisco.com>
..it Sure Would Be Nice if some of the people who have been
exposed to things like this sat down and wrote a few
Informational RFCs *documenting* some of this folklore. One of
the most infuriating things about implementing some of the
Internet protocols is running across these bits of important
information that aren't written down *anywhere*, apparently on
the assumption that anyone who needs to know them already does.
Well, the "Host Requirments" RFCs documented some of it, and tried to
legislate the rest of it out of existancs. Unfortunately, that doesn't
seem to have worked.
BillW
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01527;
4 Jul 92 14:50 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa13667; 4 Jul 92 14:51 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA01589>; Fri, 3 Jul 1992 20:41:51 -0700
Received: from alpha.Xerox.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA01584>; Fri, 3 Jul 1992 20:41:48 -0700
Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11570>; Fri, 3 Jul 1992 20:40:04 PDT
Received: by redwing.parc.xerox.com id <57234>; Fri, 3 Jul 1992 20:39:54 -0700
Date: Fri, 3 Jul 1992 20:39:42 PDT
Sender: Lixia Zhang <lixia at parc.xerox.com>
From: Lixia Zhang <lixia at parc.xerox.com>
Reply-To: lixia at parc.xerox.com
To: Hans-Werner Braun <hwb at upeksa.sdsc.edu>
Cc: big-internet at munnari.oz.au, ietf at isi.edu
Subject: Re: Milo going Nova.
In-Reply-To: Your message of Fri, 3 Jul 1992 16:36:05 -0700
Message-Id: <CMM.0.88.710221182.lixia at parc.xerox.com>
> Sorry for the size of this note. Unless you have a serious
> interest in this area, you may want to skip it...
Hi Hans-Werner,
Your msg is indeed a bit too long to read, especially in a holiday
eve :-) Yes you got the name right, GADS. It was created late'84,
the first meeting was held Jan'85 in D.C. Doesn't seem to be that
long ago, except when one looks at how much IP world has changed.
I agree with you on that, up to today, we have not had a viable
solution(not proposals, but field-tested implementation) to the
problem. (someone privately commented that this might also reflect
a failure of the funders) But this is not equivalent to say that we
have no solution. Just as you have had successful experience of
putting NSFbackbone up on time, some special effort out of this
community in the next few months may well present a solution in time.
Lixia
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01563;
4 Jul 92 15:19 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01557;
4 Jul 92 15:19 EDT
Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa14157;
4 Jul 92 15:21 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA27423; Sat, 4 Jul 92 15:07:50 EDT
Received: from animal.clearpoint.com by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA27419; Sat, 4 Jul 92 15:07:47 EDT
Received: by animal.clearpoint.com (4.1/1.34)
id AA27272; Sat, 4 Jul 92 14:59:55 EDT
Date: Sat, 4 Jul 92 14:59:55 EDT
From: "Frank T. Solensky" <solensky at animal.clearpoint.com>
Message-Id: <9207041859.AA27272 at animal.clearpoint.com>
To: MRC at panda.com, henry at zoo.toronto.edu
Subject: Re: folklore etc.
Cc: ietf-822 at dimacs.rutgers.edu, ietf at isi.edu
From: Mark Crispin <MRC at panda.com>
>I don't think there is much hope for getting such folklore
>documented... A significant
>subset of these consist of problems that could have been
>readily addressed by minor modifications to the protocol
>specification, but which for political reasons never
>happened.
I disagree.. This type of thing was exactly why RFCs 1122 and 1123 were
created. If it's not already described in RFC-1123, perhaps it should
be considered as one of the items to be added.
-- Frank
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01663;
4 Jul 92 15:56 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa14888; 4 Jul 92 15:57 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03810>; Fri, 3 Jul 1992 22:07:40 -0700
Received: from cider.cisco.com by venera.isi.edu (5.65c/5.65+local-6)
id <AA03805>; Fri, 3 Jul 1992 22:07:38 -0700
Received: by cider.cisco.com; Fri, 3 Jul 92 22:05:46 -0700
Date: Fri, 3 Jul 92 22:05:46 PDT
From: William Chops Westfield <billw at cider.cisco.com>
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Cc: big-internet at munnari.oz.au, ietf at isi.edu, road at lanl.gov
Subject: Re: IAB proposal for CIDR and IPv7
In-Reply-To: Your message of Thu, 02 Jul 92 17:22:58 +0100
Message-Id: <CMM.0.90.2.710226346.billw at cider.cisco.com>
it also is introducing a policy which is NOT in line with
starting new Internet Standard Initiatives on a level playing
field, since only some vendors (very few end system vendors,
slightly more router vendors) provide CLNP bundled...
Is it now stated policy of the IETF/etc that new Standard initiatives
should place vendors on a level playing field? This sort of attitude
was instrumental in making the OSI specs the impossible conglomeration
that they are now!
All is lost.
BillW
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01747;
4 Jul 92 16:35 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa15629; 4 Jul 92 16:37 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA03916>; Fri, 3 Jul 1992 22:15:48 -0700
Received: from upeksa.sdsc.edu by venera.isi.edu (5.65c/5.65+local-6)
id <AA03912>; Fri, 3 Jul 1992 22:15:46 -0700
Received: Fri, 3 Jul 1992 22:13:58 -0700 by upeksa.sdsc.edu (AIX/1.6)
From: Hans-Werner Braun <hwb at upeksa.sdsc.edu>
Message-Id: <9207040513.AA19381 at upeksa.sdsc.edu>
Subject: Re: Milo going Nova.
To: lixia at parc.xerox.com
Date: Fri, 3 Jul 92 22:13:58 PDT
Cc: big-internet at munnari.oz.au, ietf at isi.edu
In-Reply-To: <CMM.0.88.710221182.lixia at parc.xerox.com>; from "Lixia Zhang" at Jul 3, 92 8:39 pm
Lixia:
>some special effort out of this
>community in the next few months may well present a solution in time.
That would certainly be ok with me, but would require more than some
protocol specification. Scalability is not only a technical term these
days. It is quite worrysome to see how many dependencies there are on
the network, and what it would take to make solutions viable, acceptable,
implementable and manageable, including in a global and also quite
politicized arena. It seems to me at times that a technical specification
is not the biggest problem to solve any more, unlike in the DARPA days,
where advanced ideas were much more welcome and applicable for the network
at hand.
Today in many cases it seems to take a year or so to to just find funding
for new effort, to even just *start* the development of a specification.
The environment is much more complicated today than in the 1984 DARPA days
you point to, there are many sharks out there, and lots of people critically
depend on services that must not be interrupted. The time has come that we
have to realize that the importance of the network is reaching towards the
importance of telephony networks, with national securities and billions of
dollars at stake. Not to lessen their importance, but research and development
has to be decoupled from the operational infrastructure in order to retain
a large scale manageable situation. It is not easy to make judgments. There
is no completely right solution, as there will be compromises somewhere, in
whatever solutions people will propose; even if someone would come up with
a protocol for generations to come.
Hans-Werner
Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01787;
4 Jul 92 16:50 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01781;
4 Jul 92 16:50 EDT
Received: from dimacs.rutgers.edu by NRI.Reston.VA.US id aa15869;
4 Jul 92 16:51 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA27613; Sat, 4 Jul 92 16:28:45 EDT
Received: from akbar.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08)
id AA27609; Sat, 4 Jul 92 16:28:43 EDT
Received: from Ikkoku-Kan.Panda.COM by akbar.cac.washington.edu
(5.65/UW-NDC Revision: 2.26 ) id AA17425; Sat, 4 Jul 92 13:26:24 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
(NeXT-1.0 (From Sendmail 5.52)/UW-NDC Revision: 2.22 ) id AA02580; Sat, 4 Jul 92 13:26:10 PDT
Date: Sat, 4 Jul 1992 12:43:32 -0700 (PDT)
From: Mark Crispin <MRC at panda.com>
Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: folklore etc.
To: "Frank T. Solensky" <solensky at animal.clearpoint.com>
Cc: henry at zoo.toronto.edu, ietf-822 at dimacs.rutgers.edu, ietf at isi.edu
In-Reply-To: <9207041859.AA27272 at animal.clearpoint.com>
Message-Id: <MailManager.710279012.2349.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 4 Jul 92 14:59:55 EDT, Frank T. Solensky wrote:
> I disagree.. This type of thing was exactly why RFCs 1122 and 1123 were
> created. If it's not already described in RFC-1123, perhaps it should
> be considered as one of the items to be added.
As I see it, the Host Requirements RFCs were created to depreciate some
functionalities which were never used, to make minor tweaks to the
specifications that had already been generally accepted as correct, and to
specifically ban some practices which were considered particularly offensive
by the community (many of which were already clearly invalid according to the
original standards, but which certain individuals did nontheless).
That did not, however, in any way deal with the issue of folklore. Host
Requirements deals in technical matters where reality and the specification
can be made to converge. It does not deal in those cases where reality and
the specification do not converge, but it is politically infeasible to change
the specification.
In particular, it does not deal with common violations of the specification
which make more sense than the specification itself, and thus are not
generally considered offensive enough by the community to merit a ban.
Much of this folklore is in areas which some are unwilling to admit even
exists. Often, these are the same individuals who defend the flaw in the
original specification. The notion of publishing such folklore in a Host
Requirements document is absurd, given this situation.
An example of folklore in the making, and of current long-term folkore:
Those of you in ietf-822 know that I have been trying to convince people that
MIME should allow things such as
;FILE=foo.tar.Z
;BOUNDARY=xyzzy.001.aax
instead of insisting upon
;FILE="foo.tar.Z"
;BOUNDARY="xyzzy.001.aax"
which is the only form that is valid in the present MIME. I am seeing the
unquoted versions in mail from other implementations now. Among other things,
there are examples in the MIME document which use the unquoted form. I
consider the requirement [the inclusion of `.' in `tspecials'] silly, and have
campaigned for its removal. This has met with formidable opposition.
Given the difficulty in fixing this, how can you possibly deal with
From: John T. Doe <jdoe at foo.bar.com>
which violates a similiar rule (which I also consider silly) in RFC-822?
If you claim these are invalid and deserve a `parse error', you are burying
your head in the sand. Your users will crucify you if you tell them they
can't read their mail because of some trivial specification BNF rule. No, if
you can't get the specification fixed, you just change your parse engine so
you accept it anyway.
Other e-mail related folklore:
. the CR is optional in Internet newlines (UNIX says it's so)
. leading or tailing spaces are permitted in host names given to SMTP (NeXT
is a big offender here).
. beware of using the SMTP return path for its intended purpose, since it is
a reply address for many people.
. Errors-To:
. % as a soft @, and mailers other than that to the right of the @ thinking
they know the semantics of %
. comments used to convey personal names
etc.
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01840;
4 Jul 92 17:37 EDT
Received: from venera.isi.edu by NRI.Reston.VA.US id aa16601; 4 Jul 92 17:38 EDT
Received: by venera.isi.edu (5.65c/5.65+local-6)
id <AA04502>; Fri, 3 Jul 1992 22:40:58 -0700
Received: from Sun.COM by venera.isi.edu (5.65c/5.65+local-6)
id <AA04426>; Fri, 3 Jul 1992 22:39:17 -0700
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA22275; Fri, 3 Jul 92 11:47:04 PDT
Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1)
id AA28470; Fri, 3 Jul 92 11:47:07 PDT
Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1)
id AA08471; Fri, 3 Jul 92 11:46:45 PDT
Date: Fri, 3 Jul 92 11:46:45 PDT
From: Bob Hinden <Bob.Hinden at eng.sun.com>
Message-Id: <9207031846.AA08471 at b5mail.Eng.Sun.COM>
Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1)
id AA10067; Fri, 3 Jul 92 11:47:00 PDT
To: ietf at isi.edu
Cc: big-internet at munnari.oz.au, iab at isi.edu, iesg at NRI.Reston.VA.US,
Bob.Hinden at eng.sun.com
Subject: Comments on IPv7 Document
Folks,
Here are my comments on the IAB recommendation for adopting CLNP as
IPv7. I strongly disagree with the overall recommendation presented.
IMHO I think what is proposed does not solve one of the key medium term
problems which face the Internet. In particular, it does nothing to
solve the routing explosion problems until after CLNP is very widely
deployed in hosts. I am very concerned that this will occur a long
time after the routing table explosion has killed the internet. CIDR
alone does not buy us enough time.
Bob
>>Abstract
>>
>> Internet growth has created serious problems of address space
>> consumption and routing information explosion. A solution to these
>> problems requires a new version of the Internet Protocol, which we
>> call IP version 7 ("IPv7"). This memo presents architectural
>> guidelines that any IPv7 should meet. It then discusses how an IPv7
I see no justification is this document for why a new version of IP is
"required" to solve the address space consumption and routing table
explosion problems. A new version of IP is one approach, but I don't
see why it is required. IPAE and similar approaches present clear
alternatives to deploying a new version of IP with much less impact on
the existing operational system. Further, no solution to the routing
table explosion problem is presented here at all as far as I can tell.
>> based upon the OSI CLNP protocol would meet these requirements, and
>> presents the reasons for the IAB's preference for this solution.
>> Finally, it makes a three-part recommendation: (1) proceed at full
>> speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3)
>> continue to pursue research in advanced routing and other future
>> extensions of the Internet architecture.
>> 1.1 The Need for IPv7
>>
>> The rapid growth of the Internet has exposed the consequences of a
>> design choice made 15 years ago, the choice of a fixed-length 32-
>> bit address field for IP [IEN-005]. At that time, 32 bits appeared
>> to be a very wide field, allowing many thousands of networks and
>> millions of hosts, several orders of magnitude beyond the likely
>> size of the Internet. However, the Internet has now grown to this
>> order of magnitude, leading to two different scaling problems:
>>
>> * Routing Information Explosion
>>
>> The cost and complexity of Internet routing grow very rapidly
>> with the number of networks. This growth is creating
>> increasingly serious operational problems.
>>
>> * Address Space Consumption
>>
>> Current IP addresses are 32 bits. While this seems to be a
>> very large number (4*10**9), its division into host and
>> network parts and into class A, B, and C networks
>> significantly reduces the available space. Projections are
>> difficult and highly arguable, but at the current rate of
>> growth, the existing space may be used up in the foreseeable
>> future.
I think it is important to also say that the first problem is going to
hit much sooner than the second problem. If we only concentrate on the
second problem, the first will kill us! I think a major weakness of
this proposal is that it only addresses the address space consumption
problem. No solution is presented to the Routing explosion problem.
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
