What showuld have been referenced was the message that referenced the
"A Plea for Internet Peace", but not the plea itself. The "Plea" does
no0t shed any light on why VTAM/SNA is, or is not, inappropriate for
anything. Best...\Stef
From: Einar Stefferud <Stef=ietf at nma.com>
To: ietf at cnri.reston.va.us
Reply-to: Stef=ietf at nma.com
Subject: Rather Long ~200 lines -- Re: TCP/ISO wars
Date: Thu, 08 Apr 1993 13:54:23 -0700
I have been pondering this great question since before 1987 when I
wrote:
"A Plea For Internet Peace", in CONNEXIONS: The
Interoperability Report, Advanced Computing Environments,
Volume 1, No, 5, September 1987 pp. 13-15.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11298;
19 Aug 93 18:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11290;
19 Aug 93 18:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28726;
19 Aug 93 18:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11270;
19 Aug 93 18:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11238;
19 Aug 93 18:45 EDT
Received: from spool.UU.NET by CNRI.Reston.VA.US id aa28699; 19 Aug 93 18:45 EDT
Received: from stallion.oz.au by spool.UU.NET with MHSnet
(5.61/UUNET-uucp-primary) id AA25477; Thu, 19 Aug 93 18:46:21 -0400
Received: from cluster.stallion.oz.au by stallion.stallion.oz.au id aa00907;
20 Aug 93 8:53 aest
Subject: ATM FORUM
To: ietf at CNRI.Reston.VA.US
Date: Fri, 20 Aug 1993 08:41:10 +1000 (AEST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Thomas Essebier <tom at stallion.oz.au>
Organisation: Stallion Technologies Pty Ltd.
Phone: +61 7 870 4999 (Fx: +61 7 371 8881)
Reply-To: Thomas Essebier <tom at stallion.oz.au>
X-Orig-Sender: Thomas Essebier <tom at stallion.oz.au>
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 296
Message-Id: <9308200841.aa22347 at cluster.stallion.oz.au>
Could you please add
ietf at stallion.oz.au
to the ATM Forum mail list.
Thank you
Tom
--
Thomas J. Essebier Stallion Technologies Pty. Ltd.
Aarnet: tom at stallion.oz.au 56 Sylvan Rd., Toowong 4066, Australia
uunet!stallion.oz.au!tom Fx: +61 7 371 8881, Ph: +61 7 870 4999
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11562;
19 Aug 93 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11555;
19 Aug 93 19:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29596;
19 Aug 93 19:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11543;
19 Aug 93 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11516;
19 Aug 93 19:25 EDT
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa29575;
19 Aug 93 19:25 EDT
Received: by CSLI.Stanford.EDU (4.1/25-CSLI-eef) id AA04273; Thu, 19 Aug 93 16:25:38 PDT
Date: Thu, 19 Aug 93 16:25:35 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: Thomas Essebier <tom at stallion.oz.au>
Cc: ietf at CNRI.Reston.VA.US
Phone: +1 415 941-3399 (Interop) or 1-800-INTEROP
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 962-2515 (Office) +1 415 998-4427 (Pager)
Fax: +1 415 949-1779 (Interop) +1 415 826-2008 (Home)
X-Comment: Ignore error messages for "ole at radiomail.net"
Subject: Re: ATM FORUM
In-Reply-To: Your message of Fri, 20 Aug 1993 08:41:10 +1000 (AEST)
Message-Id: <CMM.0.90.4.745802735.ole at Csli.Stanford.EDU>
According to the ATM Forum Secretariat, you have to be a member of
the forum in order to be on said mailing list. For information
about the forum and its activities, call 415-962-2585 or send e-mail
to:
atmforum_info at atmforum.com
In any case, as has been stated a million times before, all messages
about "add me" or "delete me" to a mailing list should be sent to the
"-request" address (as in "ietf-request at cnri.reston.va.us") and not
the list itself.
Thanks for your attention.
Ole
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report
Interop Company, 480 San Antonio Road,Mountain View, CA 94040-1219, USA
Phone: +1 (415) 962-2515 FAX: +1 (415) 949-1779 E-mail: ole at interop.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11689;
19 Aug 93 19:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11682;
19 Aug 93 19:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29901;
19 Aug 93 19:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11670;
19 Aug 93 19:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11630;
19 Aug 93 19:38 EDT
Received: from POLARIS.INTEROP.COM by CNRI.Reston.VA.US id aa29822;
19 Aug 93 19:38 EDT
Received: from interop.com (mailer.interop.com) by polaris.interop.com (4.1/SMI-4.1)
id AA03388; Thu, 19 Aug 93 16:41:47 PDT
Message-Id: <9308192341.AA03388 at polaris.interop.com>
Date: 19 Aug 1993 16:39:10 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Anne Ferris <aferris at interop.com>
Subject: ATM Forum Information
To: IETF List <ietf at CNRI.Reston.VA.US>
Subject: Time:4:28 PM
OFFICE MEMO ATM Forum Information Date:8/19/93
Regarding recent requests,
The ATM Forum does not have open e-mail lists. Forum activities and
documentation are available to members only. Membership info is as follows:
Principal Members pay $10,000 USD annually to join the Forum. They are allowed
to attend Technical and Market Committee meetings, vote on issues and submit
technical contributions. All technical documentation is sent over e-mail, and
therefore all members must be on e-mail. Principal members can send up to 2
reps per working group to Technical Committee meetings, there are now 8
subworking groups, so theoretically 16 people from any one Principal member can
attend. Principal Members may send 2 representatives to all General and Annual
Meetings free of charge, additional attendees may attend for an extra fee.
Auditing Members pay $1500 USD annually to join the Forum. They are NOT ALLOWED
to attend Technical and Market Committee meetings, NOT ALLOWED to vote on
issues and NOT ALLOWED to submit technical contributions. They are allowed to
be the e-mail distribution list to "audit" all documentation and are NOT
ALLOWED to make comments.
Auditing Members may send 1 representative to all General and Annual Meetings
free of charge, additional attendees may attend for an extra fee.
**1993 ATM Forum Membership fees are valid thru December 31, 1993. We do not
pro-rate fees regardless of the date you join the Forum.
To have an information package mailed to you, please send your complete
name/address/phone/fax to: atmforum_info at atmforum.com
regards
af
**********************************************************
Anne M. Ferris / Executive Director / The ATM Forum
480 San Antonio Road, Mountain View, CA 94040 USA
aferris at interop.com / Ph +1 415-962-2570 / FAX +1 415-941-0849
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01902;
20 Aug 93 8:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01895;
20 Aug 93 8:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07050;
20 Aug 93 8:15 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01878;
20 Aug 93 8:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01693;
20 Aug 93 8:06 EDT
Received: from thor.tjhsst.edu by CNRI.Reston.VA.US id aa06767;
20 Aug 93 8:06 EDT
Received: from localhost.tjhsst.edu by thor.tjhsst.edu (AIX 3.2/UCB 5.64/TJ1.06)
id AA13501; Fri, 20 Aug 1993 08:11:04 -0400
Message-Id: <9308201211.AA13501 at thor.tjhsst.edu>
To: Anne Ferris <aferris at interop.com>
Cc: IETF List <ietf at CNRI.Reston.VA.US>
Subject: Re: ATM Forum Information
In-Reply-To: Your message of "19 Aug 1993 16:39:10 EDT."
<9308192341.AA03388 at polaris.interop.com>
Date: Fri, 20 Aug 1993 08:11:03 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Metz <cmetz at thor.tjhsst.edu>
In message <9308192341.AA03388 at polaris.interop.com>, you write:
> Subject: Time:4:28 PM
> OFFICE MEMO ATM Forum Information Date:8/19/93
>Regarding recent requests,
>
>The ATM Forum does not have open e-mail lists. Forum activities and
>documentation are available to members only. Membership info is as follows:
>
>Principal Members pay $10,000 USD annually to join the Forum. They are allowed
>to attend Technical and Market Committee meetings, vote on issues and submit
>technical contributions. All technical documentation is sent over e-mail, and
>therefore all members must be on e-mail.
Could anyone enlighten me as to how this fits into the acceptable
use policies of many network service providers (and for that matter the
remains of the NSFnet backbone)? Or are we now completely ignoring the old
idea of trying to keep the net from becoming a haven for profiteers?
-Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02906;
20 Aug 93 9:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02902;
20 Aug 93 9:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08363;
20 Aug 93 9:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02884;
20 Aug 93 9:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02879;
20 Aug 93 9:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08356;
20 Aug 93 9:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02874;
20 Aug 93 9:07 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: host-conf at sol.bucknell.edu
Cc: The Internet Engineering Steering Group <IESG at CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Dynamic Host Configuration to Proposed Standard
Date: Fri, 20 Aug 93 09:07:26 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308200907.aa02874 at IETF.CNRI.Reston.VA.US>
The IESG has approved the following Internet-Drafts as a Proposed
Standard.
o "Interoperation Between DHCP and BOOTP"
<draft-ietf-dhc-between-bootp-03.txt>
o "Clarifications and Extensions for the Bootstrap Protocol"
<draft-ietf-dhc-bootp-02.txt>
o "DHCP Options and BOOTP Vendor Extensions"
<draft-ietf-dhc-options-04.txt>
o "Dynamic Host Configuration Protocol"
<draft-ietf-dhc-protocol-07.txt>
These documents are the product of the Dynamic Host Configuration
Working Group. The IESG contact persons are Stev Knowles and Dave
Piscitello.
Technical Summary
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network.
DHCP provides a mechanism for transmitting configuration parameters
to hosts using the TCP/IP protocol suite. DHCP is based on the
Bootstrap Protocol (BOOTP), but adds the capability of automatic
allocation of reusable network addresses and additional
configuration options [19]. The format of DHCP messages is based
on the format of BOOTP messages, so that, in certain circumstances,
DHCP and BOOTP participants may exchange messages. This document
series specifies
a) The Dynamic Host Configuration Protocol
b) The means whereby and circumstances under which the DHCP and
BOOTP may exchange messages (i.e., interoperate)
c) Clarifications and extensions to the BOOTP
d) DHC Options and vendor-specific extensions
Working Group Summary
The development of dynamic host configuration is a multi-faceted
and complex effort. The WG has made substantial progress in
improving upon the framework initially defined in the BOOTP. It is
the judgement of the relevant area director and his predecessor
(Phil Almquist) that work in this area is essentially open-ended
since a great deal of the configuration information that may fall
within the dominion of a dynamic host configuration is vendor-
specific. With this in mind, the recommendation is to actively
encourage development within the IETF community by taking what has
been specified at this time and advancing the documents to proposed
status.
Protocol Quality
This work has been reviewed by David Piscitello and Phil Almquist
on behalf of the IESG. There are at least 2 implementations under
development.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03039;
20 Aug 93 9:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03031;
20 Aug 93 9:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08473;
20 Aug 93 9:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03016;
20 Aug 93 9:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02964;
20 Aug 93 9:11 EDT
Received: from QUCDN.QueensU.CA by CNRI.Reston.VA.US id aa08441;
20 Aug 93 9:11 EDT
Received: from QUCDN.QUEENSU.CA by QUCDN.QueensU.CA (IBM VM SMTP V2R2)
with BSMTP id 2690; Fri, 20 Aug 93 09:10:41 EDT
Received: from QUCDN.QueensU.CA (NJE origin HOOPER at QUCDN) by QUCDN.QUEENSU.CA (LMail V1.1d/1.7f) with BSMTP id 4597; Fri, 20 Aug 1993 09:10:26 -0400
Date: Fri, 20 Aug 93 08:59:45 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Andy Hooper <HOOPER at qucdn.queensu.ca>
Subject: Re: ATM Forum Information
To: Craig Metz <cmetz at thor.tjhsst.edu>
cc: IETF List <ietf at CNRI.Reston.VA.US>
In-Reply-To: Message of Fri, 20 Aug 1993 08:11:03 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US from <cmetz at thor.tjhsst.edu>
Message-ID: <9308200911.aa08441 at CNRI.Reston.VA.US>
Craig Metz writes:
>Could anyone enlighten me as to how this fits into the acceptable
>use policies of many network service providers (and for that matter the
>remains of the NSFnet backbone)?
As an example, "The ONet network exists to facilitate the exchange of
information in support of research, development, education and technology
transfer." "Support" easily covers obtaining information about developments
which may affect your institution, from whatever source. I believe many
AUPs use similar phrasing.
--
Andy Hooper Queen's University Computing Services, Kingston, Ontario, Canada
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03089;
20 Aug 93 9:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03084;
20 Aug 93 9:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08523;
20 Aug 93 9:15 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03063;
20 Aug 93 9:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03059;
20 Aug 93 9:15 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: host-conf at sol.bucknell.edu
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Dynamic Host Configuration to Proposed Standard
Date: Fri, 20 Aug 93 09:15:02 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308200915.aa03059 at IETF.CNRI.Reston.VA.US>
The IESG has approved the following Internet-Drafts as a Proposed
Standard.
o "Interoperation Between DHCP and BOOTP"
<draft-ietf-dhc-between-bootp-03.txt>
o "Clarifications and Extensions for the Bootstrap Protocol"
<draft-ietf-dhc-bootp-02.txt>
o "DHCP Options and BOOTP Vendor Extensions"
<draft-ietf-dhc-options-04.txt>
o "Dynamic Host Configuration Protocol"
<draft-ietf-dhc-protocol-07.txt>
These documents are the product of the Dynamic Host Configuration
Working Group. The IESG contact persons are Stev Knowles and Dave
Piscitello.
Technical Summary
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network.
DHCP provides a mechanism for transmitting configuration parameters
to hosts using the TCP/IP protocol suite. DHCP is based on the
Bootstrap Protocol (BOOTP), but adds the capability of automatic
allocation of reusable network addresses and additional
configuration options [19]. The format of DHCP messages is based
on the format of BOOTP messages, so that, in certain circumstances,
DHCP and BOOTP participants may exchange messages. This document
series specifies
a) The Dynamic Host Configuration Protocol
b) The means whereby and circumstances under which the DHCP and
BOOTP may exchange messages (i.e., interoperate)
c) Clarifications and extensions to the BOOTP
d) DHC Options and vendor-specific extensions
Working Group Summary
The development of dynamic host configuration is a multi-faceted
and complex effort. The WG has made substantial progress in
improving upon the framework initially defined in the BOOTP. It is
the judgement of the relevant area director and his predecessor
(Phil Almquist) that work in this area is essentially open-ended
since a great deal of the configuration information that may fall
within the dominion of a dynamic host configuration is vendor-
specific. With this in mind, the recommendation is to actively
encourage development within the IETF community by taking what has
been specified at this time and advancing the documents to proposed
status.
Protocol Quality
This work has been reviewed by David Piscitello and Phil Almquist
on behalf of the IESG. There are at least 2 implementations under
development.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03206;
20 Aug 93 9:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03201;
20 Aug 93 9:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08654;
20 Aug 93 9:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03187;
20 Aug 93 9:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03182;
20 Aug 93 9:17 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Interactive Mail Access Protocol - Version 3 to
Historic
Date: Fri, 20 Aug 93 09:17:57 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308200917.aa03182 at IETF.CNRI.Reston.VA.US>
The IESG has reclassified RFC1203 "Interactive Mail Access Protocol -
Version 3" as a Historic protocol. This document is not the product
of an IETF Working Group, but has been reviewed by the IESG. The IESG
contact person is John Klensin.
Technical Summary
IMAP3 was originally written as an alternative to RFC1176. Based on
recent discussions with the author and other members of the community,
it seems clear that "IMAP3" hasn't gone, and isn't going, anywhere
and there is no longer a constituency for it. Reclassifying it as
Historic clears up the record and reduces the odds of new
implementations that are incompatible with the IMAP-WG work.
Working Group Summary
The IMAP Working Group, which is using RFC1176, rather than RFC1023,
as its starting point, has not been asked to comment on this action,
but the request for it originates in discussions on another subject
with one of its major participants.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03871;
20 Aug 93 9:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03867;
20 Aug 93 9:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09501;
20 Aug 93 9:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03857;
20 Aug 93 9:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03853;
20 Aug 93 9:43 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-ppp at ucdavis.edu
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: CIPX and IPXCP to Proposed Standard
Date: Fri, 20 Aug 93 09:43:10 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308200943.aa03853 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Drafts:
o "Compressing IPX Headers Over WAN Media (CIPX)"
<draft-ietf-pppext-cipx-04.txt>
o "The PPP Internetwork Packet Exchange Control Protocol (IPXCP)"
<draft-ietf-pppext-ipxcp-04.txt>
as a Proposed Standard. These documents are the product of the
Point-to-Point Protocol Extensions Working Group. The IESG
contact persons are Stev Knowles and David Piscitello.
CIPX
====
Technical Summary
This document describes a method for compressing the headers of IPX
datagrams (CIPX). With this method, it is possible to significantly
improve performance over lower speed wide area network (WAN) media.
For normal IPX packet traffic, CIPX can provide a compression ratio
of approximately 2:1 including both IPX header and data. This method
can be used on various type of WAN media, including those supporting
PPP and X.25.
Working Group Summary
The protocol has been discussed and studied by members of the Point-
to-Point Protocol Extensions Working Group. It is widely supported by
committee members.
Protocol Quality
The protocol has been reviewed by David Piscitello, Internet Area
Director, on behalf of the IESG. Comments submitted to the authors
were considered, and corrections and additions have been introduced.
The revised draft was been posted to the internet-drafts directories
on July 20, 1993.
There is at least one implementation of CIPX (although this is not a
criteria for this protocol action).
IPXCP
=====
Technical Summary
The Point-to-Point Protocol provides a method for transmitting multi-
protocol datagrams over point-to-point links. This document is one of
a family of Network Control Protocols for establishing and configuring
different network-layer protocols. This document defines the Network
Control Protocol for establishing and configuring the IPX protocol
over PPP. The IPX protocol, originally used in Novell's NetWare
products, is now supported by numerous other vendors. The IPXCP
packets defined herein are used to choose and configure the IPX
network-layer protocol.
Working Group Summary
There are no objections to moving this document to proposed at this
time.
Protocol Quality
David Piscitello has reviewed this document on behalf of the IESG.
Comments sent to the author have been considered in the preparation
of the Internet-Draft noted above. There are several known
implementations (having multiple interoperable implementations is
not a requirement at this level of protocol action).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05465;
20 Aug 93 10:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05457;
20 Aug 93 10:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11574;
20 Aug 93 10:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05443;
20 Aug 93 10:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05400;
20 Aug 93 10:55 EDT
Received: from SGI.COM by CNRI.Reston.VA.US id aa11534; 20 Aug 93 10:55 EDT
Received: by sgi.sgi.com (920330.SGI/910110.SGI)
id AA22400; Fri, 20 Aug 93 07:47:04 -0700
To: ietf at nri.reston.va.us
Reply-To: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
X-Approved: newsmail at sgi.sgi.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Subject: Re: ATM Forum Information
Message-Id: <jtqiqtg at rhyolite.wpd.sgi.com>
Date: Fri, 20 Aug 1993 14:42:50 GMT
Craig Metz <cmetz at thor.tjhsst.edu> writes:
> >The ATM Forum does not have open e-mail lists. Forum activities and
> >documentation are available to members only. Membership info is as follows:
> >
>>Principal Members pay $10,000 USD annually to join the Forum. They are allowed
> >to attend Technical and Market Committee meetings, vote on issues and submit
>>technical contributions. All technical documentation is sent over e-mail, and
> >therefore all members must be on e-mail.
>
> Could anyone enlighten me as to how this fits into the acceptable
> use policies of many network service providers (and for that matter the
> remains of the NSFnet backbone)? Or are we now completely ignoring the old
> idea of trying to keep the net from becoming a haven for profiteers?
The ATM Forum is as open-to-all-comers and not-for-profit as the
nearest University or college that charges $10,000. That some of the
participants hope to make a bundle with products developed while
particpating is also similar.
The purpose of the ATM Forum is not to run a "bulletin board" for
everyone who wants to talk about the latest buzzword. There are
already free (to most participants) facilities for that, such as the
comp.dcom.cell-relay newsgroup.
A distant observer might conclude that the industrial participants in
the ATM forum, the ones that are spending far more than $10,000/year,
have decided that they don't want to have another Standards Process
Experience like the 10 years devoted to get FDDI as far as it is
(incomplete). An obvious first step is disenfranchising members of
"Information Services" departments on junkets to learn new buzz words
and rub shoulders with designers and developers, consultants on
prospecting trips, and others with vested interests in extending the process
and making the result more complicated. I do not know that those were
the motives of the Principal Members, but they better do such things if
they hope to have a (de facto) standard this century.
Vernon Schryver, vjs at sgi.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06278;
20 Aug 93 11:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06271;
20 Aug 93 11:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13015;
20 Aug 93 11:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06259;
20 Aug 93 11:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06230;
20 Aug 93 11:51 EDT
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa12990;
20 Aug 93 11:51 EDT
Received: by CSLI.Stanford.EDU (4.1/25-CSLI-eef) id AA01057; Fri, 20 Aug 93 08:52:23 PDT
Date: Fri, 20 Aug 93 8:52:21 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: ietf at CNRI.Reston.VA.US
Phone: +1 415 941-3399 (Interop) or 1-800-INTEROP
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 962-2515 (Office) +1 415 998-4427 (Pager)
Fax: +1 415 949-1779 (Interop) +1 415 826-2008 (Home)
X-Comment: Ignore error messages for "ole at radiomail.net"
Subject: Disclaimer
Message-Id: <CMM.0.90.4.745861941.ole at Csli.Stanford.EDU>
Apologies for yet another message. My memo yesterday about the ATM Forum
has been read by some to imply that I represent them. I do not. I am not
in any way affiliated with the Forum. The only "connection" is that I work
for the same company that runs the Secretariat for the Forum. Questions
and comments about fees and policies should be directed to the Forum itself.
Since there is great interest in the Forum (and the Frame Relay Forum and
the SMDS Interest Group), I have asked each to prepare a one-page writeup
which I will publish in ConneXions soon. I'd be happy to send that issue
to anyone who asks.
"I will learn to use disclaimers. I will learn to use disclaimers. I
will learn to use disclaimers. I will learn to use disclaimers. I will
learn to use disclaimers. I will learn to use disclaimers. I will learn
to use disclaimers."
Ole
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report
Interop Company, 480 San Antonio Road,Mountain View, CA 94040-1219, USA
Phone: +1 (415) 962-2515 FAX: +1 (415) 949-1779 E-mail: ole at interop.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06595;
20 Aug 93 12:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06588;
20 Aug 93 12:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13727;
20 Aug 93 12:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06565;
20 Aug 93 12:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06528;
20 Aug 93 12:16 EDT
Received: from uga.cc.uga.edu by CNRI.Reston.VA.US id aa13697;
20 Aug 93 12:16 EDT
Received: from UWF.CC.UWF.EDU by uga.cc.uga.edu (IBM VM SMTP V2R2)
with BSMTP id 4366; Fri, 20 Aug 93 12:18:18 EDT
Received: from UWF (NJE origin STANKULI at UWF) by UWF.CC.UWF.EDU (LMail
V1.1d/1.7f) with BSMTP id 4631; Fri, 20 Aug 1993 11:17:41 -0500
Date: Fri, 20 Aug 93 11:16:18 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: stan kulikowski ii <STANKULI%UWF.BITNET at uga.cc.uga.edu>
Subject: internetworking protocols?
To: ietf at CNRI.Reston.VA.US
Message-ID: <9308201216.aa13697 at CNRI.Reston.VA.US>
i am looking for network sources of internetworking protocols. i am
familiar with
FTP.NISC.SRI.COM for the arpanet and internet rfc, and
NIC.MERIT.EDU for nsfnet and nren documents
WORLD.STD.COM for a few ccitt and iso protocols...
but the ccitt x and iso osi protocols are woefully incomplete and are
full of markups for some laser-print formatting. i would like to find a
complete set of these protocols that are free of hardcopy contamination.
surely there must be some european archives online, but my archie search
does not reveal any. i do not mind if they are not in english, so long as
they are fairly complete.
i would also like to know if ieee or eia protocols are available for
download somewhere. any hope for sna, dna, xns, ipx, or even appletalk?
below i will attach a document that shows some of the protocols i am
interested in finding in ftp network archives. if you see something out
of place or missing in the protocol matrix below, i would appreciate some
advice.
stan
stankuli at UWF.bitnet
.
=== god created time so everything would not happen at once
god created space so everything would not happen to me
--- -- lament of the overburdened
==========================================================================
A Simple Internetwork Protocol Matrix:
ISO, CCITT, RFC, IEEE, MIL-STD, EIA
prepared by Stan Kulikowski II stankuli at UWF.bitnet
ERDC University of West Florida
Pensacola, FL 32514
Layer 1: Physical =======================================================
unbalanced 25-pin iso2110 v.24, v.28 rs232
balanced 37-pin x.26, x.27 rs449, rs422, rs423
circuit-switched 15-pin x.21
Layer 2: Data Link =======================================================
logical link control iso8802/2 ieee802.2
CSMA/CD ethernet iso8802/3 ieee802.3
token bus iso8802/4 ieee802.4
token ring iso8802/5 ieee802.5
Layer 3: Network ========================================================
connection network iso8208 x.25 rfc877
connection network iso8348
connectionless network iso8473 rfc994
ES-IS routing exchange rfc995
x.25 addresses x.121
IP internet protocol rfc791, rfc963 mil-std1777
ICMP control message rfc792
RIP routing information rfc1058
Layer 4: Transport =======================================================
connection transport iso8072 x.214
connection transport iso8073 x.224 rfc905
connectionless transport iso8602
UDP user datagram rfc768
TCP transmission control rfc793, rfc964 mil-std1778
ISODE transport rfc1006-8
Layer 5: Session =========================================================
connection session iso8826 x.215
connection session iso8827 x.225
Layer 6: Presentation ====================================================
connection presentation iso8822-3
abstract syntax notation iso8824-5 x.208-9
MHS presentation x.409
Layer 7: Application =====================================================
virtual terminal iso9040
FTAM iso8571 rfc1415
job transfer manipulation iso8831
message handling system iso10021 x.400 rfc987, rfc1026
directory service x.500 rfc1274-6
domain name system rfc1031-5
FTP file transfer rfc959 mil-std1780
TELNET remote login rfc854, rfc930 mil-std1782
SMTP simple mail transfer rfc821, rfc974 mil-std1781
SMTP service extension rfc1425-7
Layer 8: Management ======================================================
common management info iso9595/2
simple network management rfc1065-7
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09233;
20 Aug 93 14:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16828;
20 Aug 93 14:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09164;
20 Aug 93 14:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08987;
20 Aug 93 14:04 EDT
To: IETF-Announce: ;
cc: ietf-822 at dimacs.rutgers.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-822ext-direction-00.txt
Date: Fri, 20 Aug 93 14:04:45 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308201404.aa08987 at IETF.CNRI.Reston.VA.US>
The attached Internet-Draft was originally attributed to the 822ext
Working Group, but it should have been treated as an independant
submission. The pathname of the Internet-Draft has been changed to
<draft-nussbacher-mime-direction-00.txt>.
My apology for any inconvenience,
Cynthia Clark
Internet Drafts Administrator
------- Forwarded Message -------------------
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-822ext-direction-00.txt
Date: Thu, 19 Aug 93 11:04:44 -0400
Sender: cclark at CNRI.Reston.VA.US
- - --NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message Extensions
Working Group of the IETF.
Title : Handling of Bi-directional Texts in MIME
Author(s) : H. Nussbacher
Filename : draft-ietf-822ext-direction-00.txt
Pages : 3
This document describes the format and syntax of the "direction"
keyword to be used with bi-directional texts in MIME.
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-822ext-direction-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-822ext-direction-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
- - --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
- - --OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-822ext-direction-00.txt
- - --OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-822ext-direction-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
- - --OtherAccess--
- - --NextPart--
- ------- End of Blind-Carbon-Copy
------- End of Forwarded Message
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09248;
20 Aug 93 14:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16847;
20 Aug 93 14:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09167;
20 Aug 93 14:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09002;
20 Aug 93 14:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-madman-networkmib-03.txt
Date: Fri, 20 Aug 93 14:04:49 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308201404.aa09002 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory Management
Working Group of the IETF.
Title : Network Services Monitoring MIB
Author(s) : N. Freed, S. Kille
Filename : draft-ietf-madman-networkmib-03.txt
Pages : 7
This document defines the generic part of a MIB suitable for monitoring
applications which provide some kind of network services. This MIB is
intended to be extended to accomodate monitoring specific to a given type
of service, for example, a Message Transfer Agent (MTA) service or a
Directory Service Agent (DSA) service.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-madman-networkmib-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-madman-networkmib-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-madman-networkmib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-networkmib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09249;
20 Aug 93 14:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16848;
20 Aug 93 14:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09162;
20 Aug 93 14:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08966;
20 Aug 93 14:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-madman-mtamib-03.txt
Date: Fri, 20 Aug 93 14:04:36 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308201404.aa08966 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory Management
Working Group of the IETF.
Title : Mail Monitoring MIB
Author(s) : N. Freed, S. Kille
Filename : draft-ietf-madman-mtamib-03.txt
Pages : 10
This document extends the basic Network Services Monitoring MIB to allow
monitoring of Message Transfer Agents (MTAs).
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-madman-mtamib-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-madman-mtamib-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-madman-mtamib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-mtamib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09352;
20 Aug 93 14:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16977;
20 Aug 93 14:10 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09335;
20 Aug 93 14:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09152;
20 Aug 93 14:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-madman-dsa-mib-02.txt
Date: Fri, 20 Aug 93 14:07:55 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308201407.aa09152 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory Management
Working Group of the IETF.
Title : Directory Monitoring MIB
Author(s) : G. Mansfield, S. Kille
Filename : draft-ietf-madman-dsa-mib-02.txt
Pages : 19
This document defines an experimental portion of the Management Information
Base (MIB). It defines the MIB for monitoring Directory System Agents
[DSA], a component of the OSI Directory. This MIB will be used in
conjunction with the APPLICATION-MIB for monitoring DSAs.
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-madman-dsa-mib-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-madman-dsa-mib-02.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-madman-dsa-mib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-dsa-mib-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09377;
20 Aug 93 14:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16991;
20 Aug 93 14:10 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09348;
20 Aug 93 14:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09216;
20 Aug 93 14:08 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tn3270e at list.nih.gov
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-tn3270e-current-pract-00.txt
Date: Fri, 20 Aug 93 14:08:29 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308201408.aa09216 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Telnet TN3270 Enhancements
Working Group of the IETF.
Title : TN3270 Current Practices
Author(s) : J. Penner
Filename : draft-ietf-tn3270e-current-pract-00.txt
Pages : 9
This document describes the existing implementation of transferring 3270
display terminal data using currently available telnet capabilities. The
name traditionally associated with this implementation is TN3270.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tn3270e-current-pract-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-tn3270e-current-pract-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-tn3270e-current-pract-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tn3270e-current-pract-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26752;
23 Aug 93 9:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26748;
23 Aug 93 9:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02078;
23 Aug 93 9:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26739;
23 Aug 93 9:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26735;
23 Aug 93 9:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02073;
23 Aug 93 9:00 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa26729;
23 Aug 93 9:00 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: bridge-mib at pa.dec.com
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: Definitions of Managed Objects for Source Routing
Bridges to Proposed Standard
Date: Mon, 23 Aug 93 09:00:06 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308230900.aa26729 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Bridge MIB Working Group to
consider "Definitions of Managed Objects for Source Routing Bridges"
<draft-ietf-bridge-sr-objects-03.txt> for the status of Proposed
Standard.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
06 September.
John Stewart
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27740;
23 Aug 93 9:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27736;
23 Aug 93 9:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02947;
23 Aug 93 9:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27721;
23 Aug 93 9:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27713;
23 Aug 93 9:35 EDT
Received: from ftp.Novell.DE by CNRI.Reston.VA.US id aa02935; 23 Aug 93 9:35 EDT
Received: from c3p0.Novell.DE by mail.novell.de with SMTP
(5.65b+SNI2/IDA-112992) id AA14868; Mon, 23 Aug 93 13:16:53 GMT
Received: by c3p0.novell.de
(5.65b+SNI2/IDA-1.0FwdMhs) id AA17775; Mon, 23 Aug 93 13:16:52 GMT
Received: by MHS.novell.de id D773732C81D93EDC; Mon, 23 Aug 93 15:16:51 MESZ
Return-Path: <-SMF71- at NWC-EUR.MHS.novell.de>
Precedence: first-class
X-Date-Posted: 19-Aug-93 12:36:19
X-Notification-Correlator: C362732C01D93EDC
X-Date-Transferred: 19-Aug-1993 12:52:44 -0400; at nwc-uk.Novell
X-Date-Transferred: 19-Aug-1993 13:44:26 -0400; at dus-gmhs.novell
To: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Message-Id: <C362732C01D93EDC at MHS.novell.de>
Subject: HR MIB comments
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: -SMF71- at mhs.novell.de
Date: Mon, 23 Aug 93 15:16:51 MESZ
X-Conversation-Id: C162732C02D93EDC
X-Original-To: mail-ser at INETGATE {iesg at cnri.reston.va.us}, mail-ser at INETGATE{ietf@cnri.reston.va.us}
X-Original-Copies-To: Glenn Stephens,John Constant,John Linney
O-Dvs-Trailtype: 0
O-Dvs-Trailaddr: JWEIN
O-Dvs-Traildate: 19-Aug-93 12:34:57
O-Dvs-Wrapinfo: 01 ,85 ,86 ,030B ,030C ,044A ,044B ,0518 ,0519 ,07C0 ,07C1 ,08D5 ,08D6 ,0A1D ,0A1E ,0A9C ,0A9D ,0C1D ,0C1E ,0CF0 ,0CF1 ,0FA0 ,0FA1,0FDB,0FDC,1083,1084,11C6,11C7,11D4,11D5,11DE,11DF,11F3,1208,121D
X-Via-Host: LAABER.NOVELL
Cc: JLINNEY at mhs.novell.de, JCONSTAN at mhs.novell.de, GLENNSTE at mhs.novell.de
The following is a collection of various points I came across during an
implementation of the HR MIB for DOS (no particular order):
1. Several tables in the HR MIB use ObjectIDs to denote the type of a
particular table entry. For example, the type of entries in
hrStorageTable is specified by one of the sub-nodes of hrStorageTypes. An
example would be a value of 1.3.6.1.36.2.1.4 to indicate that this entry
in the storage table is a fixed disk and 1.3.6.1.36.2.1.6 to indicate
that it is a floppy. In the hrDiskStorageTable however (which also
represents storage media and hence replicates some of the data of the
other table), such types are represented by an enumerated integer
(similar to the "C" enum statement), so for example, 3 means a hard disk
and 4 means a floppy.
The former method is also used for the type in the device table and in
the file system table whereas the latter is also used for the device
status in the device table, the printer status in the printer table, the
file system access mode, the software run type, the software run status
and the software installed type.
The first example already shows that the choice of method seems to have
been made arbitrarily. Personally, I find the ObjID method very clumsy
(difficult to handle on both the agent and the console side).
The enumerated method has its problems: If the MIB browser is used (as
opposed to a custom application) there is no provision within MIBs to
separate logical strings from their actual (human language specific)
instance. If I define in a MIB for example that a particular variable
'switch' can take the values 'switched-on' or 'switched-off' these very
same English words are displayed by the browser. There is no facility to
translate this into Spanish, for example, without changing the MIB
definition file itself. The ObjectId method is hardly superior since
strings like 1.3.6.1.36.2.1.4 are unintelligible to both English and
Spanish speakers (at least it's fair on both...)
2. The description of 'hrNetworkIfIndex' in the HR MIB refers to a
variable 'ifIndex' that is not mentioned anywhere else in the MIB
definition. What is that variable and how does it relate to
'hrNetworkIfIndex' and 'hrDeviceIndex'? Does it actually refer to a
different MIB?
3. I noticed that the Host Resource MIB defines hrStorageSize as having
read/write access. I'm puzzled by the meaning of performing a SET
operation on e.g. the RAM size or the size of a hard disk: Surely I
can't "remotely" upgrade my machine by simply telling it that is really
has more RAM or a bigger drive than it thought?
4. How will the console know the unit of timer ticks for systemUpTime
since the tick rate differs between different machines?
5. Error status information for printers is returned in the printer
table. There doesn't appear to be any link between printer table entries
and parallel or serial ports in the device table. If the hardware
provides the error information on a per-port basis, how can it be made
available on a per-printer basis? There should really be a logical
connection between printers and ports!
6. Product IDs (Object IDs) to denote hardware or software are useless
without a published list of such IDs since otherwise they won't be
available for either HR MIB implementors or management console writers.
7. Both the hrStorageTable and the hrDiskStorageTable refer to
unpartitioned (physical) disks, not to drives as seen by DOS (i.e.
partitions). The hrDiskStorageTable kind of repeats the hrStorageTable.
While the hrStorageTypes distinguish between hrStorageFixedDisk and
hrStorageRemovableDisk, hrDiskStorageMedia only knows 'hardDisk'. On the
other hand, where hrDiskStorageMedia knows about opticalDiskROM,
opticalDiskWORM and opticalDiskRW, hrStorageTypes only know about
hrStorageCompactDisk. Why couldn't they at least make the same
distinctions? Why did one have to be more specific on one media type, and
the other on another? Does sound rather arbitrary and inconsistent to
me...
8. hrDiskStorageRemoveable: shouldn't it be 'removable' ?
9. Several groups in the HR MIB are, according to the comments in the HR
MIB, optional but then they are declared with "STATUS mandatory". How
does that fit together?
On the whole, it seemed more like a "Unix Host Resource MIB" to me --
many PC or DOS specific issues are not addressed at all while some other
items are pretty pointless under DOS. It is possible to support the same
relevant information as well as extra DOS specific data in something a
third of the size of the HR MIB...
Best regards
Joe Wein
MHS: JWEIN @ NOVELL
Tel: (+49) 9498-2525
Fax: (+49) 9498-1701
Compuserve: 100142,3715
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28376;
23 Aug 93 9:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28369;
23 Aug 93 9:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03597;
23 Aug 93 9:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28350;
23 Aug 93 9:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220;
23 Aug 93 9:52 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481;
23 Aug 93 9:52 EDT
Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13)
id <AA03534>; Mon, 23 Aug 1993 06:53:15 -0700
Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef)
id AA13355; Mon, 23 Aug 93 08:47:34 -0500
Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6)
id <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; Mon, 23 Aug 93 08:52 CDT
Message-Id: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
Date: Mon, 23 Aug 93 8:52:00 CDT
Cc: IP over ATM WG <atm at sun.com>, ietf-ppp at ucdavis.edu, rolc at network.com,
IETF <ietf at isi.edu>
Reflecting discussions at the last two IETF meetings, this note is to
announce that the IP over Large Public Data Networks WG has disbanded.
Unfinished work will be continued in the IP over ATM, PPP-EXT, and
Routing over Large Clouds Working Groups. IPLPDN is closing down
because issues had migrated to the IP over ATM WG and because of an Area
Director policy to create working groups that focus on specific issues rather
than on general topics. The mail list will continue to be maintained, and
RFCs which are on the standards track will be shepherded through by email.
These RFCs include...
o Multiprotocol over Frame Relay
o Inverse ARP
o Multiprotocol over X.25
Please let me know if there are other RFCs that are should be listed.
There was some recent email to the effect that IPLPDN solved the easy
problems and punted on the hard ones. This criticism of IPLPDN is not
really troubling because I am confident of the quality of work done by
the group. I owe it to my colleagues in the group, though, to respond.
IPLPDN dealt with problems that *had* to be solved to enable near-term,
interoperable implementations of virtual private networks over public,
switched data services. We produced excellent work that has been
widely accepted and implemented. You would be hard pressed to find
a vendor of SMDS and Frame Relay equipment who does not implement
RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been
adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground-
breaking work on address resolution in large environments. The work
on Shortcut Routing and Directed ARP has advanced the understanding
of people who are now participating in the IP over ATM and ROLC WGs.
Finally, we went a long way towards nailing down "multiprotocol over
circuit switched services" (included circuit ISDN), and this work
should be completed soon in the PPP group.
This recent criticism is unfortunate, and I'm sorry that we are ending on
a bit of a sour note. But I'm confident that the work done by IPLPDN will
continue to have value and that these comments will be recognized as
misplaced. IPLPDN was a great group that stayed focused on solving technical
problems. It was terrific fun, and I'm glad to have had the chance to
participate.
George Clapp
voice: 708-248-6507
fax: 708-248-3996
email: clapp at ameris.center.il.ameritech.com
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29934;
23 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05612;
23 Aug 93 11:07 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29915;
23 Aug 93 11:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa29875;
23 Aug 93 11:05 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-wada-packet-forwarding-00.txt
Date: Mon, 23 Aug 93 11:05:12 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308231105.aa29875 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Packet Forwarding for Mobile Hosts
Author(s) : H. Wada, B. Marsh
Filename : draft-wada-packet-forwarding-00.txt
Pages : 26
This memo describes a new protocol for mobile internetworking: the
Internet Packet Transmission Protocol (IPTP). IPTP provides packet
forwarding and host location functions that make mobility transparent to
all protocols above IP. IPTP specifies control messages between the
networking software on mobile hosts and a special Packet Forwarding
Service. Backward compatibility is provided by requiring no modifications
to stationary hosts or internetwork routers. To reduce overhead, IPTP
provides for lazy propagation of location updates. To enhance performance,
routes adapt as mobile hosts move.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-wada-packet-forwarding-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-wada-packet-forwarding-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-wada-packet-forwarding-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-wada-packet-forwarding-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00759;
23 Aug 93 11:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00755;
23 Aug 93 11:37 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa06651; 23 Aug 93 11:37 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA03316; Mon, 23 Aug 93 08:35:46 PDT
Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA16677; Mon, 23 Aug 93 08:35:45 PDT
Received: by atm.Eng.Sun.COM (4.1/SMI-4.1)
id AA07664; Mon, 23 Aug 93 08:34:50 PDT
Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1)
id AA07658; Mon, 23 Aug 93 08:34:49 PDT
Received: from snail.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA28667; Mon, 23 Aug 93 08:34:51 PDT
Received: from Eng.Sun.COM (zigzag-bb) by snail.Sun.COM (4.1/SMI-4.1)
id AA15551; Mon, 23 Aug 93 08:34:46 PDT
Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA16593; Mon, 23 Aug 93 08:34:45 PDT
Received: by bigriver.Eng.Sun.COM (5.0/SMI-SVR4)
id AA01822; Mon, 23 Aug 1993 08:34:40 +0800
Date: Mon, 23 Aug 1993 08:34:40 +0800
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Hinden <Bob.Hinden at eng.sun.com>
Message-Id: <9308231534.AA01822 at bigriver.Eng.Sun.COM>
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Cc: IPLPDN WG <iplpdn at nri.reston.va.us>, IP over ATM WG <atm at sun.com>,
ietf-ppp at ucdavis.edu, rolc at network.com, IETF <ietf at venera.isi.edu>
In-Reply-To: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>
Subject: re: dissolution of IPLPDN
Content-Length: 513
X-Orig-Sender: atm-request at atm.eng.sun.com
George,
As the IESG Area Director who helped start IPLPDN, I wish to congratulate
you and the IPLPDN working group for a job well done. I think we all
found out there was a lot important work which needed to be done in this
area.
The work done by IPLPDN under your leadership was very good and solved
real problems for people. It helped create additional environments to
run IP which did not exist when the group was started.
I personally thank you and the IPLPDN working group for a job well done.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03143;
23 Aug 93 13:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03136;
23 Aug 93 13:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10968;
23 Aug 93 13:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03117;
23 Aug 93 13:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03044;
23 Aug 93 13:46 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa10911;
23 Aug 93 13:46 EDT
Received: from nic.cerf.net by venera.isi.edu (5.65c/5.61+local-13)
id <AA10877>; Mon, 23 Aug 1993 10:46:48 -0700
Received: from [198.67.38.102] by nic.cerf.net (4.1/CERFnet-1.0) id AA06836; Mon, 23 Aug 93 10:50:09 PDT
Date: Mon, 23 Aug 93 10:50:08 PDT
Message-Id: <9308231750.AA06836 at nic.cerf.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: High Bandwidth Services Startup <mis at nexsys.net>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Robert Berger <rberger at cerf.net>
Subject: dissolution of IPLPDN
Cc: IP over ATM WG <atm at sun.com>, ietf-ppp at ucdavis.edu, rolc at network.com,
IETF <ietf at isi.edu>
Reflecting discussions at the last two IETF meetings, this note is to
announce that the IP over Large Public Data Networks WG has disbanded.
Unfinished work will be continued in the IP over ATM, PPP-EXT, and
Routing over Large Clouds Working Groups. IPLPDN is closing down
because issues had migrated to the IP over ATM WG and because of an Area
Director policy to create working groups that focus on specific issues rather
than on general topics. The mail list will continue to be maintained, and
RFCs which are on the standards track will be shepherded through by email.
These RFCs include...
o Multiprotocol over Frame Relay
o Inverse ARP
o Multiprotocol over X.25
Please let me know if there are other RFCs that are should be listed.
There was some recent email to the effect that IPLPDN solved the easy
problems and punted on the hard ones. This criticism of IPLPDN is not
really troubling because I am confident of the quality of work done by
the group. I owe it to my colleagues in the group, though, to respond.
IPLPDN dealt with problems that *had* to be solved to enable near-term,
interoperable implementations of virtual private networks over public,
switched data services. We produced excellent work that has been
widely accepted and implemented. You would be hard pressed to find
a vendor of SMDS and Frame Relay equipment who does not implement
RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been
adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground-
breaking work on address resolution in large environments. The work
on Shortcut Routing and Directed ARP has advanced the understanding
of people who are now participating in the IP over ATM and ROLC WGs.
Finally, we went a long way towards nailing down "multiprotocol over
circuit switched services" (included circuit ISDN), and this work
should be completed soon in the PPP group.
This recent criticism is unfortunate, and I'm sorry that we are ending on
a bit of a sour note. But I'm confident that the work done by IPLPDN will
continue to have value and that these comments will be recognized as
misplaced. IPLPDN was a great group that stayed focused on solving technical
problems. It was terrific fun, and I'm glad to have had the chance to
participate.
George Clapp
voice: 708-248-6507
fax: 708-248-3996
email: clapp at ameris.center.il.ameritech.com
Robert J. Berger Internet: rberger at cerf.net
InterNex Information Services
1050 Chestnut Street Suite 202, Menlo Park, CA 94025
Voice: 415-473-3060 Fax: 415-473-3062
Email after 8/25: rberger at internex.net
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04450;
23 Aug 93 14:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12137;
23 Aug 93 14:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04438;
23 Aug 93 14:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04371;
23 Aug 93 14:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12068;
23 Aug 93 14:25 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04366;
23 Aug 93 14:25 EDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
To: IETF-Announce: ;
Subject: WG ACTION: IP Over Large Public Data Networks (IPLPDN) to Conclude
Date: Mon, 23 Aug 93 14:25:30 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308231425.aa04366 at IETF.CNRI.Reston.VA.US>
The IP Over Large Public Data Networks Working Group of the IETF
has concluded. Unfinished work will be continued in existing
working groups. The mailing list will remain active.
The IESG contact persons are Stev Knowles and Dave Piscitello.
John Stewart
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00392;
23 Aug 93 19:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00383;
23 Aug 93 19:13 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa02204; 23 Aug 93 19:13 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA20845; Mon, 23 Aug 93 16:12:58 PDT
Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA04637; Mon, 23 Aug 93 16:12:55 PDT
Received: by atm.Eng.Sun.COM (4.1/SMI-4.1)
id AA08379; Mon, 23 Aug 93 16:11:51 PDT
Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1)
id AA08373; Mon, 23 Aug 93 16:11:50 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1)
id AA06020; Mon, 23 Aug 93 16:11:57 PDT
Received: from cpmx.saic.com by Sun.COM (4.1/SMI-4.1)
id AA20685; Mon, 23 Aug 93 16:11:49 PDT
Message-Id: <9308232311.AA20685 at Sun.COM>
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c795032025730; Mon, 23 Aug 93 16:18:11 -0700
Date: 23 Aug 1993 12:53:18 U
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: QM Administrator <QM_Administrator at cpqm.saic.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
Cc: IETF <ietf at isi.edu>, ietf-ppp at ucdavis.edu, IP over ATM WG <atm at sun.com>,
rolc at network.com
X-Orig-Sender: atm-request at atm.eng.sun.com
Mail*Link(r) SMTP dissolution of IPLPDN
Reflecting discussions at the last two IETF meetings, this note is to
announce that the IP over Large Public Data Networks WG has disbanded.
Unfinished work will be continued in the IP over ATM, PPP-EXT, and
Routing over Large Clouds Working Groups. IPLPDN is closing down
because issues had migrated to the IP over ATM WG and because of an Area
Director policy to create working groups that focus on specific issues rather
than on general topics. The mail list will continue to be maintained, and
RFCs which are on the standards track will be shepherded through by email.
These RFCs include...
o Multiprotocol over Frame Relay
o Inverse ARP
o Multiprotocol over X.25
Please let me know if there are other RFCs that are should be listed.
There was some recent email to the effect that IPLPDN solved the easy
problems and punted on the hard ones. This criticism of IPLPDN is not
really troubling because I am confident of the quality of work done by
the group. I owe it to my colleagues in the group, though, to respond.
IPLPDN dealt with problems that *had* to be solved to enable near-term,
interoperable implementations of virtual private networks over public,
switched data services. We produced excellent work that has been
widely accepted and implemented. You would be hard pressed to find
a vendor of SMDS and Frame Relay equipment who does not implement
RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been
adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground-
breaking work on address resolution in large environments. The work
on Shortcut Routing and Directed ARP has advanced the understanding
of people who are now participating in the IP over ATM and ROLC WGs.
Finally, we went a long way towards nailing down "multiprotocol over
circuit switched services" (included circuit ISDN), and this work
should be completed soon in the PPP group.
This recent criticism is unfortunate, and I'm sorry that we are ending on
a bit of a sour note. But I'm confident that the work done by IPLPDN will
continue to have value and that these comments will be recognized as
misplaced. IPLPDN was a great group that stayed focused on solving technical
problems. It was terrific fun, and I'm glad to have had the chance to
participate.
George Clapp
voice: 708-248-6507
fax: 708-248-3996
email: clapp at ameris.center.il.ameritech.com
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;23 Aug 1993 07:26:25 U
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28267;
23 Aug 93 9:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220;
23 Aug 93 9:52 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481;
23 Aug 93 9:52 EDT
Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13)
id <AA03534>; Mon, 23 Aug 1993 06:53:15 -0700
Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef)
id AA13355; Mon, 23 Aug 93 08:47:34 -0500
Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6)
id <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; Mon, 23 Aug 93 08:52 CDT
Message-Id: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
Date: Mon, 23 Aug 93 8:52:00 CDT
Cc: IP over ATM WG <atm at sun.com>, ietf-ppp at ucdavis.edu, rolc at network.com,
IETF <ietf at isi.edu>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00576;
23 Aug 93 19:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00572;
23 Aug 93 19:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02392;
23 Aug 93 19:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00494;
23 Aug 93 19:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ac00475;
23 Aug 93 19:17 EDT
Received: from cpmx.SAIC.COM by CNRI.Reston.VA.US id aa02122;
23 Aug 93 19:11 EDT
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c795032025730; Mon, 23 Aug 93 16:18:11 -0700
Date: 23 Aug 1993 12:53:18 U
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: QM Administrator <QM_Administrator at cpqm.saic.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
CC: IETF <ietf at isi.edu>, ietf-ppp at ucdavis.edu, IP over ATM WG <atm at sun.com>,
rolc at network.com
Message-ID: <9308231911.aa02122 at CNRI.Reston.VA.US>
Mail*Link(r) SMTP dissolution of IPLPDN
Reflecting discussions at the last two IETF meetings, this note is to
announce that the IP over Large Public Data Networks WG has disbanded.
Unfinished work will be continued in the IP over ATM, PPP-EXT, and
Routing over Large Clouds Working Groups. IPLPDN is closing down
because issues had migrated to the IP over ATM WG and because of an Area
Director policy to create working groups that focus on specific issues rather
than on general topics. The mail list will continue to be maintained, and
RFCs which are on the standards track will be shepherded through by email.
These RFCs include...
o Multiprotocol over Frame Relay
o Inverse ARP
o Multiprotocol over X.25
Please let me know if there are other RFCs that are should be listed.
There was some recent email to the effect that IPLPDN solved the easy
problems and punted on the hard ones. This criticism of IPLPDN is not
really troubling because I am confident of the quality of work done by
the group. I owe it to my colleagues in the group, though, to respond.
IPLPDN dealt with problems that *had* to be solved to enable near-term,
interoperable implementations of virtual private networks over public,
switched data services. We produced excellent work that has been
widely accepted and implemented. You would be hard pressed to find
a vendor of SMDS and Frame Relay equipment who does not implement
RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been
adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground-
breaking work on address resolution in large environments. The work
on Shortcut Routing and Directed ARP has advanced the understanding
of people who are now participating in the IP over ATM and ROLC WGs.
Finally, we went a long way towards nailing down "multiprotocol over
circuit switched services" (included circuit ISDN), and this work
should be completed soon in the PPP group.
This recent criticism is unfortunate, and I'm sorry that we are ending on
a bit of a sour note. But I'm confident that the work done by IPLPDN will
continue to have value and that these comments will be recognized as
misplaced. IPLPDN was a great group that stayed focused on solving technical
problems. It was terrific fun, and I'm glad to have had the chance to
participate.
George Clapp
voice: 708-248-6507
fax: 708-248-3996
email: clapp at ameris.center.il.ameritech.com
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;23 Aug 1993 07:26:25 U
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28267;
23 Aug 93 9:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220;
23 Aug 93 9:52 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481;
23 Aug 93 9:52 EDT
Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13)
id <AA03534>; Mon, 23 Aug 1993 06:53:15 -0700
Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef)
id AA13355; Mon, 23 Aug 93 08:47:34 -0500
Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6)
id <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; Mon, 23 Aug 93 08:52 CDT
Message-Id: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
Date: Mon, 23 Aug 93 8:52:00 CDT
Cc: IP over ATM WG <atm at sun.com>, ietf-ppp at ucdavis.edu, rolc at network.com,
IETF <ietf at isi.edu>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00626;
23 Aug 93 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00618;
23 Aug 93 19:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02461;
23 Aug 93 19:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00603;
23 Aug 93 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ad00475;
23 Aug 93 19:17 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa02127;
23 Aug 93 19:11 EDT
Received: from cpmx.SAIC.COM by venera.isi.edu (5.65c/5.61+local-13)
id <AA20723>; Mon, 23 Aug 1993 16:12:22 -0700
Message-Id: <199308232312.AA20723 at venera.isi.edu>
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c795032025730; Mon, 23 Aug 93 16:18:11 -0700
Date: 23 Aug 1993 12:53:18 U
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: QM Administrator <QM_Administrator at cpqm.saic.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
Cc: IETF <ietf at isi.edu>, ietf-ppp at ucdavis.edu, IP over ATM WG <atm at sun.com>,
rolc at network.com
Mail*Link(r) SMTP dissolution of IPLPDN
Reflecting discussions at the last two IETF meetings, this note is to
announce that the IP over Large Public Data Networks WG has disbanded.
Unfinished work will be continued in the IP over ATM, PPP-EXT, and
Routing over Large Clouds Working Groups. IPLPDN is closing down
because issues had migrated to the IP over ATM WG and because of an Area
Director policy to create working groups that focus on specific issues rather
than on general topics. The mail list will continue to be maintained, and
RFCs which are on the standards track will be shepherded through by email.
These RFCs include...
o Multiprotocol over Frame Relay
o Inverse ARP
o Multiprotocol over X.25
Please let me know if there are other RFCs that are should be listed.
There was some recent email to the effect that IPLPDN solved the easy
problems and punted on the hard ones. This criticism of IPLPDN is not
really troubling because I am confident of the quality of work done by
the group. I owe it to my colleagues in the group, though, to respond.
IPLPDN dealt with problems that *had* to be solved to enable near-term,
interoperable implementations of virtual private networks over public,
switched data services. We produced excellent work that has been
widely accepted and implemented. You would be hard pressed to find
a vendor of SMDS and Frame Relay equipment who does not implement
RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been
adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground-
breaking work on address resolution in large environments. The work
on Shortcut Routing and Directed ARP has advanced the understanding
of people who are now participating in the IP over ATM and ROLC WGs.
Finally, we went a long way towards nailing down "multiprotocol over
circuit switched services" (included circuit ISDN), and this work
should be completed soon in the PPP group.
This recent criticism is unfortunate, and I'm sorry that we are ending on
a bit of a sour note. But I'm confident that the work done by IPLPDN will
continue to have value and that these comments will be recognized as
misplaced. IPLPDN was a great group that stayed focused on solving technical
problems. It was terrific fun, and I'm glad to have had the chance to
participate.
George Clapp
voice: 708-248-6507
fax: 708-248-3996
email: clapp at ameris.center.il.ameritech.com
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;23 Aug 1993 07:26:25 U
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28267;
23 Aug 93 9:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220;
23 Aug 93 9:52 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481;
23 Aug 93 9:52 EDT
Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13)
id <AA03534>; Mon, 23 Aug 1993 06:53:15 -0700
Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef)
id AA13355; Mon, 23 Aug 93 08:47:34 -0500
Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6)
id <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; Mon, 23 Aug 93 08:52 CDT
Message-Id: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
Date: Mon, 23 Aug 93 8:52:00 CDT
Cc: IP over ATM WG <atm at sun.com>, ietf-ppp at ucdavis.edu, rolc at network.com,
IETF <ietf at isi.edu>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00971;
23 Aug 93 20:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00967;
23 Aug 93 20:43 EDT
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa04087;
23 Aug 93 20:43 EDT
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05)
id AA06197; Mon, 23 Aug 93 16:26:11 PDT
X-Orig-Sender: ietf-ppp-request at ucdavis.edu
Received: from cpmx.saic.com by ucdavis.ucdavis.edu (4.1/UCD2.05)
id AA05484; Mon, 23 Aug 93 16:10:34 PDT
Message-Id: <9308232310.AA05484 at ucdavis.ucdavis.edu>
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c795032025730; Mon, 23 Aug 93 16:18:11 -0700
Date: 23 Aug 1993 12:53:18 U
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: QM Administrator <QM_Administrator at cpqm.saic.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
Cc: IETF <ietf at isi.edu>, ietf-ppp at ucdavis.edu, IP over ATM WG <atm at sun.com>,
rolc at network.com
Mail*Link(r) SMTP dissolution of IPLPDN
Reflecting discussions at the last two IETF meetings, this note is to
announce that the IP over Large Public Data Networks WG has disbanded.
Unfinished work will be continued in the IP over ATM, PPP-EXT, and
Routing over Large Clouds Working Groups. IPLPDN is closing down
because issues had migrated to the IP over ATM WG and because of an Area
Director policy to create working groups that focus on specific issues rather
than on general topics. The mail list will continue to be maintained, and
RFCs which are on the standards track will be shepherded through by email.
These RFCs include...
o Multiprotocol over Frame Relay
o Inverse ARP
o Multiprotocol over X.25
Please let me know if there are other RFCs that are should be listed.
There was some recent email to the effect that IPLPDN solved the easy
problems and punted on the hard ones. This criticism of IPLPDN is not
really troubling because I am confident of the quality of work done by
the group. I owe it to my colleagues in the group, though, to respond.
IPLPDN dealt with problems that *had* to be solved to enable near-term,
interoperable implementations of virtual private networks over public,
switched data services. We produced excellent work that has been
widely accepted and implemented. You would be hard pressed to find
a vendor of SMDS and Frame Relay equipment who does not implement
RFCs 1209 and 1294 (now 1490), and our work in those RFCs has been
adopted by the IP over ATM WG and ATM Forum. IPLPDN also did ground-
breaking work on address resolution in large environments. The work
on Shortcut Routing and Directed ARP has advanced the understanding
of people who are now participating in the IP over ATM and ROLC WGs.
Finally, we went a long way towards nailing down "multiprotocol over
circuit switched services" (included circuit ISDN), and this work
should be completed soon in the PPP group.
This recent criticism is unfortunate, and I'm sorry that we are ending on
a bit of a sour note. But I'm confident that the work done by IPLPDN will
continue to have value and that these comments will be recognized as
misplaced. IPLPDN was a great group that stayed focused on solving technical
problems. It was terrific fun, and I'm glad to have had the chance to
participate.
George Clapp
voice: 708-248-6507
fax: 708-248-3996
email: clapp at ameris.center.il.ameritech.com
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;23 Aug 1993 07:26:25 U
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28267;
23 Aug 93 9:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28220;
23 Aug 93 9:52 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa03481;
23 Aug 93 9:52 EDT
Received: from gateway.ameritech.com by venera.isi.edu (5.65c/5.61+local-13)
id <AA03534>; Mon, 23 Aug 1993 06:53:15 -0700
Received: from [144.157.92.11] by gateway.Ameritech.COM with SMTP (5.65/25-eef)
id AA13355; Mon, 23 Aug 93 08:47:34 -0500
Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6)
id <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; Mon, 23 Aug 93 08:52 CDT
Message-Id: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Subject: dissolution of IPLPDN
To: IPLPDN WG <iplpdn at CNRI.Reston.VA.US>
Date: Mon, 23 Aug 93 8:52:00 CDT
Cc: IP over ATM WG <atm at sun.com>, ietf-ppp at ucdavis.edu, rolc at network.com,
IETF <ietf at isi.edu>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01041;
24 Aug 93 7:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01034;
24 Aug 93 7:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03614;
24 Aug 93 7:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01018;
24 Aug 93 7:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ax00726;
24 Aug 93 7:10 EDT
Received: from relay.surfnet.nl by CNRI.Reston.VA.US id aa01734;
24 Aug 93 5:44 EDT
Received: from erasmus.rare.nl by relay.surfnet.nl with SMTP (PP)
id <25616-0 at relay.surfnet.nl>; Tue, 24 Aug 1993 10:02:05 +0200
Received: from [192.87.30.20] (macewan.rare.nl) by erasmus.rare.nl (5.65c/4.31)
with SMTP id AA03160; Tue, 24 Aug 1993 10:01:50 +0200
Message-Id: <199308240801.AA03160 at erasmus.rare.nl>
X-Mail-Interface: Macintosh Eudora (Ac.Comp.Centr.Utrecht)
Date: Tue, 24 Aug 1993 09:15:31 +0100
To: coa at rare.no, wg-all at rare.nl, newsletters at rare.nl, M2107 at eurokom.ie,
tcp-ip at nic.ddn.mil, iepg at nri.reston.va.us, ietf at nri.reston.va.us,
iucc-directors at durham.ac.uk, ccirn at lbl.gov, apccirn at aarnet.edu.au,
ripe at ripe.net, ifip65-prog at ics.uci.edu, ifip-gtwy at ics.uci.edu,
mhsnews at ics.uci.edu, isoc-interest at relay.sgi.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: bersee at rare.nl
Subject: Call for Papers iNET'94/JENC5
(Version 2.5 of August 3, 1993)
CALL FOR PAPERS
INET '94, the Annual Conference of the Internet Society
held in conjunction with the
5th Joint European Networking Conference (JENC5)
Jointly organized by RARE and the Internet Society
Prague, Czech Republic, June 13-17, 1994
The Internet Society (ISOC) and Reseaux Associes pour la Recherche
Europeenne (RARE) have joined forces to organize a global networking
conference. It will take place on 13 - 17 June 1994, in Prague, the
capital of the Czech Republic. Focusing on worldwide issues of com-
puter-based networking, the goal of the conference is to bring together
individuals from academia, industry and government who are involved
with planning, developing, implementing, managing, funding, and using
national, regional and international research, academic, and commercial
computer networks.
The official language of the conference is English. Possible topics for
paper submission include but are not limited to the following:
1. Network Technology: Advances in the Network Technology Base
- Progress towards international open network protocols
- Security, management and authentication in managing networks
- Transmission, routing, and transport technologies
- Technologies of the '90s and 21st century
- Very high speed networks
- LAN/WAN integration and interworking
- Support for mobility
2. Network Engineering and Operation: Building and Operating the
Global Infrastructure
- Application of network technology to provide networking services
- Interoperability among existing national and international networks
- Network management systems and methods
- Reliability and performance engineering
- Issues related to scaling
- Emergency response organizations and support
- Resource allocation and control
3. Distributed Applications and Their Enabling Technologies
- Collaboration technologies
- Multimedia issues
- Mail and directory services
- Workstation teleconferencing
- Computer supported collaborative work
- Interoperability of application services
- Management protocols, systems and methods for distributed
applications
- Security aspects of distributed applications
- Distributed application development environments
- Visions for the future of internationalized services
(application platforms, functionality and tools)
4. Support and Training for International Communities of Interest
- Support of international collaboration
- Globalization of user support services (including support for multiple
languages and character sets in applications and information systems)
- Access to scientific papers and data across national boundaries
- Supercomputing
- High energy physics, atmospheric modeling, and other scientific
applications
- Education/distance learning
- Medical research and clinical applications
- Libraries
- Work and play in Cyberspace: How networks are changing the
social nature of work and play
- Networking and the arts
- High payoff application areas to support national and
international development
- Tools for user education and training
5. User Information
- Networked information retrieval
- User documentation
- Navigation services
- Document delivery services
- Library services
6. Regional Issues: Networking Around the Globe
- Africa
- Asia-Pacific Rim
- Former Soviet Republics
- Latin America
- North America
- Western and Central Europe
7. Policy Issues: Governance, Management, and Financing of
International Networks
- Globalization of services
- Commercialization, privatization and public access
- Coordination of international resources
- Copyright and intellectual property rights
- Appropriate use and speech restrictions
- International security policy
- Privacy and data protection
- Telecommunications policy
- Enhancing information and coordination between network
users/providers and suppliers/policy makers
- Interworking issues between commercial and academic
network providers
Information for Paper Submission:
All papers must be written in English. Electronic submission is highly
recommended.
- ASCII or uuencoded PostScript(R):
send by e-mail to <inet-jenc-submit at rare.nl>
- PostScript documents:
send by anonymous FTP to "erasmus.rare.nl" (IP address 192.87.30.2),
into directory "pub/inet-jenc/submit".
Please note that files deposited in this directory can only be written
once and cannot be deleted afterwards.
Should electronic submission be impossible, please submit 6 copies of
double-spaced full paper manuscript (maximum of 4000 words) with an
abstract to the INET-JENC Secretariat at the address given below.
Demonstrations
There will be the opportunity for participants to present their projects
or activities in the form of a demonstration. Proposed demonstrations
should be documented with a description not exceeding one page.
Important dates
- December 15, 1993 : Full manuscript due
- December 15, 1993 : Proposals for demonstrations due
- March 1, 1994 : Notification of acceptance to authors
- April 11, 1994 : Camera-ready papers due
Publications
Conference proceedings containing full papers will handed out to the
participants. A selection of the best papers will be published as a
special issue of Computer Networks and ISDN Systems.
Network Technology Training Workshop
A workshop on the installation and use of networking technology is
planned to take place adjacent to the conference week. Travel and
tuition support may be available for selected attendees. Additional
information will be forthcoming.
Tutorials
Tutorials are planned to be held on June 13 and 14, 1994.
Working Group Presentations
There will be provisions for presentations describing the activities in
RARE Working Groups and IETF Areas.
Points of Contact
Conference Chair : Geoff Manning <GM1 at ib.rl.ac.uk>
Program Chair : Bernhard Plattner <plattner at komsys.tik.ethz.ch>
Program Chair Deputy : Hannes P. Lubich <lubich at komsys.tik.ethz.ch>
Local Organization Chair : Jan Gruntorad <tkjg at earn.cvut.cs>
Internet Society Liaison : Lawrence H. Landweber <landweber at cs.wisc.edu>
RARE Liaison : Tomaz Kalin <kalin at rare.nl>
General Inquiries
To be added to the conference e-mail distribution list send a message to:
Internet : inet-jenc-request at rare.nl
X.400 : C=nl; ADMD=400net; PRMD=surf; O=rare; S=inet-jenc-request
For further information contact:
INET-JENC Secretariat
c/o RARE Secretariat
Singel 466-468
NL-1017 AW AMSTERDAM
Tel. : +31 20 639 1131
Fax : +31 20 639 3289
Internet : inet-jenc-sec at rare.nl
X.400 : C=nl; ADMD=400net; PRMD=surf; O=rare; S=inet-jenc-sec
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01800;
24 Aug 93 8:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01796;
24 Aug 93 8:26 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa04830;
24 Aug 93 8:26 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA15043; Tue, 24 Aug 93 07:27:35 CDT
Received: by hemlock.cray.com
id AA15019; 4.1/CRI-5.6; Tue, 24 Aug 93 07:27:30 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
id AA15013; 4.1/CRI-5.6; Tue, 24 Aug 93 07:27:26 CDT
Received: from UICVM.UIC.EDU by cray.com (4.1/CRI-MX 2.19)
id AA15032; Tue, 24 Aug 93 07:27:23 CDT
Message-Id: <9308241227.AA15032 at cray.com>
Received: from VM1.LCC.UFMG.BR by UICVM.UIC.EDU (IBM VM SMTP V2R1)
with BSMTP id 8212; Tue, 24 Aug 93 07:26:57 CST
Received: from BRUFMG (NJE origin SIDEM at BRUFMG) by VM1.LCC.UFMG.BR (LMail
V1.1d/1.7f) with BSMTP id 2865; Tue, 24 Aug 1993 09:26:24 -0300
Date: Tue, 24 Aug 93 09:25:53 BSC
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Euzimar M. Leite" <SIDEM%vm1.lcc.ufmg.br at uicvm.uic.edu>
To: telnet-ietf at cray.com
HELP
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06108;
24 Aug 93 12:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06101;
24 Aug 93 12:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12436;
24 Aug 93 12:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06089;
24 Aug 93 12:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06041;
24 Aug 93 12:43 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa12134;
24 Aug 93 12:43 EDT
Received: by trystero.malamud.com
(5.65/IDA-93081802) id AA00613; Tue, 24 Aug 93 12:46:24 -0400
Date: Tue, 24 Aug 93 12:46:24 -0400
Message-Id: <9308241646.AA00613 at trystero.malamud.com>
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: carl at town.hall.org
Org: Internet Multicasting Service
Role: Secretariat for the TPC.INT Subdomain
Subject: TPC.INT Gala and Live Demonstration
Greetings -
The TPC.INT Subdomain would like to invite you to participate
in a live demonstration of remote printing. Marshall T. Rose
and I will be presenting a description of remote printing on
global facsimile devices at INTEROP 93 August. We will be
trying to convince several hundred skeptical industry executives
and members of the press that the Internet exists and that remote
printing works. We would like to ask you for your help in getting
that message through.
In addition to the balloons, buttons, t-shirts, and other
aspects of this dignified demonstration (;-), there will be
four fax machines in the ballroom. We'd like you to send in
your 1-PAGE message. The fabulous TPC.INT Tabulating Team will
keep track of incoming messages and present periodic reports
to the distinguished audience.
Address your message to the following address:
To: remote-printer.Hello_World at 7.5.7.6.2.4.4.5.1.4.1.tpc.int
NON-US MESSAGES ARE PARTICULARLY WELCOME!!
The circus-like atmosphere will be used to make some very
serious points. Marshall and I will be discussing the economic
model that will allow this project to scale and will be announcing
several commercial organizations that will be joining the TPC.INT
subdomain to provide service to the Internet community. Internet
Drafts and RFCs on the topic will be out soon.
The two-hour lecture will be held at 7:30-9:30PM on
Weds. August 25 in the Presidio Ballroom of the San
Francisco Marriott. If you are in town, please stop by!
No badges are needed.
Please join us in this exciting demonstration of the power of
general-purpose infrastructure like the Internet.
Regards,
Carl Malamud
Internet Multicasting Service
For more information on remote printing, send mail to tpc-faq at town.hall.org
For coverage for remote printing, send mail to tpc-coverage at town.hall.org
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07261;
24 Aug 93 14:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15602;
24 Aug 93 14:16 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07242;
24 Aug 93 14:16 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07123;
24 Aug 93 14:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atm at sun.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-atm-classic-ip-02.txt
Date: Tue, 24 Aug 93 14:11:59 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308241412.aa07123 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IP Over Asynchronous Transfer
Mode Working Group of the IETF.
Title : Classical IP and ARP over ATM
Author(s) : M. Laubach
Filename : draft-ietf-atm-classic-ip-02.txt
Pages : 14
This memo describes an initial application of classical IP and ARP in an
Asynchronous Transfer Mode (ATM) network environment configured as a
Logical IP Subnetwork (LIS) as described below and in RFC1209. This
document does not preclude the subsequent development of ATM technology
into areas other than an LIS; specifically, as single ATM networks grow to
replace many ethernet local LAN segments and as these networks become
globally connected, the application of IP and ARP will be treated
differently. This memo considers only the application of ATM a as a direct
replacement for the "wires" and local LAN segments connecting IP
end-stations and routers. Issues raised by MAC level bridging are beyond
the scope of this paper.
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-atm-classic-ip-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-atm-classic-ip-02.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-atm-classic-ip-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atm-classic-ip-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08623;
24 Aug 93 15:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08616;
24 Aug 93 15:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18599;
24 Aug 93 15:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08604;
24 Aug 93 15:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08538;
24 Aug 93 15:17 EDT
Received: from is.internic.net by CNRI.Reston.VA.US id aa18449;
24 Aug 93 15:17 EDT
Received: by is.internic.net (4.1/SMI-4.1)
id AA05549; Tue, 24 Aug 93 12:17:57 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Pushpendra Mohta <pushp at is.internic.net>
Message-Id: <9308241917.AA05549@ is.internic.net>
Subject: [InterNIC] Information Service Manager Position
To: ietf at CNRI.Reston.VA.US
Date: Tue, 24 Aug 93 12:17:56 PDT
X-Mailer: ELM [version 2.3 PL11]
Attached is a announcement for the position of the
InterNIC Information Services Manager based in San Diego, CA.
Please note the contact information at the end of the message.
Further information about the InterNIC can be obtained by
connecting via anonymous ftp or gopher to is.internic.net
Apologies if you see multiple copies.
Regards
--pushpendra
Pushpendra Mohta pushp at internic.net +1 619 455 3908
Director of Technology
InterNIC IS +1 800 876 2373
Management Opportunity
InterNIC Information Services Manager
General Atomics' Advanced Computing Division invites applications
and nominations for the position of Manager to implement,
coordinate, and manage a National Science Foundation supported
project to provide Information Services to Internet users, regional
and academic network information centers (NIC's). The Manager is
responsible for the implementation and overall project coordination
of service in cooperation with two additional NSF funded partners,
for the entire InterNIC project. The primary objective of the
program is provide leadership to the national networking community
in the development of the National Information Infrastructure (NII)
and the National Research and Education Network (NREN).
The InterNIC Information Services Manager will have the opportunity
to incorporate both his or her personal vision and that of other
community leaders in the implementation of creative and innovative
services for all segments of the Internet community. Extensive
interaction with individuals and groups from all aspects of
networking and networked information will be encouraged. The
successful candidate will provide a leadership role in the network
information services community.
The successful candidate will be innovative and must build new
opportunities into the InterNIC business plan to increase the
potential revenues both from the NSF and from products and services
made available to the general networking user community. It is
essential to develop a business plan encompassing the next 5 years
which generates additional revenue to support Internic services.
Responsibilities will include developing the overall business
strategy for InterNIC, managing a staff of 10-20 employees,
preparing and managing the annual budget, convening the InterNIC
Liaison Council, and serving as liaison with NSF officials, principal
partners, SDSC and GA staff as well as with the Internet leadership
organizations.
Minimum Qualifications:
Bachelors degree and 10 years of experience in a field related to
computers or networking or equivalent experience with emphasis on
computer networking environments, especially the Internet; or
Masters degree or above with 5 years experience in field related to
computers or networking or equivalent experience with emphasis on
computer networking environments, especially the Internet.
5 years experience in managing NSF grants.
5 years experience in managing people.
National recognition in the Internet community
Good writing skills.
Resumes should be sent by Friday, Sept 10, 1993 to the attention
of:
Bob Randall, Exective Director, Network Programs, General Atomics
via email: jobs at is.internic.net
via fax : +1 619 455 3990
via US Mail: PO BOX 85608, San Diego, CA 92186-9784
via Fedex: 3483 Dunhill, San Diego, CA 92121
The InterNIC Information Services can be reached at +1 800 444 4345
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09694;
24 Aug 93 16:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21366;
24 Aug 93 16:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09681;
24 Aug 93 16:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09543;
24 Aug 93 16:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: pip at thumper.bellcore.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pip-processing-02.txt
Date: Tue, 24 Aug 93 16:24:29 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308241624.aa09543 at IETF.CNRI.Reston.VA.US>
--NextPart
Note: This Internet-Draft reflects only minor editorial changes since
the previous version.
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the P. Internet Protocol Working
Group of the IETF.
Title : Pip Header Processing
Author(s) : P. Francis
Filename : draft-ietf-pip-processing-02.txt
Pages : 17
Pip is an internet protocol intended as the replacement for IP version 4.
Pip is a general purpose internet protocol, designed to handle all
forseeable internet protocol requirements. This specification defines the
Pip header processing for Routers and Hosts.
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-pip-processing-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-pip-processing-02.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pip-processing-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pip-processing-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09750;
24 Aug 93 16:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21383;
24 Aug 93 16:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09726;
24 Aug 93 16:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09580;
24 Aug 93 16:25 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-pppext-sonet-01.txt
Date: Tue, 24 Aug 93 16:25:49 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308241625.aa09580 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP over SONET/SDH
Author(s) : W. Simpson
Filename : draft-ietf-pppext-sonet-01.txt
Pages : 5
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of PPP over Synchronous Optical Network
(SONET) and Synchronous Digital Heirarchy (SDH) circuits.
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-sonet-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-pppext-sonet-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-sonet-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-sonet-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09752;
24 Aug 93 16:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21384;
24 Aug 93 16:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09728;
24 Aug 93 16:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09614;
24 Aug 93 16:26 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-heinanen-nhrp-00.txt
Date: Tue, 24 Aug 93 16:26:20 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308241626.aa09614 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : NBMA Next Hop Resolution Protocol (NHRP)
Author(s) : J. Heinanen
Filename : draft-heinanen-nhrp-00.txt
Pages : 11
This document describes the NBMA Next Hop Resolution Protocol (NHRP). NHRP
can be used by a source terminal (host or router) connected to a
Non-Broadcast, Multi-Access link layer (NBMA) network to find out the IP
and NBMA addresses of the "NBMA next hop" towards a destination terminal.
The NBMA next hop is the destination terminal itself, if the destination is
connected to the NBMA network. Otherwise, it is the egress router from the
NBMA network that is "nearest" to the destination terminal. Although this
document focuses on NHRP in the context of IP, the technique is applicable
to other network layer protocols as well.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-heinanen-nhrp-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-heinanen-nhrp-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-heinanen-nhrp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-heinanen-nhrp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10603;
24 Aug 93 17:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10596;
24 Aug 93 17:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23826;
24 Aug 93 17:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10584;
24 Aug 93 17:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10555;
24 Aug 93 17:33 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa23778;
24 Aug 93 17:33 EDT
Received: by ginger.lcs.mit.edu
id AA14975; Tue, 24 Aug 93 17:33:59 -0400
Date: Tue, 24 Aug 93 17:33:59 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9308242133.AA14975 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Aiieee, run for your lives....
Cc: jnc at ginger.lcs.mit.edu
Aiiiieeee, run for your lives, the Great Unwashed Masses are coming! For those
of you who aren't capitalist pigs (i.e. readers of the Wall Street Journal
:-), if you look on the *front page* of the second section of today's WSJ, at
the very *top of the page* is the *giant headline*:
"Cable Company Plans to Connect to the Internet"
Yes. *Our* Internet. If you read on, it talks about how Continental Cablevision
is going to sell a service, in partnership with PSI, where you use a special
modem to plug your PC into CC's cable systems, bypassing the RBOC's, at speeds
of up to 10 Mbits/sec; it's quite a long article.
Hmm, we better get TCP/IP ready for Prime Time. One amusing thing: they
describe the Internet as "information pathway to millions of personal-computer
users worldwide". Makes it sound like we all run MS-DOS...
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10747;
24 Aug 93 18:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10740;
24 Aug 93 18:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24686;
24 Aug 93 18:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10726;
24 Aug 93 18:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10698;
24 Aug 93 17:58 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa24631;
24 Aug 93 17:58 EDT
Received: by trystero.malamud.com
(5.65/IDA-93081802) id AA01520; Tue, 24 Aug 93 18:01:32 -0400
Date: Tue, 24 Aug 93 18:01:32 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at trystero.malamud.com>
Message-Id: <9308242201.AA01520 at trystero.malamud.com>
To: ietf at CNRI.Reston.VA.US, tpc-rp at aarnet.edu.au
Subject: When to start faxing ....
John Curran kindly pointed out that my message requesting
email to a fax number was ambigious in that it didn't say
*when* to start. The answer ... now. We'd like to have
full send queues when the BOF starts at 7:30 PM.
Send your messages in to:
To: remote-printer.Hello_World at 7.5.7.6.2.4.4.5.1.4.1.tpc.int
You can send us whatever messages you feel are appropriate,
though we do ask you to keep it down to one page.
Thanks!
Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11309;
24 Aug 93 18:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11302;
24 Aug 93 18:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25730;
24 Aug 93 18:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11290;
24 Aug 93 18:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11255;
24 Aug 93 18:43 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa25680;
24 Aug 93 18:43 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA07270; Tue, 24 Aug 93 18:44:12 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA22685; Tue, 24 Aug 93 18:46:39 EDT
Message-Id: <9308242246.AA22685 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Aiieee, run for your lives....
In-Reply-To: Your message of "Tue, 24 Aug 93 17:33:59 EDT."
<9308242133.AA14975 at ginger.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 24 Aug 93 18:46:39 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
"Ten Million bits per second - Information superhighway speeds". I guess
expectations must be dropping:-).
Simon // who can't even get cablevision to carry the SCI-FI channel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11630;
24 Aug 93 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11623;
24 Aug 93 19:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26718;
24 Aug 93 19:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11611;
24 Aug 93 19:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11587;
24 Aug 93 19:24 EDT
Received: from genesis.mcs.com by CNRI.Reston.VA.US id aa26671;
24 Aug 93 19:24 EDT
Received: by genesis.mcs.com (/\==/\ Smail3.1.28.1 #28.12)
id <m0oV7af-000ZDaC at genesis.mcs.com>; Tue, 24 Aug 93 18:15 CDT
Message-Id: <m0oV7af-000ZDaC at genesis.mcs.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Karl Denninger <karl at genesis.mcs.com>
Subject: Re: Aiieee, run for your lives....
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Date: Tue, 24 Aug 1993 18:15:48 -0500 (CDT)
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
In-Reply-To: <9308242133.AA14975 at ginger.lcs.mit.edu> from "Noel Chiappa" at Aug 24, 93 05:33:59 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 3503
> Aiiiieeee, run for your lives, the Great Unwashed Masses are coming! For those
> of you who aren't capitalist pigs (i.e. readers of the Wall Street Journal
> :-), if you look on the *front page* of the second section of today's WSJ, at
> the very *top of the page* is the *giant headline*:
>
> "Cable Company Plans to Connect to the Internet"
>
>Yes. *Our* Internet. If you read on, it talks about how Continental Cablevision
> is going to sell a service, in partnership with PSI, where you use a special
> modem to plug your PC into CC's cable systems, bypassing the RBOC's, at speeds
> of up to 10 Mbits/sec; it's quite a long article.
>
> Hmm, we better get TCP/IP ready for Prime Time. One amusing thing: they
> describe the Internet as "information pathway to millions of personal-computer
> users worldwide". Makes it sound like we all run MS-DOS...
Yeah, there are a few hitches though.
1: Is this the thing from the folks in California or another
"standard"? Does this make at least two commercial encoding and
other formats that are now in use? Unless I read this wrong, it
certainly might.
2: What's the back-channel? If this is the one we've heard about
before it's a dial-up. Ok, so you get your Internet for your
$70-100 PLUS the cost of a dial-up line to get packets <back> into
the system. This is fine if you're an information <consumer>, it
bites if you're a <provider>. Don't say "the cable is bidirectional".
It isn't for economic reasons in nearly <all> cable systems today.
Therefore, either someone is spending a <ton> of money to retrofit
the distribution amps (at minimum) or you still need the phone line,
which is nice but slow, and costs more money to use.
3: What's the service behind it? Is this a data stream source? If so
it might interest <me> personally but probably not the serious
majority of folks. Who holds your email, news, etc? You still need
a host system - either yours or someone else's. I agree that for
telecommuting or the serious hacker this could be very, very nice.
4: If the answer to (3) is "hi, we just dumped 500,000 new users on the
net with nowhere to go" you're going to see some serious scrambling.
Current midlevel backbone traffic levels are pretty well understood.
Joe PC downloading the entire contents of CICA via FTP to his
house, multiplied by 500,000 users, is going to change significantly
the load levels experienced by the midlevel connectivity providers.
This could get politically interesting within the communities.
I still don't see how PSI can do this. Their major cost center isn't local
lines, it is long distance and (to a degree) equipment. Those charges aren't
changed by using the cable system as a distribution media to solve the "last
mile" problem.
I don't care about the $150 leased line, it is the $1k monthly access charge
that costs <real> money. If they really think they can do that for $70 then
either (1) something funny is going on (ie: they have another way to pay for
this and are willing to sell it at a loss), (2) its not really what you
think it is -- there is a catch, or (3) they have solved the inter-LATA
problem somehow and you're going to see a bunch of other companies like
Alternet either figure it out fast as well -- or die.
--
Karl Denninger (karl at genesis.MCS.COM) | You can never please everyone except
Modem Access: [+1 312 248-0900] | by bankrupting yourself.
Voice & FAX: [+1 312 248-8649] | Internet in Chicago; a MCSNET first!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11901;
24 Aug 93 20:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11894;
24 Aug 93 20:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27754;
24 Aug 93 20:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11872;
24 Aug 93 20:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11826;
24 Aug 93 20:05 EDT
Received: from vnet.ibm.com by CNRI.Reston.VA.US id aa27729; 24 Aug 93 20:05 EDT
Received: from RALVM14 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 2543;
Tue, 24 Aug 93 15:19:06 EDT
Date: Tue, 24 Aug 93 15:19:25 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Layne 543-9182 <LAYNE at ralvm14.vnet.ibm.com>
To: ietf at CNRI.Reston.VA.US
Subject: testing
Message-ID: <9308242005.aa27729 at CNRI.Reston.VA.US>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11914;
24 Aug 93 20:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11906;
24 Aug 93 20:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27762;
24 Aug 93 20:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11871;
24 Aug 93 20:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11832;
24 Aug 93 20:05 EDT
Received: from vnet.ibm.com by CNRI.Reston.VA.US id aa27733; 24 Aug 93 20:05 EDT
Received: from RALVM14 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 2794;
Tue, 24 Aug 93 15:50:14 EDT
Date: Tue, 24 Aug 93 15:48:58 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Bill Layne (543-9182 T/L - 441)" <LAYNE at ralvm14.vnet.ibm.com>
To: ietf at CNRI.Reston.VA.US
Subject: RMON Token Ring MIB
Message-ID: <9308242005.aa27733 at CNRI.Reston.VA.US>
Regarding the Token Ring Source Routing Group:
The manner in which an manager configures the
sourceRoutingStatsEntry seems to be unnecessarily
awkward as compared to the other RMON
groups. According to the draft document, the
manager cannot change the sourceRoutingStatsStatus
to 'valid' until the sourceRoutingStatsRingNumber
object exists. This requires one of two approaches
for interoperating with this group:
1. After setting up the entry ( setting the status
to 'create request' and the ownerstring ), the
manager has to put itself into a loop to
wait on the RingNumber object. Once it exists,
the Status is set to 'valid' and the agent
proceeds to collecting the requested data.
2. The manager always assumes that the agent will
initialize with the sourceRoutingStatsEntry
preconfigured. Therefore, it uses the agent
default ... the 'monitor' entry.
Given that there is no requirement for an agent to
initialize with default tables, the manager would
have to implement both of the above techniques.
We suggest that the working group consider requiring
the agent to turn the EntryStatus to valid without
further interaction with the manager. This would
allow the agent to begin data collection as soon
it determines the ring number.
Bill Layne
IBM
layne at ralvm14.vnet.ibm.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12262;
24 Aug 93 21:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12255;
24 Aug 93 21:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29258;
24 Aug 93 21:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12243;
24 Aug 93 21:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12218;
24 Aug 93 21:16 EDT
Received: from [132.198.2.7] by CNRI.Reston.VA.US id aa29218;
24 Aug 93 21:16 EDT
Received: by sadye.emba.uvm.edu id AA16652
(5.65/1.23); Tue, 24 Aug 93 21:16:18 -0400
Date: Tue, 24 Aug 93 21:16:18 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: wollman at uvm-gen.emba.uvm.edu
Message-Id: <9308250116.AA16652 at sadye.emba.uvm.edu>
To: Karl Denninger <karl at genesis.mcs.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Aiieee, run for your lives....
In-Reply-To: <m0oV7af-000ZDaC at genesis.mcs.com>
References: <9308242133.AA14975 at ginger.lcs.mit.edu>
<m0oV7af-000ZDaC at genesis.mcs.com>
Disclaimer: I don't know anything about the proposed service, but the
former site of ``The Campus Network'' (you know, the one that's always
down and people are asking you to fix for free...) is about twenty
feet away, and so I think I must respond.
<<On Tue, 24 Aug 1993 18:15:48 -0500 (CDT), Karl Denninger <karl at genesis.mcs.com> said:
> 1: Is this the thing from the folks in California or another
> "standard"? Does this make at least two commercial encoding and
> other formats that are now in use? Unless I read this wrong, it
> certainly might.
I don't know. Here at UVM, for ten years we used a broadband system
based on equipment from Ungermann-Bass. This ran at 5Mbit/s in each
direction, and took up one TV channel on our video network for each
data stream. It started out as XNS-based (I'm told; I wasn't here at
the time), but switched to IP in its later incarnation. (I use the
past tense here, but the network is still running---last I
checked---because the people who are on it don't want to pay to
upgrade their network to something modern. It no longer forms the
campus backbone, however.)
Machines were not, for the most part, attached directly to the
broadband, but were instead either attached to a U-B NIU terminal
server, or a ``buffered repeater'' (an ordinary repeater is not
possible because of the difference in bandwidth). In our network,
most signals (except those originating in our machine room) were
injected on the ``reverse channel'' associated with each main (or
``forward'') channel; these wound their way to our headend where they
were put through a frequency translator and sent back out on the
forward channel (just like the old IBM PC Network). Our system used a
single cable for both forward and reverse, but U-B also sold
dual-cable systems. (Our two networks used CATV channels 3P and 4A,
with the reverse on channels Q and R, if I understand the labels
correctly.) The system otherwise used standard CATV-type equipment
(which you would expect, since that's what it is, essentially):
distribution amps, signal processors, distribution taps, and what have
you.
We were considering upgrading the U-B system to a newer 10-Mbit system
from Chipcom, but another campus organization put in fiber, so we
punted. We still have about 50 NIUs sitting around in our basement,
used as spares (so that we never need to buy another terminal
server...)
I can go over and kick a box in our headend which is the interface
between our network and the local cable company. If Adelphia cared to
dedicate a channel, we could probably make it work for at least a
limited area just with the equipment we have lying around.
> (3) they have solved the inter-LATA problem somehow and you're going
> to see a bunch of other companies like Alternet either figure it out
> fast as well -- or die.
Perhaps you saw another item in the news today: A Federal judge told
Bell Atlantic that they are free to start providing cable service
within their telephone service area.
-GAWollman
--
Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ...
wollman at emba.uvm.edu | Shashish is the bonding of hearts in spite of distance.
uvm-gen!wollman | It is a bond more powerful than absence. We like people
UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19457;
25 Aug 93 0:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19450;
25 Aug 93 0:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03456;
25 Aug 93 0:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19432;
25 Aug 93 0:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19410;
25 Aug 93 0:18 EDT
Received: from qualcomm.com by CNRI.Reston.VA.US id aa03430; 25 Aug 93 0:18 EDT
Received: from servo.qualcomm.com by qualcomm.com; id AA16863
sendmail 5.65/QC-main-2.1 via SMTP
Tue, 24 Aug 93 21:19:30 -0700 for ietf at CNRI.Reston.VA.US
Received: by servo; id AA15277
sendmail 5.67/QC-subsidiary-2.1
Tue, 24 Aug 93 21:19:29 -0700 for ietf at CNRI.Reston.VA.US
Date: Tue, 24 Aug 93 21:19:29 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Phil Karn <karn at qualcomm.com>
Message-Id: <9308250419.AA15277 at servo>
To: jnc at ginger.lcs.mit.edu
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: Noel Chiappa's message of Tue, 24 Aug 93 17:33:59 -0400 <9308242133.AA14975 at ginger.lcs.mit.edu>
Subject: Aiieee, run for your lives....
Calm down, Noel. What you didn't mention was that this service is
likely to sell for $70-$100/month. This isn't much cheaper than
existing dialup SLIP services, which haven't yet swamped the Internet.
True, the cable-based service is *much* faster than a telephone line
(at least in the downstream direction, dunno if this is two-way or a
telephone/cable hybrid). But at this high price, the service probably
isn't going to have much immediate appeal beyond hard-core
can't-get-enough-at-work Internet weenies like you and me.
When they offer the Internet as a standard part of basic cable
service, THEN you can panic.
Phil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19702;
25 Aug 93 0:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19695;
25 Aug 93 0:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04489;
25 Aug 93 0:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19674;
25 Aug 93 0:49 EDT
Received: from ibm.cl.msu.edu by IETF.CNRI.Reston.VA.US id aa19652;
25 Aug 93 0:48 EDT
Received: from MSU.BITNET by msu.edu (IBM VM SMTP V2R2) with BSMTP id 4090;
Wed, 25 Aug 93 00:50:15 EDT
Received: by MSU (Mailer R2.08 PTF008) id 8636; Wed, 25 Aug 93 00:50:15 EDT
Date: Wed, 25 Aug 93 00:43:13 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Richard Wiggins <WIGGINS at msu.edu>
Subject: Re: Aiieee, run for your lives....
To: Phil Karn <karn at qualcomm.com>, ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: Your message of Tue, 24 Aug 93 21:19:29 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
Message-ID: <9308250048.aa19652 at IETF.CNRI.Reston.VA.US>
It has occurred to me more than once that Gopher / WWW and even WAIS
are appropriate models for "channel surfing" in a 500 channel CATV
universe. Amazing to see the whole Internet offered as a service.
Maybe we'll have remote controls with built-in Gopher menus soon.
It's impossible to evaluate the impact of this in terms of the
resources you find on today's Internet. This could be an important
force for creating multimedia MUDs, IRC, and Usenet News. And
video games and the 900 industry tell us lots of folks *will*
pay $70 or more per month for certain kinds of communication.
/Rich Wiggins, Gopher Coordinator, Michigan State U
(PS -- is there a better forum for this thread? Com-priv?)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab00766;
25 Aug 93 2:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00759;
25 Aug 93 2:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01083;
25 Aug 93 2:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab00744;
25 Aug 93 2:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00704;
25 Aug 93 2:42 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa00964;
25 Aug 93 2:41 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af29230;
25 Aug 93 6:29 GMT
Date: Wed, 25 Aug 93 06:33 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Aiieee, run for your lives....
Message-Id: <65930825063356/0003858921NA4EM at mcimail.com>
>Aiiiieeee, run for your lives, the Great Unwashed Masses are coming! For
>those of you who aren't capitalist pigs (i.e. readers of the Wall Street
>Journal :-), if you look on the *front page* of the second section of
>today's WSJ, at the very *top of the page* is the *giant headline*:
> "Cable Company Plans to Connect to the Internet"
>Yes. *Our* Internet. If you read on, it talks about how Continental
>Cablevision is going to sell a service, in partnership with PSI, where you
>use a special modem to plug your PC into CC's cable systems, bypassing the
>RBOC's, at speeds of up to 10 Mbits/sec; it's quite a long article.
Isn't this along the lines of what we were discussing here only a couple of
weeks ago? I went off to the Big-internet list to learn what the theorists
were doing to *REALLY* fix IPv4 and things kind of quited down here. But
the issue did not go away. The Internet needs to get ready for some real
usage.
>Hmm, we better get TCP/IP ready for Prime Time. One amusing thing: they
>describe the Internet as "information pathway to millions of
>personal-computer users worldwide". Makes it sound like we all run
>MS-DOS...
But aren't UNIX workstations 'personal-computers' too? Just a different OS
from the majority of single user systems in existance today? Maybe we
should stop saying Personal Computers or UNIX workstations, or whatever and
create yet another BUZZ WORD: Single User Systems, or SUSs ;-}>
And if this is 'something of concern'. Wait until the millions of Segas and
Nintedos are ready to use this feature as well!
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02099;
25 Aug 93 8:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02092;
25 Aug 93 8:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07523;
25 Aug 93 8:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02079;
25 Aug 93 8:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02035;
25 Aug 93 8:27 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa07414; 25 Aug 93 8:27 EDT
Received: by ftp.com
id AA12387; Wed, 25 Aug 93 08:28:19 -0400
Date: Wed, 25 Aug 93 08:28:19 -0400
Message-Id: <9308251228.AA12387 at ftp.com>
To: ses at tipper.oit.unc.edu
Subject: Re: Aiieee, run for your lives....
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten at ftp.com>
Reply-To: kasten at ftp.com
Cc: jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US
> "Ten Million bits per second - Information superhighway speeds". I guess
> expectations must be dropping:-).
This is the land of the 55 Mph (um, er 88Kph) speed limit
--
Frank Kastenholz
FTP Software
2 High Street
North Andover, Mass. USA 01845
(508)685-4000
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05343;
25 Aug 93 11:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05335;
25 Aug 93 11:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12294;
25 Aug 93 11:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05319;
25 Aug 93 11:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05263;
25 Aug 93 11:04 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa12185;
25 Aug 93 11:04 EDT
Received: by ginger.lcs.mit.edu
id AA20713; Wed, 25 Aug 93 11:04:44 -0400
Date: Wed, 25 Aug 93 11:04:44 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9308251504.AA20713 at ginger.lcs.mit.edu>
To: jnc at ginger.lcs.mit.edu, karn at qualcomm.com
Subject: Re: Aiieee, run for your lives....
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
Calm down, Noel.
Sorry, physically impossible! :-) Actually, the "Aiieeee" bit was just a
joke (which unfortunately obscured the message, sigh)...
What you didn't mention was that this service is likely to sell for
$70-$100/month. This isn't much cheaper than existing dialup SLIP
services, which haven't yet swamped the Internet.
I read the article, and yes, no massive wave is coming tomorrow. What I was
trying to bring out (and didn't do well, sorry everyone) was that the WSJ,
which has an influential and savvy readership, thought this was a big enough
deal to give it a really big play. Perceptions and realities are inter-related,
and while in various ways (the Gore bill, etc) the Internet has been gaining
prominence for some time, think about what the perception of the Internet must
be, to cause this kind of coverage. Will it affect the reality? Almost
certainly.
This article (regardless of the details of the actual deal being reported
therein) is to me a sign that the Internet is now a reasonably big deal to
people who control even more investment capital than governments. It's time to
get Really Serious.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05759;
25 Aug 93 11:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05752;
25 Aug 93 11:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12820;
25 Aug 93 11:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05738;
25 Aug 93 11:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05697;
25 Aug 93 11:24 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa12763;
25 Aug 93 11:24 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA23143; Wed, 25 Aug 93 11:25:02 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA06051; Wed, 25 Aug 93 11:27:30 EDT
Message-Id: <9308251527.AA06051 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: karn at qualcomm.com, ietf at CNRI.Reston.VA.US
Subject: Re: Aiieee, run for your lives....
In-Reply-To: Your message of "Wed, 25 Aug 93 11:04:44 EDT."
<9308251504.AA20713 at ginger.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 25 Aug 93 11:27:29 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
Really big play? Really big play?
Fellah, you ain't made it till you've had login instructions for your
site printed on the front page of the first section.
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06387;
25 Aug 93 11:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06372;
25 Aug 93 11:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13764;
25 Aug 93 11:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06339;
25 Aug 93 11:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06265;
25 Aug 93 11:52 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa13706;
25 Aug 93 11:52 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA18186; Wed, 25 Aug 93 08:52:47 -0700
Message-Id: <9308251552.AA18186 at Mordor.Stanford.EDU>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: karn at qualcomm.com, ietf at CNRI.Reston.VA.US
Subject: Re: Aiieee, run for your lives....
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 25 Aug 93 11:04:44 -0400. <9308251504.AA20713 at ginger.lcs.mit.edu>
Date: Wed, 25 Aug 93 08:52:47 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
---- Included message:
This article (regardless of the details of the actual deal being reported
therein) is to me a sign that the Internet is now a reasonably big deal to
people who control even more investment capital than governments. It's time
to
get Really Serious.
I guess I've never completely shaken off the influence of the '60s. It
seems to me that we should acknowledge the new mantra to dominate
technical discussions on the Internet:
Mass Market... Mass Market... Mass Market... Mass Market...
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06933;
25 Aug 93 12:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06926;
25 Aug 93 12:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14423;
25 Aug 93 12:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06900;
25 Aug 93 12:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06844;
25 Aug 93 12:11 EDT
Received: from OPAL.ACC.COM by CNRI.Reston.VA.US id aa14308; 25 Aug 93 12:11 EDT
Received: by opal.acc.com (4.1/SMI-4.0)
id AA22758; Wed, 25 Aug 93 09:11:35 PDT
Date: Wed, 25 Aug 93 09:11:35 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Art Berggreen <art at opal.acc.com>
Message-Id: <9308251611.AA22758 at opal.acc.com>
To: karl at genesis.mcs.com, wollman at uvm-gen.emba.uvm.edu
Subject: Re: Aiieee, run for your lives....
Cc: ietf at CNRI.Reston.VA.US
>I don't know. Here at UVM, for ten years we used a broadband system
>based on equipment from Ungermann-Bass. This ran at 5Mbit/s in each
>direction, and took up one TV channel on our video network for each
>data stream. It started out as XNS-based (I'm told; I wasn't here at
>the time), but switched to IP in its later incarnation. (I use the
>past tense here, but the network is still running---last I
>checked---because the people who are on it don't want to pay to
>upgrade their network to something modern. It no longer forms the
>campus backbone, however.)
>
>Machines were not, for the most part, attached directly to the
>broadband, but were instead either attached to a U-B NIU terminal
>server, or a ``buffered repeater'' (an ordinary repeater is not
>possible because of the difference in bandwidth). In our network,
>most signals (except those originating in our machine room) were
>injected on the ``reverse channel'' associated with each main (or
>``forward'') channel; these wound their way to our headend where they
>were put through a frequency translator and sent back out on the
>forward channel (just like the old IBM PC Network). Our system used a
>single cable for both forward and reverse, but U-B also sold
>dual-cable systems. (Our two networks used CATV channels 3P and 4A,
>with the reverse on channels Q and R, if I understand the labels
>correctly.) The system otherwise used standard CATV-type equipment
>(which you would expect, since that's what it is, essentially):
>distribution amps, signal processors, distribution taps, and what have
>you.
Well, trying to remember my MAP/802.4 development days...
Most of the CATV systems of the type sold by UB were "mid-split" systems.
This means that the head-end and any amplifiers are set up to carry half
the CATV channels in one direction, and the other half in the reverse.
It's my recollection that the typical Cable TV company ran a "high-split"
system where the bulk of the bandwidth was outbound (great for TV
service) and that most of the amplifiers were unidirectional.
>
>
>I can go over and kick a box in our headend which is the interface
>between our network and the local cable company. If Adelphia cared to
>dedicate a channel, we could probably make it work for at least a
>limited area just with the equipment we have lying around.
>
>> (3) they have solved the inter-LATA problem somehow and you're going
>> to see a bunch of other companies like Alternet either figure it out
>> fast as well -- or die.
>
>Perhaps you saw another item in the news today: A Federal judge told
>Bell Atlantic that they are free to start providing cable service
>within their telephone service area.
I remember hearing about a cable TV company trying to carry data a few
years ago. The local telephone company took them to court and was
able to block the service as an illegal bypass. Maybe the legal
situation has changed since then.
Art
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07515;
25 Aug 93 12:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07508;
25 Aug 93 12:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15465;
25 Aug 93 12:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07493;
25 Aug 93 12:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07420;
25 Aug 93 12:43 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa15372;
25 Aug 93 12:43 EDT
Received: by ginger.lcs.mit.edu
id AA21415; Wed, 25 Aug 93 12:44:22 -0400
Date: Wed, 25 Aug 93 12:44:22 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9308251644.AA21415 at ginger.lcs.mit.edu>
To: jnc at ginger.lcs.mit.edu, ses at tipper.oit.unc.edu
Subject: Re: Aiieee, run for your lives....
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu, karn at qualcomm.com
(Not to spin this out too long, but the coincidence is just to good to
let pass...)
Fellah, you ain't made it till you've had login instructions for your
site printed on the front page of the first section.
True! Then there's the guy who has his Internet Email address in the top item
of the "Industry Outlook" page in the front of this week's Aviation Week...
Speaking as someone who remembers the entire TCP/IP user community sitting
around a table at Lincoln Labs in 1977, this is all Really Wierd. Nothing I
ever ingested in my ill-spent youth ever felt *half* as bizarre as this...
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07723;
25 Aug 93 13:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07716;
25 Aug 93 13:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15982;
25 Aug 93 13:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07704;
25 Aug 93 13:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07662;
25 Aug 93 12:58 EDT
Received: from [192.76.177.18] by CNRI.Reston.VA.US id aa15908;
25 Aug 93 12:58 EDT
Received: from BJR.ACF.NYU.EDU by cmcl2.NYU.EDU (5.61/1.34)
id AA14834; Wed, 25 Aug 93 12:58:27 -0400
Message-Id: <9308251658.AA14834 at cmcl2.NYU.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 25 Aug 1993 13:07:58 -0500
To: Art Berggreen <art at opal.acc.com>, karl at genesis.mcs.com,
wollman at uvm-gen.emba.uvm.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bill Russell <russell at nyu.edu>
Subject: Re: Aiieee, run for your lives....
Cc: ietf at CNRI.Reston.VA.US
NYU still has a hi-split CATV plant serving 60+ buildings. It has two of
the five possible IEEE data-cahnnels active. Both are outfitted with UB
gear. One channel is a backup for the other. It also has lots of video
channels.
We are migrating away from this technology because the suppliers of the
amps, splitters, etc, told us that they were getting out of the mixed use
CATV field because there was no market. This was serveral years ago. We
bought spares to last us for several years until we are migrated. The
suppliers said they could sell us at much lower cost all of the "regular"
CATV stuff we wanted, ie, what every "real" CATV system was using. For the
understanding impaired - one way CATV.
When Hybrid and DEC announced there products, I thought, my what a concept,
use my Broadband for data, ie, what we've been doing for years. However, it
is very clear that what they are offering can't be what UB and Chipcom and
Sytek (IBM PC-LAN) were offering - full 5, 10, and 2 MB two-communication
over the CATV plant. They are offering a one-way street with a low-speed
backhaul. Not the same thing at all.
It will be nice to see what these products really are - I still have yet to
see a clear and precise description of what it is I get.
Bill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09633;
25 Aug 93 14:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09623;
25 Aug 93 14:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18925;
25 Aug 93 14:39 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09610;
25 Aug 93 14:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09530;
25 Aug 93 14:36 EDT
Received: from umd5.umd.edu by CNRI.Reston.VA.US id aa18824; 25 Aug 93 14:36 EDT
Received: by umd5.umd.edu id <AA16549 at umd5.umd.edu>; Wed, 25 Aug 93 14:37:22 -0400
Message-Id: <9308251837.AA16549 at umd5.umd.edu>
To: ietf at CNRI.Reston.VA.US
Subject: [pushp at is.internic.net (Pushpendra Mohta): Re: [InterNIC] Information Service Manager Position]
Date: Wed, 25 Aug 93 14:37:21 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike StJohns <stjohns at umd5.umd.edu>
X-Mts: smtp
Obviously a word to the wise isn't sufficient. This is NOT a valid
use of the IETF mailing list. PERIOD.
------- Forwarded Message
From: pushp at is.internic.net (Pushpendra Mohta)
Subject: Re: [InterNIC] Information Service Manager Position
To: stjohns at umd5.umd.edu (Mike StJohns)
Date: Wed, 25 Aug 93 0:07:55 PDT
Cc: pushp at is.internic.net, pushp at is.internic.net (Pushpendra Mohta)
Mike StJohns writes:
>
> Messages of the type "job offer" are not appropriate for the IETF
> mailing list - please don't do it again.
>
> Mike
>
Obviously, I disagree.
This position is to lead the entire Network Information Services effort
for the US R&E Internet, and the NSF (the sponsor) indicated it wanted
the widest eligible audience for it: the IETF audience certainly qualifies.
- --pushpendra
Pushpendra Mohta pushp at internic.net +1 619 455 3908
InterNIC Information Services pushp at sdsc.bitnet +1 800 876 2373
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10070;
25 Aug 93 15:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10063;
25 Aug 93 15:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19808;
25 Aug 93 15:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10051;
25 Aug 93 15:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10016;
25 Aug 93 14:58 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa19696; 25 Aug 93 14:58 EDT
Received: from solensky.fenway.ftp.com by ftp.com via PCMAIL with DMSP
id AA27771; Wed, 25 Aug 93 14:59:20 -0400
Date: Wed, 25 Aug 93 14:59:20 -0400
Message-Id: <9308251859.AA27771 at ftp.com>
To: jnc at ginger.lcs.mit.edu
Subject: Re: Aiieee, run for your lives....
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank T Solensky <solensky at ftp.com>
Cc: ses at tipper.oit.unc.edu, ietf at CNRI.Reston.VA.US, karn at qualcomm.com
X-Orig-Sender: solensky at ftp.com
Repository: babyoil.ftp.com
Originating-Client: fenway.ftp.com
> Date: Wed, 25 Aug 93 12:44:22 -0400
> From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
>
> .. Then there's the guy who has his Internet Email address in the top item
> of the "Industry Outlook" page in the front of this week's Aviation Week...
Or the Boston Globe:
Letters to the Editor: letters at globe.com
"Ask the Globe": ask at globe.com
-- Frank
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12418;
25 Aug 93 18:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27280;
25 Aug 93 18:42 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12406;
25 Aug 93 18:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12379;
25 Aug 93 18:38 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27214;
25 Aug 93 18:38 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA13506>; Wed, 25 Aug 1993 15:39:09 -0700
Message-Id: <199308252239.AA13506 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1494 on X.400/MIME Body Equivalences
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 25 Aug 93 15:39:01 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1494:
Title: Equivalences between 1988 X.400 and RFC-822
Message Bodies
Author: H. Alvestrand & S. Thompson
Mailbox: Harald.Alvestrand at delab.sintef.no,
sjt at gateway.ssw.com
Pages: 19
Characters: 37,273
Updates/Obsoletes: none
This document is a companion to RFC 1495, which defines the principles
behind interworking between MIME-based RFC-822 mail and X.400 mail.
This document describes the content of the, "IANA MHS/MIME Equivalence
table" referenced in the companion document, and defines the initial
configuration of this table. Mappings for new MIME content-types
and/or X.400 body part types should be registered with the Internet
Assigned Numbers Authority (IANA) to minimize redundancy and promote
interoperability.
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
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 CNRI.RESTON.VA.US. Requests to be added
to or deleted from the RFC-DIST distribution list should be sent to
RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info at ISI.EDU" with the message body
"help: ways_to_get_rfcs". For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1494.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1494.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12520;
25 Aug 93 18:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27496;
25 Aug 93 18:50 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12507;
25 Aug 93 18:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12482;
25 Aug 93 18:48 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27418;
25 Aug 93 18:48 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA13755>; Wed, 25 Aug 1993 15:49:16 -0700
Message-Id: <199308252249.AA13755 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1495 on MHS/RFC-822 Message Body Mapping
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 25 Aug 93 15:49:08 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1495:
Title: Mapping between X.400 and RFC-822 Message Bodies
Author: H. Alvestrand, S. Kille, R. Miles, M. Rose, &
S. Thompson
Mailbox: Harald.Alvestrand at delab.sintef.no,
S.Kille at ISODE.COM, rsm at spyder.ssw.com,
mrose at dbc.mtview.ca.us, sjt at gateway.ssw.com
Pages: 11
Characters: 20,071
Updates: 1327
Recently, the Internet Engineering Task Force (IETF) developed a
document called, "Multipurpose Internet Mail Extensions" or MIME (RFC
1341). The title is actually misleading. MIME defines structure for
Internet message bodies. It is not an extension to STD 11, RFC 822.
Independently of this, the International standards community developed
a different framework in 1984. This framework is known as the OSI
Message Handling System (MHS) or sometimes X.400.
Since the introduction of X.400(84), there has been work ongoing for
defining mappings between MHS and RFC 822. The most recent work in
this area is RFC 1327, which focuses primarily on translation of
envelope and headers. This document is complimentary to RFC 1327 as
it focuses on translation of the message body. The mappings defined
are largely symmetrical with respect to MIME and MHS structuring
semantics, although the MIME semantics are somewhat richer. In order
to provide for reversible transformations, MHS heading extensions are
used to carry the additional MIME semantics.
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
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 CNRI.RESTON.VA.US. Requests to be added
to or deleted from the RFC-DIST distribution list should be sent to
RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info at ISI.EDU" with the message body
"help: ways_to_get_rfcs". For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1495.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1495.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12601;
25 Aug 93 18:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27672;
25 Aug 93 18:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12589;
25 Aug 93 18:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12556;
25 Aug 93 18:54 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27592;
25 Aug 93 18:54 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA13889>; Wed, 25 Aug 1993 15:55:15 -0700
Message-Id: <199308252255.AA13889 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1496 on HARPOON
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 25 Aug 93 15:55:06 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1496:
Title: Rules for downgrading messages from X.400/88 to
X.400/84 when MIME content-types are present in
the messages
Author: H. Alvestrand, J. Romaguera & K. Jordan
Mailbox: Harald.T.Alvestrand at delab.sintef.no,
Kevin.E.Jordan at mercury.oss.arh.cpg.cdc.com,
Romaguera at netconsult.ch
Pages: 5
Characters: 8,411
Updates: 1328
Interworking between X.400(88) and X.400 (84) is achieved by RFC 1328.
That document does not describe what to do in the case where body
parts arrive at the gateway that cannot be adequately represented in
the X.400(84) system. This document describes how RFC 1328 must be
modified in order to provide adequate support for the scenarios:
SMTP(MIME) -> X.400(84), and X.400(84) -> SMTP(MIME).
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
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 CNRI.RESTON.VA.US. Requests to be added
to or deleted from the RFC-DIST distribution list should be sent to
RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info at ISI.EDU" with the message body
"help: ways_to_get_rfcs". For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1496.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1496.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12735;
25 Aug 93 19:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28006;
25 Aug 93 19:06 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12723;
25 Aug 93 19:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12693;
25 Aug 93 19:04 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27944;
25 Aug 93 19:04 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA14069>; Wed, 25 Aug 1993 16:05:21 -0700
Message-Id: <199308252305.AA14069 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1502 on X.400 Use of Extended Character Sets
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 25 Aug 93 16:05:12 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1502:
Title: X.400 Use of Extended Character Sets
Author: H. Alvestrand
Mailbox: Harald.Alvestrand at delab.sintef.no
Pages: 14
Characters: 27,976
Updates/Obsoletes: none
Since 1988, X.400 has had the capacity for carrying a large number of
different character sets in a message by using the body part
"GeneralText" defined by ISO/IEC 10021-7. Since 1992, the Internet
also has the means of passing around messages containing multiple
character sets, by using the mechanism defined in RFC 1341 (MIME).
This RFC defines a suggested method of using "GeneralText" in order
harmonize as much as possible the usage of this body part.
This is now a Proposed Standard Protocol.
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
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 CNRI.RESTON.VA.US. Requests to be added
to or deleted from the RFC-DIST distribution list should be sent to
RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info at ISI.EDU" with the message body
"help: ways_to_get_rfcs". For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1502.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1502.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12824;
25 Aug 93 19:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28189;
25 Aug 93 19:13 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12812;
25 Aug 93 19:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12778;
25 Aug 93 19:12 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa28137;
25 Aug 93 19:12 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA14176>; Wed, 25 Aug 1993 16:12:44 -0700
Message-Id: <199308252312.AA14176 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1503 on Automating Administration in SNMPv2 Manager
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 25 Aug 93 16:12:36 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1503:
Title: Algorithms for Automating Administration
in SNMPv2 Managers
Author: K. McCloghrie & M. Rose
Mailbox: kzm at hls.com, mrose at dbc.mtview.ca.us
Pages: 14
Characters: 33,542
Updates/Obsoletes: none
When a user invokes an SNMPv2 (RFC 1441) management application, it
may be desirable for the user to specify the minimum amount of
information necessary to establish and maintain SNMPv2 communications.
This RFC suggests an approach to achieve this goal.
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 CNRI.RESTON.VA.US. Requests to be added
to or deleted from the RFC-DIST distribution list should be sent to
RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info at ISI.EDU" with the message body
"help: ways_to_get_rfcs". For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1503.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1503.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00711;
26 Aug 93 3:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00707;
26 Aug 93 3:16 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa01532; 26 Aug 93 3:16 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA26035; Thu, 26 Aug 93 00:16:01 PDT
Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA09550; Thu, 26 Aug 93 00:16:07 PDT
Received: by atm.Eng.Sun.COM (4.1/SMI-4.1)
id AA12241; Thu, 26 Aug 93 00:15:01 PDT
Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1)
id AA12235; Thu, 26 Aug 93 00:15:00 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1)
id AA08945; Thu, 26 Aug 93 00:15:13 PDT
Received: from thuer.netcs.com ([192.76.152.15]) by Sun.COM (4.1/SMI-4.1)
id AA25956; Thu, 26 Aug 93 00:14:59 PDT
Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef)
id AA29699; Thu, 26 Aug 1993 09:14:30 +0200
Received: by keks.netcs.com (5.65/25-eef)
id AA08874; Wed, 25 Aug 93 09:14:26 +0200
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Oliver Korfmacher <okorf at netcs.com>
Message-Id: <9308250714.AA08874 at keks.netcs.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Date: Wed, 25 Aug 93 9:14:24 MEST
Cc: iplpdn at CNRI.Reston.VA.US, atm at sun.com, ietf-ppp at ucdavis.edu,
rolc at nsco.network.com, ietf at venera.isi.edu
In-Reply-To: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; from "George H. Clapp" at Aug 23, 93 8:52 am
X-Mailer: ELM [version 2.2 PL0]
X-Charset: ASCII
X-Char-Esc: 29
X-Orig-Sender: atm-request at atm.eng.sun.com
>
> This recent criticism is unfortunate, and I'm sorry that we are ending on
> a bit of a sour note. But I'm confident that the work done by IPLPDN will
> continue to have value and that these comments will be recognized as
> misplaced. IPLPDN was a great group that stayed focused on solving technical
> problems. It was terrific fun, and I'm glad to have had the chance to
> participate.
One point I can't resist to mention: The discussion "multiprotocol over
circuit switched ISDN" was started too late. Here, in non-US countries,
we now have a variety of methods for IP and other protocols over the ISDN.
I hope that finally ppp will be widely accepted (just to have ONE
standard, but it will now take some time to established and accepted
method). ppp may not be the most efficient method, but anyhow.
Oliver
Oliver Korfmacher (okorf at netcs.com, whois OK11)
>
> George Clapp
> voice: 708-248-6507
> fax: 708-248-3996
> email: clapp at ameris.center.il.ameritech.com
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03031;
26 Aug 93 8:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03022;
26 Aug 93 8:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08337;
26 Aug 93 8:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03005;
26 Aug 93 8:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02937;
26 Aug 93 8:56 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa08278;
26 Aug 93 8:56 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA04727; Thu, 26 Aug 93 05:57:11 -0700
Message-Id: <9308261257.AA04727 at Mordor.Stanford.EDU>
To: Mike StJohns <stjohns at umd5.umd.edu>
Cc: ietf at CNRI.Reston.VA.US, Pushpendra Mohta <pushp at is.internic.net>
Subject: Re: [pushp at is.internic.net (Pushpendra Mohta): Re: [InterNIC] Information Service Manager Position]
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 25 Aug 93 14:37:21 -0400. <9308251837.AA16549 at umd5.umd.edu>
Date: Thu, 26 Aug 93 05:57:11 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
The Internet operates without the benefit of a general enforement
method for various kinds of unacceptable behavior. This is inherent in
its lack of central authority. ("Laws" are a way of having central
authority without requiring overall central administration.)
Hence, a very, very key component to the successfull operation of the
Internet's many, large email lists is the unversal conformance to basic
matters of "etiquette". It is particularly troubling when an
organization in a major position to provide a core Internet service does
not understand the culture of mutual respect, instead feeling that it
has special privileges.
The operative test, here, is "what if everyone did this?" since I don't
believe there is any other way to decide who is and who is not
authorized to sent out advertisements. (No confusion, here. Job
announcements are a form of advertising.)
I strongly encourage other readers of this list to communicate their
views to the author of the job announcement. Their organization needs
some training.
Dave
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03514;
26 Aug 93 9:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08828;
26 Aug 93 9:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03479;
26 Aug 93 9:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03371;
26 Aug 93 9:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bgp at ans.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-bgp-mibv4-03.txt
Date: Thu, 26 Aug 93 09:12:49 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308260912.aa03371 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : Definitions of Managed Objects for the Border Gateway
Protocol (Version 4)
Author(s) : S. Willis, J. Burruss, J. Chu
Filename : draft-ietf-bgp-mibv4-03.txt
Pages : 28
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 Border Gateway 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-bgp-mibv4-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-bgp-mibv4-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-bgp-mibv4-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-mibv4-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03516;
26 Aug 93 9:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08829;
26 Aug 93 9:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03477;
26 Aug 93 9:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03355;
26 Aug 93 9:12 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-meyer-demandrouting-02.txt
Date: Thu, 26 Aug 93 09:12:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308260912.aa03355 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Routing over Demand Circuits on Wide Area Networks - RIP
Author(s) : G. M. Meyer
Filename : draft-meyer-demandrouting-02.txt
Pages : 32
Running routing protocols on connection oriented Public Data Networks, for
example X.25 packet switched networks or ISDN, can be expensive if the
standard form of periodic broadcasting of routing information is adhered
to. The high cost arises because a connection has to all practical intents
and purposes be kept open to every destination to which routing information
is to be sent, whether or not it is being used to carry user data.
Routing information may also fail to be propagated if the number of
destinations to which the routing information is to be sent exceeds the
number of channels available to the router on the Wide Area Network (WAN).
This memo defines a generalized modification which can be applied to
Bellman-Ford (or distance vector) algorithm information broadcasting
protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes
the limitations of the traditional methods described above. The routing
protocols support a purely triggered update mechanism on demand circuits on
WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-meyer-demandrouting-02.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-meyer-demandrouting-02.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-meyer-demandrouting-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-meyer-demandrouting-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03530;
26 Aug 93 9:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08845;
26 Aug 93 9:15 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03481;
26 Aug 93 9:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03418;
26 Aug 93 9:13 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-gwinn-paging-protocol-00.txt
Date: Thu, 26 Aug 93 09:13:56 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308260913.aa03418 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : SIMPLE NETWORK PAGING PROTOCOL - VERSION 1
Author(s) : A. Gwinn
Filename : draft-gwinn-paging-protocol-00.txt
Pages : 4
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-gwinn-paging-protocol-00.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-gwinn-paging-protocol-00.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-gwinn-paging-protocol-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-gwinn-paging-protocol-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09104;
26 Aug 93 14:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09097;
26 Aug 93 14:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17995;
26 Aug 93 14:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09080;
26 Aug 93 14:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09011;
26 Aug 93 14:07 EDT
Received: from spider.lloyd.COM by CNRI.Reston.VA.US id aa17974;
26 Aug 93 14:06 EDT
Received: from isaac.lloyd.COM by spider.lloyd.com (5.67/1.37)
id AA11849; Thu, 26 Aug 93 11:06:14 -0700
Date: Thu, 26 Aug 93 11:06:14 -0700
Message-Id: <9308261806.AA11849 at spider.lloyd.com>
To: Bill Russell <russell at nyu.edu>, Art Berggreen <art at opal.acc.com>,
karl at genesis.mcs.com, wollman at uvm-gen.emba.uvm.edu
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Brian Lloyd <brian at lloyd.com>
X-Sender: brian at spider.lloyd.com
Subject: Re: Aiieee, run for your lives....
Cc: ietf at CNRI.Reston.VA.US
At 13:07 8/25/93 -0500, Bill Russell wrote:
>When Hybrid and DEC announced there products, I thought, my what a concept,
>use my Broadband for data, ie, what we've been doing for years. However, it
>is very clear that what they are offering can't be what UB and Chipcom and
>Sytek (IBM PC-LAN) were offering - full 5, 10, and 2 MB two-communication
>over the CATV plant. They are offering a one-way street with a low-speed
>backhaul. Not the same thing at all.
Turn it around. Don't look at it as what you have lost, look at what has
been gained. There are lots of these one-way CATV systems out there that
aren't going to upgrade soon. What DEC and Hybrid have done is to turn
this capacity into a usable two-way digital communications channel. There
are applications that work fine in this assymetric capacity environment.
This reminds me of the "Let's Make A Deal" game show. A contestant would
play the game, "lose," e.g. not win the car, and walk away with "only" $500
or a washer/dryer. When you think about it, he/she walked in with only a
funny suit on and has actually "won," e.g. departed significantly richer
than when she/he walked in but you could never tell that from the look on
the faces or the groans from the audience. ;^)
So don't sell assymetrical capacity short. 10MB inbound with 14,400
outbound sounds like a win over symetrical 14.4/14.4 to me.
Brian Lloyd BP Lloyd & Associates, Inc.
brian at lloyd.com 3420 Sudbury Road
brian at mail.barrnet.net Cameron Park, CA 95682
(916) 676-1147 - voice (916) 676-3442 - fax
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09741;
26 Aug 93 14:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09734;
26 Aug 93 14:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18791;
26 Aug 93 14:39 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09721;
26 Aug 93 14:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab09677;
26 Aug 93 14:38 EDT
Received: from cpmx.SAIC.COM by CNRI.Reston.VA.US id aa18735;
26 Aug 93 14:38 EDT
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d04ce010413; Thu, 26 Aug 93 11:45:35 -0700
Date: 26 Aug 1993 11:27:40 +0000
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: CPSMTP01 Admin <CPSMTP01_Admin at cpqm.saic.com>
Subject: Re: [pushp at is.internic.net (
To: Mike StJohns <stjohns at umd5.umd.edu>
CC: ietf at CNRI.Reston.VA.US, Pushpendra Mohta <pushp at is.internic.net>
Message-ID: <9308261438.aa18735 at CNRI.Reston.VA.US>
Mail*Link(r) SMTP RE>[pushp at is.internic.net (
The Internet operates without the benefit of a general enforement
method for various kinds of unacceptable behavior. This is inherent in
its lack of central authority. ("Laws" are a way of having central
authority without requiring overall central administration.)
Hence, a very, very key component to the successfull operation of the
Internet's many, large email lists is the unversal conformance to basic
matters of "etiquette". It is particularly troubling when an
organization in a major position to provide a core Internet service does
not understand the culture of mutual respect, instead feeling that it
has special privileges.
The operative test, here, is "what if everyone did this?" since I don't
believe there is any other way to decide who is and who is not
authorized to sent out advertisements. (No confusion, here. Job
announcements are a form of advertising.)
I strongly encourage other readers of this list to communicate their
views to the author of the job announcement. Their organization needs
some training.
Dave
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;26 Aug 1993 06:09:49 +0000
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02947;
26 Aug 93 8:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02937;
26 Aug 93 8:56 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa08278;
26 Aug 93 8:56 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA04727; Thu, 26 Aug 93 05:57:11 -0700
Message-Id: <9308261257.AA04727 at Mordor.Stanford.EDU>
To: Mike StJohns <stjohns at umd5.umd.edu>
Cc: ietf at CNRI.Reston.VA.US, Pushpendra Mohta <pushp at is.internic.net>
Subject: Re: [pushp at is.internic.net (Pushpendra Mohta): Re: [InterNIC]
Information Service Manager Position]
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 25 Aug 93 14:37:21 -0400.
<9308251837.AA16549 at umd5.umd.edu>
Date: Thu, 26 Aug 93 05:57:11 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09934;
26 Aug 93 14:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09930;
26 Aug 93 14:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19288;
26 Aug 93 14:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09892;
26 Aug 93 14:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09888;
26 Aug 93 14:55 EDT
Received: from cpmx.SAIC.COM by CNRI.Reston.VA.US id aa19245;
26 Aug 93 14:55 EDT
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d08b0011062; Thu, 26 Aug 93 12:02:09 -0700
Date: 26 Aug 1993 11:39:16 +0000
X-Orig-Sender:iplpdn-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: CPSMTP01 Admin <CPSMTP01_Admin at cpqm.saic.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
CC: atm at sun.com, ietf-ppp at ucdavis.edu, ietf at isi.edu,
iplpdn at CNRI.Reston.VA.US, rolc at nsco.network.com
Message-ID: <9308261455.aa19245 at CNRI.Reston.VA.US>
Mail*Link(r) SMTP RE>dissolution of IPLPDN
>
> This recent criticism is unfortunate, and I'm sorry that we are ending on
> a bit of a sour note. But I'm confident that the work done by IPLPDN will
> continue to have value and that these comments will be recognized as
> misplaced. IPLPDN was a great group that stayed focused on solving technical
> problems. It was terrific fun, and I'm glad to have had the chance to
> participate.
One point I can't resist to mention: The discussion "multiprotocol over
circuit switched ISDN" was started too late. Here, in non-US countries,
we now have a variety of methods for IP and other protocols over the ISDN.
I hope that finally ppp will be widely accepted (just to have ONE
standard, but it will now take some time to established and accepted
method). ppp may not be the most efficient method, but anyhow.
Oliver
Oliver Korfmacher (okorf at netcs.com, whois OK11)
>
> George Clapp
> voice: 708-248-6507
> fax: 708-248-3996
> email: clapp at ameris.center.il.ameritech.com
>
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;26 Aug 1993 00:44:00 +0000
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717;
26 Aug 93 3:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00681;
26 Aug 93 3:14 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01472;
26 Aug 93 3:13 EDT
Received: from thuer.netcs.com ([192.76.152.15]) by venera.isi.edu
(5.65c/5.61+local-13)
id <AA12545>; Thu, 26 Aug 1993 00:14:37 -0700
Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef)
id AA29699; Thu, 26 Aug 1993 09:14:30 +0200
Received: by keks.netcs.com (5.65/25-eef)
id AA08874; Wed, 25 Aug 93 09:14:26 +0200
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Oliver Korfmacher <okorf at netcs.com>
Message-Id: <9308250714.AA08874 at keks.netcs.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Date: Wed, 25 Aug 93 9:14:24 MEST
Cc: iplpdn at CNRI.Reston.VA.US, atm at sun.com, ietf-ppp at ucdavis.edu,
rolc at nsco.network.com, ietf at isi.edu
In-Reply-To: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; from "George H.
Clapp" at Aug 23, 93 8:52 am
X-Mailer: ELM [version 2.2 PL0]
X-Charset: ASCII
X-Char-Esc: 29
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09947;
26 Aug 93 14:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09940;
26 Aug 93 14:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19304;
26 Aug 93 14:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09915;
26 Aug 93 14:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09882;
26 Aug 93 14:55 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa19228;
26 Aug 93 14:55 EDT
Received: from cpmx.SAIC.COM by venera.isi.edu (5.65c/5.61+local-13)
id <AA15591>; Thu, 26 Aug 1993 11:55:43 -0700
Message-Id: <199308261855.AA15591 at venera.isi.edu>
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d08b0011062; Thu, 26 Aug 93 12:02:09 -0700
Date: 26 Aug 1993 11:39:16 +0000
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: CPSMTP01 Admin <CPSMTP01_Admin at cpqm.saic.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Cc: atm at sun.com, ietf-ppp at ucdavis.edu, ietf at isi.edu,
iplpdn at CNRI.Reston.VA.US, rolc at nsco.network.com
Mail*Link(r) SMTP RE>dissolution of IPLPDN
>
> This recent criticism is unfortunate, and I'm sorry that we are ending on
> a bit of a sour note. But I'm confident that the work done by IPLPDN will
> continue to have value and that these comments will be recognized as
> misplaced. IPLPDN was a great group that stayed focused on solving technical
> problems. It was terrific fun, and I'm glad to have had the chance to
> participate.
One point I can't resist to mention: The discussion "multiprotocol over
circuit switched ISDN" was started too late. Here, in non-US countries,
we now have a variety of methods for IP and other protocols over the ISDN.
I hope that finally ppp will be widely accepted (just to have ONE
standard, but it will now take some time to established and accepted
method). ppp may not be the most efficient method, but anyhow.
Oliver
Oliver Korfmacher (okorf at netcs.com, whois OK11)
>
> George Clapp
> voice: 708-248-6507
> fax: 708-248-3996
> email: clapp at ameris.center.il.ameritech.com
>
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;26 Aug 1993 00:44:00 +0000
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717;
26 Aug 93 3:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00681;
26 Aug 93 3:14 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01472;
26 Aug 93 3:13 EDT
Received: from thuer.netcs.com ([192.76.152.15]) by venera.isi.edu
(5.65c/5.61+local-13)
id <AA12545>; Thu, 26 Aug 1993 00:14:37 -0700
Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef)
id AA29699; Thu, 26 Aug 1993 09:14:30 +0200
Received: by keks.netcs.com (5.65/25-eef)
id AA08874; Wed, 25 Aug 93 09:14:26 +0200
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Oliver Korfmacher <okorf at netcs.com>
Message-Id: <9308250714.AA08874 at keks.netcs.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Date: Wed, 25 Aug 93 9:14:24 MEST
Cc: iplpdn at CNRI.Reston.VA.US, atm at sun.com, ietf-ppp at ucdavis.edu,
rolc at nsco.network.com, ietf at isi.edu
In-Reply-To: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; from "George H.
Clapp" at Aug 23, 93 8:52 am
X-Mailer: ELM [version 2.2 PL0]
X-Charset: ASCII
X-Char-Esc: 29
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09963;
26 Aug 93 14:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09959;
26 Aug 93 14:59 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa19352; 26 Aug 93 14:59 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA03702; Thu, 26 Aug 93 11:56:54 PDT
Received: from atm.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA06686; Thu, 26 Aug 93 11:57:05 PDT
Received: by atm.Eng.Sun.COM (4.1/SMI-4.1)
id AA13113; Thu, 26 Aug 93 11:55:49 PDT
Received: from Eng.Sun.COM (engmail1) by atm.Eng.Sun.COM (4.1/SMI-4.1)
id AA13107; Thu, 26 Aug 93 11:55:48 PDT
Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1)
id AA08525; Thu, 26 Aug 93 11:55:53 PDT
Received: from cpmx.saic.com by Sun.COM (4.1/SMI-4.1)
id AA03546; Thu, 26 Aug 93 11:55:47 PDT
Message-Id: <9308261855.AA03546 at Sun.COM>
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d08b0011062; Thu, 26 Aug 93 12:02:09 -0700
Date: 26 Aug 1993 11:39:16 +0000
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: CPSMTP01 Admin <CPSMTP01_Admin at cpqm.saic.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Cc: atm at sun.com, ietf-ppp at ucdavis.edu, ietf at isi.edu,
iplpdn at CNRI.Reston.VA.US, rolc at nsco.network.com
X-Orig-Sender: atm-request at atm.eng.sun.com
Mail*Link(r) SMTP RE>dissolution of IPLPDN
>
> This recent criticism is unfortunate, and I'm sorry that we are ending on
> a bit of a sour note. But I'm confident that the work done by IPLPDN will
> continue to have value and that these comments will be recognized as
> misplaced. IPLPDN was a great group that stayed focused on solving technical
> problems. It was terrific fun, and I'm glad to have had the chance to
> participate.
One point I can't resist to mention: The discussion "multiprotocol over
circuit switched ISDN" was started too late. Here, in non-US countries,
we now have a variety of methods for IP and other protocols over the ISDN.
I hope that finally ppp will be widely accepted (just to have ONE
standard, but it will now take some time to established and accepted
method). ppp may not be the most efficient method, but anyhow.
Oliver
Oliver Korfmacher (okorf at netcs.com, whois OK11)
>
> George Clapp
> voice: 708-248-6507
> fax: 708-248-3996
> email: clapp at ameris.center.il.ameritech.com
>
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;26 Aug 1993 00:44:00 +0000
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717;
26 Aug 93 3:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00681;
26 Aug 93 3:14 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01472;
26 Aug 93 3:13 EDT
Received: from thuer.netcs.com ([192.76.152.15]) by venera.isi.edu
(5.65c/5.61+local-13)
id <AA12545>; Thu, 26 Aug 1993 00:14:37 -0700
Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef)
id AA29699; Thu, 26 Aug 1993 09:14:30 +0200
Received: by keks.netcs.com (5.65/25-eef)
id AA08874; Wed, 25 Aug 93 09:14:26 +0200
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Oliver Korfmacher <okorf at netcs.com>
Message-Id: <9308250714.AA08874 at keks.netcs.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Date: Wed, 25 Aug 93 9:14:24 MEST
Cc: iplpdn at CNRI.Reston.VA.US, atm at sun.com, ietf-ppp at ucdavis.edu,
rolc at nsco.network.com, ietf at isi.edu
In-Reply-To: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; from "George H.
Clapp" at Aug 23, 93 8:52 am
X-Mailer: ELM [version 2.2 PL0]
X-Charset: ASCII
X-Char-Esc: 29
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10683;
26 Aug 93 15:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10679;
26 Aug 93 15:47 EDT
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa20622;
26 Aug 93 15:47 EDT
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05)
id AA20170; Thu, 26 Aug 93 12:07:30 PDT
X-Orig-Sender: ietf-ppp-request at ucdavis.edu
Received: from cpmx.saic.com by ucdavis.ucdavis.edu (4.1/UCD2.05)
id AA19674; Thu, 26 Aug 93 11:54:32 PDT
Message-Id: <9308261854.AA19674 at ucdavis.ucdavis.edu>
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c7d08b0011062; Thu, 26 Aug 93 12:02:09 -0700
Date: 26 Aug 1993 11:39:16 +0000
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: CPSMTP01 Admin <CPSMTP01_Admin at cpqm.saic.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Cc: atm at sun.com, ietf-ppp at ucdavis.edu, ietf at isi.edu,
iplpdn at CNRI.Reston.VA.US, rolc at nsco.network.com
Mail*Link(r) SMTP RE>dissolution of IPLPDN
>
> This recent criticism is unfortunate, and I'm sorry that we are ending on
> a bit of a sour note. But I'm confident that the work done by IPLPDN will
> continue to have value and that these comments will be recognized as
> misplaced. IPLPDN was a great group that stayed focused on solving technical
> problems. It was terrific fun, and I'm glad to have had the chance to
> participate.
One point I can't resist to mention: The discussion "multiprotocol over
circuit switched ISDN" was started too late. Here, in non-US countries,
we now have a variety of methods for IP and other protocols over the ISDN.
I hope that finally ppp will be widely accepted (just to have ONE
standard, but it will now take some time to established and accepted
method). ppp may not be the most efficient method, but anyhow.
Oliver
Oliver Korfmacher (okorf at netcs.com, whois OK11)
>
> George Clapp
> voice: 708-248-6507
> fax: 708-248-3996
> email: clapp at ameris.center.il.ameritech.com
>
------------------ RFC822 Header Follows ------------------
Received: by cpqm.saic.com with SMTP;26 Aug 1993 00:44:00 +0000
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00717;
26 Aug 93 3:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00681;
26 Aug 93 3:14 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01472;
26 Aug 93 3:13 EDT
Received: from thuer.netcs.com ([192.76.152.15]) by venera.isi.edu
(5.65c/5.61+local-13)
id <AA12545>; Thu, 26 Aug 1993 00:14:37 -0700
Received: from keks.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef)
id AA29699; Thu, 26 Aug 1993 09:14:30 +0200
Received: by keks.netcs.com (5.65/25-eef)
id AA08874; Wed, 25 Aug 93 09:14:26 +0200
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Oliver Korfmacher <okorf at netcs.com>
Message-Id: <9308250714.AA08874 at keks.netcs.com>
Subject: Re: dissolution of IPLPDN
To: "George H. Clapp" <clapp at ameris.center.il.ameritech.com>
Date: Wed, 25 Aug 93 9:14:24 MEST
Cc: iplpdn at CNRI.Reston.VA.US, atm at sun.com, ietf-ppp at ucdavis.edu,
rolc at nsco.network.com, ietf at isi.edu
In-Reply-To: <m0oUcJU-0001bGC at ameris.center.il.ameritech.com>; from "George H.
Clapp" at Aug 23, 93 8:52 am
X-Mailer: ELM [version 2.2 PL0]
X-Charset: ASCII
X-Char-Esc: 29
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10937;
26 Aug 93 16:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10930;
26 Aug 93 16:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21079;
26 Aug 93 16:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10913;
26 Aug 93 16:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10860;
26 Aug 93 16:00 EDT
Received: from lando1.hns.com by CNRI.Reston.VA.US id aa21020;
26 Aug 93 16:00 EDT
Date: Thu, 26 Aug 1993 16:01 EST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wayne @ 601-4092" <JSTRAUCH at lando.hns.com>
Subject: Information Exchange at the HIGHEST level
To: stjohns at umd5.umd.edu
Cc: ietf at CNRI.Reston.VA.US
Message-id: <B2ABE69EC0820C2A at LANDO.HNS.COM>
X-VMS-To: SMTP%"stjohns at umd5.umd.edu"
X-VMS-Cc: SMTP%"ietf at cnri.reston.va.us",JSTRAUCH
I do not object to posting advertisements for positions related to the
Internet. One of the primary purposes of the Internet is to promote
the exchange of networking information among the Internet community.
We announce the availability of information in the form of RFCs.
Organizations are explicitly provided with a mechanism to access
to this information.
Why not allow organizations access to the information accrued by an
individual working with the Internet?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13413;
26 Aug 93 18:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13406;
26 Aug 93 18:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26453;
26 Aug 93 18:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13394;
26 Aug 93 18:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13368;
26 Aug 93 18:55 EDT
Received: from optics.wc.novell.com by CNRI.Reston.VA.US id aa26432;
26 Aug 93 18:55 EDT
Received: from by wc.novell.com (4.1/smi4.1.1.v91190)
id AB21200; Thu, 26 Aug 93 15:49:05 PDT
Date: Thu, 26 Aug 93 15:49:05 PDT
Message-Id: <9308262249.AB21200 at wc.novell.com>
To: Vince Fuller <vaf at valinor.stanford.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: minshall at wc.novell.com
X-Sender: minshall at optics.wc.novell.com (Unverified)
Cc: ietf at CNRI.Reston.VA.US
Vince,
I'd like to push on the scaling issue a bit...
In the "Re: IP address traceability" thread, you said:
> I thought about this one quite a long time ago but decided that it was not
>feasable in all cases: consider a provider which learns many routes from a
>client site. In this case, it may well be feasable to filter the routing
>information but not the forwarded traffic. The problem is, of course, one of
>performance - filtering routing updates is fairly low-cost, since the filter
>need only be examined when a routing update is received. Filtering of forwarded
>packets, on the other hand, can be very expensive, since it needs to be done in
>the main part of the forwarding operation (and it's particularly expensive to
>filter on source addresses, since lookups on them are typically not optimized
>as for routing destinations). So, while it would be a small matter to configure
>appropriate traffic filters to match the routing filters, I am concerned that
>this may not be feasable for sites which posses a large number of discontiguous
>networks. It probably would be a good idea to do this for simple sites, where
>a single expression may be used to match all sources within the site, but even
>then, I'd be leary of implementing this everywhere until the performance impact
>was well known.
My impression of the world (and, as you know, i have no actual operational
experience) is that for a given network provider (regional or backbone)
there will be a "backbone" set of routers, and for a given customer of that
provider there will be a router which provide the interface between that
customer and the network provider's backbone.
My assumption has been that the scaling problems occur *inside the
provider's backbone*, and not at this interface router. (Now, there may be
many situations in which the interface router *IS* a backbone router; but
it seems to me that conceptually there are two entities here.)
Thus, i would tend to agree to putting more load on the interface router,
especially if that would offload the backbone routers for that network
provider.
(And, i'm not really thinking about Erik's proposal for IP address
traceability.)
Thanks in advance for any thoughts you might have on this,
Greg Minshall
ps - I also had a question about the expense of filtering on sources: i
was under the impression that at least *some* routers, maybe on the
backbone, do routing lookups on the {source, destination} pair, in order to
do load sharing but ensure path-affinity for a given {source, destination}
pair. What is the actual situation with this?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14117;
26 Aug 93 21:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14110;
26 Aug 93 21:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29340;
26 Aug 93 21:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14098;
26 Aug 93 21:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14071;
26 Aug 93 21:06 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa29314;
26 Aug 93 21:06 EDT
Received: by ginger.lcs.mit.edu
id AA00492; Thu, 26 Aug 93 21:06:47 -0400
Date: Thu, 26 Aug 93 21:06:47 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9308270106.AA00492 at ginger.lcs.mit.edu>
To: minshall at wc.novell.com, vaf at valinor.stanford.edu
Subject: IP address traceability
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
> I ... decided that it was not feasable in all cases ... it may well be
> feasable to filter the routing information but not the forwarded traffic.
> The problem is, of course, one of performance - filtering routing updates
> is fairly low-cost, since the filter need only be examined when a routing
> update is received. Filtering of forwarded packets, on the other hand,
> can be very expensive, since it needs to be done in the main part of the
> forwarding operation
i would tend to agree to putting more load on the interface router,
especially if that would offload the backbone routers for that network
provider.
There's an easier solution. Most modern high-performance routers have a
smallish cache which translates directly from IP destination (and perhaps
other fields, such as TOS, etc) to outbound interface and next-hop MAC
address, to maximize packet throughput. Assuming a goodly percentage of the
packets which go through routers are part of ongoing flows (e.g. TCP
connections), which seems a safe bet, the overhead of filtering the data
traffic, as opposed to the routing information, can be minimized by doing
this user data access control check before the cache entry is made. That
way, it only happens for the first packet of a flow, and thereafter there is
zero overhead.
How many router vendors with access control features already do this? Can
anyone provide this info? Has anyone measured performance of common routers
with access control off and on? If you've tried a router which can take a
longish access control list, with little performance degradation on
throughput test, it probably already does this.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05849;
27 Aug 93 12:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05842;
27 Aug 93 12:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19714;
27 Aug 93 12:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05821;
27 Aug 93 12:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab05709;
27 Aug 93 12:44 EDT
Received: from vela.acs.oakland.edu by CNRI.Reston.VA.US id aa18949;
27 Aug 93 12:44 EDT
Received: from via.dsf4.merit.edu by vela.acs.oakland.edu with SMTP id AA05509
(5.65c+/IDA-1.4.4); Fri, 27 Aug 1993 12:42:26 -0400
Date: Fri, 27 Aug 93 12:09:31 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-Id: <1033.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Cc: Stephen Wolff <steve at cise.cise.nsf.gov>
Reply-To: bsimpson at morningstar.com
Subject: over funding of [InterNIC]
It has become apparent with the recent spate of disregard for internet
etiquette (posting job positions, posting "advertisements"), and the
simultaneous attempt to reduce expected services (whois), the providers
of the InterNIC are not suitable.
Did everyone see that they can afford a nice booth at InterOp? When did
any previous NSF grantee get such a thing?
The cost could have funded 3-4 full-time employees typing whois entries.
Obviously, the grant was too large, since they have all of this extra
money for advertising.
And why would they need to advertise, except that they want to leverage
a monopoly grant position into some commercial market?
I call for an NSF audit to endure that NSF money was not spent for
advertising and lobbying.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09135;
27 Aug 93 16:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09128;
27 Aug 93 16:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27927;
27 Aug 93 16:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09101;
27 Aug 93 16:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09035;
27 Aug 93 16:08 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa27756;
27 Aug 93 16:09 EDT
Received: by trystero.malamud.com
(5.65/IDA-93081802) id AA10772; Fri, 27 Aug 93 16:11:52 -0400
Date: Fri, 27 Aug 93 16:11:52 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at trystero.malamud.com>
Message-Id: <9308272011.AA10772 at trystero.malamud.com>
To: ietf at CNRI.Reston.VA.US
Subject: Wall Street Journal
Those of you that read today's Wall Street
Journal may have noticed a fairly surreal
description of remote printing in the
Marketplace section.
Just to set the record straight, NASA Ames
Research Center will *NOT* be selling ads
on the cover page of faxes that it sends.
I can't speak for NASA, but it is highly
unlikely that this unique form of government
business cooperation would meet the mission
of NASA or the Ames Research Center.
Marshall Rose and I will be releasing
documents next week that discuss the different
models of operation for remote printer
servers. The tpc.int subdomain allows
a mix of different models, some of which
are commercial organizations that serve a
wide area, some of which are simply servers
for a particular organization.
The press occassionally views the world
through a prism unavailable to the rest
of us. Hope this screwed up article by
the WSJ doesn't cause any problems.
Carl
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09881;
27 Aug 93 16:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29635;
27 Aug 93 16:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09845;
27 Aug 93 16:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09689;
27 Aug 93 16:42 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-madman-dsa-mib-03.txt
Date: Fri, 27 Aug 93 16:42:32 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308271642.aa09689 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Mail and Directory Management
Working Group of the IETF.
Title : Directory Monitoring MIB
Author(s) : G. Mansfield, S. Kille
Filename : draft-ietf-madman-dsa-mib-03.txt
Pages : 19
This document defines an experimental portion of the Management
Information Base (MIB). It defines the MIB for monitoring
Directory System Agents [DSA], a component of the OSI Directory.
This MIB will be used in conjunction with the APPLICATION-MIB
for monitoring DSAs.
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-madman-dsa-mib-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-ietf-madman-dsa-mib-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-madman-dsa-mib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-dsa-mib-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09886;
27 Aug 93 16:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29645;
27 Aug 93 16:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09847;
27 Aug 93 16:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09783;
27 Aug 93 16:44 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-nussbacher-mime-direction-01.txt
Date: Fri, 27 Aug 93 16:44:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308271644.aa09783 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Handling of Bi-directional Texts in MIME
Author(s) : H. Nussbacher
Filename : draft-nussbacher-mime-direction-01.txt
Pages : 3
This document describes the format and syntax of the "direction" keyword to
be used with bi-directional texts in MIME.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-nussbacher-mime-direction-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
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 draft-nussbacher-mime-direction-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-nussbacher-mime-direction-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-nussbacher-mime-direction-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09951;
27 Aug 93 16:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29704;
27 Aug 93 16:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09926;
27 Aug 93 16:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09833;
27 Aug 93 16:46 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa29624;
27 Aug 93 16:46 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA15358>; Fri, 27 Aug 1993 13:46:46 -0700
Message-Id: <199308272046.AA15358 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1505 on Encoding Header Field
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 27 Aug 93 13:46:37 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1505:
Title: Encoding Header Field for Internet Messages
Author: A. Costanzo, D. Robinson & R. Ullmann
Mailbox: AL at AKC.COM, DRB at Relay.CV.COM, ariel at world.std.com
Pages: 36
Characters: 63,796
Obsoletes: 1154
This document expands upon the elective experimental Encoding header
field which permits the mailing of multi-part, multi-structured
messages. It replaces RFC 1154.
IESG Note: Note that a standards-track technology already exists in
this area (RFC 1341).
This memo defines an Experimental Protocol for the Internet community.
It does not specify an Internet standard. 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 CNRI.RESTON.VA.US. Requests to be added
to or deleted from the RFC-DIST distribution list should be sent to
RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info at ISI.EDU" with the message body
"help: ways_to_get_rfcs". For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1505.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1505.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10075;
27 Aug 93 16:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29892;
27 Aug 93 16:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10063;
27 Aug 93 16:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10034;
27 Aug 93 16:50 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa29817;
27 Aug 93 16:51 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA15432>; Fri, 27 Aug 1993 13:51:25 -0700
Message-Id: <199308272051.AA15432 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1504 on Appletalk Update-Based Routing Protocol
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 27 Aug 93 13:51:16 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1504:
Title: Appletalk Update-Based Routing Protocol:
Enhanced Appletalk Routing
Author: A. Oppenheimer
Mailbox: Oppenheime1 at applelink.apple.com
Pages: 82
Characters: 20,1553
Updates/Obsoletes: none
This RFC provides detailed information about the AppleTalk
Update-based Routing Protocol (AURP) and wide area routing. AURP
provides wide area routing enhancements to the AppleTalk routing
protocols and is fully compatible with AppleTalk Phase 2. This memo
is being distributed to members of the Internet community to fully
document an Apple protocol that may be running over the Internet.
While the issues discussed may not be directly relevant to the
research problems of the Internet, they may be interesting to a number
of researchers and implementers.
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 CNRI.RESTON.VA.US. Requests to be added
to or deleted from the RFC-DIST distribution list should be sent to
RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info at ISI.EDU" with the message body
"help: ways_to_get_rfcs". For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1504.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1504.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13188;
29 Aug 93 21:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13181;
29 Aug 93 21:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19716;
29 Aug 93 21:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13167;
29 Aug 93 21:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13117;
29 Aug 93 21:46 EDT
Received: from access.digex.net by CNRI.Reston.VA.US id aa19601;
29 Aug 93 21:46 EDT
Received: by access.digex.net id AA21739
(5.65c/IDA-1.4.4 for ietf at cnri.reston.va.us); Sun, 29 Aug 1993 21:46:20 -0400
Newsgroups: pub.tdarcos.private.mail
Date: Sun, 29 Aug 1993 21:45:52 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Tansin A. Darcos & Company" <0005066432 at mcimail.com>
X-Orig-Sender: Paul Robinson <TDARCOS at access.digex.net>
Reply-To: "Tansin A. Darcos & Co." <0005066432 at mcimail.com>
Subject: The Internet Want Ad controversy
To: ietf at CNRI.Reston.VA.US
Message-Id: <0119930829212200/0005066432ND1EM-b100000 at MCIMAIL.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
From: Paul Robinson <TDARCOS at MCIMAIL.COM>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
Aproximately ten times as much bandwidth has been used for complaints
about one advertisement on this list as the ad took. The ad is searching
for someone intimately connected with the type of material that the list
is related to. I think this is reasonable.
Now if I ran an ad, "Now available: subscribe to all the newsgroups you
want and have them mailed to you, for $20 a year," that would clearly
be inappropriate here. But not necessarily on the alt.internet.services
newsgroup.
John Levine moderates the comp.compilers news group. Once a week he posts
all of the "Position Wanted" job postings he receives which deal with
compilers. I think that is reasonable too.
The purpose of the network is to allow us to recieve direct information
which we are either interested in or is related to the particular mailing
lists or groups we subscribe to. I think that an advertisement, exactly
on point and precisely related to the group, is reasonable as long as
these groups do not become "saturated" with ads. Or even if they do,
as long as they are relevant and we can screen them out, it's not
necessarily that bad.
Does anyone on here purchase Computer Shopper? More than half of that
monthly tome is advertising. Yet that is one of the primary reasons for
buying that magazine; to get current price quotes on avaialble computers
and computer-related supplies and products.
In short, it is not the use of the network for someone running a position
wanted ad - unless the article was fraudulent, e.g. there was no real
position and it was just an effort to collect information - that is a
problem. It is unwanted or irrelevant information that is a problem.
---
Paul Robinson - TDARCOS at MCIMAIL.COM
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21482;
30 Aug 93 8:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21475;
30 Aug 93 8:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06737;
30 Aug 93 8:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21462;
30 Aug 93 8:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21398;
30 Aug 93 8:24 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa06596;
30 Aug 93 8:24 EDT
Received: by ginger.lcs.mit.edu
id AA19509; Mon, 30 Aug 93 08:24:27 -0400
Date: Mon, 30 Aug 93 08:24:27 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9308301224.AA19509 at ginger.lcs.mit.edu>
To: 0005066432 at mcimail.com, ietf at CNRI.Reston.VA.US
Subject: Re: The Internet Want Ad controversy
Cc: jnc at ginger.lcs.mit.edu
The purpose of the network is to allow us to recieve direct information
which we are either interested in or is related to the particular mailing
lists or groups we subscribe to.
What's at issue here is not what is acceptable on the network as a whole, but
*on this mailing list*. This mailing list is the primary discussion forum for
the self-organized standards body, the IETF, which is responsible for the
design and engineering of the Internet as a whole. The IETF members have made
a decision that this type of traffic is *not* to be sent on the IETF mailing
list.
I won't bother to go back over the reasons why in detail: suffice it to say
that once traffic not reasonably directly related to the function of the IETF
was allowed, it would be hard to erect a fair boundary to limit the amount of
noise. (See an essay called "The Tragedy of the Commons".) This list has lots
of very busy people on it, people who have a low tolerance for useless noise
in their lives, be it advertising or bureacracy; we've already lost some good
people due to the seemingly unavoidable rules the IETF has to have, now that
the Internet is a Big Deal. If we lost one more because of such messages, it
would be too big a cost.
John Levine moderates the comp.compilers news group.
You used the key word: "moderated". This list isn't, although it may come to
that.
In short, it is not the use of the network for someone running a position
wanted ad ... that is a problem. It is unwanted or irrelevant information
that is a problem.
Exactly. These want-ads are both irrelevant and unwanted, *on this list*.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24344;
30 Aug 93 10:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24328;
30 Aug 93 10:47 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa11852;
30 Aug 93 10:47 EDT
Received: by bitsy.MIT.EDU
id AA03725; Mon, 30 Aug 93 10:30:42 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA03717; Mon, 30 Aug 93 10:29:33 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA01811; Mon, 30 Aug 93 10:29:28 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <KAA08434 at pad-thai.aktis.com>; Mon, 30 Aug 1993 10:29:54 -0400
Date: Mon, 30 Aug 1993 10:29:54 -0400
Message-Id: <199308301429.KAA08434 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at security.ov.com>
X-Orig-Sender: jik at gza.com
To: cat-ietf at mit.edu
Subject: Comments about GSS-API I-D in messages following this one
I just read through the entire GSS-API I-D for the first time this
morning. I noted a couple of questions while I was reading it, and
after a conversation about them with John Linn, some of them remain
relevant (i.e., I wasn't just confused), so I'd like to share them
with the list and see see what other people think.
Since they're independent of each other, I'm going to send them in
separate mail messages, following this one, with meaningful Subject
lines, so that their discussions don't get mucked together into one
thread without any way to easily distinguish between them.
Jonathan Kamens | OpenVision Technologies, Inc. | jik at security.ov.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24735;
30 Aug 93 11:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24728;
30 Aug 93 11:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12392;
30 Aug 93 11:03 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24715;
30 Aug 93 11:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24668;
30 Aug 93 11:01 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa12336; 30 Aug 93 11:01 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA06647 for ietf at cnri.reston.va.us; Mon, 30 Aug 93 11:01:18 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA10575; Mon, 30 Aug 93 07:59:12 PDT
Message-Id: <9308301459.AA10575 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: Reminder, SIGCOMM '93 Registration
Reply-To: Craig Partridge <craig at aland.bbn.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Mon, 30 Aug 93 07:59:12 -0700
X-Orig-Sender: craig at aland.bbn.com
[One last reminder for folks. Lots of papers that I think would be of
interest to IETFers. -- Craig]
ADVANCE PROGRAM FOR ACM SIGCOMM '93
September 13-17th, San Francisco, California, USA
**************************************************************************
**************************************************************************
CONFERENCE LOCATION
The SIGCOMM '93 Conference will be held at the Westin St. Francis Hotel
in downtown San Francisco, California. The hotel is within walking
distance of San Francisco's Chinatown and an easy cable car ride
away from Ghiradelli Square and Fisherman's Wharf. Napa and Sonoma
Valleys, the heart of California wine country, are an hour's drive
away.
Weather: San Francisco in September is typically very pleasant. Sunny
and warm (about 70F) during the day, and cool (about 50F) in the
evenings. Note that the evening fog often makes it feel a bit
colder and we recommend you bring a jacket.
Transportation: The hotel is about 20 minutes away from San Francisco
International Airport. A taxi ride from the airport typically costs
about $25. Also, the SFO Airporter has direct service to the
hotel at 20-minute intervals. The fare is $8 one-way and $14
round-trip.
Rental Cars: HERTZ has been appointed as the car rental supplier for
SIGCOMM '93. Special rates with unlimited mileage have been negotiated
for SIGCOMM attendees and are also available the week prior and the
week after the symposium. To make reservations call HERTZ Meeting Services
at 1-800-654-2240 (In Canada 1-800-263-0600) and identify yourself as
SIGCOMM attendee (Meeting # 2499). Cars can be rented at most Bay-area
airports and also at the Westin St. Francis Hotel.
Social Event: An evening dinner-cruise on the San Francisco Bay is planned
for Wednesday, September 15. The cost of the cruise is included in
the registration fee. Additional tickets may be purchased at a price
of $53 each. The cruise will be held on the Hornblower Dining Yachts's
Empress. Beverages will include premium wine and beer, soft drinks,
fruit juices and mineral water. Dinner will be a Greek Salad, Rice
Pilaf, a choice of carved turkey or pasta, and dessert.
**************************************************************************
**************************************************************************
ADVANCE PROGRAM
Monday, September 13th
1:00-5:00 TUTORIALS
Tutorial T1A: High-Speed Transport Protocols
Krishan Sabnani, AT&T Bell Labs
Tutorial T1B: Interconnecting MANs and LANs to ATM
Mario Gerla, UCLA
------------------------------------------------------------------------------
Tuesday, September 14th
8:00-12:00 TUTORIALS
Tutorial T2A: Wireless Communication Worldwide for Cellular and PCS
Donald L. Schilling, InterDigital Communications Corporation
Tutorial T2B: Trends and Challenges in Broadband Networking
Richard D. Gitlin, AT&T Bell Labs
1:30-5:30 TUTORIALS
Tutorial T3A: All-Optical Networking
Paul E. Green Jr., IBM T.J. Watson Research Center
Tutorial T3B: Metropolitan Area Networks
James F. Mollenauer, Technical Strategy Associates
6:00-8:00 Reception at Westin St. Francis Hotel.
------------------------------------------------------------------------------
Wednesday, September 15th
9:00 - 10:30
Keynote Address: SIGCOMM Award Winner
11:00 - 12:30 REAL TIME COMMUNICATIONS
On Per-Session End-to-End Delay Distribution and the Call Admission
Problem for Real Time Applications with QOS Requirements
David Yates, Jim Kurose, Don Towsley (Univ. of Mass) and
Mike Hluchyj (Motorola/Codex Corp)
Analysis of Burstiness and Jitter in Real Time Communications
Zheng Wang and Jon Crowcroft (University College London)
An Adaptive Congestion Control Scheme for Real Time Packet Video Transport
Hemant Kanakia, Amy Reibman (AT&T Bell Lab) and
Partho P Misra (Univ. of Maryland - CP)
2:00 - 3:30 ROUTING
The Synchronization of Periodic Routing Messages
Sally Floyd and Van Jacobson (Lawrence Berkeley Lab.)
Dynamics of Internet Routing Information
Bilal Chinoy (San Diego Supercomputer Center)
Open Shortest Path First (OSPF) Routing Protocol Simulation
Deepinder Sidhu, Tayang Fu, Shukri Abdallah, Raj Nair
(Univ. of Maryland - BC) and Rob Coltun (Consultant)
4:00 - 5:00 PROTOCOL IMPLEMENTATION ISSUES
Implementation of Network Protocols at the User Level
Chandramohan Thekkath, Edward D. Lazowska, Thu. D. Nguyen
and Evelyn Moy (University of Washington)
Locking Effects in Multiprocessor Implementation of Protocols
Mats Bjorkman (Uppsala University) and
Per Gunningberg (Swedish Institute of Computer Science)
5:30 Busses Leave for Cruise.
6:30 - 9:00 SOCIAL EVENT
Cruise in San Francisco Bay.
------------------------------------------------------------------------------
Thursday, September 16th
9:00 - 10:30 MULTICAST
Core Based Trees
Tony Ballardie (University College London), Paul Francis (Bellcore)
and Jon Crowcroft (University College London)
Routing Reserved Bandwidth Multi-Point Connections
Dinesh C. Verma, P. M. Gopal (IBM T.J. Watson Research Center)
The Design of a Reliable Multicast Algorithm
R. Ajello, E. Pagani, G.P. Rossi (Universita' di Milano)
11:00 - 12:30 CONGESTION AND ADMISSION CONTROL, SCHEDULING
Optimizing File Transfer Response Time Using the Loss Load Curve Congestion
Control Mechanism. Carey Williamson (Univ. of Saskatchewan)
An Adaptive Framework for Dynamic Access to Bandwidth at High Speed.
Kerry W. Fendick and Manoel A. Rodrigues (AT&T Bell Laboratories)
Warp Control: A Dynamically Stable Congestion Protocol and its Analysis.
Kihong Park (Boston University)
2:00 - 3:30 PROTOCOL DESCRIPTION
Control Handling in Real-Time Communication Protocols.
Atsushi Shionozaki and Mario Tokoro (Keio University)
Structural Complexity and Execution Efficiency of Distributed Application
Protocols. K. Ravindran and X. T. Lin (Kansas State University)
A Data Labelling Technique for High-Performance Protocol Processing
and its Consequences. David C. Feldmeier (Bellcore)
4:00 - 5:00 TRAFFIC CHARACTERISTICS
On the Self-Similar Nature of Ethernet Traffic
Will E. Leland (Bellcore), Murad S. Taqqu (Boston University),
Walter Willinger and Daniel V. Wilson (Bellcore)
Application of Sampling Methodologies to Network Traffic Characterization
George Polyzos, K. C. Claffy and H. W. Braun
(UC, San Diego)
------------------------------------------------------------------------------
Friday, September 17th
9:00 - 10:30 SCHEDULING AND MANAGEMENT
ATM Scheduling with Queueing Delay Predictions
Daniel B. Schwartz (GTE Laboratories)
HAP: A New Model for Packet Arrivals with Implications for Broadband
Network Control. Ying Dar Lin, Tzu Chieh Tsai and Mario Gerla (UCLA)
Management of Virtual Private Networks for Integrated Broadband Communication
Juergen M. Schneider (IBM European Networking Center),
Thomas Preuss (Technische Universitaet Cottbus) and
Peter S. Nielsen (L. M. Ericsson A/S)
11:00 - 12:30 NETWORKING ISSUES
A Case for Caching File Objects Inside Internetworks
Peter B. Danzig (University of Southern California), Richard S. Hall
and Michael F. Schwartz (University of Colorado, Boulder)
Linear Recursive Networks and Their Applications in Topological Design and
Data Routing. Hsu Wen Jing, A. Das (Nanyang Technological Univ.,
Singapore), and M.J. Chung (Michigan State Univ.)
The Importance of Non-Data Touching Processing Overheads in TCP/IP.
Jonathon Kay and Joseph Pasquale (UC, San Diego)
2:00 - 3:30 PRACTICAL PROTOCOLS
A Distributed Queueing Random Access Protocol for a Broadcast Channel.
Graham Campbell and Wenxin Xu (Illinois Institute of Technology)
Fault Detection in an Ethernet Network Using Anomaly Signature Matching
Frank Feather (Hewlett-Packard Company), Dan Siewiorek and
Roy Maxion (Carnegie Mellon University)
End-to-End Packet Delay and Loss Behavior in the Internet
Jean - Chrysostome Bolot (INRIA)
**************************************************************************
**************************************************************************
TUTORIAL DESCRIPTIONS
Tutorial T1A: High-Speed Transport Protocols. Instructor: Krishan Sabnani,
AT&T Bell Laboratories (Monday, Sept. 13th, 1:00-5:00)
Advances in data transmission and switching over the last
decade promise deployment of communication systems with raw
bandwidth and switching speeds that are orders of magnitude
higher than the current systems. Optical fibers, for
example, allow transmission of tens of gigabits/sec over
several kilometers without repeaters and switch fabrics that
can switch bit-streams of more than hundreds of megabits/sec
have already been prototyped. To realize the fruits of
these advances, transport protocols capable of delivering
high end-to-end bandwidth to their users are needed.
Various approaches for doing this have been proposed:
(1) design of lightweight transport protocols such as NETBLT,
SNR, and VMTP; (2) VLSI implementations of transport
protocols such as PROVE and the Protocol Engine. Some
high-speed versions of standard protocols such as TCP have
also been developed. Many important advances in this area
will be discussed. A special effort will be made to
describe the underlying principles behind these approaches.
In addition, the adaptation layer protocols being proposed
for the ATM/BISDN networks will also be presented.
Biography: Krishan Sabnani is a researcher in the Distributed Systems
Research Department of AT&T Bell Laboratories. His major area of interest
is communication protocols. Krishan received the Leonard G. Abraham
Award from the IEEE Communications Society in 1991. He was awarded
the Bell Laboratories Distinguished Technical Staff Award in 1990.
He is also a fellow of the IEEE, and an editor for the IEEE/ACM
Transactions on Networking. He has been an editor of the IEEE
Transactions on Communications and of the IEEE Transactions on
Computers. He has served as a guest editor for the IEEE Journal
on Selected Areas in Communications (JSAC) and the Computer
Networks Journal. He also serves on the editorial boards
of Journal of Systems Integration and Journal of High
Speed Networks.
---------------------------------------------------------------
Tutorial T1B: Interconnecting MANs and LANs to ATM. Instructor: Mario Gerla,
Computer Science Department, UCLA. (Monday, Sept. 13, 1:00-5:00).
The need for higher data rates in local and metropolitan areas has
recently led to the development of several network products in the
100 MBPS speed range ( eg FDDI, DQDB etc). Following the introduction
of a nationwide ATM network, it will be natural to interconnect
these LANs and MANs to ATM, thus extending their services to
large geographical areas. One of the main challenges of the
LAN/MAN/ATM interconnect is the connectionless traffic support in
ATM. In fact, LANs and MANs are virtually all connectionless,
while ATM is connection oriented and requires bandwidth allocation
prior to connection setup. In this seminar, we will examine and
compare various alternatives for ATM connectionless service support,
including: dedicated VPs (Virtual Paths); on-the-fly burst
transmissions; fast reservations; and connectionless servers.
We will also discuss the problem of extending LAN and MAN multicast
services within ATM. Finally, we will consider the ATM LAN
solution for local and campus area coverage, and examine the
problem of interconnecting the ATM LAN to the ATM WAN.
Biography: Dr. Gerla was born in Milan, Italy. He received a
graduate degree in engineering from the Politecnico di Milano, in
1966, and the M.S. and Ph.D. degrees in engineering from UCLA in 1970
and 1973, respectively. He joined the faculty of the UCLA Computer
Science Department in 1977. His research interests cover the
performance evaluation, design and control of distributed computer
communication systems and high speed computer networks (ATM and
Optical Networks).
---------------------------------------------------------------
Tutorial T2A: Wireless Communication Worldwide for Cellular and PCS.
Instructor: Donald L. Schilling, InterDigital Communication Corporation
(Tuesday, Sept. 14th, 8:00-12:00)
This is the decade of wireless telecommunications. During the 1990s people
will demand, in increasing numbers, the ability to communicate
with a high degree of mobility, high quality voice, data at ISDN rates
and multimedia information such as video. Indeed, consumers demand
wired line quality with wireless convenience. The user of a cellular
or PCS system wants to use one phone for all of these intended needs.
Thus, a single portable phone should be able to operate in a residence
as a cordless phone, in a vehicle using a cellular system and in an
office using a WPBX. This tutorial discusses the two primary
technologies for wireless communications: TDMA and CDMA. Topics include:
principles of operation of TDMA and CDMA; channel
characterization-multipath fading, theory and experimental results;
as well as applications and comparison of TDMA and CDMA for cellular
and PCS.
Biography: Donald L. Schilling is Executive President of InterDigital
Communications Corporation where he directs programs leading to
the production and sale of Wireless TDMA and B-CDMA Communication's
products. Dr. Schilling retired in May 1992 as the Herbert
G. Kayser, Distinguished Professor of Electrical Engineering at
the City College of the City University of New York where he
had been a Professor since 1969. Dr. Schilling is an
internationally-known expert in the field of Communications Systems.
He has made many notable contributions in Meteor-Burst Communications
Systems, Spread Spectrum Communication Systems, FM and Phase Locked
Systems and HF systems. His design of a voice digitizer, called
an adaptive delta modulator, is used on the Space Shuttle. Dr.
Schilling was President of IEEE Communications Society from
1980-1981, and a member of the Board of Directors of the IEEE
from 1982-1983. He was Editor of the IEEE Transactions on
Communications for 1968-1978. He is a Fellow of the IEEE and a
member of Sigma Xi. He has co-authored eight textbooks and more than
140 papers in Telecommunications and Electronics.
---------------------------------------------------------------
Tutorial T2B: Trends and Challenges in Broadband Networking.
Instructor: Richard Gitlin, AT&T Bell Labs (Tuesday, Sept. 14th,
8:00-12:00)
This tutorial will present an overview of research in Broadband Networking
(B-ISDN) based on the Asynchronous Transfer Mode (ATM). ATM is the leading
candidate to provide a technological discontinuity that enables integrated
broadband telecommunication services (e.g., multimedia), high-speed
computer networking and scalable local, metropolitan, and wide area
networks. Specific topics that will be addressed are:
o The technological discontinuities between narrowband and broadband
networking;
o Challenges and barriers to a broadband network;
o Selected research topics (including the LuckyNet broadband testbed).
Biography: Richard D. Gitlin received the B.E.E. degree (cum laude) from
the City College of New York, N.Y., in 1964 and the M.S. and D.Eng.Sc.
degrees from Columbia University, New York, N.Y., in 1965 and 1969,
respectively. Since 1969, he has been with AT&T Bell Laboratories,
Holmdel, N.J. In November, 1992 he was appointed Director of the
Communications Systems Research Laboratory. He is now responsible for
research in broadband networking, wireless networks, and access
technologies. Dr. Gitlin is the author of more than 50 technical
papers, numerous conference papers, and he holds 25 patents in the
areas of data communications, digital signal processing, and broadband
networking. He is a co-author of the text, Data Communication Principles
(Plenum Press, 1992). He is a member of Sigma Xi, and in 1985 he was
elected a Fellow of the IEEE for his contributions to data communications
technology. In 1987 he was named an AT&T Bell Laboratories Fellow.
---------------------------------------------------------------
Tutorial T3A: All-Optical Networking. Instructor: P. E. Green, Jr.,
IBM TJ Watson Research Center. (Tuesday, Sept. 14th, 1:30-5:30).
This short course will focus on recent developments in
networks that exploit the multiprotocol and high bandwidth
possibilities of clear end-to-end optical fiber paths by sending
different sessions or connections at different wavelengths of light.
In the first hour, the motivation and overall principles of such
networks are reviewed. In the next, the appropriate fiber optic
technology is covered, focussing on those components that are special
to networking. In the third hour, various architectural topics are
covered, (including link budgets, topologies and protocols), and in
the final hour the status and prospects for real operational
all-optical networks of various types are presented.
Biography: Paul E. Green, Jr. is Manager of Advanced Optical
Networking Member at IBM Research in Hawthorne, NY. After some years
at M.I.T. Lincoln Laboratory, where he made pioneering contributions
to spread spectrum, adaptive receivers, radar astronomy and seismic
data processing, he joined IBM, where he has held a variety of
research and Corporate Technical Staff positions. His technical
interests have centered on computer network architecture, and he has
received several IBM Outstanding Innovation Awards for his role in
formulating and promoting Advanced Peer-to-Peer Networking, now the
basis for further evolution of IBM's System Network Architecture. He
is a member of the National Academy of Engineering, in 1983 was named
Distinguished Engineering Alumnus by North Carolina State University,
and received the IEEE's Simon Ramo Medal in 1991. He is the author of
many technical papers, has edited several books on computer
communications, and is the author of the textbook: Fiber Optic
Networks, (Prentice Hall, 1993), on which this course is based.
Currently he is President of the IEEE Communication Society.
---------------------------------------------------------------
Tutorial T3B: Metropolitan Area Networks. Instructor: James F. Mollenauer,
Technical Strategy Associates. (Tuesday, Sept. 14th, 1:30-5:30).
This tutorial will cover the applications, standards aspects, and
technology of metropolitan area networks and their relationship
to ATM technology. The need for segmented transmission to
support data, voice, and video services led early on to the
adoption of an ATM or cell-based transmission strategy. This
provides a close relationship to ATM as it has emerged as a
technology of choice for premises networks, replacing the shared
medium LAN. The tutorial will cover private multiservice networks
and public facilities and their support of voice and video in addition
to data. Implementation issues will be addressed, both for the
IEEE 802.6 MAN standard and for the public SMDS service based on it.
Biography: James F. Mollenauer is currently President, Technical
Strategy Associates, of Newton, Massachusetts, providing consultation
in metropolitan and other high-speed networks from both a technical
and product strategy point of view. Since 1982 he has chaired
the standardization group for metropolitan area networks, IEEE
Project 802.6. Prior to his present position Dr. Mollenauer was
Vice President, Advanced Technology at Artel Communications
Corporation, architecting a new line of very-high-performance LAN
bridging and routing products. Previously he spent 17 years at
Bell Laboratories, starting out in nuclear physics research and
moving on to work in real-time computing, time sharing, and
computer-aided design. He has also served at Prime Computer and
its Computervision division in data communication architectures
and planning, and at Codex Corporation, where he undertook
strategic studies in LAN's and metropolitan area networks, and
developed a wireless radio-based LAN. Dr. Mollenauer is the
author of many articles and conference papers on metropolitan and
high speed networks and is currently Chair of the IEEE Local
Computer Networks Conference. He received his bachelor's degree
at Amherst College and his PhD from the University of California
at Berkeley.
**************************************************************************
**************************************************************************
REGISTRATION INFORMATION
Advance registration is available using the form below through September
7th. (E-mail registration available only through August 10th, and must
use a credit card number). On site registration at the Westin St. Francis
Hotel will be available starting Sunday, September 12th from 1PM-5PM, and
every day of the conference starting at 7:30 AM.
Student Registration includes conference proceedings and presentations
but does not include the conference social event.
---------------------------------------------------------------------------
SIGCOMM '93
Registration Form
Please send this form and a check, credit card information,
or money order (no purchase orders) to SIGCOMM '93.
Registrations accepted via postal mail, FAX, or email only.
SIGCOMM '93 Registrar
Hewlett-Packard Laboratories, MS 1U-17
P.O. Box 10490
Palo Alto, CA 94303-0969
FAX: +1 415 813-3706
EMAIL: sigcomm93-registration at hp.com (**note)
Inquiries only: +1 415 857-3295 (voice)
-----------------------------------------------------------
If you are not an ACM or a SIGCOMM member at this time,
you may join now to take full advantage of ACM/SIG Member
or Student(*) rates for SIGCOMM '93:
ACM Associate Member Dues __ $79 US
Add SIGCOMM to ACM Membership __ $22 US
ACM Student Dues __ $24 US
Add SIGCOMM to ACM Student Membership __ $15 US
SIGCOMM Membership only (non-ACM) __ $50 US
Total New Membership Fees $_____ US
-----------------------------------------------------------
Tutorials (check the box for each tutorial attending)
Note: You may select at most one tutorial from each
session time (MAX 3).
___
High-Speed Transport Protocols ....................../__/ T1A
(Monday, 1-5)
___
Interconnecting MANs and LANS to ATM . ............../__/ T1B
(Monday, 1-5)
___
Wireless Communication Worldwide ..................../__/ T2A
for Cellular and PCS (Tuesday, 8-12AM)
___
Trends and Challenges in ............................/__/ T2B
Broadband Networking (Tuesday, 8-12AM)
___
All-Optical Networking ............................../__/ T3A
(Tuesday, 1:30-5:30)
___
Metropolitan Area Networks ........................../__/ T3B
(Tuesday, 1:30-5:30)
Enter total number of tutorials at the appropriate rate:
For registrations received (postmarked)
by after
August 10 1993 August 10 1993
# $'s Each # $'s Each
--------------- ---------------
ACM/SIG Member ___ @ $ 99 US ___ @ $125 US
Non-Member ___ @ $119 US ___ @ $145 US
Student* ___ @ $ 50 US ___ @ $ 50 US
Total Tutorial Fee: $_____ US
-----------------------------------------------------------
Conference (select one):
For registrations received (postmarked)
by after
August 10 1993 August 10 1993
ACM/SIG Member ___ $290 US ___ $340 US
Non-Member ___ $355 US ___ $395 US
Student* ___ $100 US ___ $100 US
Conference Fee: $_____ US
-----------------------------------------------------------
Extra Dinner/Cruise Tickets ___ @ $53 US
(September 15)
Total for extra tickets: $_____ US
-----------------------------------------------------------
Total Amount enclosed: $_____ US
-----------------------------------------------------------
Vegetarian Meals: ___ YES / ___ NO
-----------------------------------------------------------
Name: ____________________________________
Affiliation: _____________________________
Address: _________________________________
Phone: ___________________________________
FAX: _____________________________________
Email Address: ___________________________
ACM Member #: ____________________________
(write "new" if joining at this time)
SIGCOMM Member? ____ YES / ___ NO
Credit Card Payment
__ Visa __ Mastercard
Card Holder Name: ________________________
Card Number: _____________________________
Expiration Date: _________________________
Signature: _______________________________
* See the Advance Program section on student fees.
** Email registration is only available through August 10th and must
use credit card payment.
**************************************************************************
**************************************************************************
HOTEL REGISTRATION
The Westin St. Francis
Union Square
335 Powell Street
San Francisco, CA 94102 USA
A special conference rate has been arranged for attendees of
SIGCOMM '93. These rates are applicable from September 10-17, 1993.
When making reservations by telephone, identify yourself as an
attendee of SIGCOMM '93. Hotel reservation deadline: August 10,
1993. Reservations received after August 10, 1993 are subject to
availability and prevailing rates.
The Westin San Francisco will not hold your reservation after 6:00 PM
on the day of arrival without guaranteeing the reservation with a
check or money order in U.S. dollars covering the first night's stay
(including 11% occupancy tax) or a major credit card with expiration
date and authorized signature.
Deposits will be refunded only if cancellation notification is
received at least 24 hours prior to arrival. Check in time is 3:00 PM.
Type of Room Main Building Towers
Single Double Single Double
Standard $120 $120 - -
Medium $135 $135 $155 $155
Deluxe $150 $150 $170 $170
Arrival Date: __________________________________
Departure Date: ________________________________
Name: __________________________________________
Share With: ____________________________________
Address: _______________________________________
_______________________________________
Daytime Telephone: ___________________
Check or Money Order Enclosed in amount:
_ Mastercard _ American Express _ Carte Blanche
_ Visa _ Discover _ Diners Club
Credit Card Holder's Name: _________________
Credit Card No: ____________________________
Expiration Date: ___________________________
Signature: _________________________________
Reservation by fax, dial: +1 774-0292/774-0124
Reservation by phone, dial: +1 415 397-7000
Identify SIGCOMM '93 for conference rates.
**************************************************************************
**************************************************************************
CONFERENCE COMMITTEE
General Chair: Imrich Chlamtac, Univ. Massachusetts
Program Chair: Deepinder Sidhu, Univ. Maryland - BC
Tutorial Chair: Ian F. Akyildiz, Georgia Tech
Local Arrangements Chair: Anujan Varma, Univ. California - Santa Cruz
Treasurer: Lixia Zhang, XEROX PARC
Publicity Chair: Craig Partridge, BBN
Fund Raising Chair: Biswanath Mukherjee, Univ. California - Davis
Registration Chair: Mark Laubach, Hewlett-Packard
INDUSTRIAL SUPPORTERS OF SIGCOMM '93
SIGCOMM '93 would like to thank Digital Equipment Corporation, Hewlett
Packard, International Business Machines Corporation, and XEROX Palo
Alto Research Center for their support of SIGCOMM '93.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24837;
30 Aug 93 11:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24829;
30 Aug 93 11:17 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa12882;
30 Aug 93 11:17 EDT
Received: by bitsy.MIT.EDU
id AA03841; Mon, 30 Aug 93 11:06:37 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA03835; Mon, 30 Aug 93 11:06:05 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA03375; Mon, 30 Aug 93 11:05:52 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <LAA09375 at pad-thai.aktis.com>; Mon, 30 Aug 1993 11:06:19 -0400
Date: Mon, 30 Aug 1993 11:06:19 -0400
Message-Id: <199308301506.LAA09375 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at security.ov.com>
X-Orig-Sender: jik at gza.com
To: cat-ietf at mit.edu
Subject: GSS_Acquire_cred is too inflexible
Overview:
GSS_Acquire_cred has, as far as I can tell, three problems:
1) There is ambiguity about exactly what major status is returned in
some situations.
2) The status returns are not granular enough to return to the
application all of the information that it might want or need.
3) The desired_name argument is not acequate when credentials are
requested for multiple mechanisms using different name types.
Details:
1) If the application requests a certain set of OID's, and only a
proper subset of those OID's can be successfully supported in the
requested credentials, should Acquire_cred return GSS_COMPLETE,
indicating that some credentials were acquired, or GSS_BAD_MECH,
indicating that credentials could not be acquired for one or more of
the requested mechanisms?
I would opt for GSS_COMPLETE, since the created credentials structure
does contain useable credentials, and the actual_mechs set indicates
the mechanism(s) for which credentials were successfully acquired.
However, here is where the lack of granularity creeps in....
2) If credentials cannot be acquired for one or more of the requested
mechanisms, how can the application know why each of the failed
mechanisms failed? It might need this information, especially if the
mechanisms it requested were explicitly requested by a user and it
wants to tell the user which ones failed and why.
3) An application can pass in multiple mechanisms in desired_mechs,
and those mechanisms might require different internal names, but there
is only one internal_name argument to the function.
Proposed solution:
I'm sure that there are a number of different ways in which these
problems might be solved. Here's one proposal:
Add a new function, GSS_Add_cred, which takes the following inputs:
cred_handle - OCTET STRING - handle to existing credentials
created with previous Acquire_cred or Add_cred,
or NULL to indicate that a new credentials
structure should be created
desired_name - as in Acquire_cred
lifetime_req - as in Acquire_cred
desired_mech - OBJECT IDENTIFIER - a single desired mechanism
cred_usage - as in Acquire_cred
Output:
major_status INTEGER
minor_status INTEGER
output_cred_handle OCTET STRING
lifetime_rec INTEGER
If the function succeeds, then output_cred_handle contains a (possibly
changed) handle to credentials, and should be used from now on instead
of the handle specified on input. If the function doesn't succeed,
then the values in major_status and minor_status are known to be
associated with the particular name and mechanism specified, rather
than being ambiguous.
Jonathan Kamens | OpenVision Technologies, Inc. | jik at security.ov.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24948;
30 Aug 93 11:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24937;
30 Aug 93 11:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13080;
30 Aug 93 11:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24925;
30 Aug 93 11:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24887;
30 Aug 93 11:22 EDT
Received: from access.digex.net by CNRI.Reston.VA.US id aa12998;
30 Aug 93 11:22 EDT
Received: by access.digex.net id AA09844
(5.65c/IDA-1.4.4 for ietf at cnri.reston.va.us); Mon, 30 Aug 1993 11:22:19 -0400
Newsgroups: pub.tdarcos.private.mail
Date: Mon, 30 Aug 1993 11:15:28 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Tansin A. Darcos & Company" <0005066432 at mcimail.com>
X-Orig-Sender: "Tansin A. Darcos & Company" <0005066432 at mcimail.com>
Reply-To: "Tansin A. Darcos & Company" <0005066432 at mcimail.com>
Subject: Eureka! (Means 'I found it') on Ads
To: ietf at CNRI.Reston.VA.US
Message-Id: <0119930830111500/0005066432NA1EM-b100000 at MCIMAIL.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
From: Paul Robinson <TDARCOS at MCIMAIL.COM>
Organization: Tansin A. Darcos & Company, Silver Spring, MD USA
-----
Cynthia Clark sent me a notice of the charter of this mailing list
when I subscribed to it. I quote:
The Internet Engineering Task Force (IETF) is the protocol
engineering, development, and standardization arm of the Internet
Architecture Board (IAB).
[deleted]
The IETF mission includes:
[deleted]
5. Providing a forum for the exchange of information within the
Internet community between vendors, users, researchers, agency
contractors, and network managers.
If a mention of a position available for something doesn't fit
into 'exchange of information..between vendors, users...' then I
would be hard pressed to fit anything serious in.
---
Paul Robinson - TDARCOS at MCIMAIL.COM
-----
The following Automatic Fortune Cookie was selected only for this message:
Do not interfere in the religious wars of Usenet, for you are an
easy target and napalm sticks to skin.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25010;
30 Aug 93 11:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25002;
30 Aug 93 11:27 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa13372;
30 Aug 93 11:27 EDT
Received: by bitsy.MIT.EDU
id AA03872; Mon, 30 Aug 93 11:17:21 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA03866; Mon, 30 Aug 93 11:16:50 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA03845; Mon, 30 Aug 93 11:16:41 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <LAA09680 at pad-thai.aktis.com>; Mon, 30 Aug 1993 11:17:08 -0400
Date: Mon, 30 Aug 1993 11:17:08 -0400
Message-Id: <199308301517.LAA09680 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at security.ov.com>
X-Orig-Sender: jik at gza.com
To: cat-ietf at mit.edu
Subject: GSS_Init_sec_context: ambiguity in I-D description
The description of the Init_sec_context call in the I-D contains the
following paragraph:
It is the caller's responsibility to establish a communications path
to the target, and to transmit any returned output_token (independent
of the accompanying returned major_status value) to the target over
that path. The output_token can, however, be transmitted along with
the first application-provided input message to be processed by
GSS_Sign() or GSS_Seal() in conjunction with a successfully-
established context.
A few comments about this paragraph:
First of all, I assume that when it says that output_token must be
transmitted to the target "independent of the accompanying returned
major_status value," I assume that it means that only if the function
returns GSS_COMPLETE or GSS_CONTINUE_NEEDED. I.e., I assume that the
caller should *not* try to transmit any returned output_token if an
error is returned. You might say, "Well, the GSS-API implementation
shouldn't *return* an output_token if there's an error," but it would
not surprise me to see a buggy implementation set the output_token to
something before realizing that there's an error, and the
specification should protect the application programmer from such
errors by being a bit more explicit.
Second, when it says that the output_token can be transmitted along
with a message "to be processed by GSS_Sign() or GSS_Seal(),"
shouldn't it say that the token can be transmitted along with a
message that *has been* processed by one of those functions? In other
words, the client application signs or seals the message *before*
transmission, not after it gets to the server, as "to be processed"
seems to imply.
Third, it is my impression that the intent of that final sentence is
that the client application can transmit an application message along
with the output_token only if Init_sec_context has returned
GSS_COMPLETE. I.e., the client shouldn't be trying to send messages
with the context is still in the process of being established. The
last sentence above does imply that the application input message
shouldn't be read by the server until after the context is
established, but it doesn't imply (from a literal reading) that the
input message can't be *transmitted* before the context is
established. I think this needs to be clarified.
Jonathan Kamens | OpenVision Technologies, Inc. | jik at security.ov.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25205;
30 Aug 93 11:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25197;
30 Aug 93 11:38 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa13790;
30 Aug 93 11:38 EDT
Received: by bitsy.MIT.EDU
id AA03911; Mon, 30 Aug 93 11:27:40 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA03905; Mon, 30 Aug 93 11:27:39 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA04359; Mon, 30 Aug 93 11:27:33 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <LAA09997 at pad-thai.aktis.com>; Mon, 30 Aug 1993 11:28:00 -0400
Date: Mon, 30 Aug 1993 11:28:00 -0400
Message-Id: <199308301528.LAA09997 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at security.ov.com>
X-Orig-Sender: jik at gza.com
To: cat-ietf at mit.edu
Subject: GSS_{Init,Accept}_sec_context need GSS_BAD_MECH return value
The GSS_Init_sec_context function needs to have GSS_BAD_MECH as one of
its possible return values, in case the application specifies a
mechanism in mech_type that is not supported by the GSS-API
implementation.
If an application knows what mechanism it always wants to use, it
should not be necessary for it to call GSS_Indicate_mechs and check if
the one it wants is in the returned set -- it should just be able to
call Init_sec_context and notice from the return value that the
mechanism isn't supported.
Similarly, if a client tries to use a mechanism that is not supported
by a server, then the server should be able to return GSS_BAD_MECH to
indicate that an unsupported mechanism was requested.
Jonathan Kamens | OpenVision Technologies, Inc. | jik at security.ov.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25382;
30 Aug 93 11:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25372;
30 Aug 93 11:42 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa13981;
30 Aug 93 11:42 EDT
Received: by bitsy.MIT.EDU
id AA03945; Mon, 30 Aug 93 11:32:26 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA03934; Mon, 30 Aug 93 11:30:53 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA04504; Mon, 30 Aug 93 11:30:48 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <LAA10018 at pad-thai.aktis.com>; Mon, 30 Aug 1993 11:31:14 -0400
Date: Mon, 30 Aug 1993 11:31:14 -0400
Message-Id: <199308301531.LAA10018 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at security.ov.com>
X-Orig-Sender: jik at gza.com
To: jik at security.ov.com
Cc: cat-ietf at mit.edu
In-Reply-To: <199308301517.LAA09680 at pad-thai.aktis.com> (jik at security.ov.com)
Subject: Re: GSS_Init_sec_context: ambiguity in I-D description
A few minutes ago, I wrote...
First of all, I assume that when it says that output_token must be
transmitted to the target "independent of the accompanying returned
major_status value," I assume that it means that only if the function
returns GSS_COMPLETE or GSS_CONTINUE_NEEDED. I.e., I assume that the
caller should *not* try to transmit any returned output_token if an
error is returned. You might say, "Well, the GSS-API implementation
shouldn't *return* an output_token if there's an error," but it would
not surprise me to see a buggy implementation set the output_token to
something before realizing that there's an error, and the
specification should protect the application programmer from such
errors by being a bit more explicit.
I just realized that I was confused and the I-D is correct. It
certainly might be necessary in some mechanisms to send a token to the
server even when an error is returned, especially if this isn't the
first time that Init_sec_context is being called. Therefore,
output_token won't be set unless there is something that needs to be
returned, so the I-D is correct.
The other two points in my message still stand.
Jonathan Kamens | OpenVision Technologies, Inc. | jik at security.ov.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26403;
30 Aug 93 12:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26396;
30 Aug 93 12:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16113;
30 Aug 93 12:39 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26384;
30 Aug 93 12:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26345;
30 Aug 93 12:36 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa15968;
30 Aug 93 12:36 EDT
Received: from itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-13)
id <AA11293>; Mon, 30 Aug 1993 09:36:56 -0700
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA14585; Mon, 30 Aug 93 12:36:54 EDT
Date: Mon, 30 Aug 93 12:36:54 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ran Atkinson <atkinson at itd.nrl.navy.mil>
Message-Id: <9308301636.AA14585 at itd.nrl.navy.mil>
To: ietf at isi.edu
Subject: advertising
I agree with those who are bothered by the advertising on the IETF
list. If the current charter is ambiguous, perhaps the most useful
thing might be to explicitly revise the charter to state that
advertising is not appropriate. There are other fora on the net where
advertising might be appropriate (e.g. USENET's misc.jobs.offered or
comp.newprod); the IETF list really isn't the right place for that
sort of thing.
Ran
atkinson at itd.nrl.navy.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26747;
30 Aug 93 13:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26743;
30 Aug 93 13:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17086;
30 Aug 93 13:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26734;
30 Aug 93 13:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26730;
30 Aug 93 13:05 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa17063;
30 Aug 93 13:06 EDT
Received: by ginger.lcs.mit.edu
id AA20788; Mon, 30 Aug 93 13:05:50 -0400
Date: Mon, 30 Aug 93 13:05:50 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9308301705.AA20788 at ginger.lcs.mit.edu>
To: 0005066432 at mcimail.com, ietf at CNRI.Reston.VA.US
Subject: Re: I love being our own standards body...
Cc: iesg at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
<From ietf/1ietf-description.txt:>
The Internet Engineering Task Force (IETF) is the protocol engineering,
development, and standardization arm of the Internet Architecture Board
(IAB). ...
The IETF mission includes:
...
5. Providing a forum for the exchange of information within the Internet
community between vendors, users, researchers, agency contractors, and
network managers.
Thanks for pointing out this loophole.
So, we have to reword the last bullet to be "exchange of information direcly
related to both the general goal above, and the specific missions above,
within the Internet community," etc, to correctly codify things. This is not
an RFC, or anything, it's just an IETF Secretariat informational document. (It
is reproduced in RFC1391, which is an informational FYI of Gary Malkin's.)
Steve Coya, perhaps you could make this happen? I assume this is OK with the
IESG, yah?
Someday, we should get energetic and publish an IETF Charter (by analogy with
RFC-1358, "Charter of IAB"); RFC-1310 talks about the standards process, but
not about how the IETF itself runs. Sigh, more formality...
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26985;
30 Aug 93 13:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26979;
30 Aug 93 13:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17515;
30 Aug 93 13:15 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26969;
30 Aug 93 13:15 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa26965;
30 Aug 93 13:15 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: rmonmib at jarthur.claremont.edu
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Token Ring Extensions to the Remote Network
Monitoring MIB to Proposed Standard
Date: Mon, 30 Aug 93 13:15:12 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308301315.aa26965 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "Token Ring Extensions to
the Remote Network Monitoring MIB" <draft-ietf-rmonmib-trmib-01.txt>
as a Proposed Standard. This document is the product of the Remote
LAN Monitoring Working Group. The IESG contact person is Marshall
Rose.
Technical Summary
The Remote Network Monitoring MIB, RFC 1271, defines a framework for
remote monitoring functions implemented on a network probe. That
MIB defines objects broken down into nine functional groups. Some
of those functional groups, the statistics and the history groups,
have a view of the data-link layer that is specific to the media
type and require specific objects to be defined for each media type.
RFC 1271 defined those specific objects necessary for Ethernet. This
companion memo defines those specific objects necessary for Token
Ring LANs.
In addition, this memo defines some additional monitoring functions
specifically for Token Ring. These are defined in the Ring Station
Group, the Ring Station Order Group, the Ring Station Configuration
Group, and the Source Routing Statistics Group.
Working Group Summary
There was no significant contention in the working group.
Protocol Quality
The IESG Area Director for Network Management has reviewed the
specification. Implementations are in progress.
Notes to the RFC editor (upon publication)
1. Please change the module name from RFCxxxx-MIB to
XXXX-MIB
2. Please check with the IESG Area Director for Network Management
for OID assignments in Section 7.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27139;
30 Aug 93 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27131;
30 Aug 93 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17601;
30 Aug 93 13:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27095;
30 Aug 93 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27014;
30 Aug 93 13:16 EDT
Received: from SGI.COM by CNRI.Reston.VA.US id aa17541; 30 Aug 93 13:16 EDT
Received: by sgi.sgi.com (920330.SGI/910110.SGI)
id AA18693; Mon, 30 Aug 93 10:00:51 -0700
To: ietf at nri.reston.va.us
Reply-To: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
X-Approved: newsmail at sgi.sgi.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Subject: Re: Eureka! (Means 'I found it') on Ads
Message-Id: <k4ffgie at rhyolite.wpd.sgi.com>
Date: Mon, 30 Aug 1993 16:56:33 GMT
"Tansin A. Darcos & Company" <0005066432 at mcimail.com> writes:
> ...
> 5. Providing a forum for the exchange of information within the
> Internet community between vendors, users, researchers, agency
> contractors, and network managers.
>
> If a mention of a position available for something doesn't fit
> into 'exchange of information..between vendors, users...' then I
> would be hard pressed to fit anything serious in.
How many positions are involved in running the Internet?
One per connected network seems low. How many networks are we up to?
Interop expected 40,000 people in San Francisco last week. Let's take
a round number, 10,000 positions of interest.
3 years is a very long time to stay in a single job, so let's take a
turn over rate of 3 years.
That calculation implies that there would be more than 10 position
announcments per day should a significant fraction of the "vendors,
users, ..." use the IETF mailing list for recruiting.
How many position announcements appear each day in the misc.jobs
netnews hierachy? How many position announcements appear each Sunday
and Monday in the San Jose "Mercury News"? How many in the
"Communications of the ACM"? Imagine what would happen if everyone
with an equally good excuse used the IETF mailing lists for broadcast
headhunting.
My guess is that the same kinds of vigilantism as happens in usenet
would limit the problem, "letter bombs" and "sendsys bombing."
(I wouldn't do such things, but there are readers of these mailing
lists who seem less temporate than I think I am.)
Vernon Schryver, vjs at sgi.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27300;
30 Aug 93 13:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27293;
30 Aug 93 13:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17831;
30 Aug 93 13:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27281;
30 Aug 93 13:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27214;
30 Aug 93 13:22 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17777;
30 Aug 93 13:22 EDT
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by venera.isi.edu (5.65c/5.61+local-13)
id <AA12773>; Mon, 30 Aug 1993 10:22:24 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa26897;
30 Aug 93 13:11 EDT
To: Ran Atkinson <atkinson at itd.nrl.navy.mil>
Cc: ietf at isi.edu
Subject: Re: advertising
In-Reply-To: Your message of "Mon, 30 Aug 93 12:36:54 EDT."
<9308301636.AA14585 at itd.nrl.navy.mil>
Date: Mon, 30 Aug 93 13:11:27 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-Id: <9308301311.aa26897 at IETF.CNRI.Reston.VA.US>
I am strongly in favor of specifying content limits for mailing
lists - as expressed by the members of the list. For IETF, if
I had a choice, I would prefer no advertising or, a minimum of
the form "see X for info on Y" where X might be a gopher or other
list pointer and Y might be some product or service. It would be
better to have a list distinct from IETF which is intended to
convey product and service information and which we could elect
to receive of not - that's all my personal opinion as a recipient
of much email.
vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28186;
30 Aug 93 13:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28177;
30 Aug 93 13:49 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa20119;
30 Aug 93 13:49 EDT
Received: by bitsy.MIT.EDU
id AA04355; Mon, 30 Aug 93 13:38:20 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA04348; Mon, 30 Aug 93 13:37:03 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA09243; Mon, 30 Aug 93 13:36:58 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <NAA13118 at pad-thai.aktis.com>; Mon, 30 Aug 1993 13:37:24 -0400
Date: Mon, 30 Aug 1993 13:37:24 -0400
Message-Id: <199308301737.NAA13118 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at security.ov.com>
X-Orig-Sender: jik at gza.com
To: cat-ietf at mit.edu
Subject: Comments about John Wray's GSS-API C-bindings I-D
I just finished reading John Wray's Internet Draft proposing C
bindings for GSS-API, and I have a number of comments and questions
about it.
Please forgive me if some of these have been brought up on the mailing
list before; I just started reading it.
Comments about the ideas in the Draft are marked with asterisks; minor
corrections to the text are marked with hyphens instead.
* The document appears to assume that only security mechanisms
involving cryptographic technique are suitable as GSS-API
mechanisms.
Examples.... Section 2 says that GSS-API "is intended for
implementation atop alternative underlying cryptographic
mechanisms." Section 3 says that a token is a "cryptographically
protected... data type." Second 4.1.7 says that the security
context holds "cryptographic state information." Section 5.8 and
5.10 say that gss_sign and gss_seal generate "cryptographic
signatures." There probably other instances of this, but you get
the idea.
My question is, are cryptographic algorithms *really* required of
any mechanism with a GSS-API interface? I guess it's understandable
for gss_sign and gss_seal to expect to use cryptographic algorithms
to generate signatures and/or encrypt data. But if integrity and
encryption are not supported, why does any cryptographic technology
have to be present at all?
Perhaps it is true that network security mechanisms that don't use
cryptography are bound to be less secure than cryptographic
mechanisms (a.k.a. "strong authentication). However, just because
they're less secure doesn't mean that people won't want GSS-API
implementations of them; it seems to me, therefore, that the
assumption of the presence of cryptographic algorithms in supported
mechanisms is somewhat "religious."
I would amend Section 2 to say "underlying authentication
mechanisms," amend Section 3 to say that tokens are *possibly*
cryptographically protected (or just remove "cryptographically
protected" completely), and amend Section 4.1.7 to say that the
security context *might* hold cryptographic state information.
* When a character string is returned in a gss_buffer_t datatype, is
it null-terminated, and is the null included as part of the length
of the string?
- In Section 4.1.6, "relavent" should be "relevant".
* Section 4.1.6 claims that a credential handle can be implemented as
"either an arithmetic or a pointer type." This seems to conflict
with Linn's GSS-API I-D, which says that handles should be octet
strings. Who's wrong, Wray or Linn :-)?
* Section 4.1.9 refers to "GSS status codes" and "Mechanism status
codes". These appear to be pretty much equivalent to the Major and
Minor status codes described in Linn's document. In fact, Wray's
paper appears to use "Minor status" and "Mechanism status"
interchangeably. If they are equivalent, why the new terminology?
* What is the motivation behind GSS_S_CALL_INACCESSIBLE_*? I can see
that it *might* be useful on a PC, although I don't know enough
about PC programming to know for sure, but I question whether it
would be wise to attempt to detect such problems on a UNIX box. Is
the implementation supposed to trap SIGSEGV or something to notice
when a reference is made to an invalid pointer?
- In Section 4.1.9.2, "set set" should probably say "be set".
- Section 5.1 should say "may choose" rather than "may chooses".
* Section 5.3's description of gss_init_sec_context says, "Initiates
the establishment of a security context...." That's not completely
accurate, because the function both initiates the establishment of
the security context and handles subsequent tokens in the exchange
(until GSS_C_COMPLETE is returned). It seems to me that it would be
more accurate to start the description, "Handles the
establishment...."
- The document uses adjectival phrases that should be hyphenated in a
large number of places without hyphens. The most common instances
of this are the many references to "Mechanism specific status" and
"Implementation specific status"; those should be
"Mechanism-specific status" and "Implementation-specific status".
* The document appears to use the terms "Mechanism-specific status"
and "Implementation-specific status" interchangeably, but it seems
to me that these terms are *not* interchangeable. If a mechanism is
specified by an I-D or RFC, then it seems to me that that mechanism
will have the same status codes in all implementations. Therefore,
"mechanism-specific status" seems correct, and
"implementation-specific status" misleading (and, again, unnecessary
new terminology). Am I missing something?
* Linn's document says that GSS_Display_status should return a set of
strings. The C binding says that instead, the application must
iterate until all strings are retrieved. Why the difference?
* Gss_display_status takes both minor_status and status_value
arguments. However, if the function is always used to interpret
*either* a GSS code *or* a mechanism code, but never both, why are
both arguments needed? Only one code is being interpreted, so it
should only be necessary to pass in one code. Again, am I missing
something?
Jonathan Kamens | OpenVision Technologies, Inc. | jik at security.ov.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28950;
30 Aug 93 14:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28943;
30 Aug 93 14:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23170;
30 Aug 93 14:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28928;
30 Aug 93 14:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28871;
30 Aug 93 14:25 EDT
Received: from Csli.Stanford.EDU by CNRI.Reston.VA.US id aa23132;
30 Aug 93 14:25 EDT
Received: by CSLI.Stanford.EDU (4.1/25-CSLI-eef) id AA19857; Mon, 30 Aug 93 11:25:30 PDT
Date: Mon, 30 Aug 93 11:25:27 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ole J. Jacobsen" <ole at csli.stanford.edu>
To: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Cc: ietf at CNRI.Reston.VA.US
Phone: +1 415 941-3399 (Interop) or 1-800-INTEROP
Or: +1 415 550-9427 (Home) or +1 415 990-9427 (Cellular)
Direct: +1 415 962-2515 (Office) +1 415 998-4427 (Pager)
Fax: +1 415 949-1779 (Interop) +1 415 826-2008 (Home)
X-Comment: Ignore error messages for "ole at radiomail.net"
Subject: Re: Eureka! (Means 'I found it') on Ads
In-Reply-To: Your message of Mon, 30 Aug 1993 16:56:33 GMT "Tansin A. Darcos
& Company" <0005066432 at mcimail.com> writes:
Message-Id: <CMM.0.90.4.746735127.ole at Csli.Stanford.EDU>
Just a slight correction: Interop expected more than 55,000 last week,
the actual final number was over 65,000.
Ole
Ole J Jacobsen, Editor & Publisher, ConneXions--The Interoperability Report
Interop Company, 480 San Antonio Road,Mountain View, CA 94040-1219, USA
Phone: +1 (415) 962-2515 FAX: +1 (415) 949-1779 E-mail: ole at interop.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29163;
30 Aug 93 14:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29150;
30 Aug 93 14:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23408;
30 Aug 93 14:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29137;
30 Aug 93 14:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29046;
30 Aug 93 14:30 EDT
Received: from sayshell.umd.edu by CNRI.Reston.VA.US id aa23285;
30 Aug 93 14:30 EDT
Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0)
id AA29375; Mon, 30 Aug 93 14:30:09 -0400
Message-Id: <9308301830.AA29375 at sayshell.umd.edu>
To: "Tansin A. Darcos & Company" <0005066432 at mcimail.com>
Cc: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Louis A. Mamakos" <louie at ni.umd.edu>
Subject: Re: Eureka! (Means 'I found it') on Ads
In-Reply-To: Your message of "Mon, 30 Aug 1993 11:15:28 EDT."
<0119930830111500/0005066432NA1EM-b100000 at MCIMAIL.COM>
Date: Mon, 30 Aug 1993 14:30:09 -0400
X-Orig-Sender: louie at sayshell.umd.edu
> 5. Providing a forum for the exchange of information within the
> Internet community between vendors, users, researchers, agency
> contractors, and network managers.
>
> If a mention of a position available for something doesn't fit
> into 'exchange of information..between vendors, users...' then I
> would be hard pressed to fit anything serious in.
Fine.
"Does anyone know how to install a 3COM 3C501 card in an IBM RT/PC?"
I'm a network manager, asking a vendor, user, or anyone else about
"information". I don't think this is appropriate traffic for the
list, nor the discussed job posting either.
It's just a matter of common sense and consideration of the PURPOSE of
this list based on the spirit of the charter. Perhaps this silly list
should be moderated to put a stop to postings like this. Feh.
Louis A. Mamakos
University of Maryland, College Park
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29859;
30 Aug 93 14:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29852;
30 Aug 93 14:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24117;
30 Aug 93 14:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29822;
30 Aug 93 14:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29767;
30 Aug 93 14:53 EDT
Received: from mon.cise.nsf.gov by CNRI.Reston.VA.US id aa24048;
30 Aug 93 14:53 EDT
Received: by mon.cise.nsf.gov (920330.SGI/920502.SGI)
for ietf at CNRI.Reston.VA.US id AA09977; Mon, 30 Aug 93 14:53:26 -0500
Date: Mon, 30 Aug 1993 14:47:29 -0500 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Stephen Wolff <steve at mon.cise.nsf.gov>
Subject: Re: [InterNIC] Information Service Manager Position]
To: ietf at CNRI.Reston.VA.US
In-Reply-To: <9308251837.AA16549 at umd5.umd.edu>
Message-Id: <Pine.3.07.9308301427.H9679-8100000 at mon.cise.nsf.gov>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
The "Help Wanted" ad was issued at my direction. I did not know that the
IETF had elected to prohibit job ads on its mailing list, and I apologize
to the list members for the breach of etiquette. -s
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29928;
30 Aug 93 14:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29924;
30 Aug 93 14:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24191;
30 Aug 93 14:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29915;
30 Aug 93 14:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29911;
30 Aug 93 14:58 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa24186;
30 Aug 93 14:58 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA16187; Mon, 30 Aug 93 14:58:25 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA10714; Mon, 30 Aug 93 14:58:24 EDT
Message-Id: <9308301858.AA10714 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: 0005066432 at mcimail.com, ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: Re: I love being our own standards body...
In-Reply-To: Your message of "Mon, 30 Aug 93 13:05:50 EDT."
<9308301705.AA20788 at ginger.lcs.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 30 Aug 93 14:58:24 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
How about starting an 'ietf-pondscum' mailing list, or using com-priv?
ObInternet: Does anybody have any pointers to experiments on determining topological
relationships between multiple sites using traceroute? I know this technique has
major flaws, but has anybody determined just how bad these really are in real life?
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00139;
30 Aug 93 15:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00131;
30 Aug 93 15:01 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa24276;
30 Aug 93 15:01 EDT
Received: by bitsy.MIT.EDU
id AA04594; Mon, 30 Aug 93 14:46:40 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA04581; Mon, 30 Aug 93 14:44:35 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA12102; Mon, 30 Aug 93 14:44:29 EDT
Received: by inet-gw-2.pa.dec.com; id AA08719; Mon, 30 Aug 93 11:44:16 -0700
Received: by us1rmc.bb.dec.com; id AA15006; Mon, 30 Aug 93 14:42:53 -0400
Message-Id: <9308301842.AA15006 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Mon, 30 Aug 93 14:42:58 EDT
Date: Mon, 30 Aug 93 14:42:58 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 30-Aug-1993 1355" <wray at tuxedo.enet.dec.com>
To: jik at security.ov.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, jik at security.ov.com
Subject: RE: Comments about John Wray's GSS-API C-bindings I-D
Jonathan,
>* When a character string is returned in a gss_buffer_t datatype, is
> it null-terminated, and is the null included as part of the length
> of the string?
The length field should describe the actual data - ie the printable characters.
A GSSAPI implementation is free to add a trailing NULL, not included in the
length field, but portable applications should use the length field to
determine how many characters are in the string.
The rationale for this is that one of the design goals of the C-bindings was to
provide a foundation for easy construction of bindings for other languages, and
most other languages don't use NULL-terminated strings. The most common thing
that an application will want to do with a string returned from a GSSAPI
routine is to print it, and that can easily be accomplished direct from the
length/pointer in a gss_buffer_t object via a "%.*s" format string.
>* Section 4.1.6 claims that a credential handle can be implemented as
> "either an arithmetic or a pointer type." This seems to conflict
> with Linn's GSS-API I-D, which says that handles should be octet
> strings. Who's wrong, Wray or Linn :-)?
John Linn's spec describes the GSSAPI at a conceptual level. The C bindings
describe a concrete realisation of the GSSAPI. John used "OCTET STRING" to
imply opaque (or at least not further defined) data, and the "handle"
terminology means the allowed operations are assignment and comparison. For the
C language, pointers and arithmetic types allow these operations.
>* Section 4.1.9 refers to "GSS status codes" and "Mechanism status
> codes". These appear to be pretty much equivalent to the Major and
> Minor status codes described in Linn's document. In fact, Wray's
> paper appears to use "Minor status" and "Mechanism status"
> interchangeably. If they are equivalent, why the new terminology?
To avoid being repetitious? :-)
Yes, GSS status codes are major status codes, and mechanism status codes are
minor status codes. I used "GSS" & "Mechanism" because I felt these terms
imparted more meaning than "Major" and "Minor", as they typically describe
where (in the implementation) the status codes originate.
A major/GSS status code is what a portable application should use to make
decisions about what to do next. A non-portable application can use
minor/mechanism codes if it wishes. Minor/mechanism codes are expected to
translate to more meaningful error messages for display to the user.
>* What is the motivation behind GSS_S_CALL_INACCESSIBLE_*? I can see
> that it *might* be useful on a PC, although I don't know enough
> about PC programming to know for sure, but I question whether it
> would be wise to attempt to detect such problems on a UNIX box. Is
> the implementation supposed to trap SIGSEGV or something to notice
> when a reference is made to an invalid pointer?
The bindings document should explicitly say that an implementation is free to
raise signals rather than return these status values. However, there's no
guarantee that a particular C implementation will ever raise SIGSEGV (or any
other signal) except via an explicit call of raise().
>* Linn's document says that GSS_Display_status should return a set of
> strings. The C binding says that instead, the application must
> iterate until all strings are retrieved. Why the difference?
Similar comments here as to the above query about OCTET STRINGs. If we'd
actually returned a SET-OF-STRING datatype, we'd have had to provide an extra
function to deallocate its storage. It was simpler to use an iterative
approach, where each iteration returned a single string via a gss_buffer_t
object, for which there is already a deallocator. Conceptually, the routine's
returning a set of strings, it's just delivering them to the application one at
a time.
>* Gss_display_status takes both minor_status and status_value
> arguments. However, if the function is always used to interpret
> *either* a GSS code *or* a mechanism code, but never both, why are
> both arguments needed? Only one code is being interpreted, so it
> should only be necessary to pass in one code. Again, am I missing
> something?
The minor_status parameter is an output, just the same as any other GSSAPI
routines. In practice, there's not much useful info that would ever be
returned from DISPLAY_STATUS, but it's there for consistency's sake.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01155;
30 Aug 93 15:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01143;
30 Aug 93 15:58 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa26221;
30 Aug 93 15:58 EDT
Received: by bitsy.MIT.EDU
id AA04816; Mon, 30 Aug 93 15:46:37 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA04810; Mon, 30 Aug 93 15:46:21 EDT
Received: from relay.pipex.net by MIT.EDU with SMTP
id AA14610; Mon, 30 Aug 93 15:46:15 EDT
Received: from Q.icl.co.uk by relay.pipex.net with SMTP (PP)
id <14484-0 at relay.pipex.net>; Mon, 30 Aug 1993 20:45:54 +0100
Received: from ming.oasis.icl.co.uk ([144.123.18.51])
by Q.icl.co.uk (4.1/icl-2.5-server) id AA04571;
Mon, 30 Aug 93 20:47:11 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA05271;
Mon, 30 Aug 93 20:47:46 BST
Message-Id: <9308301945.AA26106 at getafix.oasis.icl.co.uk>
Date: Mon, 30 Aug 93 20:45:11 BST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: P.V.McMahon.rea0803 at oasis.icl.co.uk
Reply-To: P.V.McMahon.rea0803 at oasis.icl.co.uk
Subject: RE: GSS_Init_sec_context: ambiguity in I-D description
To: jik at security.ov.com
Cc: cat-ietf at mit.edu
Priority: URGENT
Jonathan,
Re: gss_init_sec_context ambiguity
----------------------------------
I have not found the description to be ambiguous.
However, it would be a concern if application writers
had problems interpreting the spec, so in general I would
encourage any helpful, non-redundant, clarifying
additions to the GSS-API specifications which don't
make technical changes, and which are agreed to be
necessary by the CAT WG.
It is likely that publication as an RFC, and as an X/Open
Preliminary Spec will attract additional rewording or
clarification suggestions as more people read and
seek to interpret the GSS-API.
Regards,
Piers
-------------------------------------------------------
Piers McMahon 30AUG93
ICL
post: Kings House, 33 Kings Road, Reading, RG1 3PX, UK
email: p.v.mcmahon at rea0803.wins.icl.co.uk
OR p.mcmahon at xopen.co.uk
phone: +44 734 586211 extension 3285
fax: +44 734 855106
-------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01187;
30 Aug 93 15:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01179;
30 Aug 93 15:59 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa26263;
30 Aug 93 15:59 EDT
Received: by bitsy.MIT.EDU
id AA04855; Mon, 30 Aug 93 15:49:19 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA04830; Mon, 30 Aug 93 15:47:14 EDT
Received: from relay.pipex.net by MIT.EDU with SMTP
id AA14661; Mon, 30 Aug 93 15:47:04 EDT
Received: from Q.icl.co.uk by relay.pipex.net with SMTP (PP)
id <14511-0 at relay.pipex.net>; Mon, 30 Aug 1993 20:46:30 +0100
Received: from ming.oasis.icl.co.uk ([144.123.18.51])
by Q.icl.co.uk (4.1/icl-2.5-server) id AA04592;
Mon, 30 Aug 93 20:47:39 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA05280;
Mon, 30 Aug 93 20:48:13 BST
Message-Id: <9308301945.AA26236 at getafix.oasis.icl.co.uk>
Date: Mon, 30 Aug 93 20:45:39 BST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: P.V.McMahon.rea0803 at oasis.icl.co.uk
Reply-To: P.V.McMahon.rea0803 at oasis.icl.co.uk
Subject: RE: GSS_(Init,Accept)_sec_context need GSS_BAD_MECH return value
To: jik at security.ov.com
Cc: cat-ietf at mit.edu
Priority: URGENT
Jonathan,
re: gss_init_sec_context GSS_S_BAD_MECH
---------------------------------------
I agree that GSS_S_BAD_MECH might be a possible return from this
function in the situation you describe. I think we use
GSS_S_NO_CRED for this case, which may be inappropriate
overloading ...
The distinction, however, would only affect a GSS-API user
that was written in a mech_type-specific way. While users
can require a specific mech_type, it should be normally be
up the GSS-API implementation to resolve the default
to be used when given an input "mech_type" argument of
GSS_C_NULL_OID.
Regards,
Piers
-------------------------------------------------------
Piers McMahon 30AUG93
ICL
post: Kings House, 33 Kings Road, Reading, RG1 3PX, UK
email: p.v.mcmahon at rea0803.wins.icl.co.uk
OR p.mcmahon at xopen.co.uk
phone: +44 734 586211 extension 3285
fax: +44 734 855106
-------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01493;
30 Aug 93 16:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01486;
30 Aug 93 16:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26742;
30 Aug 93 16:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01464;
30 Aug 93 16:11 EDT
Received: from corp.timeplex.com by IETF.CNRI.Reston.VA.US id aa01417;
30 Aug 93 16:10 EDT
Received: from mr.timeplex.com by sys30.timeplex.com (PMDF #2740 ) id
<01H2D297D9TY8WX0P1 at sys30.timeplex.com>; Mon, 30 Aug 1993 16:13:17 EDT
Received: with PMDF-MR; Mon, 30 Aug 1993 16:13:08 EDT
Date: 30 Aug 1993 16:12:50 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Malis_A <MALISAB at corp.timeplex.com>
Subject: RE: advertising
To: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Cc: ietf <ietf at IETF.CNRI.Reston.VA.US>
Message-id: <01H2D2979SFO8WX0P1 at mr.timeplex.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
UA-content-id: RE: advertising
X-Hop-count: 1
A1-type: MAIL
To : Vinton G. Cerf
Cc : ietf
Date: 30-AUG-1993 16:12:50.00
> It would be better to have a list distinct from IETF which is intended
> to convey product and service information and which we could elect to
> receive of not - that's all my personal opinion as a recipient of much
> email.
comp.protocols.tcp-ip is probably the best place, since it's germane to the
newsgroup and it's pretty easy to filter incoming news (at least with most
newsreaders).
Andy
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02777;
30 Aug 93 18:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02359;
30 Aug 93 18:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02761;
30 Aug 93 18:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02725;
30 Aug 93 18:09 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa02269;
30 Aug 93 18:09 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA24899>; Mon, 30 Aug 1993 15:09:07 -0700
Message-Id: <199308302209.AA24899 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: STD1, RFC1500 on Internet Standards
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Mon, 30 Aug 93 15:08:57 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
STD 1:
RFC 1500:
Title: INTERNET OFFICIAL PROTOCOL STANDARDS
Author: J. Postel, Editor
Mailbox: postel at isi.edu
Pages: 36
Characters: 79,557
Obsoletes: 1410
This memo describes the state of standardization of protocols used in
the Internet as determined by the Internet Architecture Board (IAB).
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be added
to or deleted from the RFC-DIST distribution list should be sent to
RFC-REQUEST at NIC.DDN.MIL.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to "rfc-info at ISI.EDU" with the message body
"help: ways_to_get_rfcs". For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to NIC.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND rfc1500.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1500.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03437;
30 Aug 93 19:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03433;
30 Aug 93 19:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03742;
30 Aug 93 19:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03423;
30 Aug 93 19:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03419;
30 Aug 93 19:08 EDT
Received: from PO5.ANDREW.CMU.EDU by CNRI.Reston.VA.US id aa03735;
30 Aug 93 19:08 EDT
Received: from localhost (postman at localhost) by po5.andrew.cmu.edu (8.5/8.5) id TAA29313; Mon, 30 Aug 1993 19:08:38 -0400
Received: via switchmail; Mon, 30 Aug 1993 19:08:37 -0400 (EDT)
Received: from zeus.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/service/mailqs/q003/QF.AgUcUoW00WArM0PdZs>;
Mon, 30 Aug 1993 19:07:32 -0400 (EDT)
Received: from zeus.andrew.cmu.edu via qmail
ID </afs/andrew.cmu.edu/usr5/sw0l/.Outgoing/QF.YgUcUje00WArEDckJL>;
Mon, 30 Aug 1993 19:07:27 -0400 (EDT)
Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.zeus.andrew.cmu.edu.sun4c.411
via MS.5.6.zeus.andrew.cmu.edu.sun4c_411;
Mon, 30 Aug 1993 19:07:19 -0400 (EDT)
Message-ID: <sgUcUbS00WArEDck8z at andrew.cmu.edu>
Date: Mon, 30 Aug 1993 19:07:19 -0400 (EDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Steven L. Waldbusser" <sw0l+ at andrew.cmu.edu>
To: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: re: HR MIB comments
-------------------------------------------
Date: Sat, 28 Aug 1993 14:07:15 -0400 (EDT)
From: "Steven L. Waldbusser" <sw0l+ at andrew.cmu.edu>
To: ietf at cnri.reston.va.us, -SMF71- at mhs.novell.de, iesg at cnri.reston.va.us
Subject: Re: HR MIB comments
CC: JLINNEY at mhs.novell.de, JCONSTAN at mhs.novell.de, GLENNSTE at mhs.novell.de
> The following is a collection of various points I came across during an
> implementation of the HR MIB for DOS (no particular order):
Thanks for the comments. I invite you to join the hostmib mailing
list to discuss your experiences. To join send mail to
hostmib-request at andrew.cmu.edu.
> 1. Several tables in the HR MIB use ObjectIDs to denote the type of a
> particular table entry. For example, the type of entries in
> hrStorageTable is specified by one of the sub-nodes of hrStorageTypes. An
> example would be a value of 1.3.6.1.36.2.1.4 to indicate that this entry
> in the storage table is a fixed disk and 1.3.6.1.36.2.1.6 to indicate
> that it is a floppy. In the hrDiskStorageTable however (which also
> represents storage media and hence replicates some of the data of the
> other table), such types are represented by an enumerated integer
> (similar to the "C" enum statement), so for example, 3 means a hard disk
> and 4 means a floppy.
>
> The former method is also used for the type in the device table and in
> the file system table whereas the latter is also used for the device
> status in the device table, the printer status in the printer table, the
> file system access mode, the software run type, the software run status
> and the software installed type.
>
> The first example already shows that the choice of method seems to have
> been made arbitrarily. Personally, I find the ObjID method very clumsy
> (difficult to handle on both the agent and the console side).
Object Identifiers are easily extensible, while enumerations are not.
The problem with extensibility is that a management station may
retrieve a value that it doesn't understand. If extensibility is not
required, enumerations should definitely be used in a MIB design
because they rarely get out of sync between management station and
agent. These criteria guided the choice of enumerations or oids for
the relevant objects in the MIB and were applied consistently.
> The enumerated method has its problems: If the MIB browser is used (as
> opposed to a custom application) there is no provision within MIBs to
> separate logical strings from their actual (human language specific)
> instance. If I define in a MIB for example that a particular variable
> 'switch' can take the values 'switched-on' or 'switched-off' these very
> same English words are displayed by the browser. There is no facility to
> translate this into Spanish, for example, without changing the MIB
> definition file itself. The ObjectId method is hardly superior since
> strings like 1.3.6.1.36.2.1.4 are unintelligible to both English and
> Spanish speakers (at least it's fair on both...)
Let me emphasize that this is only an issue for MIB browsers. Smarter
applications (even enlightened MIB browsers) can replace these strings
with strings in another language. As long as MIB browsers
(incorrectly) use the MIB specification as an application description
language, this problem will exist (unless we re-write every MIB in
every known language!). This is a general issue, beyond the scope
of the Host MIB or enumerations.
> 2. The description of 'hrNetworkIfIndex' in the HR MIB refers to a
> variable 'ifIndex' that is not mentioned anywhere else in the MIB
> definition. What is that variable and how does it relate to
> 'hrNetworkIfIndex' and 'hrDeviceIndex'? Does it actually refer to a
> different MIB?
This is ifIndex from MIB-II. This is the reason that the introductory
text requires the implementation of the interfaces group of MIB-II.
> 3. I noticed that the Host Resource MIB defines hrStorageSize as having
> read/write access. I'm puzzled by the meaning of performing a SET
> operation on e.g. the RAM size or the size of a hard disk: Surely I
> can't "remotely" upgrade my machine by simply telling it that is really
> has more RAM or a bigger drive than it thought?
This capability was added so that one can configure the allocation of
memory between several pools. The best example exists on a PC when
configuring the sizes of conventional, expanded and extended memory.
> 4. How will the console know the unit of timer ticks for systemUpTime
> since the tick rate differs between different machines?
The console will not know. This object is not intended to be used by
the management station to keep time. It is intended to be used to
tell how long the system has been up. No interest was expressed in
the working group for retrieval of the tick rate.
> 5. Error status information for printers is returned in the printer
> table. There doesn't appear to be any link between printer table entries
> and parallel or serial ports in the device table. If the hardware
> provides the error information on a per-port basis, how can it be made
> available on a per-printer basis? There should really be a logical
> connection between printers and ports!
This doesn't make sense. The agent either has enough OS/hardware
support to instrument printers or it doesn't. Adding more
instrumentation is not going to make it more successful. I really
don't see a problem here.
> 6. Product IDs (Object IDs) to denote hardware or software are useless
> without a published list of such IDs since otherwise they won't be
> available for either HR MIB implementors or management console writers.
I will be offering a registration service for Product IDs. This will
include publication of IDs registered by organizations, as well as
registration and publication of IDs for organizations who can't or
won't register their own IDs. This will be discussed on the hostmib
mailing list in the next couple of weeks (hostmib at andrew.cmu.edu).
> 7. Both the hrStorageTable and the hrDiskStorageTable refer to
> unpartitioned (physical) disks, not to drives as seen by DOS (i.e.
> partitions). The hrDiskStorageTable kind of repeats the hrStorageTable.
The hrStorageTable bears no resemblance to the hrDiskStorageTable.
While the hrDiskStorageTable does describe physical disks, the
hrStorageTable is described in the MIB as:
"This table is intended to be a useful diagnostic for `out of memory'
and `out of buffers' types of failures. In addition, it can be a
useful performance monitoring tool for tracking memory, disk, or buffer
usage."
In other words, it is a fault/performance tracking tool for any type
of storage: disk, memory, or even logical forms of storage.
> While the hrStorageTypes distinguish between hrStorageFixedDisk and
> hrStorageRemovableDisk, hrDiskStorageMedia only knows 'hardDisk'. On the
> other hand, where hrDiskStorageMedia knows about opticalDiskROM,
> opticalDiskWORM and opticalDiskRW, hrStorageTypes only know about
> hrStorageCompactDisk. Why couldn't they at least make the same
> distinctions? Why did one have to be more specific on one media type, and
> the other on another?
They have different distinctions because they are different tables
serving different purposes. The hrStorageTable, in its role of
tracking allocation of storage, is only concerned with what general
type of storage is being allocated. The hrDiskStorageTable is much
more detailed about the technology in use in the disk drive,
separately describing the media (hrDiskStorageMedia) and the
removability (hrDiskStorageRemoveable).
> 8. hrDiskStorageRemoveable: shouldn't it be 'removable' ?
Yes. I'll see what I can do to fix this. Thanks for noticing.
> 9. Several groups in the HR MIB are, according to the comments in the HR
> MIB, optional but then they are declared with "STATUS mandatory". How
> does that fit together?
This is a commonly asked question about SNMP. For historical
reasons, the SNMP's SMI included the status clause with the options
mandatory, optional, and obsolete. However, this conflicted with the
IETF policy that "all variables of a group be supported if any
element of the group is supported." Effectively, this clause became
irrelevant because it always said "mandatory". SNMPv2 fixes this by
changing the options to be "current", "deprecated", or "obsolete",
referring to the standardization status of the object.
> On the whole, it seemed more like a "Unix Host Resource MIB" to me --
> many PC or DOS specific issues are not addressed at all while some other
> items are pretty pointless under DOS.
For some reason DOS people complain that this is Unix-oriented, and
Unix people complain that it is DOS-oriented. Given that my
co-author is employed by Intel, the DOS perspective has probably been
well considered.
> It is possible to support the same
> relevant information as well as extra DOS specific data in something a
> third of the size of the HR MIB...
A PC specific MIB would not provide a common management perspective
across host platforms. I help manage a campus with 6000 Mac's, PC's and
workstations (roughly equal numbers of each), where such a common
perspective is attractive, as it is on many multi-vendor networks.
The charter of the Host Resources MIB Working Group explains quite
well what we set out to do. I've appended it below.
The Host MIB defines a common set of objects for managing
hosts. This common MIB should be augmented with platform-specific
MIBs. For example, a PC MIB to work in conjunction with the Host MIB
might instrument IO port addresses, interrupt numbers, drive
assignments, and so on. This is all consistent with the charter.
Steve
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.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00691;
31 Aug 93 7:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00685;
31 Aug 93 7:04 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa06017; 31 Aug 93 7:04 EDT
Received: by bitsy.MIT.EDU
id AA07500; Tue, 31 Aug 93 06:43:32 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA07494; Tue, 31 Aug 93 06:41:59 EDT
Received: from relay.pipex.net by MIT.EDU with SMTP
id AA00580; Tue, 31 Aug 93 06:41:49 EDT
Received: from Q.icl.co.uk by relay.pipex.net with SMTP (PP)
id <03028-0 at relay.pipex.net>; Tue, 31 Aug 1993 11:41:26 +0100
Received: from ming.oasis.icl.co.uk ([144.123.18.51])
by Q.icl.co.uk (4.1/icl-2.5-server) id AA17832;
Tue, 31 Aug 93 11:42:30 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA08775;
Tue, 31 Aug 93 11:43:06 BST
Message-Id: <9308311040.AA10674 at getafix.oasis.icl.co.uk>
Date: Tue, 31 Aug 93 11:40:24 BST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: P.V.McMahon.rea0803 at oasis.icl.co.uk
Reply-To: P.V.McMahon.rea0803 at oasis.icl.co.uk
Subject: RE: GSS_Acquire_cred is too inflexible
To: jik at security.ov.com
Cc: cat-ietf at mit.edu
Priority: URGENT
I am resending this which was sent yesterday at the same
time as my other comments because it doesn't seem to have got
through cat-ietf and back to me.
Apologies if you receive multiple copies.
--cut-here--
Jonathan,
re: gss_acquire_cred inflexibility
----------------------------------
> Details:
>
> 1) If the application requests a certain set of OID's, and only a
> proper subset of those OID's can be successfully supported in the
> requested credentials, should Acquire_cred return GSS_COMPLETE,
> indicating that some credentials were acquired, or GSS_BAD_MECH,
> indicating that credentials could not be acquired for one or more of
> the requested mechanisms?
>
> I would opt for GSS_COMPLETE, since the created credentials structure
> does contain useable credentials, and the actual_mechs set indicates
> the mechanism(s) for which credentials were successfully acquired.
I think that this problem applies to "multi-headed" GSS-API
clients which are rather thin on the ground at the moment,
as GSS-API implementations such in the MIT Kerberos
distribution and, I understand, IBM's KryptoKnight sit atop
one mechanism.
Furthermore, the scenarios you raise are only applicable
to application clients that are aware of which mechanisms
they require. While the GSS-API does and should support such
clients, I hope that they would be a small minority of
applications, otherwise portability is lost. For this reason,
I don't think that I would care very much if implementation-
specific decisions were made here as cross-mech-type portability
would appear to be a non-goal for applications that don't use
GSS_C_NULL_OID_SET for desired_mechs in gss_acquire_cred().
However, having said that, SESAME are implementing a multi-headed
credential and security context management component so we
have already made interpretations of the GSS-API spec
in the areas you have mentioned. As our interpretation matched
your proposal, in the 2nd para of your point 1, it may imply
that the spec needs no change, or it may imply that it would
be non-controversial to add in a clause to the description of
gss_init_sec_context() which clarifies that the applicable subset
of mechanisms is returned, and that GSS_BAD_MECH is only returned
to where *all* of the desired mech(s) are unsupported. (Is this
your intent?).
----
> However, here is where the lack of granularity creeps in....
>
> 2) If credentials cannot be acquired for one or more of the requested
> mechanisms, how can the application know why each of the failed
> mechanisms failed? It might need this information, especially if the
> mechanisms it requested were explicitly requested by a user and it
> wants to tell the user which ones failed and why.
This doesn't seem to be the kind of thing that users need to know. In practice
gss_acquire_cred would typically be used by servers (i.e. application users).
For clients (i.e. applications with with user interfaces), gss_acquire_cred
would only be necessary if the human had established credentials under more
than one mech_type.
Invariably this will require an authentication procedure before the user
can invoke the gss_acquire_cred, and this authentication procedure is
the normal place to inform the human user of credential establishment problems.
Looking at the inputs to gss_acquire_cred, perhaps the only one which might
come from a human user is the required time, and even then there is not much
that a human user can do if there is a mech_type-specific problem.
This line of thought leads me to the view that this is an obscure problem
which assumes an error-handling model that I am not sure is necessarily
the best one. (I think that you believe that all errors must always be
passable out via the GSS-API).
It should also be noted that if an implementor is concerned about this
problem, then s/he can set up a credential for each separate mech_type
using the existing gss_acquire_cred.
So I don't think that this is sufficient reason to change the GSS-API spec
to replace gss_acquire_cred() (which I know you didn't suggest) - although
your suggested gss_add_cred() may be a useful extension for some classes
of application.
----
> 3) An application can pass in multiple mechanisms in desired_mechs,
> and those mechanisms might require different internal names, but there
> is only one internal_name argument to the function.
As for the previous case, in practice, the use of gss_acquire_cred()
is not likely to be typical for clients. So the issues concerning
establishing a credential with, say, a private key, and a certificate
binding a DN to a public key, and a TGT with the DNS name, and a
privilege ticket granting ticket with the DCE name is most likely
to be an GSS-API implementation issue.
(It is not clear to me how a client could know which name to input
to the gss_acquire_cred call without being written in a
non-portable way).
The name which appears as the output of gss_accept_sec_context should
be the name authenticated by the security context mech_type, but
needn't be the only name which a GSS_API client can assert.
However, organisations which adopt different names for the same users
are likely to find confusion in their access control administration ...
So I believe that users should be encouraged to have a single name
for each principal. In a mixed X.509/Kerberos environment, this
name should be the InformationFramework Distinguished Name.
IF this view is not accepted then the GSS-API programming model
doesn't preclude separate calls to gss_acquire_cred so that a
separate credential gets set up for each different name.
So, again, while what you propose is probably ok, it doesn't
seem sufficiently urgent (to me) to warrant a change to the
existing GSS-API. An extension like gss_add_cred
would help some small classes of app[lication, but isn't
crucial enough to be supported by all GSS-API implementations
as most clients and servers in even a multi-headed client
environment wouldn't need it.
----
Your comments imply either a theoretical interest in this
area or that you may be adding to the number of multi-headed
implementations. If the latter, then it would suggest that
community interest in GSS-API implementations supporting
more than one mech_type would warrant action to at least address
any ambiguities in the spec before publication of GSS-API as
an RFC.
This would suggest that action on point 1 is advisable
(if further list discussion confirms it to be an ambiguity).
I wouldn't mind if gss_add_cred() were an optional extension -
but I would like it to get more review first.
Regards,
Piers
-------------------------------------------------------
Piers McMahon 30AUG93
ICL
post: Kings House, 33 Kings Road, Reading, RG1 3PX, UK
email: p.v.mcmahon at rea0803.wins.icl.co.uk
OR p.mcmahon at xopen.co.uk
phone: +44 734 586211 extension 3285
fax: +44 734 855106
-------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00846;
31 Aug 93 7:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00830;
31 Aug 93 7:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06229;
31 Aug 93 7:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00801;
31 Aug 93 7:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ah00699;
31 Aug 93 7:05 EDT
Received: from cheviot.ncl.ac.uk by CNRI.Reston.VA.US id aa04034;
31 Aug 93 5:19 EDT
Received: from [128.240.3.201] (pudding.ncl.ac.uk) by cheviot.ncl.ac.uk id <AA26145 at cheviot.ncl.ac.uk>
(5.65cVUW/NCL-CMA.1.35 for <IETF at nri.reston.va.us>) with SMTP; Tue, 31 Aug 1993 10:19:41 +0100
Date: Tue, 31 Aug 1993 10:19:41 +0100
Message-Id: <199308310919.AA26145 at cheviot.ncl.ac.uk>
To: IETF at nri.reston.va.us
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Denis.Russell at ncl.ac.uk
X-Sender: ndmr at eata.ncl.ac.uk
Subject: Help needed to get onto the Internet
Cc: Ravindra Corea <F.M.R.Corea at newcastle.ac.uk>
Please forward helpful information, and especially contacts to Ravindra::
>From: Ravindra Corea <F.M.R.Corea at newcastle.ac.uk>
>Date: Fri, 27 Aug 93 12:21:54 BST
>To: Denis.Russell at newcastle.ac.uk
>Subject: Internet
>Content-Type: text
>Content-Length: 1832
>
>
>
>Denis,
>
>I've tried to put together a request for information, keeping it as short as
>possible. Feel free to edit it further if you think it is necessary.
>
>
>Problem:
>
>The academic community in Sri Lanka is trying to get their university sites
>connected to Internet. There have been some positive noises from funding
>agencies (especially in the U.S). They would like to have a fairly well
>defined proposal, which we are nowtrying to put together. "We", at the moment,
>consist mainly of academics currently working/studying at various western
>universities. The information we gather will be passed on to a more formal
>body for the final proposal.
>
>Currently, our connection to the outside world is maintained via dial up
>lines. There is a domain name registered with Internet. Messages sent to this
>domain end up on a machine in the U.S. These are sent batch wise to a machine
>in Sri Lanka which in turnuses dial up lines to pass them on to the other
>sites.
>
>Essentially, we are looking for information from other people who might have
>had similar experience. In particular:
>
>> How do you go about setting up a ``internet service provider'' in Sri
> Lanka. This is probably the most important step.
>
>> We'd like to get some idea of recommended equipment. A minimal
>>requirement spec would probably be very useful at this stage.
>
>> We're also trying to make a reasonable estimate of cost, the sticking
>>point with any funding agency!
>
>Thanks in advance.
>
>
>----------------------
>
>Thanks for your help, Denis.
>
>Ravi Corea.
>(Chem. Eng.)
>
>----------------------
>In case of difficulty, please contact the postmaster at Newcastle
>who can be reached at one of the following addresses:
>
>JANET = postmaster at uk.ac.newcastle
>ARPA = postmaster at newcastle.ac.uk
>UUCP = ...!uknet!newcastle.ac.uk!postmaster
>
>
>----- End Included Message -----
>
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00845;
31 Aug 93 7:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00832;
31 Aug 93 7:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06228;
31 Aug 93 7:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00802;
31 Aug 93 7:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00699;
31 Aug 93 7:05 EDT
Received: from dec4ie.IEunet.ie by CNRI.Reston.VA.US id aa00613;
31 Aug 93 2:57 EDT
Received: from netcomm by dec4ie.ieunet.ie UUCP (IEunet) id aa21007;
31 Aug 93 7:20 BST
Received: from netcomm by netcomm.ie with UUPC;
Mon, 30 Aug 93 23:28:05 0 (GMT)
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Kevin Brown <Kevin_Brown at netcomm.ie>
Subject: Re: The Internet Want Ad controversy
Date: Mon, 30 Aug 93 23:28:05 GMT
Message-ID: <9308310720.aa21007 at dec4ie.ieunet.ie>
Hi All,
You should all listen to yourselves! Yes, it was self-evident a mistake was
made, but I have never seen such useless flogging of a dead "horse" . One
email pointing out the error of the ways would suffice....yes? I have seen
far bigger waste of "bandwidth" ( mental as well as communications ) than
befits the poor transgressor. If you are annoyed, email direct; I have no
need to see ethics discussed here.
I think the point has been made, now can I go back to passively listening
to the future of the Internet?
Thank God I bought a V32Bis modem with compression!
regards to all,
Kevin
////////////////////////////////////////////////////////////
Kevin Brown | N \ Cromlech Lodge
NetComm | e / Shanganagh Road
Unix Training, Consultancy | t \ Killiney, County Dublin
Networking | C / Ireland
| o \ Voice: 353-1-282-7342
| m / Fax: 353-1-282-7342
Authorised Sun Training | m \ email: kevinbr at netcomm.ie
| / (Internet)
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01887;
31 Aug 93 8:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01881;
31 Aug 93 8:51 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa08583; 31 Aug 93 8:51 EDT
Received: by bitsy.MIT.EDU
id AA07760; Tue, 31 Aug 93 08:41:29 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA07750; Tue, 31 Aug 93 08:39:55 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA00861; Tue, 31 Aug 93 08:39:50 EDT
Received: from gza-server.aktis.com by pad-thai.aktis.com (8.6.beta.10/) with SMTP
id <IAA01246 at pad-thai.aktis.com>; Tue, 31 Aug 1993 08:40:17 -0400
Received: by gza-server.aktis.com (4.1/4.7) id AA27532; Tue, 31 Aug 93 08:40:16 EDT
Message-Id: <9308311240.AA27532 at gza-server.aktis.com>
To: cat-ietf at mit.edu
Cc: linn at gza.com
Subject: Re: GSS_Acquire_cred is too inflexible
Date: Tue, 31 Aug 1993 08:40:15 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at gza.com>
Piers writes:
>Your comments imply either a theoretical interest in this
>area or that you may be adding to the number of multi-headed
>implementations. If the latter, then it would suggest that
>community interest in GSS-API implementations supporting
>more than one mech_type would warrant action to at least address
>any ambiguities in the spec before publication of GSS-API as
>an RFC.
I've been informed by the RFC editor's office that the GSS-API and C
bindings specs are next on the list for RFC publication, and should
come out as Proposed Standards within the next week. It's taken us a
while to get to this point, and I'd rather not pull them at this time
and restart the advancement and publication process. It's intended
that Proposed Standards serve as the basis for multiple
implementations, and that implementation and testing experience should
trigger refinements to the documents before they advance to the next
level (Draft Standards). If, as now appears to perhaps be the case,
several multi-mechanism implementations are emerging, this will
provide valuable experience. I suggest that we discuss and document
refinements, clarifications, and extensions on the list, with the
expectation that they be folded into the specs as follow-on
Internet-Drafts which would form the basis for next-level RFCs.
One specific:
>However, having said that, SESAME are implementing a multi-headed
>credential and security context management component so we
>have already made interpretations of the GSS-API spec
>in the areas you have mentioned. As our interpretation matched
>your proposal, in the 2nd para of your point 1, it may imply
>that the spec needs no change, or it may imply that it would
>be non-controversial to add in a clause to the description of
>gss_init_sec_context() which clarifies that the applicable subset
>of mechanisms is returned, and that GSS_BAD_MECH is only returned
>to where *all* of the desired mech(s) are unsupported. (Is this
>your intent?).
I'd also intended that GSS_COMPLETE would be returned by
gss_acquire_cred if credentials could be established for any
of the requested set, with actual_mechs reflecting a possibly
proper subset of the input set. As Piers notes, use of "default"
is desirable where feasible.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03513;
31 Aug 93 10:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03505;
31 Aug 93 10:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11609;
31 Aug 93 10:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03493;
31 Aug 93 10:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03450;
31 Aug 93 10:19 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa11490;
31 Aug 93 10:19 EDT
Received: from Mordor.Stanford.EDU by venera.isi.edu (5.65c/5.61+local-13)
id <AA13516>; Tue, 31 Aug 1993 07:19:27 -0700
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA24322; Tue, 31 Aug 93 07:19:22 -0700
Message-Id: <9308311419.AA24322 at Mordor.Stanford.EDU>
To: ietf at isi.edu
Subject: Re: advertising
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Mon, 30 Aug 93 13:11:27 -0400. <9308301311.aa26897 at IETF.CNRI.Reston.VA.US>
Date: Tue, 31 Aug 93 07:19:22 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
Since the Internet is not a single entity, there is no central authority.
In fact, things are run loosely enough that there isn't really much
distributed authority, on matters of acceptable use these days.
The IETF writes technical standards for Internet protocols. Occasionally,
it also produces operational guidelines, suggested for use on the Internet.
If there is enough interest in determining a 'rough consensus' about
acceptable use on Internet mailing lists (and other aspects of Internet
use?) then I'd like to suggest formation of a working group with that
goal.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03594;
31 Aug 93 10:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03588;
31 Aug 93 10:32 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa11839;
31 Aug 93 10:32 EDT
Received: by bitsy.MIT.EDU
id AA08071; Tue, 31 Aug 93 10:23:16 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA08063; Tue, 31 Aug 93 10:21:42 EDT
Received: from relay.pipex.net by MIT.EDU with SMTP
id AA02645; Tue, 31 Aug 93 10:21:32 EDT
Received: from Q.icl.co.uk by relay.pipex.net with SMTP (PP)
id <12468-0 at relay.pipex.net>; Tue, 31 Aug 1993 15:17:48 +0100
Received: from ming.oasis.icl.co.uk ([144.123.18.51])
by Q.icl.co.uk (4.1/icl-2.5-server) id AA22150;
Tue, 31 Aug 93 15:18:50 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA10479;
Tue, 31 Aug 93 15:19:24 BST
Message-Id: <9308311416.AA26310 at getafix.oasis.icl.co.uk>
Date: Tue, 31 Aug 93 15:16:43 BST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: P.V.McMahon.rea0803 at oasis.icl.co.uk
Reply-To: P.V.McMahon.rea0803 at oasis.icl.co.uk
Subject: RE: Re: GSS_Acquire_cred is too inflexible
To: cat-ietf at mit.edu
Priority: URGENT
> I'd also intended that GSS_COMPLETE would be returned by
> gss_acquire_cred if credentials could be established for any
> of the requested set, with actual_mechs reflecting a possibly
> proper subset of the input set.
Given that the author, and two independent readers of the text
have now interpreted the same text in the same way, it seems
reasonable to conclude that there actually no serious threat of
confusion on this specific point.
> I suggest that we discuss and document
> refinements, clarifications, and extensions on the list, with the
> expectation that they be folded into the specs as follow-on
> Internet-Drafts which would form the basis for next-level RFCs.
Seconded.
Piers
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06682;
31 Aug 93 13:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06678;
31 Aug 93 13:52 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa19448;
31 Aug 93 13:52 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA11827; Tue, 31 Aug 93 12:51:53 CDT
Received: by hemlock.cray.com
id AA20841; 4.1/CRI-5.6; Tue, 31 Aug 93 12:51:49 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
id AA20832; 4.1/CRI-5.6; Tue, 31 Aug 93 12:51:45 CDT
Received: from TGV.COM (HQ.TGV.COM) by cray.com (4.1/CRI-MX 2.19)
id AA11800; Tue, 31 Aug 93 12:51:32 CDT
Date: Tue, 31 Aug 93 10:51:29 PDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Sam Sjogren <sjogren at tgv.com>
Message-Id: <930831105129.60a0013e at TGV.COM>
Subject: current TELNET sources
To: telnet-ietf at cray.com
The FTP site for the authentication/encryption TELNET has changed
a couple times in the past. Where should I point people to currently?
Cheers,
-Sam
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06724;
31 Aug 93 13:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06718;
31 Aug 93 13:54 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa19524;
31 Aug 93 13:54 EDT
Received: by bitsy.MIT.EDU
id AA08837; Tue, 31 Aug 93 13:44:33 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA08827; Tue, 31 Aug 93 13:42:28 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA02743; Tue, 31 Aug 93 13:42:19 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <NAA07751 at pad-thai.aktis.com>; Tue, 31 Aug 1993 13:42:46 -0400
Date: Tue, 31 Aug 1993 13:42:46 -0400
Message-Id: <199308311742.NAA07751 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at gza.com>
X-Orig-Sender: jik at gza.com
To: cat-ietf at mit.edu
Subject: GSS_Display_status description is insufficient
I don't think this got through yesterday, because our local newsgroup
archive of the mailing list doesn't have a copy of it and John Linn
says he didn't get a copy either. So here's another try at it....
----- Forwarded message
Date: Mon, 30 Aug 1993 11:35:36 -0400
From: "Jonathan I. Kamens" <jik at security.ov.com>
Sender: jik at GZA.COM
To: cat-ietf at mit.edu
Subject: GSS_Display_status description is insufficient
The description of GSS_Display_status says that it returns a set of
status strings. However, it doesn't give any indication of why a set
of strings would be returned rather than a single error string, and
furthermore, it doesn't give any idea of how a UI should display those
strings.
I mean, is each string in the set a separate word of the error
message, so that they can be word-wrapped according to the UI's
preference? Or does each string indicate a separate error condition,
to be displayed on a line by itself?
The I-D should be more explicit about what the application can do with
the strings it gets.
Jonathan Kamens | OpenVision Technologies, Inc. | jik at security.ov.com
----- End of forwarded message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07516;
31 Aug 93 14:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07510;
31 Aug 93 14:23 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa20905;
31 Aug 93 14:23 EDT
Received: by bitsy.MIT.EDU
id AA09331; Tue, 31 Aug 93 14:10:40 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA09325; Tue, 31 Aug 93 14:10:37 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA03907; Tue, 31 Aug 93 14:10:25 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <OAA08471 at pad-thai.aktis.com>; Tue, 31 Aug 1993 14:10:20 -0400
Date: Tue, 31 Aug 1993 14:10:20 -0400
Message-Id: <199308311810.OAA08471 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at gza.com>
X-Orig-Sender: jik at gza.com
To: P.V.McMahon.rea0803 at oasis.icl.co.uk
Cc: cat-ietf at mit.edu
In-Reply-To: <9308301945.AA26158 at getafix.oasis.icl.co.uk> (P.V.McMahon.rea0803 at oasis.icl.co.uk)
Subject: RE: GSS_Acquire_cred is too inflexible
From: P.V.McMahon.rea0803 at oasis.icl.co.uk
Date: Mon, 30 Aug 93 20:45:21 BST
Furthermore, the scenarios you raise are only applicable
to application clients that are aware of which mechanisms
they require. While the GSS-API does and should support such
clients, I hope that they would be a small minority of
applications, otherwise portability is lost. For this reason,
I don't think that I would care very much if implementation-
specific decisions were made here as cross-mech-type portability
would appear to be a non-goal for applications that don't use
GSS_C_NULL_OID_SET for desired_mechs in gss_acquire_cred().
I think that any application that wishes to use only a subset of
available mechanisms will consider it unacceptable not to know whether
it can rely on the GSS-API implementation to choose the useable
mechanisms from the set that it specifies and build a credential
structure for those mechanisms.
Furthermore, I see no reason for different implementations to behave
differently in a specific situation just because that situation is not
the "recommended usage" of GSS-API, especially when it doesn't cost
anything for the specification to be amended to describe what it
considers the "correct" behavior.
> 2) If credentials cannot be acquired for one or more of the requested
> mechanisms, how can the application know why each of the failed
> mechanisms failed? It might need this information, especially if the
> mechanisms it requested were explicitly requested by a user and it
> wants to tell the user which ones failed and why.
This doesn't seem to be the kind of thing that users need to
know. In practice gss_acquire_cred would typically be used by
servers (i.e. application users).
Um, "servers" and "application users" seem to me to be opposites here,
so I'm not quite sure what you mean.
An application that needs to use GSS_Acquire_cred to request specific
mechanisms is likely to be doing something "hairy" enough that it will
also want to know what went wrong with the mechanisms that couldn't be
used.
For example, let's say that there's an application which allows the
user to use a menu to select which mechanism(s) to use. When the
application tries to get credentials using the mechanisms the user has
selected, it will want to tell the user which ones couldn't be used
and why. The current API provides no way to find that out.
Yes, I know, "The specific specification of which mechanisms to use is
not something that is likely to be used by user applications." That's
what YOU think, now, but how do you know what other people's
applications are going to want to be able to do? For example, I can
certainly envision an application doing what I described above. The
API specification should not be limited to the functionality that the
people writing it think might be "reasonably" needed, especially not
when it costs so little to add the missing functionality.
This line of thought leads me to the view that this is an obscure problem
which assumes an error-handling model that I am not sure is necessarily
the best one. (I think that you believe that all errors must always be
passable out via the GSS-API).
I believe that all errors which *might be useful to the application*
must be available from the GSS-API. I believe that it is entirely
possible that an application, whether a server or a user application,
might be interested in selecting a specific list of mechanisms to use
and in knowing which of them *couldn't* be used.
For example, let's say I'm a server and I want to be able to accept
(according to my configuration file) either X.509 or Kerberos V5
GSS-API authentication. But when I start up, I discover that the file
containing my X.509 private key is missing. Shouldn't that fact be
syslog'd so the administrator can install the missing private key?
If the library just returns GSS_COMPLETE from Acquire_cred because it
was able to get Kerberos V5 credentials out of a srvtab, then no one
will know there's a problem until people start complaining that X.509
connections to the server aren't working, and there won't be any
evidence in the server logs to explain why, so it won't exactly be the
easiest problem to track down.
It should also be noted that if an implementor is concerned about this
problem, then s/he can set up a credential for each separate mech_type
using the existing gss_acquire_cred.
That's bogus. It seems to me that one of the main points of
Acquire_cred is that it allows for credentials from a number of
different mechanisms to be supported with a single handle. When a
server application gets a GSS-API token and wants to process it with
Accept_sec_context, how will it know, under what you propose, which of
its context handles to pass in? Keep in mind that the token is
opaque.
So I don't think that this is sufficient reason to change the GSS-API spec
to replace gss_acquire_cred() (which I know you didn't suggest) - although
your suggested gss_add_cred() may be a useful extension for some classes
of application.
Why are you making a case against a change I never suggested, when you
seem to be saying that you think that the change I *did* suggest might
be useful?
As for the previous case, in practice, the use of gss_acquire_cred()
is not likely to be typical for clients. So the issues concerning
establishing a credential with, say, a private key, and a certificate
binding a DN to a public key, and a TGT with the DNS name, and a
privilege ticket granting ticket with the DCE name is most likely
to be an GSS-API implementation issue.
I don't understand this point. You're saying that because it's not
something that should be used often, it doesn't matter how it's
implemented? I disagree. If the functionality is in the API at all,
then it seems clear that the people who designed the API thought that
it was necessary enough that it should be supported. If that's the
case, shouldn't it be supported properly?
(It is not clear to me how a client could know which name to input
to the gss_acquire_cred call without being written in a
non-portable way).
Mechanism specifications might very well state which name types they
are guaranteed to work with (by listing their OID's). In fact,
mechanism specifications are likely to include name type
specifications. Therefore, once an application has decided that it's
necessary to use a specific set of mechanisms, it probably knows which
name types to use.
The name which appears as the output of gss_accept_sec_context should
be the name authenticated by the security context mech_type, but
needn't be the only name which a GSS_API client can assert.
I don't understand what this point has to do with the point I raised.
However, organisations which adopt different names for the same users
are likely to find confusion in their access control administration ...
So I believe that users should be encouraged to have a single name
for each principal. In a mixed X.509/Kerberos environment, this
name should be the InformationFramework Distinguished Name.
As I've probably already said directly or indirectly, it is, in my
opinion, unreasonable for the GSS-API to be enforcing policy decisions
of this sort. What if one division of my company uses Kerberos and
another uses X.509, and the two divisions are constantly at each
others' throats and unwilling to reconcile to one authentication
system and namespace? In that situation, I will need to use
separate Kerberos and X.509 names in my day-to-day work to access
services provided by the two divisions, and the GSS-API should not
preclude the possibility of my doing so.
So, again, while what you propose is probably ok, it doesn't
seem sufficiently urgent (to me) to warrant a change to the
existing GSS-API. An extension like gss_add_cred
would help some small classes of app[lication, but isn't
crucial enough to be supported by all GSS-API implementations
as most clients and servers in even a multi-headed client
environment wouldn't need it.
I never argued that the existing GSS-API should be changed. I agree
that Acquire_cred is sufficient for the most common (and recommended)
usage of the system. I am arguing that there is missing functionality
that might be needed by some applications and that therefore should be
provided.
Thanks for your response.
Jonathan Kamens | OpenVision Technologies, Inc. | jik at security.ov.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08507;
31 Aug 93 15:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08501;
31 Aug 93 15:24 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa23330;
31 Aug 93 15:24 EDT
Received: by bitsy.MIT.EDU
id AA10152; Tue, 31 Aug 93 15:13:21 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA10146; Tue, 31 Aug 93 15:13:19 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA01844; Tue, 31 Aug 93 15:13:03 EDT
Received: by inet-gw-2.pa.dec.com; id AA04331; Tue, 31 Aug 93 12:12:56 -0700
Received: by us1rmc.bb.dec.com; id AA11044; Tue, 31 Aug 93 15:11:40 -0400
Message-Id: <9308311911.AA11044 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Tue, 31 Aug 93 15:11:41 EDT
Date: Tue, 31 Aug 93 15:11:41 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 31-Aug-1993 1456" <wray at tuxedo.enet.dec.com>
To: jik at gza.com
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, jik at gza.com
Subject: RE: GSS_Display_status description is insufficient
>> The C-bindings spec. goes into more detail over this.
>
>I know, but it seems to me that the GSS-API overview isn't detailed
>enough. In other words, isn't each of the two documents supposed to
>stand on its own? If the C-bindings spec. is just about the C
>bindings, then Linn's overview should not depend on the C-bindings
>spec. to fill out some of its documentation.
>
>I guess what I'm saying is that if someone designed another language
>binding relying only on Linn's overview (and it would seem reasonable
>to me to do that), such a binding might choose a different meaning
>than the one you've chosen for the various error strings returned. I
>think that Linn's document should have a bit more explanatory text so
>that this problem can be avoided.
Well, there's no reason that different language bindings need to make the same
interpretation of the top-level spec, at least not for API issues. I think
you're viewing John Linn's spec the wrong way - think of it as a framework
rather than a detailed specification. It describes the routines that a GSSAPI
should contain, and gives some guidance as to the information that each routine
consumes and produces. It doesn't define exact language-specific data-types,
nor names (the C-bindings use lower-case rather than the mixed-case names of
the overview spec, and also C status codes are called GSS_S_xxx rather than
GSS_xxx), nor precise semantics of the routines.
In this area, the top-level spec says that status codes can contain multiple
messages (in the documentation for the GSS_COMPLETE return to
GSS_Display_Status). The wording explicitly allows for an interpretation where
instead of invoking the routine multiple times, or getting an actual set of
messages back, the routine somehow concatenates the individual error messages
(perhaps separating them with newline characters). We felt (in the C bindings)
that it was better to give the application the choice of how to format status
messages, so we returned them separately.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09777;
31 Aug 93 16:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09770;
31 Aug 93 16:15 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa25842;
31 Aug 93 16:15 EDT
Received: by bitsy.MIT.EDU
id AA10873; Tue, 31 Aug 93 16:01:02 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA10867; Tue, 31 Aug 93 16:01:00 EDT
Received: from relay.pipex.net by MIT.EDU with SMTP
id AA00617; Tue, 31 Aug 93 16:00:52 EDT
Received: from Q.icl.co.uk by relay.pipex.net with SMTP (PP)
id <24453-0 at relay.pipex.net>; Tue, 31 Aug 1993 20:51:30 +0100
Received: from ming.oasis.icl.co.uk ([144.123.18.51])
by Q.icl.co.uk (4.1/icl-2.5-server) id AA28846;
Tue, 31 Aug 93 20:52:46 BST
Received: from trojan.oasis.icl.co.uk on ming.oasis.icl.co.uk id AA12420;
Tue, 31 Aug 93 20:53:22 BST
Message-Id: <9308311950.AA18920 at getafix.oasis.icl.co.uk>
Date: Tue, 31 Aug 93 20:50:40 BST
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: P.V.McMahon.rea0803 at oasis.icl.co.uk
Reply-To: P.V.McMahon.rea0803 at oasis.icl.co.uk
Subject: RE: RE: GSS_Acquire_cred is too inflexible
To: jik at gza.com
Cc: cat-ietf at mit.edu
Priority: URGENT
Jonathan,
Some thoughts on your reply follow:
> Furthermore, I see no reason for different implementations to behave
> differently in a specific situation just because that situation is not
I agree it would be desirable for every potential area of confusion
such as this to be clarified in a later revision of the spec.
> GSS-API authentication. But when I start up, I discover that the file
> containing my X.509 private key is missing. Shouldn't that fact be
> syslog'd so the administrator can install the missing private key?
I would suggest that it is up to the authentication mechanism to handle
auditing of such details.
> It should also be noted that if an implementor is concerned about this
> problem, then s/he can set up a credential for each separate mech_type
> using the existing gss_acquire_cred.
>
> That's bogus.
It still looks accurate to me :-).
> It seems to me that one of the main points of
> Acquire_cred is that it allows for credentials from a number of
> different mechanisms to be supported with a single handle. When a
> server application gets a GSS-API token and wants to process it with
> Accept_sec_context, how will it know, under what you propose, which of
> its context handles to pass in? Keep in mind that the token is
> opaque.
In order to support your scenario with the existing API, I would be
obliged to call gss_acquire_cred for each mech_type I wanted
specific error handling, and then call gss_acquire_cred
for the set of required mech_types to be encapsulated into a
credential. This may not be very efficient in some implementations ...
But as I wouldn't encourage the usage of the API in the way you are
suggesting (with explicit as opposed to defaulted mech types) for
portable applications this unsatisfactory usage doesn't arise.
> The name which appears as the output of gss_accept_sec_context should
> be the name authenticated by the security context mech_type, but
> needn't be the only name which a GSS_API client can assert.
>
> I don't understand what this point has to do with the point I raised.
I was referring to my suggested use of multiple credentials as the
solution, however crude, within the existing API to your problem.
Each credential is associated with a distinct name which can be a
different type as you required.
> However, organisations which adopt different names for the same users
> are likely to find confusion in their access control administration ...
> So I believe that users should be encouraged to have a single name
> for each principal. In a mixed X.509/Kerberos environment, this
> name should be the InformationFramework Distinguished Name.
> **
>
> As I've probably already said directly or indirectly, it is, in my
> opinion, unreasonable for the GSS-API to be enforcing policy decisions
> of this sort. What if one division of my company uses Kerberos and
> another uses X.509, and the two divisions are constantly at each
> others' throats and unwilling to reconcile to one authentication
> system and namespace? In that situation, I will need to use
> separate Kerberos and X.509 names in my day-to-day work to access
> services provided by the two divisions, and the GSS-API should not
> preclude the possibility of my doing so.
Yes. My posting did actually make the following remark after ** (as
I know that security policy is something which customers sometimes
have their own ideas about ...).
"IF this view is not accepted then the GSS-API programming model
doesn't preclude separate calls to gss_acquire_cred so that a
separate credential gets set up for each different name."
> So I don't think that this is sufficient reason to change the GSS-API spec
> to replace gss_acquire_cred() (which I know you didn't suggest) - although
> your suggested gss_add_cred() may be a useful extension for some classes
> of application.
>
> Why are you making a case against a change I never suggested, when you
> seem to be saying that you think that the change I *did* suggest might
> be useful?
> I never argued that the existing GSS-API should be changed.
I understand that.
You have made a case for gss_acquire_cred being deficient in some
cases.
In response to this observation it's a useful exercise for the WG
to decide (a) whether or not they agree, and (b) if they agree,
decide what the solution is.
In these remarks, I am just making my individual contribution
to this group process, as one possible solution could be to
improve gss_acquire_cred(), and another, as you have suggested,
is to add a new API.
> I agree
> that Acquire_cred is sufficient for the most common (and recommended)
> usage of the system.
Right.
> An application that needs to use GSS_Acquire_cred to request specific
> mechanisms is likely to be doing something "hairy" enough that it will
> also want to know what went wrong with the mechanisms that couldn't be
> used.
> The
> API specification should not be limited to the functionality that the
> people writing it think might be "reasonably" needed, especially not
> when it costs so little to add the missing functionality.
>
> This line of thought leads me to the view that this is an obscure problem
> which assumes an error-handling model that I am not sure is necessarily
> the best one. (I think that you believe that all errors must always be
> passable out via the GSS-API).
>
> I believe that all errors which *might be useful to the application*
> must be available from the GSS-API. I believe that it is entirely
> possible that an application, whether a server or a user application,
> might be interested in selecting a specific list of mechanisms to use
> and in knowing which of them *couldn't* be used.
>
>
> I don't understand this point. You're saying that because it's not
> something that should be used often, it doesn't matter how it's
> implemented? I disagree. If the functionality is in the API at all,
> then it seems clear that the people who designed the API thought that
> it was necessary enough that it should be supported. If that's the
> case, shouldn't it be supported properly?
Yes. I am not arguing with your absolute correctness, I am just
seeking to understand the relative importance of the issues
you raise.
> I am arguing that there is missing functionality
> that might be needed by some applications and that therefore should be
> provided.
I think we agree on this in principle.
But what is your perception of the priority of this relative to
advancement of the existing text as a Proposed Standard?
Regards,
Piers
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10015;
31 Aug 93 16:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10009;
31 Aug 93 16:30 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa26478;
31 Aug 93 16:30 EDT
Received: by bitsy.MIT.EDU
id AA11186; Tue, 31 Aug 93 16:21:34 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA11180; Tue, 31 Aug 93 16:21:32 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA01495; Tue, 31 Aug 93 16:21:26 EDT
Received: from localhost by pad-thai.aktis.com (8.6.beta.10/)
id <QAA12229 at pad-thai.aktis.com>; Tue, 31 Aug 1993 16:21:47 -0400
Date: Tue, 31 Aug 1993 16:21:47 -0400
Message-Id: <199308312021.QAA12229 at pad-thai.aktis.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jonathan I. Kamens" <jik at gza.com>
X-Orig-Sender: jik at gza.com
To: P.V.McMahon.rea0803 at oasis.icl.co.uk
Cc: cat-ietf at mit.edu
In-Reply-To: <9308311950.AA18920 at getafix.oasis.icl.co.uk> (P.V.McMahon.rea0803 at oasis.icl.co.uk)
Subject: RE: RE: GSS_Acquire_cred is too inflexible
From: P.V.McMahon.rea0803 at oasis.icl.co.uk
Date: Tue, 31 Aug 93 20:50:40 BST
But what is your perception of the priority of this relative to
advancement of the existing text as a Proposed Standard?
I do not think that any of the issues I have raised are significant
enough to delay the advancement of the existing text to RFC status.
jik
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20308;
10 Aug 93 14:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20298;
10 Aug 93 14:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20065;
10 Aug 93 14:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20285;
10 Aug 93 14:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20230;
10 Aug 93 14:50 EDT
Received: from pandora.sf.ca.us by CNRI.Reston.VA.US id aa19991;
10 Aug 93 14:50 EDT
Newsgroups: list.ietf.general
Path: cook
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Gordon Cook <cook at path.net>
Subject: Re: Now is the time for radical thinking...
Date: Tue, 10 Aug 1993 18:50:47 GMT
Message-ID: <CBK4Cp.G71 at pandora.sf.ca.us>
X-Newsreader: TIN [version 1.2 PL1]
References: <9308101349.AA08725 at ginger.lcs.mit.edu>
The possibility raised by Bob Moskowitz of Internet reception via cable
tv is reality right now. Only problem is it is not quite so cheap. but
consider the bandwidth incoming: 10 megabits per second - ethernet.
DEC offers the Digital Channel - by far the most expensive.
Zenith Electronics offers various electronics for CATV hook up.
Hybrid Networks offers a black box at about $1400 that will
connect your lan or workstation or PC to the CATV channel. Return
channel is by ISDN or high speed dial up modem. For more info
contact Ed moura ejm at hybrid.com. Or contact me for my recently
completed 15,000 word report ($250) CATV vs. Telco's: Who Will Build
and Control NII?
TCI and other CATV companies have on going field tests of these technologies.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21003;
10 Aug 93 15:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20999;
10 Aug 93 15:17 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa21190;
10 Aug 93 15:17 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA28891 on Tue, 10 Aug 93 13:55:14 -0400
Received: from pandora.sf.ca.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA28887 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Tue, 10 Aug 93 13:55:07 -0400
Newsgroups: list.ietf.uri
Path: mitra
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mitra <mitra at path.net>
Subject: Re: Minutes - Again
Organization: Pandora Systems
Date: Tue, 10 Aug 1993 17:54:42 GMT
Message-Id: <CBK1r6.C80 at pandora.sf.ca.us>
X-Newsreader: TIN [version 1.2 PL1]
References: <9308101102.AA23570 at kudzu.cnidr.org>
Apparently-To: <uri at bunyip.com>
P.S. If anyone has an ASCII version of the latest draft please email it
to me, I wanted to check over the specifics.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12931;
25 Aug 93 19:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12924;
25 Aug 93 19:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28440;
25 Aug 93 19:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12911;
25 Aug 93 19:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12877;
25 Aug 93 19:22 EDT
Received: from pandora.sf.ca.us by CNRI.Reston.VA.US id aa28407;
25 Aug 93 19:22 EDT
Newsgroups: list.ietf.general
Path: cook
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Gordon Cook <cook at path.net>
Subject: Re: Aiieee, run for your lives....
Date: Wed, 25 Aug 1993 23:23:11 GMT
Message-ID: <CCC8yo.2An at pandora.sf.ca.us>
X-Newsreader: TIN [version 1.2 PL1]
References: <9308251658.AA14834 at cmcl2.NYU.EDU>
Bill Russell says:
They are offering a one-way street with a low-speed
backhaul. Not the same thing at all.
Unless I have misunderstood what you say this is not correct. Digital
channel offers 10 meg out and 10 meg back. Zenith roughly 2 meg out and
2 meg back.
For my September newsletter out next week I just interviewed Bill
Schrader:
PSI will make final announcement of offerings and prices by December
first. They will include multiple connectivity options.... ie high
medium and low back channel bandwidth.
_______________________________________________________________
Gordon Cook, Editor Publisher: COOK Report on Internet -> NREN
431 Greenway Ave, Ewing, NJ 08618
cook at path.net (609) 882-2572
Ask out my 15,000 word, $250, CATV vs. Telco's Internet & NII Study
_______________________________________________________________
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01442;
1 Sep 93 6:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01434;
1 Sep 93 6:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03583;
1 Sep 93 6:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01417;
1 Sep 93 6:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01277;
1 Sep 93 6:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ac03165;
1 Sep 93 6:47 EDT
Received: from [128.9.0.32] by IETF.CNRI.Reston.VA.US id aa00651;
1 Sep 93 2:54 EDT
Received: from daiduk.kaist.ac.kr by venera.isi.edu (5.65c/5.61+local-13)
id <AA09333>; Tue, 31 Aug 1993 23:11:28 -0700
Received: from mani.kaist.ac.kr by daiduk.kaist.ac.kr (4.1/KAISTNet-Relay-3.2)
id AA25369; Wed, 1 Sep 93 15:20:01 KST
Received: by mani.kaist.ac.kr (4.1/SMI-4.1)
id AA05668; Wed, 1 Sep 93 15:12:44 KST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Kyungran Kang <krkang%mani.kaist.ac.kr at daiduk.kaist.ac.kr>
Message-Id: <9309010612.AA05668 at mani.kaist.ac.kr>
Errors-To: Postmaster%mani.kaist.ac.kr at daiduk.kaist.ac.kr
Subject: IETF meeting schedule
To: ietf at isi.edu
Date: Wed, 1 Sep 93 15:12:44 KST
X-Mailer: ELM [version 2.3 PL11]
Hello.
I have read about the schedule of IETF meeting, but I lost the mail.
I'd like to know when and where the IETF meeting is planed for coming 3 years.
Thanks in advance.
+----------------------------------------------------+
| Kang, Kyungran : krkang at cosmos.kaist.ac.kr |
| |
| Tel. : +82-42-869-3554 Fax. : +82-2-869-8700 |
| System Architecture Lab. |
| Computer Science Department, KAIST, KOREA |
+----------------------------------------------------+
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01973;
1 Sep 93 8:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01966;
1 Sep 93 8:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05176;
1 Sep 93 8:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01955;
1 Sep 93 8:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01908;
1 Sep 93 7:58 EDT
Received: from [128.9.0.32] by CNRI.Reston.VA.US id aa05084; 1 Sep 93 7:58 EDT
Received: from mcigateway.mcimail.com by venera.isi.edu (5.65c/5.61+local-13)
id <AA15874>; Wed, 1 Sep 1993 04:58:01 -0700
Received: by MCIGATEWAY.MCIMail.com id ac01704; 1 Sep 93 11:48 GMT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id bc01284;
1 Sep 93 11:39 GMT
Date: Wed, 1 Sep 93 11:45 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at isi.edu>
Subject: Question on RFC 1500
Message-Id: <54930901114545/0003858921NA2EM at mcimail.com>
I see in RFC 1500 that the HOSTNAME rfc, 953, is historical. When was it
moved there? I have a vendor that insists on using it and I have had to
write an AWK script to convert a regular UNIX host file to HOSTNAME format.
Is there an RFC that documents the alternative to 953?
RFC 953 does allow for multiple IP addresses for a name, just like DNS with
multiple A records. This is a real advantage to HOSTNAME and the awk script
I've written takes comments on alternate IP addresses and places them into
the HOSTNAME format very nicely. Is there any way to support multiple IP
addresses with the UNIX host file format?
Thank you for your assistance in this IP protocol standards question.
After answering it, you may return to your regularly scheduled debate of
Acceptable Usage Policy for this list :(
Bob Moskowitz
Chrysler Corp
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05979;
1 Sep 93 10:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11618;
1 Sep 93 10:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05883;
1 Sep 93 10:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05788;
1 Sep 93 10:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11464;
1 Sep 93 10:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05779;
1 Sep 93 10:53 EDT
To: IETF-Announce: ;
REPLY-TO: ietf-rsvp at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 1a: IETF, November 1-5, 1993/Houston
Date: Wed, 01 Sep 93 10:53:45 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9309011053.aa05779 at IETF.CNRI.Reston.VA.US>
Dear IETFers:
Following this message (1a), you will receive four more listed below:
IETF MAILING 1b: IETF RSVP FORM. Payment DOES NOT need to accompany the
RSVP Form, but the Form must be received by September 30th
in order to guarantee the lower fee. We strongly
encourage you to register immediately, even if you know
payment will be delayed for a bit.
IETF MAILING 1c: DRAFT AT-A-GLANCE. This is still in draft form.
IETF MAILING 1d: DRAFT AGENDA. Please keep in mind that this is only
a draft and is subject to frequent changes.
The IETF Social has been scheduled for___TBD_____.
NOTE: WE CANNOT STRESS THIS ENOUGH. Though we'd prefer to have payment of
the meeting fee as soon as possible, we definitely want immediate
notification that you are planning on coming. So even though you know that
payment will be delayed for one reason or another, SEND THE RSVP FORM IN
ANYWAY.
Thank You,
Megan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05996;
1 Sep 93 10:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05980;
1 Sep 93 10:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11619;
1 Sep 93 10:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05901;
1 Sep 93 10:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05834;
1 Sep 93 10:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11541;
1 Sep 93 10:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05827;
1 Sep 93 10:56 EDT
To: IETF-Announce: ;
REPLY-TO: ietf-rsvp at CNRI.Reston.VA.US
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 1b: IETF RSVP FORM: November 1-4 1993/Houston
Date: Wed, 01 Sep 93 10:56:37 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9309011056.aa05827 at IETF.CNRI.Reston.VA.US>
REGISTRATION FORM
28th Internet Engineering Task Force - Page 1 of 2
November 1-5, 1993
Houston, Texas
Please print or type:
Name (Mr/Dr/Ms)__________________________________________________________
Title____________________________________________________________________
Organization_____________________________________________________________
Address__________________________________________________________________
_________________________________________________________________________
City_____________________________State_____________Postal Code___________
Country__________________________________________________________________
Telephone______________________________Fax_______________________________
Email____________________________________________________________________
Do you plan to attend the Sunday, October 31st NEWCOMER'S ORIENTATION at
16:30?
YES___ NO___
Do you plan to attend the Sunday, October 31st reception at 18:00?
YES___ NO___
$130.00 Registration postmarked on or BEFORE Thursday, September 30, 1993.
$150.00 ($130.00 + $20.00 late fee) Registration postmarked after
Thursday, September 30, 1993.
Method of payment: ___AMEX ___VISA ___MC ___Diners ___Check
(U.S. dollars, drawn on a U.S. Bank), payable to:
Corporation for National Research Initiatives
Account No.____________________________ Expiration Date__________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
Registration Forms can be sent via electronic mail, facsimile, or postal mail:
Electronic: ietf-rsvp at cnri.reston.va.us
Facsimile: +1-703-620-0913
Postal: Corporation for National Research Initiatives
Accounting Department - 28th IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
REGISTRATION FORM
28th Internet Engineering Task Force - Page 2 of 2
November 1-5, 1993
Houston, Texas
IMPORTANT:
1. Payment MAY, but does NOT have to, accompany the Form.
2. Register ONE person per form. Substitutions are NOT allowed.
3. Include a completed Registration Form with payment.
4. Purchase orders are NOT accepted.
5. DD Form 1556 IS accepted.
6. We CANNOT invoice for payment.
7. Registration Forms will be accepted via electronic mail and
facsimile until 13:00 ET on Thursday, October 28, 1993.
8. Requests for refunds must be received by Thursday, October 28, 1993.
9. Refund policy: Refunds are subject to a $20.00 service charge.
Late fees will not be refunded.
10. Your registration fee includes a copy of the Meeting's Proceedings,
Sunday evening reception (cash bar), and a daily continental
breakfast and coffee breaks.
For additional information or assistance, please contact +1-703-620-8990,
+1-703-620-0913 (Fax) or ietf-rsvp at cnri.reston.va.us. Direct all inquiries
to: 28th IETF Meeting - Houston, Texas.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06067;
1 Sep 93 11:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11679;
1 Sep 93 11:00 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06046;
1 Sep 93 11:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05879;
1 Sep 93 10:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11586;
1 Sep 93 10:58 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05874;
1 Sep 93 10:58 EDT
To: IETF-Announce: ;
REPLY-TO: ietf-rsvp at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
FROM: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 1c: DRAFT AT-A-GLANCE: November 1-5, 1993
Date: Wed, 01 Sep 93 10:58:09 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9309011058.aa05874 at IETF.CNRI.Reston.VA.US>
28th INTERNET ENGINEERING TASK FORCE Mailing Date : 9/1/93
AT-A-GLANCE Mailing Number: 1c
DATES: November 1-5, 1993 HOST(S):
Bill Manning
SESQUINET and Rice University
HOTEL/MEETING SITE: Sheraton Astrodome Hotel
8686 Kirby Drive
Houston, Texas 77054
Phone: (800) 627-6461 {fax: (713) 790-9676}
CI 2:00 p.m.; CO 12:00 p.m.
250 Rooms reserved until September 30, 1993
$92.00/single; $92.00/double (please add 15% tax)
Specify: IETF93
ALTERNATE ACCOM: Holiday Inn Astrodome (not yet confirmed)
8111 Kirby Drive
Houston, Texas 77054
Phone: (713) 790-1900 {fax: (713) 799-8574}
20 Rooms reserved until: TBD
$ TBD
Specify: TBD
NEWCOMER'S Sunday, October 31, 1993
ORIENTATION: 16:30 - 17:30
Room: San Jacinto 1
PRE-REGISTRATION: Sunday, October 31, 1993
18:00 - 20:00 (reception during)
Sheraton Astrodome Hotel
Room: Sam Houston Ballroom 1
REGISTRATION: Monday, November 1, 1993
08:00 - 18:00
Tuesday, November 2 - Thursday November 4, 1993
08:30 - 18:00
Friday, November 5, 1993
08:30 - 12:00
Sheraton Astrodome Hotel
Room: Connecting walkway outside San Jacinto 1
TERMINAL ROOM: Stephen F. Austin Ballroom B
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
$130.00 if registered BY September 30, 1993
$150.00 if registered AFTER September 30, 1993
AIRLINE: Continental Airlines, Inc. (special rate roundtrip only)
1 (800) 468-7022 U.S./Canada Meeting ID: ZKB17
Discounts are available on some International Flights.
International Attendees may call their local Continental
reservation number, reference the same Meeting ID No.
CAR RENTAL: TBD
AIRPORT: Intercontinental (30-40 min drive to Hotel)
Hobby Airport (15-20 min drive to Hotel)
PARKING: Sheraton Astrodome Hotel: complimentary
SHUTTLE: Airport Express directly from Hobby to the Sheraton.
Rate: $8.00 one way. Must purchase tickets inside baggage
claim area lower level. Return tickets available at
Sheraton Front Desk. Shuttle from Intercontinental:
Take Greenway Shuttle to Greenway Plaza ~$9.70. Call
Sheraton from Greenway Plaza and they will send a van.
CAB: $18 from Hobby Airport; $32 from Intercontinental
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06267;
1 Sep 93 11:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11873;
1 Sep 93 11:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06242;
1 Sep 93 11:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06160;
1 Sep 93 11:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11726;
1 Sep 93 11:02 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06154;
1 Sep 93 11:02 EDT
To: IETF-Announce: ;
REPLY-TO: ietf-rsvp at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
FROM: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 1d: DRAFT AGENDA: November 1-5, 1993
Date: Wed, 01 Sep 93 11:02:22 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9309011102.aa06154 at IETF.CNRI.Reston.VA.US>
Agenda of the Twenty-Eighth IETF - as of 8/31/93 - 4:00pm
(November 1-5, 1993)
MONDAY, November 1, 1993
0800-0900 IETF Registration and Continental Breakfast
Working Group Chairs Workshop (Dave Crocker/Silicon Graphics)
0900-0930 Introductions
0930-1200 Technical Presentations
Breaks Coffee available.
1330-1530 Afternoon Sessions I
APP Interactive Mail Access Protocol WG (imap)
(Terry Gray/UWash)
INT P. Internet Protocol WG (pip) (Paul Francis/Bellcore)
MGT ATM MIB WG (atommib) (Kaj Tesink/Bellcore)
SEC Security Area Advisory Group (saag) (Steve Crocker/TIS)
TSV Multiparty Multimedia Session Control WG (mmusic)
(Eve Schooler/ISI and Abel Weinrib/Bellcore)
USV Whois and Network Information Lookup Service WG (wnils)
(Joan Gargano/UCDavis)
1530-1600 Break (Refreshments provided)
1600-1800 Afternoon Sessions II
INT Simple Internet Protocol WG (sip)
(Steve Deering/Xerox PARC and Bob Hinden/Sun)
MGT Remote LAN Monitoring WG (rmonmib)
(Mike Erlinger/Harvey Mudd College)
SEC Authorization and Access Control WG (aac)
(Cliff Neuman/ISI)
1930-2200 Evening Sessions
TUESDAY, November 2, 1993
0830-0900 Continental Breakfast
0900-0930 IETF Technical Presentations
0930-1200 Morning Sessions
APP TELNET WG (telnet)
(Steve Alexander/Lachman Technology)
INT IP Over Asynchronous Transfer Mode WG (atm)
(Mark Laubach/Hewlett-Packard)
RTG Inter-Domain Multicast Routing WG (idmr)
(Tony Ballardie/UCL and Paul Francis/Bellcore)
MGT Network Management Area: Open Meeting (nmdir)
(Marshall Rose/DBC)
Breaks Coffee available.
1330-1530 Afternoon Sessions I
INT Point-to-Point Protocol Extensions WG (pppext)
(Fred Baker/ACC)
RTG Inter-Domain Policy Routing WG (idpr)
(Martha Steenstrup/BBN)
RTG IP Routing for Wireless/Mobile Hosts WG (mobileip)
(Steve Deering/Xerox PARC and Greg Minshall/Novell)
TSV Multiparty Multimedia Session Control WG (mmusic)
(Eve Schooler/ISI and Abel Weinrib/Bellcore)
CAT Common Authentication Technology WG (cat)
(John Linn/Geer Zolot Associates)
USV Network Information Services Infrastructure WG (nisi)
(April Marine/SRI and Pat Smith/Merit)
1530-1600 Break (Refreshments provided)
1600-1800 Afternoon Sessions II
APP Interactive Mail Access Protocol WG (imap)
(Terry Gray/UWash)
MGT Frame Relay Service MIB WG (frnetmib)
(James Watt/Newbridge Networks)
RTG Source Demand Routing Protocol WG (sdr)
(Deborah Estrin/USC and Tony Li/cisco)
TSV Audio/Video Transport WG (avt) (Steve Casner/ISI)
1930-2200 Tuesday, November 2, 1993 - Evening Sessions
WEDNESDAY, November 3, 1993
0800-0900 Working Group Chairs Workshop
(Dave Crocker/Silicon Graphics)
0830-0900 Continental Breakfast
0900-0930 Technical Presentations
0930-1200 Morning Sessions
INT P. Internet Protocol WG (pip) (Paul Francis/Bellcore)
INT Point-to-Point Protocol Extensions WG (pppext)
(Fred Baker/ACC)
USV User Services WG (uswg) (Joyce K. Reynolds/ISI)
Breaks Coffee available.
1330-1530 Afternoon Sessions I
APP Telnet TN3270 Enhancements WG (tn3270e)
(Robert Moskowitz/Chrysler Corporation)
RTG Open Shortest Path First IGP WG (ospf)
(Rob Coltun/RainbowBridge Communications)
SEC Privacy-Enhanced Electronic Mail WG (pem)
(Steve Kent/BBN)
USV Networked Information Retrieval WG (nir)
(Jill Foster/UNewcastle-Upon-Tyne and George Brett/MCNC)
1530-1600 Break (Refreshments provided)
1600-1800 Afternoon Sessions II
MGT Frame Relay Service MIB WG (frnetmib)
(James Watt/Newbridge Networks)
RTG Source Demand Routing Protocol WG (sdr)
(Deborah Estrin/USC and Tony Li/cisco)
CAT Common Authentication Technology WG (cat)
(John Linn/Geer Zolot Associates)
1930-2200 Wednesday, November 3, 1993 - Evening Session
TSV RSVP -- Resource Reservation Setup Protocol for
the Internet BOF (rsvp) (Bob Braden/ISI)
THURSDAY, November 4, 1993
0830-0900 Continental Breakfast
0900-0930 Technical Presentations
0930-1200 Morning Sessions
INT IP Over Asynchronous Transfer Mode WG (atm)
(Mark Laubach/Hewlett-Packard)
MGT Remote LAN Monitoring WG (rmonmib)
(Mike Erlinger/Harvey Mudd College)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)*
RTG OSI IDRP for IP over IP WG (ipidrp) (Sue Hares/Merit)*
USV Network Training Materials WG (trainmat)
(Ellen Hoffman/Merit and
Jill Foster/UNewcastle-Upon-Tyne)
Breaks Coffee available.
1330-1530 Afternoon Sessions I
INT Simple Internet Protocol WG (sip)
(Steve Deering/Xerox PARC and Bob Hinden/Sun)
MGT ATM MIB WG (atommib) (Kaj Tesink/Bellcore)
RTG RIP Version II WG (ripv2) (Gary Malkin/Xylogics)
SEC Security Area Advisory Group (saag) (Steve Crocker/TIS)
1530-1600 Break (Refreshments provided)
1600-1800 Technical Presentations
1930-2200 Open Plenary and IESG
* BGP and IPIDPR will be meeting in joint session.
FRIDAY, November 5, 1993
0830-0900 Continental Breakfast
0900-1200 Morning Sessions
Key to Abbreviations
APP Applications Erik Huizer/SURFnet and
John Klensin/UNU
INT Internet Stev Knowles/FTP Software and
Dave Piscitello/Bellcore
MGT Network Management Marshall Rose/DBC
OPS Operational Requirements Scott Bradner/Harvard
RTG Routing Bob Hinden/Sun
SAP Service Applications Dave Crocker/SGI
SEC Security Steve Crocker/TIS
TSV Transport Allison Mankin/NRL
USV User Services Joyce K. Reynolds/ISI
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10085;
1 Sep 93 14:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10078;
1 Sep 93 14:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19221;
1 Sep 93 14:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10039;
1 Sep 93 14:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09989;
1 Sep 93 14:16 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa19162;
1 Sep 93 14:16 EDT
Received: from INFOODS.MIT.EDU by venera.isi.edu (5.65c/5.61+local-13)
id <AA26021>; Wed, 1 Sep 1993 11:16:32 -0700
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-13 #2603) id
<01H2FJAO933K000DFD at INFOODS.UNU.EDU>; Wed, 1 Sep 1993 14:15:57 EDT
Date: Wed, 01 Sep 1993 14:15:56 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John C Klensin <KLENSIN at infoods.mit.edu>
Subject: HOSTNAME protocol (was: Question on RFC 1500)
In-Reply-To: <54930901114545/0003858921NA2EM at mcimail.com>
To: 0003858921 at mcimail.com
Cc: ietf at isi.edu
Message-Id: <746907356.810140.KLENSIN at INFOODS.UNU.EDU>
X-Envelope-To: ietf at ISI.EDU
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <MultiNet-MM(330)+TOPSLIB(156)+PMDF(4.2)@INFOODS.UNU.EDU>
Robert,
Take this as a personal opinion, not a policy statement or an IESG
position...
HOSTNAME is an historical artifact of the pre-DNS days. Whatever the
strengths of the protocol and its data formats, it assumes that all the
relevant informations sits in one file and that you would want to
retrieve it all at once. Those are nasty sorts of assumptions in a
large network. It also has no way to represent MX record/information,
which is pretty important these days.
One of the implications of RFC1123 (and the DNS requirements and
schedules docs that preceeded it) is that a product from a "vendor that
insists on using it" is fairly seriously non-conforming and, in a word,
broken.
I'd guess that the move of RFC 953 to historic was the inevitable result
of the evolution of the network away from monolithic host tables and
toward the DNS. Encourage your vendor to do likewise or, to the degree
feasible, find another vendor--if they are backward on this, there are
probably other nasty problems with their implementation.
--john
p.s. "regular UNIX host file[s]" are no better, of course.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13005;
1 Sep 93 16:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25554;
1 Sep 93 16:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12968;
1 Sep 93 16:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12875;
1 Sep 93 16:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25385;
1 Sep 93 16:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12868;
1 Sep 93 16:50 EDT
To: IETF-Announce: ;
REPLY-TO: ietf28-social at sesqui.net
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: ietf28-social at sesqui.net
Subject: November IETF: Social Event
Date: Wed, 01 Sep 93 16:50:51 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9309011650.aa12868 at IETF.CNRI.Reston.VA.US>
--------------------- SOCIAL SURVEY ANNOUNCEMENT---------------------
Hi folks;
The Social Event for the 28th Internet Engineering Task Force (November 1-5),
sponsored by Rice University, has tentatively been scheduled to take
place Monday evening. We have been working on arrangements for at
least 200 attendees to tour Space Center Houston, adjacent to the
Johnson Space Center.
Current plans include: access to all the hands on exihibits, followed by
a reception....
Before our plans are finalized, we'd like to get an idea of the number of
folks who would attend such an event (we definitely need 200 takers).
It's important that we hear from you by >> 20 Sept. 1993 << in order to
determine whether to proceed with the final negotiations. If we don't have
200 affirmative responses by the due date above we will proceed with
alternative plans.
All responses should be directed to: ietf28-social at sesqui.net
We only need to hear from those who would attend.
___, Yes, I would attend the IETF Social if it were held at
the Space Center Houston.
----------
Thanks,
Bill Manning
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02167;
2 Sep 93 3:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02160;
2 Sep 93 3:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01613;
2 Sep 93 3:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02146;
2 Sep 93 3:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ai01740;
2 Sep 93 3:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ak01089;
2 Sep 93 2:42 EDT
Received: from paris.ics.uci.edu by IETF.CNRI.Reston.VA.US id aa14736;
1 Sep 93 20:48 EDT
Received: from valentine.ics.uci.edu by Paris.ics.uci.edu id aa12185;
1 Sep 93 17:46 PDT
To: ietf at CNRI.Reston.VA.US
Cc: suda at valentine.ics.uci.edu
Reply-to: suda at ics.uci.edu
Subject: IEEE Computer Communications Workshop
Date: Wed, 01 Sep 1993 17:46:47 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tatsuya Suda <suda at valentine.ics.uci.edu>
Message-ID: <9309011746.aa12185 at Paris.ics.uci.edu>
I believe the following workshop is of interest to many of the
IETFers. Workshop registration form is included at the end.
TS
The 8th IEEE Workshop on Computer Communications
IEEE COMMUNICATIONS SOCIETY
Technical Committee on Computer Communications
Sept. 1, 1993
Dear Colleague:
I am enclosing the advance technical program and registration materials for
the 8th IEEE Workshop on Computer Communications sponsored by the Technical
Committee on Computer Communications of the IEEE Communications Society.
The workshop will be held October 17-20 at the L'Auberge Del Mar Resort and
Spa, Del Mar (San Diego), California. This year we are holding the workshop
in conjunction with the Metropolitan Area Network Workshop, October 13-16.
This year we will continue to offer special rates for graduate students on
a very limited basis. Each application for this rate must be accompanied
by a letter by the student's advisor stating his/her qualifications. Only
graduate students who are close to completion of a doctoral program and
will receive the maximum benefit from the workshop need apply. Students
will be selected primarily by postmark date as space allows.
The L'Auberge Del Mar Resort and Spa is located in the exclusive seaside
village of Del Mar. L'Auberge features 123 luxury guest rooms & suites;
European health and beauty spa; fine dining; shopping; championship tennis
courts; swimming and lap pools; all with a spectacular ocean view. It is
twenty minutes from major San Diego tourist attractions and airport; less
than a mile from Del Mar Racetrack. There is a footpath to the beach.
It is a Four-star rated hotel recently affiliated with the prestigious
Hotel Bel-Air.
I am personally looking forward to exploring state of the art technology
at this year's workshop with you. I am sure you will enjoy exciting
discussions in this luxurious and tranquil setting.
Sincerely,
Tatsuya Suda
Workshop Chair
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717-3425
phone: (714) 856-5474 fax: (714) 856-4056 internet: ieeewksp at ics.uci.edu
=============================================================================
Technical Program
IEEE Communications Society
Technical Committee on Computer Communications
8th Annual Computer Communications Workshop
L'Auberge Inn at Del Mar (San Diego), California
October 17-20, 1993
Oct. 17: Registration Oct. 18-20: Technical Sessions
_____________________________________________________________________________
The annual IEEE Computer Communications Workshop is dedicated to informative
discussions and presentations of important and timely research in
communications. The focus of this year's workshop is on current trends in
network technology and management for broadband, optical and wireless
networks. As novel technologies and services have begun to evolve toward a
wider realization, new research issues have developed. This workshop has
been organized to explore these issues in detail, permitting a technical
understanding of their interrelatedness and laying a foundation for further
research.
_____________________________________________________________________________
_____________________________________________________________________________
Sunday, October 17
____________________________________________________________________________
5:00pm - 9:00pm Registration
Wine & Cheese Reception
_____________________________________________________________________________
_____________________________________________________________________________
Monday, October 18
_____________________________________________________________________________
7:00am Registration
Continental Breakfast
_____________________________________________________________________________
8:00am - 10:00am Technical Session I: Measurements of
High Speed Networks
Organizer: John Daigle (MITRE Corp.)
Brief Description: Presentation and discussion of measurements taken
from gigabit testbed networks will take place in
this session.
Tentative Speakers: Gary Minden (U. Kansas) and John Daigle (MITRE Corp.)
Existing and Proposed Testing and Measurement
in Gigabit Testbed Programs
Arne Nilsson (NCSU)
Traffic Characteristics in the VISTAnet
Allison Mankin (Naval Research Labs)
A Comparison of Measurement Results from
the BLANCA and NRL High Speed Optical
Network -- WANs and LANs
Prominent speaker to be added
_____________________________________________________________________________
10:00am - 10:30am Coffee Break
_____________________________________________________________________________
10:30am - 12:30pm Technical Session II: Local Area ATM
Organizer: Thomas La Porta (AT&T Bell Labs)
Tatsuya Suda (UC Irvine)
Brief Description: ATM technologies, although originally targeted for
use in wide area, public networks, are rapidly being
harnessed by those in the LAN community. ATM's
accommodation of high link speeds and multimedia
capability have made it attractive in small, high-
demand networked environments. Research issues
raised by the introduction of ATM technology into
the local environment will be discussed in this
session.
Tentative Speakers: Peter Newman (Adaptive Corp.)
LAN Emulation for ATM Networks
Vijay Kumar (AT&T Bell Labs)
A Multimedia ATM LAN
Al Leon-Garcia (U. Toronto) &
You-Ze Cho (Kyungpook National University, Korea)
Burst-Level Bandwidth Management in Local
ATM Networks
Thomas La Porta (AT&T Bell Labs)
Homogeneous Signaling for ATM LANs, MANs,
and WANs
Victor Li (USC) and Irfan Khan (SRI Int'l)
High Speed Network Traffic Modeling and
Management
_____________________________________________________________________________
12:30pm- 2:30pm Lunch
_____________________________________________________________________________
2:30pm - 5:00pm Technical Session III: ATM Performance Issues -
(half hour break at 3:30) Supporting Broadband Services
Organizers: Jack Brassil (AT&T Bell Labs)
Mark Karol (AT&T Bell Labs)
Brief Description: B-ISDNs are expected to carry various forms of
traffic (voice, video data), each of which places
distinct requirements on network transport systems.
The purpose of this session is to discuss
performance issues associated with supporting
various anticipated traffic types.
Tentative Speakers: Kai Eng (AT&T Bell Labs)
State of the Art in Gigabit ATM Switching
Magda El Zarki & Pramod Pancha (U. Pennsylvania)
Understanding VBR Video Sources for
Transmission over ATM-based Networks
Arvind Krishna, Hamid Ahmadi, Moshe Sidi &
Khosrow Sohraby (IBM T.J. Watson)
Delay and Jitter Analysis in Wireless
Environments
Izhak Rubin & Ho-Ting Wu(UCLA)
Local and Metropolitan ATM Ring Networks:
Throughput Capacity and Local Fairness
Regulation
Hisashi Kobayashi (Princeton)
A Diffusion Approximation of ATM Traffic
for Statistical Multiplexing
_____________________________________________________________________________
5:30pm Cocktail Party
8:30pm Town Hall Meeting
_____________________________________________________________________________
_____________________________________________________________________________
Tuesday, October 19
_____________________________________________________________________________
7:00am Breakfast
_____________________________________________________________________________
8:00am - 10:00am Technical Session IV: Multicast Communications
Organizer: Nachum Shacham (SRI Int'l.)
Tentative Speakers: Lixia Zhang (Xerox PARC)
RSVP: A Multicast ReSerVation Protocol
Mostafa Ammar (Georgia Inst. of Technology)
Probabilistic Multicast: Generalizing the
Multicast Paradigm to Improve Scalability"
Nachum Shacham (SRI Int'l.)
Hierarchical Multicast over ATM
Deborah Estrin (USC)
Wide-area Multicast Routing Support for
Sparse Groups
_____________________________________________________________________________
10:00am - 10:30am Coffee Break
_____________________________________________________________________________
10:30am - 12:30pm Technical Session V: Directions in Network Management
Organizers: Carl Sunshine (Aerospace Corp.)
Joseph Betser (Aerospace Corp.)
Brief Description: Network management systems have been evolving
rapidly, with competing technologies and many
product offerings for both management stations
and subnet monitors. Some standards are emerging,
but problems of scalability, integration and
security remain to be solved. This session will
focus on exploring these issues.
Tentative Speakers: Joseph Betser (Aerospace Corp.)
Current Trends in Technology and Products
Mike Erlinger (Harvey Mudd College and Aerospace Corp.)
Subnet Monitoring and RMON
Steve Waldbusser (CMU)
New Developments with SNMP and SNMPv2
Liang Wu (Bellcore)
Quality of Service Management in ATM Networks
Yechiam Yemini (Columbia U)
Management by Delegation
_____________________________________________________________________________
12:30pm- 2:30pm Lunch Break
_____________________________________________________________________________
2:30pm - 5:00pm Technical Session VI: Host Interface Design for
(half hour break at 3:30) High Speed Networks
Organizer: Sean O'Malley (U. Arizona)
Brief Description: As network performance has increased, the network-
host interface has emerged as a significant
bottleneck in overall network performance. In
addition, this increase in network performance has
blurred some of the distinctions between WANs, LANs,
distributed memory multiprocessor interconnection
networks, and intrahost communication channels.
Thus the traditional approach to network host
interface design appears to provide neither the
performance nor the flexibility required by modern
computer systems. This session will include
presentations of novel approaches to network host
interface design.
Tentative Speakers: Darleen Fisher (NSF)
An Update on Gigabit Network Testbeds
Danny Cohen (ISI)
The ATOMIC LAN
Bruce Davie (Bellcore)
The OSIRIS ATM Interface: Experience and
Insights
Vineet Kumar (Intel)
The Intel Paragon HIPPI Interface
John Kubiantowicz (MIT LCS)
Fast Messaging in the Alewife Multiprocessor
David Tennenhouse (MIT LCS)
The Design Space for Network Host Interface
_____________________________________________________________________________
6:00pm Dinner Banquet
8:30pm Town Hall Meeting
_____________________________________________________________________________
_____________________________________________________________________________
Wednesday, October 20
_____________________________________________________________________________
7:00am Breakfast
_____________________________________________________________________________
8:00am - 10:00am Technical Session VII: Optical Technology and
the Future of Networking
Organizers: Joseph Bannister (Aerospace Corp.)
Biswanath Mukherjee (UC Davis)
Brief Description: Optical technologies will provide the principal
foundation for networks of the future. The trends,
opportunities, risks and concerns with optical
networks will be discussed.
Tentative Speakers: Jon Sauer (U. Colorado)
Deflection Routing Networks for Computer
Interconnection
Mario Gerla (UCLA)
Cost-Technology Tradeoffs in Multifiber
WDM Networks
Tony Acampora and Tom Stern (Columbia)
All-Optical Network Architectures Based
on Wavelength Routing
Vincent Chan (Lincoln Labs)
Wideband Optical Network of the Future
_____________________________________________________________________________
10:00am - 10:30am Coffee Break
_____________________________________________________________________________
10:30am - 12:30pm Technical Session VIII: Wireless Network
Communications
Organizer: Khosrow Sohraby (IBM - T.J. Watson)
Brief Description: It is expected that, in the future, wireless
networks will be supporting a broad range of
services such as voice, data, and video. This
session will deal with various challenging issues
in such networks.
Tentative Speaker: Hamid Ahmadi (IBM T.J. Watson)
Design Issues for Wireless Local Area Networks
S. Nanda (AT&T Bell Labs)
A Data Link Protocol for Wireless Links
Mahmoud Naghshineh (Columbia)
An Architecture and Methodology for
Mobile-Executed Cell Hand-off in Wireless
ATM Networks
Leandros Tassiulas (Polytechnic U.)
Efficient Spectrum Management for High
Capacity Wireless Networks
_____________________________________________________________________________
12:30pm - 1:00pm Wrap-up Session
_____________________________________________________________________________
=============================================================================
REGISTRATION INFORMATION
Registration with payment must be received by Monday, September 13, 1993.
Registration received after this date cannot be guaranteed acceptance.
Please mail or fax a copy of the registration form to:
Robin Sharp Phone: (714) 856-5474
IEEE Computer Communications Workshop FAX: (714) 856-4056
Information and Computer Science
University of California
Irvine, CA 92717-3425
USA
Please make checks payable to "IEEE 1993 Computer Communications Workshop".
For workshop inquiries, you may contact us through email at:
ieeewksp at ics.uci.edu.
Cancellations/substitutions must be submitted in writing and received by
Monday, September 13, 1993.
Workshop fees include workshop attendance, refreshments at breaks,
lunches, workshop reception and dinner banquet, and one copy of the
conference materials.
FEE: $275 *IEEE members
$315 Nonmembers
$100 Students (subject to approval)
*IEEE members must include membership number to receive member discount.
=============================================================================
REGISTRATION FORM
First Name________________________ Last Name_________________________
Title__________________________________________________________________
Badge Name_____________________________________________________________
Company/Institution____________________________________________________
Address________________________________________________________________
City____________________ State_________ Country__________ Zip__________
Telephone____________________________ Fax______________________________
Email__________________________________________________________________
IEEE Member Number_____________________________________________________
Special Meal Requirements:
Vegetarian__________ Kosher__________ Other(Specify)_____________
Amount Enclosed (must be in U.S. dollars) $____________
=============================================================================
The 8th IEEE Workshop on Computer Communications
ACCOMMODATION INFORMATION
A block of rooms has been reserved at:
L'Auberge Del Mar Resort and Spa
1540 Camino Del Mar
Del Mar (San Diego), California 92014
Phone: (619) 259-1515 or (800) 553-1336
Fax: (619) 755-4940
The hotel will hold these rooms until October 1, 1993. Hotel
arrangements should be made directly to the hotel by phone or the
reservation form provided. To receive the special rates (see
reservation form), please mention you will be attending the IEEE
Computer Communications Workshop. We are holding our workshop in
conjunction with the IEEE Metropolitan Area Network Workshop which
is being held October 13-16.
-----------------------------------------------------------------------------
TRANSPORTATION INFORMATION
It is recommended that you fly into San Diego for the easiest access to
the workshop location. The San Diego Airport is serviced by all major
airlines. If you need assistance with your travel arrangements, the hotel
has an on-site travel agency, Ranch and Coast Travel at (619) 481-1230.
International travellers may find more convenient flights into Los Angeles
Airport. There are also flights available from Los Angeles Airport to
San Diego Airport. If you choose not to fly into San Diego Airport from
Los Angeles Airport, a rental car is necessary to travel from Los Angeles
to the hotel.
TRANSPORTATION FROM SAN DIEGO AIRPORT TO L'AUBERGE:
Limousine service $40 (4-6 people) phone hotel for arrangements
Super Shuttle $25 phone: (619) 278-8877
Taxi $35-40
DIRECTIONS TO L'AUBERGE DEL MAR RESORT AND SPA
DIRECTIONS BY CAR:
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.