CAOES Electronic Forum on Networking Emergency Management
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CAOES Electronic Forum on Networking Emergency Management
- Subject: CAOES Electronic Forum on Networking Emergency Management
- Newsgroups: comp.dcom.telecom
Since the use of networks for emergency management has been discussed
here before, I thought that you would find this x-posting (from the
HSPNET-L listserv) interesting >>>
Comments: Resent-From: "Donald F. Parsons MD" <DFP10 at ALBNYVM1>
Comments: Originally-From: david tilson - admin DVI
<davidt at brain.vifp.monash.edu.au>
--------Original message------
Hi All,
The following was sent by Art Botterell, from the California Office of
Emergency Services. Art's Internet address, for further information
is acb at oes.ca.gov
Regards, davidt
ELECTRONIC FORUM ON NETWORKING EMERGENCY MANAGEMENT
The California Office of Emergency Services invites practitioners and
students of emergency management to take part in a new electronic-
mail forum (which we hope will be a worthy complement to "ADMIN".)
"Networks In Emergency Management" is a moderated forum on the uses
of networks and networked computers in the practice of emergency
management.
The "nets" forum is facilitated by staff of the Telecommunications
Division, California Office of Emergency Services. However, opinions
and representations are the writers' own, and their inclusion in this
forum does not imply endorsement by the State of California or
California OES.
Comments for this forum may be mailed to "nets at oes.ca.gov". We'll
include the most appropriate ones, as space permits, in the next
issue.
To be added to the "nets" mailing list, please send e-mail to
"nets-request at oes.ca.gov" with the word "subscribe" in the message
text.
+---------------------------------------------------------------------+
| John K. Scoggin, Jr. Email: scoggin at delmarva.com |
| Supervisor, Network Operations Phone: (302) 451-5200 |
| Delmarva Power & Light Company Fax: (302) 451-5321 |
| 500 N. Wakefield Drive NOC: (800) 388-7076 |
| Newark, DE 19714-6066 |
| The opinions expressed are not those of Delmarva Power, simply the |
| product of an over-active imagination... |
+---------------------------------------------------------------------+
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25635;
10 May 93 13:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25629;
10 May 93 13:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15200;
10 May 93 13:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25622;
10 May 93 13:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25610;
10 May 93 13:00 EDT
Received: from david.zfe.siemens.de by CNRI.Reston.VA.US id aa15165;
10 May 93 13:00 EDT
Received: from ztivax.zfe.siemens.de by david.zfe.siemens.de with SMTP id AA03640
(5.65c/IDA-1.4.4 for <ietf at cnri.reston.va.us>); Mon, 10 May 1993 18:59:27 +0200
Received: from pnsts412-sun.zfe.siemens.de (pnsts412-sun) by ztivax.zfe.siemens.de with SMTP id AA15932
(5.65c/IDA-1.4.4 for <ietf at cnri.reston.va.us>); Mon, 10 May 1993 19:00:23 +0200
Received: from clipper.PhoneMail by pnsts412-sun.zfe.siemens.de (4.1/SMI-4.1)
id AA04909; Mon, 10 May 93 19:01:06 +0200
Received: from trek.PhoneMail by clipper.PhoneMail (4.1/SMI-4.1)
id AA27671; Mon, 10 May 93 10:01:05 PDT
Date: Mon, 10 May 93 10:01:04 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Roberto Perelman <perelman at clipper.zfe.siemens.de>
Message-Id: <9305101701.AA27671 at clipper.PhoneMail>
To: ietf at CNRI.Reston.VA.US
Subject: Reliable delivery using PPP
Cc: sepulvr at clipper.zfe.siemens.de, tonyp at clipper.zfe.siemens.de,
jeff at clipper.zfe.siemens.de, glenn at clipper.zfe.siemens.de
Status: O
I'm new to PPP, and am trying to understand what it provides. Perhaps
someone can clarify something for me. In most literature I have read,
PPP is described as guaranteeing reliable delivery. RFC 1331 itself
only says:
Some protocols expect error free transmission, and either provide
error detection only on a conditional basis, or do not provide it
at all. PPP uses the HDLC Frame Check Sequence for error
detection. This is commonly available in hardware
implementations, and a software implementation is provided.
Since PPP relies on the use of the Unnumbered Information (UI) command
of HDLC for transmission of frames, and since these type of frames are
not numbered (i.e. N(R) or N(S) not used) nor acknowledged, how can PPP
be considered to provide reliable delivery? I realize there is a FCS in
every frame, and this could be used to detect frames received in error,
but: 1) the receiver has no way of informing the sender about the error
(at the data link layer), and 2) the frame might be missed altogether
by the receiver.
Your answer to these hopefully not too obvious questions is appreciated.
Roberto Perelman
ROLM - A Siemens Company
M/S 1206
4900 Old Ironsides Dr.
P.O. Box 58075
Santa Clara, CA 95052-8075
Phone: (408) 492-6551
Fax: (408) 492-6132
e-mail # 1: perelman at clipper.zfe.siemens.de
e-mail # 2: perelman at scrvm2.ibmmail.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25875;
10 May 93 13:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25871;
10 May 93 13:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15572;
10 May 93 13:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25854;
10 May 93 13:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25850;
10 May 93 13:09 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa15556; 10 May 93 13:09 EDT
Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA22342 for iab at cnri.reston.va.us; Mon, 10 May 93 13:09:27 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA10321; Mon, 10 May 93 10:08:52 PDT
Message-Id: <9305101708.AA10321 at aland.bbn.com>
To: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US, iab at CNRI.Reston.VA.US
Subject: re: Censorship...
X-Orig-Sender:iesg-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, 10 May 93 10:08:51 -0700
X-Orig-Sender: craig at aland.bbn.com
Status: O
> The procedures allowing free discussion are flawed.
>
> I, as a member of this community, demand that our procedures be corrected.
>
> IESG, IAB, and ISOC, what are you going to do to correct this
> situation and allow free and unintimidated discussion?
Karl:
Since ISOC is a volunteer organization, I think actually the burden is
on you to put a proposal forward. Besides, systems always work best when
responding to concrete suggestions.
What mechanism to provide free and un-intimidated (and I'd add, useful)
discussion do you think the IESG, IAB, ISOC should put in place, and how
much time are you willing to put in to putting the mechanism in place?
Craig
PS: Keep in mind that some mechanisms already exist -- e.g. Gary Malkin's
intro to IETF, designed to help first-time attendees avoid faux-pas, and
the recently started seminars to train WG chairs.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26356;
10 May 93 13:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26350;
10 May 93 13:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16027;
10 May 93 13:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26329;
10 May 93 13:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26311;
10 May 93 13:21 EDT
Received: from OPAL.ACC.COM by CNRI.Reston.VA.US id aa16022; 10 May 93 13:21 EDT
Received: by opal.acc.com (4.1/SMI-4.0)
id AA03735; Mon, 10 May 93 10:20:41 PDT
Date: Mon, 10 May 93 10:20:41 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: <9305101720.AA03735 at opal.acc.com>
To: ietf at CNRI.Reston.VA.US, perelman at clipper.zfe.siemens.de
Subject: Re: Reliable delivery using PPP
Cc: glenn at clipper.zfe.siemens.de, jeff at clipper.zfe.siemens.de,
sepulvr at clipper.zfe.siemens.de, tonyp at clipper.zfe.siemens.de
Status: O
>
>I'm new to PPP, and am trying to understand what it provides. Perhaps
>someone can clarify something for me. In most literature I have read,
>PPP is described as guaranteeing reliable delivery. RFC 1331 itself
>only says:
>
> Some protocols expect error free transmission, and either provide
> error detection only on a conditional basis, or do not provide it
> at all. PPP uses the HDLC Frame Check Sequence for error
> detection. This is commonly available in hardware
> implementations, and a software implementation is provided.
>
>Since PPP relies on the use of the Unnumbered Information (UI) command
>of HDLC for transmission of frames, and since these type of frames are
>not numbered (i.e. N(R) or N(S) not used) nor acknowledged, how can PPP
>be considered to provide reliable delivery? I realize there is a FCS in
>every frame, and this could be used to detect frames received in error,
>but: 1) the receiver has no way of informing the sender about the error
>(at the data link layer), and 2) the frame might be missed altogether
>by the receiver.
>
>Your answer to these hopefully not too obvious questions is appreciated.
I'm not sure where you got the idea that PPP provides guaranteed delivery.
As it stands today, PPP is just a datagram service with error detection
(using the HDLC FCS), but no error correction. The major benefits of
PPP are multiprotocol multiplexing/demultiplexing and option negotiation.
There is some interest in adding an option for negotiating a guaranteed
delivery mode (most likely using LAPB) under PPP. This is desireable for
a couple of uses (especially data compression).
>
>Roberto Perelman
Art
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26640;
10 May 93 13:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26634;
10 May 93 13:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16266;
10 May 93 13:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26627;
10 May 93 13:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26620;
10 May 93 13:31 EDT
Received: from [192.135.241.98] by CNRI.Reston.VA.US id aa16259;
10 May 93 13:31 EDT
Received: from strange-brew.cisco.com by europe.cisco.com with TCP; Mon, 10 May 93 19:31:22 +0200
Received: by strange-brew.cisco.com; Mon, 10 May 93 20:32:58 +0200
Date: Mon, 10 May 93 20:32:58 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Alex Bochannek <abochann at cisco.com>
Message-Id: <9305101832.AA00684 at strange-brew.cisco.com>
To: Roberto Perelman <perelman at clipper.zfe.siemens.de>
Cc: glenn at clipper.zfe.siemens.de, ietf at CNRI.Reston.VA.US,
jeff at clipper.zfe.siemens.de, sepulvr at clipper.zfe.siemens.de,
tonyp at clipper.zfe.siemens.de
Subject: Reliable delivery using PPP
In-Reply-To: <9305101701.AA27671 at clipper.PhoneMail>
References: <9305101701.AA27671 at clipper.PhoneMail>
Reply-To: abochann at cisco.com
Status: O
Roberto Perelman writes:
> I'm new to PPP, and am trying to understand what it provides. Perhaps
> someone can clarify something for me. In most literature I have read,
> PPP is described as guaranteeing reliable delivery. RFC 1331 itself
Check out RFC1377 (OSINLCP), there is an interesting paragraph that
puts things into perspective (page 3):
Connection-Oriented Network Protocol
The OSI Connection-Oriented Network Protocol (ISO 8208) [8],
effectively the Packet Layer of CCITT X.25, is intended to be run
over a reliable data link, such as IEEE 802.2 type II or LAPB.
Therefore, the unreliable data link service provided by PPP is not
appropriate for use with ISO 8208.
P.S.: Are you by any chance referring to the O'Reilly book "TCP/IP
Network Administration" page 119?
--
Alex Bochannek TAC : +32 2 643 26-30
Technical Support Analyst Direct: +32 2 643 26-38
Cisco Systems International S.A. Fax : +32 2 643 26-27
250 avenue Louise, 8th Floor RFC822: abochann at cisco.com
1050 Brussels, Belgium
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26939;
10 May 93 13:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26925;
10 May 93 13:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16539;
10 May 93 13:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26911;
10 May 93 13:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26904;
10 May 93 13:39 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa16500; 10 May 93 13:39 EDT
Received: by ftp.com
id AA23980; Mon, 10 May 93 13:39:50 -0400
Date: Mon, 10 May 93 13:39:50 -0400
Message-Id: <9305101739.AA23980 at ftp.com>
To: perelman at clipper.zfe.siemens.de
Subject: Re: Reliable delivery using PPP
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: ietf at CNRI.Reston.VA.US, sepulvr at clipper.zfe.siemens.de,
tonyp at clipper.zfe.siemens.de, jeff at clipper.zfe.siemens.de,
glenn at clipper.zfe.siemens.de
Status: O
Roberto,
The literature that you have read is wrong. RFC1331 is right, as is
your analysis. PPP does not provide any guarantees of delivery. You
would have to use a reliable transport protocol to achieve that.
--
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 aa27008;
10 May 93 13:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26996;
10 May 93 13:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16554;
10 May 93 13:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26948;
10 May 93 13:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26923;
10 May 93 13:40 EDT
Received: from SAFFRON.ACC.COM by CNRI.Reston.VA.US id aa16540;
10 May 93 13:40 EDT
Received: by saffron.acc.com (4.1/SMI-4.1)
id AA13591; Mon, 10 May 93 10:39:54 PDT
Date: Mon, 10 May 93 10:39:54 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker at acc.com>
Message-Id: <9305101739.AA13591 at saffron.acc.com>
To: perelman at clipper.zfe.siemens.de
Subject: Re: Reliable delivery using PPP
Cc: glenn at clipper.zfe.siemens.de, ietf at CNRI.Reston.VA.US,
jeff at clipper.zfe.siemens.de, sepulvr at clipper.zfe.siemens.de,
tonyp at clipper.zfe.siemens.de
Status: O
>> I'm new to PPP, and am trying to understand what it provides. Perhaps
>> someone can clarify something for me. In most literature I have read,
>> PPP is described as guaranteeing reliable delivery.
I suggest that this discussion continue on the PPP list
(ietf-ppp at ucdavis.edu); Ask postmaster at ztivax.zfe.siemens.de to create
an alias listing yourself and your collegues listed on the CC line, and
send a note to David Arredondo (ietf-ppp-request at ucdavis.edu) asking
him to add it to the PPP mailing list.
As to PPP's reliability, it is explicitly a *best effort* data link
protocol, designed to support best effort network layers like IP,
CLNS, IPX, or DDP. The approach assumes that message sequence and
reliability is an end to end problem which must be solved in the
transport layer anyway. It follows the advice of the End to End
Principle, which asserts that it is pointless to provide a service in a
layer below that at which it must ultimately be implemented.
If your application requires reliability, you may wish to contribute to
current work in progress towards negiation of the use of the numbered
mode (LAPB, etc) in conjunction with PPP. This is being done to
support data link layer reliability requirements such as exist on
compressed links.
Fred Baker
Chair, PPP WG
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27226;
10 May 93 13:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27220;
10 May 93 13:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16883;
10 May 93 13:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27208;
10 May 93 13:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27202;
10 May 93 13:49 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa16842;
10 May 93 13:49 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA18272>; Mon, 10 May 1993 10:50:02 -0700
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA23018; Mon, 10 May 93 13:49:56 -0400
Received: from hull.opl.com by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12645; Mon, 10 May 93 13:49:22 -0400
Received: by hull.opl.com from ottawa.opl.com (vers 4.1)
for info-ietf at uunet.uu.net (from news at opl.com)
id <AA06686 at hull.opl.com>; Mon, 10 May 93 13:47:11 EDT
Received: by ottawa.opl.com (4.1/3.1.090690-OPL )
id AA14966; Mon, 10 May 93 13:47:13 EDT
To: info-ietf at uunet.uu.net
Path: opl.com!psinntp!psinntp!cmcl2!news.ans.net!mercury!scoggin
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John K Scoggin Jr <scoggin at delmarva.com>
Newsgroups: info.ietf
Subject: Disaster Communications (fwd message from telecom newsgroup)
Message-Id: <1slf83INNn1v at blackhole.delmarva.com.ans-relay>
Date: 10 May 93 11:45:07 GMT
X-Orig-Sender: ietf-request at IETF.CNRI.Reston.VA.US
Reply-To: scoggin at delmarva.com
Organization: Delmarva Power & Light Company
Lines: 63
To: info-ietf at uunet.uu.net
X-Orig-Sender: news at delmarva.com
Nntp-Posting-Host: mercury.delmarva.com
Status: O
Since we were discussing the potential uses of the Internet for disaster
communications, I found this message interesting:
---
>From Peter M. Weiss <PMW1 at psuvm.psu.edu> ()
Newsgroups: comp.dcom.telecom
Subject: CAOES Electronic Forum on Networking Emergency Management
Since the use of networks for emergency management has been discussed
here before, I thought that you would find this x-posting (from the
HSPNET-L listserv) interesting >>>
Comments: Resent-From: "Donald F. Parsons MD" <DFP10 at ALBNYVM1>
Comments: Originally-From: david tilson - admin DVI
<davidt at brain.vifp.monash.edu.au>
--------Original message------
Hi All,
The following was sent by Art Botterell, from the California Office of
Emergency Services. Art's Internet address, for further information
is acb at oes.ca.gov
Regards, davidt
ELECTRONIC FORUM ON NETWORKING EMERGENCY MANAGEMENT
The California Office of Emergency Services invites practitioners and
students of emergency management to take part in a new electronic-
mail forum (which we hope will be a worthy complement to "ADMIN".)
"Networks In Emergency Management" is a moderated forum on the uses
of networks and networked computers in the practice of emergency
management.
The "nets" forum is facilitated by staff of the Telecommunications
Division, California Office of Emergency Services. However, opinions
and representations are the writers' own, and their inclusion in this
forum does not imply endorsement by the State of California or
California OES.
Comments for this forum may be mailed to "nets at oes.ca.gov". We'll
include the most appropriate ones, as space permits, in the next
issue.
To be added to the "nets" mailing list, please send e-mail to
"nets-request at oes.ca.gov" with the word "subscribe" in the message
text.
+---------------------------------------------------------------------+
| John K. Scoggin, Jr. Email: scoggin at delmarva.com |
| Supervisor, Network Operations Phone: (302) 451-5200 |
| Delmarva Power & Light Company Fax: (302) 451-5321 |
| 500 N. Wakefield Drive NOC: (800) 388-7076 |
| Newark, DE 19714-6066 |
| The opinions expressed are not those of Delmarva Power, simply the |
| product of an over-active imagination... |
+---------------------------------------------------------------------+
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28369;
10 May 93 14:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28365;
10 May 93 14:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19515;
10 May 93 14:46 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28355;
10 May 93 14:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28351;
10 May 93 14:46 EDT
Received: from INFOODS.MIT.EDU by CNRI.Reston.VA.US id aa19510;
10 May 93 14:46 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GXZ1Y7PLW00006ER at INFOODS.UNU.EDU>; Mon, 10 May 1993 14:46:35 EDT
Date: Mon, 10 May 1993 14:46:34 -0400 (EDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John C Klensin <KLENSIN at infoods.unu.edu>
Subject: re: Censorship...
To: karl at empirical.com
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US, iab at CNRI.Reston.VA.US
Message-id: <737059594.492103.KLENSIN at INFOODS.UNU.EDU>
X-Envelope-to: iab at CNRI.RESTON.VA.US, iesg at CNRI.RESTON.VA.US,
ietf at CNRI.RESTON.VA.US
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>
Status: O
Karl,
It seems to me that, while some fine-tuning might be done (and when I
have specific ideas, I'll propose them -- I haven't been heard from on
this one because I don't), asking for huge improvements in the system
may involve requirements for changes in human nature (or maybe
nerd-nature) or other utopia-requiring measures.
Could things be better, smoother, more receptive to ideas? Of course.
But much of that would require, as Marshall points out (and, in case you
haven't noticed, these are not areas in which Marshall and I often
agree), changes in individual behavior, not changes in procedures. If
people would always study the relevant materials and archives before
posting, we would save a lot of time and bad temper. If we are going to
"let" people post without study and thinking, then we will waste some
time and increase the risk of good ideas being washed out with the bad
ones. To not "let" them implies that we have procedures for preventing
it; all of those I can think of would really call forth claims/fears of
censorship. It is a nasty tradeoff, but I'm not sure we can do a lot
better than we are doing as a procedural model.
Going back to discussions of a year ago, one could eliminate a lot of
problems by creating an IETF Competency test and using it as a
prerequisite for postings or meeting attendance. Unfortunately, it
would cost us a lot of good ideas, even if we could figure out who we
trusted to design and administer such a test.
The email medium we use is also rotten at communicating certain types of
tone and some things get easily blown out of proportion. And we aren't
a community with a history of being polite when we criticize ideas with
which we don't agree. The two reinforce each other. Some may consider
that an advantage. Although, as someone who has gradually learned to
disagree while being civil, I tend not to accept that, it is obvious
that I could write shorter messages if I would replace paragraphs of
explanatory text with "Foo, you are an idiot, that idea stinks, and any
right-thinking person would know it" flames.
The way we do things sometimes stokes the fires that we then complain
about. I'm not singling you out in particular, but, when I see a
sentence containing "...as a member of this community, I demand...",
especially without a concrete and feasible proposal about how to fix
whatever problem is identified, my immediate reaction is "oh, grow up".
To the extent that IAB or IESG has similar reactions, your legitimate
points get less consideration than they might otherwise: that serves
neither you nor the overall community well.
And I think the same thing sometimes happens with technical proposals:
even the thick-skinned among us can get defensive about ideas that we've
spent a lot of time developing and discussing when someone proposes an
alternate approach by suggesting that only rampant stupidity or hidden
motives could have produced our approach. "Your idea is ok, but my idea
is better and here are the reasons" is a _lot_ easier to take
emotionally and is proportionately more likely to get yours a better
hearing. Maybe it shouldn't work that way and that any contribution,
regardless of tone and timing, should be given equal consideration. But
the real problem probably can't be fixed by procedures. We need to
"fix" how people behave or just adapt to it, and IAB and IESG don't have
a lot of control over that, even if they would like to.
That is not to say that rampant stupidity and hidden motives (and
complete technical ignorance) don't occur. Unfortunately, I actually
expect the hidden motives (at least) to increase as the size of the
community and the financial stakes in IETF decisions rise. But we have
procedures for dealing with that now, which Marshall and others have
identified. They aren't perfect but I would hope that proposals for
changes would be specific and would consider what we might lose by
creating more procedures or specifics about ways of doing things and
responding to contributions.
I would also hope that all of us could remember that accidents,
ignorance, or even stupidity, are much more often the correct
explanations for disagreeable proposals than conspiracies. In
particular, we charge WG chairs both with maintaining a speedy schedule
and with making sure that all input is considered. That job is
impossible to handle perfectly: the best it is logical to hope for is
that we get it about right most of the time and that we have decent
mechanisms for correcting things on the occasions where things go
seriously wrong (regardless of the cause). Again, I'm not sure we can
do a lot better than we are doing on the basis of things that can be
legislated or proceduralized: some errors and noise may be the price for
a relatively open system that nonetheless is actually accomplishing
things.
-john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29145;
10 May 93 15:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29139;
10 May 93 15:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20150;
10 May 93 15:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29126;
10 May 93 15:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29108;
10 May 93 15:03 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa20140;
10 May 93 15:03 EDT
Received: from TGV.COM (HQ.TGV.COM) by venera.isi.edu (5.65c/5.61+local-12)
id <AA21075>; Mon, 10 May 1993 12:04:14 -0700
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Mon, 10 May 93 12:03:31 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA08377; Mon, 10 May 93 12:03:44 PDT
Date: Mon, 10 May 93 12:03:44 PDT
Message-Id: <9305101903.AA08377 at mel-brooks.empirical.com>
To: simon at internode.com.au
Subject: Re: FTP block mode implementations?
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
Cc: ietf at isi.edu, ietf-ftpext at ucdavis.edu
X-Orig-Sender: karl at mel-brooks.tgv.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
> >\ I also have reservations about the CPU needed to re-count all those
> >\ serialized bytes when I try to restart. I would suppose that my
> >\ expensive computer hardware (especially when we are considering the
> >\ kind that generally supports gigantic files) would find its cpu
> >\ cycles better spent on real work.
>
> That misses the point. If the file transfer on your putative large
> system fails, today, and the user has to transmit the entire file
> again, then they incur all the load you are mentioning, *plus*
> incurring all the network load and all the cpu cycles required for
> protocol stack processing overhead, in order to just get up to the
> point in the file where the failure originally occurred.
I was considering that the sender would have to re-serialize the
file, doing everything but send, those first N bytes. If N were very
large, that could be far more work than just seeking into the file.
> I would like to see the day when my average vendors' FTP will
> _automatically_ restart a transfer for me by default, and get it
> right.
Yes, I like to do file transfers without having to watch whether they
work or not.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29673;
10 May 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29666;
10 May 93 15:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20518;
10 May 93 15:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29652;
10 May 93 15:18 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa29648;
10 May 93 15:18 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: noop at merit.edu
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: An Echo Function for CLNP (ISO 8473) to Draft
Standard
Date: Mon, 10 May 93 15:18:03 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305101518.aa29648 at IETF.CNRI.Reston.VA.US>
Status: O
The IESG has approved the Internet Draft "An Echo Function for CLNP
(ISO 8473)" <draft-ietf-noop-echo-02.txt> as a Draft Standard. This
document was reviewed by Network OSI Operations Working Group.
The IESG contact person is David Piscitello.
Technical Summary
This document defines an echo function for the OSI connection-less
network layer protocol (ISO 8473, CLNP). Like the ICMP echo, this may be
used to support diagnostic applications like (e.g., a CLNP ping). The
function is supported through the use of echo request and reply packets
specified in ISO 8473, version 2.
Working Group Summary
This document has been approved by the Network OSI Operations Working
Group. The major change since the Proposed standard has been the
selection of the "long-term" option as mandatory for support of an echo
function. This option is based on the packet formats specified in ISO
8473, version 2, to be published in 1993.
Protocol Quality
The protocol has been implemented and used in operational CLNP networks
across the Internet. The minimum criteria of 2 interoperable implementations
has been met and exceeded.
Note to RFC Editor
The title of this document differs from the Internet Draft. The
title should be same as used in this protocol action. Please work
with the author to include a reference to the ISO 8473 echo request
option in this document.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29726;
10 May 93 15:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29722;
10 May 93 15:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20561;
10 May 93 15:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29712;
10 May 93 15:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29708;
10 May 93 15:19 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa20556; 10 May 93 15:19 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Mon, 10 May 93 12:19:31 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA08423; Mon, 10 May 93 12:19:47 PDT
Date: Mon, 10 May 93 12:19:47 PDT
Message-Id: <9305101919.AA08423 at mel-brooks.empirical.com>
To: KLENSIN at infoods.unu.edu
Subject: Do we need an Ombdusman? re: Censorship...
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
> It seems to me that, while some fine-tuning might be done (and when I
> have specific ideas, I'll propose them -- I haven't been heard from on
> this one because I don't), asking for huge improvements in the system
> may involve requirements for changes in human nature (or maybe
> nerd-nature) or other utopia-requiring measures.
I've spent the weekend trying to figure out what specific procedural
mechanisms would help prevent the intellectual intimidation which has
been so rampant in the network management area for the last many
years.
I do not agree with Bob Stewart that people who were intimidated
ought to have have had the guts to complain. And that since few have
complained, there is no problem. (My paraphrase).
Yet Bob came up with what is precisely the answer; people need to be
free to talk about times they have been ridiculed into silence, or
worse, when they have been afraid to speak at all for fear of being
bullied.
Perhaps we need an ombudsman.
--karl--
BTW -- It is interesting that while I did not mention network
management in my previous posting many people knew exactly what I was
talking about. That is interesting evidence that the situation does
exist and that people know about it.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00272;
10 May 93 15:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00263;
10 May 93 15:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20810;
10 May 93 15:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00243;
10 May 93 15:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00237;
10 May 93 15:28 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa20800; 10 May 93 15:28 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Mon, 10 May 93 12:29:12 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA08437; Mon, 10 May 93 12:29:28 PDT
Date: Mon, 10 May 93 12:29:28 PDT
Message-Id: <9305101929.AA08437 at mel-brooks.empirical.com>
To: ietf at CNRI.Reston.VA.US
Subject: Whirlyball photos?
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
This has nothing to do with SNMP, procedures, censorship, or even
computer networks...
And sorry for the broadcast, we forgot to make an attendee list of
the working group meeting...
Someone took photographs of the Whirlyball working group meeting at
the Columbus IETF meeting.
I'd sure like to get copies of a few of the shots. It seems that a
number of folk have a hard time believing that Whirlyball is real.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03976;
10 May 93 16:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03970;
10 May 93 16:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24271;
10 May 93 16:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03962;
10 May 93 16:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03955;
10 May 93 16:59 EDT
Received: from uswat.advtech.uswest.com by CNRI.Reston.VA.US id aa24265;
10 May 93 16:59 EDT
Received: from atqm.advtech.uswest.com by uswat.advtech.uswest.com with SMTP id AA27583
(5.65c/IDA-1.4.4 for <ietf at cnri.reston.va.us>); Mon, 10 May 1993 14:59:30 -0600
Message-Id: <199305102059.AA27583 at uswat.advtech.uswest.com>
Date: 10 May 1993 14:36:10 U
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rick Sturm <sturm at atqm.advtech.uswest.com>
Subject: Re: Keeping working groups
To: ietf at CNRI.Reston.VA.US
Status: O
Reply to: RE>>Keeping working groups o
>The only weakness is that the community continues to tolerate pointless
>messages of little or no redeeming value. Unfortunately, it is
>impossible to mandate good taste or professional responsibility. The
>problem is not that people with "competent, but perhaps not completely
>perfectly formed, comments" are discouraged from speaking. The >problem is
that some people who could contribute competent comments >do not do so, but
instead send pointless messages to multiple mailing
>lists.
Marshall,
I too get weary of some of the seemingly endless, pointless threads on the
list. I have a suggestion to offer which might help improve the quality of the
dialogue. In a couple of weeks, why don't you, as AD, post to the list a set
of "guidelines?" My personal #1 pet peeve is duplicate postings to the lists.
However, I also get very tired of the pointless, endless, unprofessional
threads that are nothing more than whining.
Actually, now that I think about it further, since you tend to be a lightening
rod, instead of drafting and issuing the guidlines yourself, why don't you
officially appoint some non-whiner to develop the guidelines? After the
guidelines have been developed, you could then sanction them in your official
capacity.
I know that it's not perfect, however, even if it made even a modest impact, it
would be time well spent.
Rick Sturm
U S WEST Advanced Technologies
Boulder, Colorado
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04706;
10 May 93 17:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04700;
10 May 93 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26034;
10 May 93 17:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04691;
10 May 93 17:55 EDT
Received: from ds.internic.net by IETF.CNRI.Reston.VA.US id aa04685;
10 May 93 17:55 EDT
Received: by ds.internic.net (4.1/SMI-4.1)
id AA10475; Mon, 10 May 93 17:55:19 EDT
Date: Mon, 10 May 93 17:55:19 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: DDBS Admin <admin at ds.internic.net>
Message-Id: <9305102155.AA10475 at ds.internic.net>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: InterNIC Plans for a White-pages Directory
Status: O
Sorry for the cross-posting.
=========
ANNOUNCEMENT
InterNIC Directory and Database Services
Members of the NSFNET community have recently expressed concern about
the continued availability of the WHOIS directory records that have
previously been available through WHOIS but that do not contain point
of contact information.
The NSF InterNIC team recognizes the importance to the NSFNET community
of this information and, therefore, will ensure that this information
is available to the community.
The continued maintenance of this information in a centralized fashion
is inconsistent, however, with the longer term need for a distributed
directory architecture in which data is collocated (logically, if not
physically) with those who have the knowledge to keep the data accurate
and up-to-date.
Applicable listings from the approximately 160,000 WHOIS directory
records will be made available on our server through WAIS. These
records will then be corrected and updated by contacting (through
e-mail) those listed and requesting correction/verification. Records
will be transferred to X.500 as they are verified. Records which are
not verified or which the listed individual doesn't want listed for any
reason will be purged.
The InterNIC Directory and Database Services team (AT&T) has chosen
X.500, because of its current availability, as the first implementation
of the InterNIC distributed directory service. As other options (e.g.,
WHOIS++) become available, they will be evaluated and, depending on the
outcome of that evaluation, will be implemented.
The Directory and Database Services team will develop a user agent that
supports the WHOIS protocol and that can search both the WAIS database
and the X.500 Directory, thus providing a consistent user interface to
the evolving directory.
As a general rule, the InterNIC will maintain no more than 50 entries
that pertain to a particular organization in the X.500 Directory
Service Agents (DSAs) that will be maintained on its servers. We will
work to help organizations implement their own X.500 DSAs. With time,
entries will moved from the WHOIS database to the InterNIC DSAs and the
distributed DSAs. In parallel, new entries will be added to both the
InterNIC DSAs and the distributed DSAs.
Related information is available via anonymous FTP on the InterNIC
Directory and Database Services server "ds.internic.net" in the
"/pub/internic-info" directory. "white-pages-position-paper.txt"
contains further details and rationale, "x500desc.txt" contains a
description of our X.500 services, and "organization-x500.template"
contains the template that organizations need to complete for a listing
in our directory.
Stay tuned for further details. . . .
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05123;
10 May 93 18:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05119;
10 May 93 18:31 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa27346;
10 May 93 18:31 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP
id <g.04404-0 at haig.cs.ucl.ac.uk>; Mon, 10 May 1993 22:47:16 +0100
Received: from ds.internic.net by bells.cs.ucl.ac.uk with Internet SMTP
id <g.17550-0 at bells.cs.ucl.ac.uk>; Mon, 10 May 1993 22:47:02 +0100
Received: by ds.internic.net (4.1/SMI-4.1) id AA10348;
Mon, 10 May 93 17:46:48 EDT
Date: Mon, 10 May 93 17:46:48 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: DDBS Admin <admin at ds.internic.net>
Message-Id: <9305102146.AA10348 at ds.internic.net>
To: ietf-announce at IETF.CNRI.Reston.VA.US
Subject: InterNIC Plans for a White-pages Directory
Cc: osi-ds at cs.ucl.ac.uk
Status: O
Sorry for the cross-posting.
=========
ANNOUNCEMENT
InterNIC Directory and Database Services
Members of the NSFNET community have recently expressed concern about
the continued availability of the WHOIS directory records that have
previously been available through WHOIS but that do not contain point
of contact information.
The NSF InterNIC team recognizes the importance to the NSFNET community
of this information and, therefore, will ensure that this information
is available to the community.
The continued maintenance of this information in a centralized fashion
is inconsistent, however, with the longer term need for a distributed
directory architecture in which data is collocated (logically, if not
physically) with those who have the knowledge to keep the data accurate
and up-to-date.
Applicable listings from the approximately 160,000 WHOIS directory
records will be made available on our server through WAIS. These
records will then be corrected and updated by contacting (through
e-mail) those listed and requesting correction/verification. Records
will be transferred to X.500 as they are verified. Records which are
not verified or which the listed individual doesn't want listed for any
reason will be purged.
The InterNIC Directory and Database Services team (AT&T) has chosen
X.500, because of its current availability, as the first implementation
of the InterNIC distributed directory service. As other options (e.g.,
WHOIS++) become available, they will be evaluated and, depending on the
outcome of that evaluation, will be implemented.
The Directory and Database Services team will develop a user agent that
supports the WHOIS protocol and that can search both the WAIS database
and the X.500 Directory, thus providing a consistent user interface to
the evolving directory.
As a general rule, the InterNIC will maintain no more than 50 entries
that pertain to a particular organization in the X.500 Directory
Service Agents (DSAs) that will be maintained on its servers. We will
work to help organizations implement their own X.500 DSAs. With time,
entries will moved from the WHOIS database to the InterNIC DSAs and the
distributed DSAs. In parallel, new entries will be added to both the
InterNIC DSAs and the distributed DSAs.
Related information is available via anonymous FTP on the InterNIC
Directory and Database Services server "ds.internic.net" in the
"/pub/internic-info" directory. "white-pages-position-paper.txt"
contains further details and rationale, "x500desc.txt" contains a
description of our X.500 services, and "organization-x500.template"
contains the template that organizations need to complete for a listing
in our directory.
Stay tuned for further details. . . .
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07767;
11 May 93 0:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07763;
11 May 93 0:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06801;
11 May 93 0:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07753;
11 May 93 0:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07749;
11 May 93 0:22 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa06796;
11 May 93 0:22 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA22027; Mon, 10 May 93 21:22:43 -0700
Message-Id: <9305110422.AA22027 at Mordor.Stanford.EDU>
To: karl at empirical.com
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Mon, 10 May 93 12:19:47 -0700. <9305101919.AA08423 at mel-brooks.empirical.com>
Date: Mon, 10 May 93 21:22:43 -0700
X-Orig-Sender:iesg-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
Status: O
Karl,
You've received a number of responses already to your "J'accuse" note,
so I will try to keep my own brief.
First, a complaint such as you apparently were intending to lodge should
be accompanied with a list of particulars. The text from Marshall that
you quoted included that advice and I am, here, repeating it. It is
not possible to repond to general statements of discontent or assertions
of mis-performance. If you have specific assertions, then please do
pursue them, but please include the detail.
As a matter of etiquette and efficiency, such concerns usually are best
raised first in a more limited forum, such as through private email or
email to the iesg, rather than including the full ietf list. I encourage
you and others to explore the benefits of limited distribution prior to
raising the public anty.
Second, I think it worth noting that the IESG went considerably beyond
its usual efforts to review wg behavior and ensure fair process, for the
recent round of activity by the SNMPv2 working group. I spent half
a day reviewing the email transcript and Erik Huizer conducted an
explicit public query for comments and concerns. Since it is unlikely
that the IESG, or any other management/oversight body or person is going
to be blessed with omniscience, there is a fundamental requirement that
those with concerns be willing to express them. In this case, there were
some concerns, but they did not lead to any reasonable conclusion that
the process of the working group had been unfair.
---- Included message:
Perhaps we need an ombudsman.
While it generally escaped notice, I served as Area Director for
Standards Management for quite awhile and tried to speak publicly
about the process, the need for balance, etc. I certainly viewed one
of the tasks of the job as being concerned with reviewing the process
when there was a complaint. What would you expect different from
an ombudsman?
BTW -- It is interesting that while I did not mention network
management in my previous posting many people knew exactly what I was
talking about. That is interesting evidence that the situation does
exist and that people know about it.
Just as a wild guess, Karl, do you think that your including the snmp
working group in the email list might have loaded the interpretive dice just
a tad?
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08564;
11 May 93 0:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08556;
11 May 93 0:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07052;
11 May 93 0:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08549;
11 May 93 0:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08542;
11 May 93 0:27 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa07047; 11 May 93 0:27 EDT
Return-Path: <jmm at merit.edu>
Received: from localhost.merit.edu by merit.edu (5.65/1123-1.0)
id AA21996; Tue, 11 May 93 00:27:43 -0400
Date: Tue, 11 May 93 00:27:43 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jeffrey K. MacKie-Mason" <jmm at merit.edu>
Message-Id: <9305110427.AA21996 at merit.edu>
To: merit.ietf at merit.edu
Newsgroups: merit.ietf
Subject: Re: What's the current internet diameter?
References: <9305070038.AA05974 at mel-brooks.empirical.com>
Organization: Merit Network, Inc. (Ann Arbor, MI)
Status: O
In article <9305070038.AA05974 at mel-brooks.empirical.com> karl at empirical.com writes:
>Does anybody have any idea what the maximum diameter (in hops) is
>from the two most distant parts of the internet? My guess is
>somewhere between 30 and 40. But I feel that I'm probably guessing
>low.
>
>??
>
>BTW, do any of the space shuttles have an IP address?
>
> --karl--
>
I recently logged several thousand traceroute requests to 8 different locations around the world (that is, traceroutes repeated hourly for several weeks)
to provide some data for a paper I wrote on the economics of pricing the
Internet. When I set up the script I didn't notice that traceroute
only keeps track of the first 30 hops by default. There were a number of times
when my traces exceeded 30 hops, however. All of my chosen sites (chosen
more or less randomly, certainly not to maximize hops) could be reached
in far fewer than 30 hops, but sometimes network conditions with dynamic
routing resulted in more than 30 hops. The worst offender was the route
from Ann Arbor, Michigan to a machine in Nova Scotia.
Since I wasn't choosing sites to maximize hops, and if you are willing to count bad realizations of dynamic routing as part of your maximum diameter, my bet is that the max number of hops is far more than 40.
Prof. Jeff MacKie-Mason voice: 313-764-7438
Dept. of Economics fax: 313-761-3989
Univ. of Michigan email: jmm at umich.edu
Ann Arbor, MI 48109
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00589;
11 May 93 6:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00583;
11 May 93 6:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02200;
11 May 93 6:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00570;
11 May 93 6:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00561;
11 May 93 6:00 EDT
Received: from relay2.UU.NET by CNRI.Reston.VA.US id aa02136; 11 May 93 6:00 EDT
Received: from spool.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA19018; Tue, 11 May 93 06:01:06 -0400
Received: from metrix.UUCP by spool.uu.net with UUCP/RMAIL
(queueing-rmail) id 055945.18387; Tue, 11 May 1993 05:59:45 EDT
Received: from cookie.metrix.com by metrix.com (4.0/SMI-4.0)
id AA13612; Tue, 11 May 93 00:07:05 EDT
Received: by cookie.metrix.com (5.0/SMI-SVR4)
id AA23778; Tue, 11 May 93 00:08:14 EDT
Date: Tue, 11 May 93 00:08:14 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: T Hariharan <hari at metrix.com>
Message-Id: <9305110408.AA23778 at cookie.metrix.com>
Subject: Duplicate postings
Cc: ietf at CNRI.Reston.VA.US
X-To: sturm at atqm.advtech.uswest.com
Content-Length: 724
Status: O
For one way to avoid cross postings, but still convey the intention that
you did want to cross-post (or reply to a person and Cc the list, but
did not want the person to get duplicate copies, as I intended), look in the
header of this mail (hope the line I'm referring to is still there when
this is posted to the list).
Of course this means that your mail UI lets you access the header
(/usr/ucb/Mail under solaris 2.1 does). It also means that you take the
time to do this.
-hari
-----------------------------------------------------------
Thiagarajan (Hari) Hariharan hari at metrix.com
Metrix Network Systems, Inc., 1 Tara Blvd, Nashua, NH 03062
voice 603.888.7000 fax 603.891.2796
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01412;
11 May 93 7:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01406;
11 May 93 7:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04128;
11 May 93 7:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01399;
11 May 93 7:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01393;
11 May 93 7:57 EDT
Received: from mwunix.mitre.org by CNRI.Reston.VA.US id aa04123;
11 May 93 7:57 EDT
Return-Path: <m_fidler%W036_NW at MWMGATE1.mitre.org>
Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2)
id AA14491; Tue, 11 May 1993 07:57:13 -0400
Message-Id: <199305111157.AA14491 at mwunix.mitre.org>
Date: Tue, 11 May 93 07:53:03 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: m_fidler%W036_NW at mwmgate1.mitre.org
To: ietf at CNRI.Reston.VA.US, karl at empirical.com
Subject: Re: Whirlyball photos?
Status: O
>Someone took photographs of the Whirlyball working group meeting at
>the Columbus IETF meeting.
>
>I'd sure like to get copies of a few of the shots. It seems that a
>number of folk have a hard time believing that Whirlyball is real.
>
> --karl--
Gee, if someone would scan one or two of those photos and leave them in
an FTP server somewhere, and...
- Mike F.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab02924;
11 May 93 9:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06620;
11 May 93 9:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02915;
11 May 93 9:04 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02894;
11 May 93 9:04 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-manning-dns-nsap-02.txt
Date: Tue, 11 May 93 09:04:22 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305110904.aa02894 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : DNS NSAP Resource Records
Author(s) : B. Manning, R. Colella
Filename : draft-manning-dns-nsap-02.txt
Pages : 10
The Internet is moving towards the deployment of an OSI lower layers
infrastructure. This infrastructure comprises the connectionless
network protocol (CLNP) and supporting routing protocols. Also
required as part of this infrastructure is support in the Domain Name
System (DNS) for mapping between names and NSAP addresses.
This document defines the format of two new Resource Records (RRs) for
the DNS, building upon earlier work in RFC 1348. This format may be
used with any NSAP address format.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-manning-dns-nsap-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-manning-dns-nsap-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-manning-dns-nsap-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-manning-dns-nsap-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 aa03712;
11 May 93 9:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07556;
11 May 93 9:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03687;
11 May 93 9:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03666;
11 May 93 9:32 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-bgp4-05.txt
Date: Tue, 11 May 93 09:32:21 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305110932.aa03666 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Border Gateway Protocol
Working Group of the IETF.
Title : A Border Gateway Protocol 4 (BGP-4)
Author(s) : Y. Rekhter, T. Li
Filename : draft-ietf-bgp-bgp4-05.txt
Pages : 57
This document, together with its companion document, "Application of
the Border Gateway Protocol in the Internet", define an
inter-autonomous system routing protocol for the Internet.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-bgp-bgp4-05.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-bgp4-05.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-bgp-bgp4-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bgp-bgp4-05.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 aa03792;
11 May 93 9:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07601;
11 May 93 9:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03779;
11 May 93 9:33 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03760;
11 May 93 9:33 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
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-mime2-03.txt, .ps
Date: Tue, 11 May 93 09:33:27 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305110933.aa03760 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised 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 : MIME (Multipurpose Internet Mail Extensions) Part
One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies
Author(s) : N. Borenstein, N. Freed
Filename : draft-ietf-822ext-mime2-03.txt, .ps
Pages : 93
RFC 822 defines a message representation protocol which specifies
considerable detail about message headers, but which leaves the
message content, or message body, as flat ASCII text. This document
redefines the format of message bodies to allow multi-part textual and
non-textual message bodies to be represented and exchanged without
loss of information. This is based on earlier work documented in RFC
934 and RFC 1049, but extends and revises that work. Because RFC 822
said so little about message bodies, this document is largely
orthogonal to (rather than a revision of) RFC 822.
In particular, this document is designed to provide facilities to
include multiple objects in a single message, to represent body text
in character sets other than US-ASCII, to represent formatted multi-font
text messages, to represent non-textual material such as images and audio
fragments, and generally to facilitate later extensions defining new types
of Internet mail for use by cooperating mail agents.
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-mime2-03.txt".
Or
"get draft-ietf-822ext-mime2-03.ps".
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-mime2-03.txt".
Or
"SEND draft-ietf-822ext-mime2-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-822ext-mime2-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-822ext-mime2-03.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 aa03875;
11 May 93 9:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03871;
11 May 93 9:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07717;
11 May 93 9:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03858;
11 May 93 9:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03852;
11 May 93 9:35 EDT
Received: from nic.cerf.net by CNRI.Reston.VA.US id aa07712; 11 May 93 9:35 EDT
Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA00209; Tue, 11 May 93 06:39:10 PDT
Date: Tue, 11 May 1993 06:02:15 -0700 (PDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Subject: Re: Do we need an Ombdusman? re: Censorship...
To: ietf at CNRI.Reston.VA.US
Cc: iesg at CNRI.Reston.VA.US
In-Reply-To: <9305101919.AA08423 at mel-brooks.empirical.com>
Message-Id: <Pine.3.05.9305110612.A27315-d100000 at nic.cerf.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
As one of the people that was intimidated into not saying anything, I will now
get things "off my chest."
First of all, to my way of thinking, a moderator approach to WGs are
necessary. A moderator is one that doesn't take sides, can't vote on the
outcome of the WG and has the sole purpose to make sure that all voices are
heard. This means heard regardless of whether or not they agree with the
statement. A moderator's job is to make sure that issues that are raised are
given a chance to be heard.
I wish to iterate that the most important part of the moderator is to be
neutral! They only direct the discussion, not participate. Yes, I know
that may seen hard and harsh, but fairness demands it. For an example of
how a moderator might function, attend a small town meeting in some New
England town ( I will invite anyone to visit the Town of West Newbury and
watch Ms. Casey Swallow do her job as Town Moderator!)
Another part of the moderator's job is to disallow any personal attacks,
basically to keep things civil. The moderator has the right and power to
remove people from the meeting, to basically control behaviour. This is
important, as well.
What does this mean for the WG concept. First, each WG has a chair. This
chair can't voice an opinion on the subject of the WG, nor vote on any
of the procedures or outcome. Rather then let all messages mingle over the
network, in chaos, the moderator scans each, recording it in the archives
and either directing the sending party to rephrase the comments, allowing
the message to the group, or directing it to a specific party.
Now, many might think this is excessive. Perhaps it is. But moderation in
discussion and debates works, and has worked in the past. One of the fears
that many of us have is that this concentrates a lot of power into the hands
of a few. For that reason, I would suggest that the job of moderator be
given to a person outside of the WG. For instance, in the case of the
SNMPv2 WG, Bob Stewart wouldn't have been allowed to chair the group. This
doesn't mean that Bob did a bad job, but he did tend to show a bias at times.
Finally, under no circumstance should exceptions be allowed to the form
and function of the WG. This means that the SNMPv2 group should have gone
through the same hoops as every other group, without exception or reservation.
Nothing is more important to the survival of the Internet than to insure
that everyone can understand what is happening, and that "special"
interests haven't effected the outcome. In other words that fairness wins
out over special interests in this community.
As for Rick Sturm's comments about M.Rose basically issuing an edict to
the NM group, I would like to think that Marshall wouldn't take that
advise. It seems to me that an AD would have a counterpart to insure that
fair and open discussions can take place. For this reason I would also
like to suggest a Moderator or Ombudsman (from outside the area) be
assigned so that things don't get out of hand -- that people or groups
aren't alienated.
Personal opinion follows
========================
The other issue concerns the medium itself. Many times we act differently
in front of a person than if we see that person face to face. What I think
is funny is that this was predicted in earlier Psyc experiments --
remember the experiment where a person, if face to face, has a hard time
providing electrical shock. Whereas an annonymous person finds it easier.
We all tend to lose our humanity -- kindness, tolerance, and the like --
via email. Remember that politeness and kindness isn't a weakness, but a
strength of humanity.
Finally, along the same lines, there is this notion that an issue once
raised is forever answered. I might like to point out, if you are
interested, that we both teachers and students. Those with the knowledge
should feeled honoured to help someone learn, granted maybe offline,
rather than feel it a "chore." What we are practicing isn't a science like
physics (where there might be an answer), but an art based on experiences.
For this reason every question or statement will lead somewhere, and
differing groups of people will cause different outcomes.
Chuck Wegrzyn.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04077;
11 May 93 9:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08142;
11 May 93 9:41 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04029;
11 May 93 9:41 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04013;
11 May 93 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: hostmib at andrew.cmu.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-hostmib-resources-01.txt
Date: Tue, 11 May 93 09:41:05 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305110941.aa04013 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Host Resources MIB
Working Group of the IETF.
Title : Host Resources MIB
Author(s) : Pete Grillo, Steven Waldbusser
Filename : draft-ietf-hostmib-resources-01.txt
Pages : 34
This memo defines a MIB for use with managing host systems. The term
"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 this MIB 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. This MIB instruments attributes
common to all internet hosts including, for example, both personal
computers and systems that run variants of Unix.
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-hostmib-resources-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-hostmib-resources-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-hostmib-resources-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-hostmib-resources-01.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 aa04276;
11 May 93 9:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04271;
11 May 93 9:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08589;
11 May 93 9:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04261;
11 May 93 9:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04257;
11 May 93 9:47 EDT
Received: from ics.uci.edu by CNRI.Reston.VA.US id aa08584; 11 May 93 9:47 EDT
Received: from nma.com by q2.ics.uci.edu id ad09337; 10 May 93 23:35 PDT
Received: from localhost by odin.nma.com id aa22612; 10 May 93 23:28 PDT
To: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
In-reply-to: Dave Crocker's message of "Mon, 10 May 1993 21:22:43 PDT."
<9305110422.AA22027 at Mordor.Stanford.EDU>
Reply-to: Stef=ietf at nma.com
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Einar Stefferud <Stef=ietf at nma.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 10 May 1993 23:28:21 -0700
Message-ID: <22610.737101701 at odin.nma.com>
X-Orig-Sender: stef at nma.com
Status: O
I want to chime in with Dave Crocker here, and endorse what he said.
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Date: Mon, 10 May 93 21:22:43 -0700
This whole thing has gone over the top in terms of expecting the ISOC,
IAB, IESG, and the MGT AD, to drop what they are doing to pursue vague
charges and strident demands for big actions.
Were I a member of any of the involved IETF related bodies, I would
find it extremely hard to do anything constructive or useful with what
has so far been demanded.
At best the charges can only lie there festering and moldering until
someone cleans them up, or until the demands are withdrawn.
I favor withdrawl.
Perhaps a nice cold shower would be helpful at this point? Best...\Stef
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04874;
11 May 93 10:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04838;
11 May 93 10:11 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa09481;
11 May 93 10:11 EDT
Received: from Relay.Prime.COM by venera.isi.edu (5.65c/5.61+local-12)
id <AA17100>; Tue, 11 May 1993 07:11:44 -0700
Message-Id: <199305111411.AA17100 at venera.isi.edu>
Received: from TURBO.Kean.EDU by Relay.Prime.COM; 11 May 93 10:11:41 EDT
Received: (from user akc) by TURBO.Kean.EDU; 11 May 93 10:11:39 EST
To: ietf at isi.edu
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Al Costanzo"@CNRI.Reston.VA.US,
Associate Director - Computer Services <AKC at turbo.prime.com>
Subject: InterNIC Plans for a White-pages Directory
Encoding: 21 text (note by akc), 77 message (from admin)
Date: 11 May 93 10:11:39 EST
Status: O
I am concerned to see that your attitude is basically one of,
first, let us break the whois command so it no longer works and then
lets push OSI on everyone to fix what we broke. You are asking everyone
to implement x.500 directory service when whois "used to" work just fine
until someone cam up with the idea of cleansing the database.
Let me ask you this....
Are YOU going to pay my vendor to implement x.500 directory service on
all my hosts? If not, lets keep this optional for a number of years
and put the Whois database back together, Please.
Many of use are working on many projects all at the same time. I do not
need another one forced on me by NSF at this point in time.
Disgruntled,
Al
---- original message:
Return-Path: <@TURBO.Kean.EDU:ietf-request at List.Kean.EDU>
Received: from TURBO.Kean.EDU by TURBO.Kean.EDU; 10 May 93 20:30:23 EST
Received: from IETF.nri.reston.VA.US by TURBO.Kean.EDU; 10 May 93 20:16:55 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04712;
10 May 93 17:55 EDT
Received: from ds.internic.net by IETF.CNRI.Reston.VA.US id aa04685;
10 May 93 17:55 EDT
Received: by ds.internic.net (4.1/SMI-4.1)
id AA10475; Mon, 10 May 93 17:55:19 EDT
Date: Mon, 10 May 93 17:55:19 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: DDBS Admin <admin at ds.internic.net>
Message-Id: <9305102155.AA10475 at ds.internic.net>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: InterNIC Plans for a White-pages Directory
Reply-To: ietf at List.Kean.EDU, DDBS Admin <admin at ds.internic.net>
Sorry for the cross-posting.
=========
ANNOUNCEMENT
InterNIC Directory and Database Services
Members of the NSFNET community have recently expressed concern about
the continued availability of the WHOIS directory records that have
previously been available through WHOIS but that do not contain point
of contact information.
The NSF InterNIC team recognizes the importance to the NSFNET community
of this information and, therefore, will ensure that this information
is available to the community.
The continued maintenance of this information in a centralized fashion
is inconsistent, however, with the longer term need for a distributed
directory architecture in which data is collocated (logically, if not
physically) with those who have the knowledge to keep the data accurate
and up-to-date.
Applicable listings from the approximately 160,000 WHOIS directory
records will be made available on our server through WAIS. These
records will then be corrected and updated by contacting (through
e-mail) those listed and requesting correction/verification. Records
will be transferred to X.500 as they are verified. Records which are
not verified or which the listed individual doesn't want listed for any
reason will be purged.
The InterNIC Directory and Database Services team (AT&T) has chosen
X.500, because of its current availability, as the first implementation
of the InterNIC distributed directory service. As other options (e.g.,
WHOIS++) become available, they will be evaluated and, depending on the
outcome of that evaluation, will be implemented.
The Directory and Database Services team will develop a user agent that
supports the WHOIS protocol and that can search both the WAIS database
and the X.500 Directory, thus providing a consistent user interface to
the evolving directory.
As a general rule, the InterNIC will maintain no more than 50 entries
that pertain to a particular organization in the X.500 Directory
Service Agents (DSAs) that will be maintained on its servers. We will
work to help organizations implement their own X.500 DSAs. With time,
entries will moved from the WHOIS database to the InterNIC DSAs and the
distributed DSAs. In parallel, new entries will be added to both the
InterNIC DSAs and the distributed DSAs.
Related information is available via anonymous FTP on the InterNIC
Directory and Database Services server "ds.internic.net" in the
"/pub/internic-info" directory. "white-pages-position-paper.txt"
contains further details and rationale, "x500desc.txt" contains a
description of our X.500 services, and "organization-x500.template"
contains the template that organizations need to complete for a listing
in our directory.
Stay tuned for further details. . . .
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06945;
11 May 93 12:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06941;
11 May 93 12:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13840;
11 May 93 12:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06930;
11 May 93 12:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06926;
11 May 93 12:17 EDT
Received: from nic.cerf.net by CNRI.Reston.VA.US id aa13833; 11 May 93 12:17 EDT
Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA08971; Tue, 11 May 93 09:21:41 PDT
Date: Tue, 11 May 1993 09:16:14 -0700 (PDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Subject: Re: Do we need an Ombdusman? re: Censorship...
To: Einar Stefferud <Stef=ietf at nma.com>
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
In-Reply-To: <22610.737101701 at odin.nma.com>
Message-Id: <Pine.3.05.9305110910.E7294-b100000 at nic.cerf.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
On Mon, 10 May 1993, Einar Stefferud wrote:
> I want to chime in with Dave Crocker here, and endorse what he said.
>
> From: Dave Crocker <dcrocker at mordor.stanford.edu>
> Date: Mon, 10 May 93 21:22:43 -0700
>
> This whole thing has gone over the top in terms of expecting the ISOC,
> IAB, IESG, and the MGT AD, to drop what they are doing to pursue vague
> charges and strident demands for big actions.
>
> Were I a member of any of the involved IETF related bodies, I would
> find it extremely hard to do anything constructive or useful with what
> has so far been demanded.
>
> At best the charges can only lie there festering and moldering until
> someone cleans them up, or until the demands are withdrawn.
>
> I favor withdrawl.
>
> Perhaps a nice cold shower would be helpful at this point? Best...\Stef
Sorry, Einar, but I don't the point of your message. I didn't demand
anything, I just suggested a few things. I suggested that WG chairs be
neutral - no vote, no opinion, just moderate. Secondly, I suggested that
the to every AD be assigned an Ombudsman. Neither of these seem too great
a change to not merit further examination; since I'm not in a position to
do that, I really can't be too sure.
What I would like to have happen is to remove the doubts and politics from
all aspects of the Internet. Either we all learn to work together, and
appreciate the contribution of everyone on the network, or it will go down
in flames. The only way I can see this happening is that everyone feel
comfortable about participating in the network. That we all recognize that
there are no enemies here, just people, such as yourself, that might have
differences of opinion and can air them.
Sincerely, Chuck Wegrzyn.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07406;
11 May 93 13:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07382;
11 May 93 13:12 EDT
Received: from INFOODS.MIT.EDU by CNRI.Reston.VA.US id aa15330;
11 May 93 13:12 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GY0SGODSS000064V at INFOODS.UNU.EDU>; Tue, 11 May 1993 13:12:02 EDT
Date: Tue, 11 May 1993 13:12:01 -0400 (EDT)
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: John C Klensin <KLENSIN at infoods.unu.edu>
Subject: Re: Do we need an Ombdusman? re: Censorship...
In-reply-to: <Pine.3.05.9305110612.A27315-d100000 at nic.cerf.net>
To: wegrzyn at nic.cerf.net
Cc: ietf at CNRI.Reston.VA.US
Message-id: <737140321.983103.KLENSIN at INFOODS.UNU.EDU>
X-Envelope-to: ietf at CNRI.RESTON.VA.US
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>
Status: O
>First of all, to my way of thinking, a moderator approach to WGs are
>necessary. A moderator is one that doesn't take sides, can't vote on the
>outcome of the WG and has the sole purpose to make sure that all voices are
>...
Chuck,
Up to a point, I prefer that role in chairs and editors to a partisan
one. I tend to try to use it. But my ability to do so effectively
depends on my having enough subject matter knowledge that, sooner or
later, I'm going to reach conclusions and probably do things that you
would construe as taking sides.
Two observations...
(1) For every New England town that has a moderator who understands what
is going on and can maintain fairness and balance without anyone questioning
the moderator's integrity, there are probably three or four where they
keep rotating moderators in the hope of finding someone who can do that
job and one or two that run by a single individual who runs the town meeting
and the town by iron-handed control of the agenda.
(2) New England town meetings are based, in part, that it is just as well
if anything about which the town can't reach consensus doesn't get done.
Because we prefer that WGs converge within finite lifetimes, and because
many engineering jobs are not finished until they have to be, an important
role of a WG chair is to decide when discussions have gone on enough and
when no new issues are being raised and to see if consensus can be
forced at that point. That requires technical competence in the areas
involved, not the role of citizen-observer. It also gets harder as the
number of people involved rises--most town meeting moderators will, in
fact, cut off questions raised for the third time in a given meeting
and, if the next meeting is a year hence, well the issues are different
and maybe the questions are appropriate again. This is a little
different than "same question every third week, as if it were new".
john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07646;
11 May 93 13:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07640;
11 May 93 13:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15883;
11 May 93 13:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07628;
11 May 93 13:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07624;
11 May 93 13:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15877;
11 May 93 13:29 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07616;
11 May 93 13:29 EDT
To: IETF-Announce: ;
Cc: IESG <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: Last Call: Post Office Protocol - Version 3 to Draft Standard
Date: Tue, 11 May 93 13:29:14 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305111329.aa07616 at IETF.CNRI.Reston.VA.US>
Status: O
The IESG has received a request to consider the Internet Draft "Post
Office Protocol - Version 3" <draft-rose-pop3-01.txt> as a Draft
Standard. This has been reviewed in the IETF but is not the product
of an IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
May 25th.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08382;
11 May 93 14:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08377;
11 May 93 14:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17027;
11 May 93 14:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08367;
11 May 93 14:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08363;
11 May 93 14:02 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa17017; 11 May 93 14:02 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Tue, 11 May 93 11:02:14 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA09469; Tue, 11 May 93 11:02:30 PDT
Date: Tue, 11 May 93 11:02:30 PDT
Message-Id: <9305111802.AA09469 at mel-brooks.empirical.com>
To: dcrocker at mordor.stanford.edu
Subject: Re: Do we need an Ombdusman? re: Censorship...
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
> First, a complaint such as you apparently were intending to lodge should
> be accompanied with a list of particulars.
I have had much private mail about this issue, yesterday and over the
last many years. The situation is one which many people seem blind
and do not want to recognize.
I did not want to put out particulars, which would simply serve to
highlight the individuals. Rather, I am attempting to focus on the
general problem. You should be able to appreciate that.
However, I might add, that I was gratuitously blasted on the entire
IETF and SNMP mailing lists. There are times when it is necessary to
stand up and say "this is wrong."
You have missed the entire point when you talk about snmpv2 working
group fairness. The group itself was fair, in large part due to the
greatly appreciated efforts of its chairman, Bob Stewart.
The point is that many, many people have simply given up working with
the snmp community at all because of the situation. Take Vince
Fuller's note as simply the tiny tip of a very large iceberg.
Overall, I am appalled that you are focusing more on the process by
which I raised the complaint than about the substance of the
complaint itself.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08407;
11 May 93 14:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08403;
11 May 93 14:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17037;
11 May 93 14:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08391;
11 May 93 14:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08383;
11 May 93 14:02 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa17029; 11 May 93 14:02 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Tue, 11 May 93 11:02:34 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA09489; Tue, 11 May 93 11:02:50 PDT
Date: Tue, 11 May 93 11:02:50 PDT
Message-Id: <9305111802.AA09489 at mel-brooks.empirical.com>
To: Stef=ietf at nma.com
Subject: Re: Do we need an Ombdusman? re: Censorship...
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: karl at empirical.com, ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
> At best the charges can only lie there festering and moldering until
> someone cleans them up, or until the demands are withdrawn.
I don't withdraw anything I've said. We see ridicule and
intimidation practiced for years, see that it still continues, and
yet most are afraid to speak out.
And we see mail that asks for specifics. Well, I'm coming up with
specifics. I would have rather dealt with the situation more
gracefully, but it seems that many are unwilling to even see, even
when there was evidence on the ietf mailing list as recently as last
week.
And we see mail that suggests that people who have been intimidated
should step up to the microphone and complain. That is unrealistic.
The damage that has been caused is very large. We have lost
credibility and have set back attempts to do real technical
cooperation with other communities.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09011;
11 May 93 14:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09007;
11 May 93 14:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17900;
11 May 93 14:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08995;
11 May 93 14:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08990;
11 May 93 14:24 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa17868;
11 May 93 14:24 EDT
Received: from LOCALHOST by black-ice.cc.vt.edu (AIX 3.2/UCB 5.64/4.03)
id AA12978; Tue, 11 May 1993 14:24:52 -0400
Message-Id: <9305111824.AA12978 at black-ice.cc.vt.edu>
To: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Cc: Einar Stefferud <Stef=ietf at nma.com>, ietf at CNRI.Reston.VA.US,
iesg at CNRI.Reston.VA.US, valdis at black-ice.cc.vt.edu
Subject: Re: Do we need an Ombdusman? re: Censorship...
In-Reply-To: Your message of "Tue, 11 May 1993 09:16:14 EDT."
<Pine.3.05.9305110910.E7294-b100000 at nic.cerf.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 11 May 1993 14:24:51 +22312049
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
Status: O
On Tue, 11 May 1993 09:16:14 EDT, Chuck Wegrzyn said:
> Sorry, Einar, but I don't the point of your message. I didn't demand
> anything, I just suggested a few things. I suggested that WG chairs be
> neutral - no vote, no opinion, just moderate. Secondly, I suggested that
> the to every AD be assigned an Ombudsman. Neither of these seem too great
> a change to not merit further examination; since I'm not in a position to
> do that, I really can't be too sure.
>
> What I would like to have happen is to remove the doubts and politics from
> all aspects of the Internet. Either we all learn to work together, and
> appreciate the contribution of everyone on the network, or it will go down
> in flames. The only way I can see this happening is that everyone feel
> comfortable about participating in the network. That we all recognize that
> there are no enemies here, just people, such as yourself, that might have
> differences of opinion and can air them.
Well, *in theory*, appointing a neutral WG chair and an ombudsman
would address the problems. However, as has been pointed out,
the WG chair needs be at least technically competent, and will thus
probably be at least slightly biased towards one proposal or another
(note that this is not necessarily a Good Thing or a Bad Thing).
However, as far as "removing the doubts and politics" goes, I'm
reminded of an old Heinlein novel, where there was inscribed on
the wall a Latin phrase which translated as "Who will guard
the guardians?". This is in fact an important point - if you're
going to appoint "neutral" chairs and ombudsmen, how are you
going to guarantee impartiality? As a specific example - would
you want *me* being the chair of the SNMP-V3 working group? I
can guarantee I'll be impartial. On the other hand, I also
guarantee that due to lack of understanding of SNMP, I'll be
unable to catch and stop any technically stupid ideas.... :)
The good thing about the IETF process is that it mostly works - we
get implementable specs, and something that's pretty much usable.
If there's a problem, there's always the review at end of the
'proposed standard' time, and you can always write an updating
RFC, etc etc etc. Yes, we get the occasional wart (such as the
mostly-ignored TCP options byte, the previously mentioned 'get-next'
problem in SNMP, etc). On the other hand, we also get things like
TCP/IP, SMTP, and so forth.
I'm speaking as a mostly-lurker member of several working groups -
on occasion I've been flamed pretty good for saying stupid things,
but in general, the flamers were kind enough to quote chapter and
verse of *why* it was a dumb idea, and much was learned as a result.
On the other hand, on a few occasions things I brought up were
incorporated into what eventually made it into RFCs.
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09919;
11 May 93 15:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09915;
11 May 93 15:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19408;
11 May 93 15:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09904;
11 May 93 15:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09900;
11 May 93 15:10 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa19399;
11 May 93 15:10 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA10338; Tue, 11 May 93 12:10:26 -0700
Message-Id: <9305111910.AA10338 at Mordor.Stanford.EDU>
To: karl at empirical.com
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 11 May 93 11:02:30 -0700. <9305111802.AA09469 at mel-brooks.empirical.com>
Date: Tue, 11 May 93 12:10:25 -0700
X-Orig-Sender:iesg-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
Status: O
Karl,
---- Included message:
Overall, I am appalled that you are focusing more on the process by
which I raised the complaint than about the substance of the
complaint itself.
I am, of course, sorry to hear of your reaction. One rarely enjoys
causing another to be appalled.
However, I tried in my previous note to make clear that the difficulty
with pursuing the substance of your complaint is that I could not discern
sufficient detail from which to determine what behaviors were being
questioned. It is, of course, possible that I simply didn't read your
notes carefully enough. I don't believe that was the problem, though.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11348;
11 May 93 15:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11344;
11 May 93 15:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21003;
11 May 93 15:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11328;
11 May 93 15:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11324;
11 May 93 15:51 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa20983; 11 May 93 15:51 EDT
Received: by ftp.com
id AA00934; Tue, 11 May 93 15:52:19 -0400
Date: Tue, 11 May 93 15:52:19 -0400
Message-Id: <9305111952.AA00934 at ftp.com>
To: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
X-Orig-Sender:iesg-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
Status: O
On Tue, 11 May 1993 09:16:14 EDT, Chuck Wegrzyn said:
> anything, I just suggested a few things. I suggested that WG chairs be
> neutral - no vote, no opinion, just moderate. Secondly, I suggested that
> the to every AD be assigned an Ombudsman. Neither of these seem too great
What happens if the Ombudsman is suspected of being a member of the
evil cabal? Do we appoint an Ombudsman**2? And if Ombudsman**2
believed to also be a member of the evil cabal? Please note that this
sequence can be continued to about Ombudsman**<5 or 6 *10**9> -- at
which point we run out of people.
What can we learn from this (admittedly extreme) example?
Well, to me it sounds like we can learn that we will have to trust
each other if we are to get any work done. And what does this mean?
Well I can draw 2 or 3 conclusions from it:
1. There is no secret, evil, conspiracy, out to squash the poor, unsuspecting
peasants. When the peasants do get squashed, it is probably because they
are bringing up something for the umpity-poo'th time and the squashers are
simply tired of refuting the same argument avery month for 2 years.
Conversely, the squashers should probably realize, after the 20th time
that someone brings up a bad idea, that this bad idea has some
prima facie attractiveness and it would be in everyone's interests if
an RFC was written explaining the design choice and describing why the
bad idea is a bad idea.
2. The poor, honest, hardworking, peasants have to realize that when
they do get squashed, it is probably not personal (at least the
first two or three times). To be brutally honest, I (and probably the
squashers as well) have better things to do with my time than go
out of my way just to turn you into road-kill -- you are simply
not worth it.
What people should do is take the time to go and read the archives
and read the rfcs and internet drafts, and perhaps look at whatever
code might be around, books, papers, and so on, before assuming that
they are experts.
Though I admit, flaming various people with wild accusations about
evil-cabal-membership, or incompetence, or whatever, is much easier.
--
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 aa15024;
11 May 93 16:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15020;
11 May 93 16:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23391;
11 May 93 16:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15010;
11 May 93 16:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15006;
11 May 93 16:45 EDT
Received: from nic.cerf.net by CNRI.Reston.VA.US id aa23385; 11 May 93 16:45 EDT
Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA00442; Tue, 11 May 93 13:49:23 PDT
Date: Tue, 11 May 1993 13:37:16 -0700 (PDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Subject: Re: Do we need an Ombudsman? Or just manners.
To: ietf at CNRI.Reston.VA.US
Cc: iesg at CNRI.Reston.VA.US
In-Reply-To: <9305111952.AA00934 at ftp.com>
Message-Id: <Pine.3.05.9305111315.D28375-b100000 at nic.cerf.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
I am sorry that the point was missed by some of the members of this
society. It seems that what I am calling for is an arbiter elegantiarum,
a sort of Miss Manners for the WGs.
One thing that everyone seems to underestimate is that we all have
something to teach and something to learn. Nothing presented on this
network is nugacious, except in the mind of a few. I would suggest that
if you don't agree with something, and feel that you must be hostile, go
out and kick you dog, or spouse or poison some goldfish. If this is to be
a professional organization, then please keep it civil.
Now, there was a suggestion that perhaps an "RFC" or may a base of
knowledge should be retained somewhere (yes, I know about 'The
Archives.'). But once again I would like to point out that not every
question ever asked in a group is not worth asking again. If you find
yourself willing to teach, then please do so. If you find it easier to be
a jerk, then send the message to yourself first. This will give you time
to think about what you are going to do. Being rude has a snow ball effect
on this network. Just try to act like Miss Manners in dealing with people.
The groups that comprise the various groups are formed of many diverse
characters. Each with their own agenda and background. This melting pot of
thoughts and correspondence can lead to new ideas or solution, but only if
there is the possibility of civil, free and open discussion. Intimidation
doesn't ever help produce a superior product.
Chuck.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15207;
11 May 93 16:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15203;
11 May 93 16:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23801;
11 May 93 16:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15193;
11 May 93 16:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15189;
11 May 93 16:54 EDT
Received: from nic.cerf.net by CNRI.Reston.VA.US id aa23796; 11 May 93 16:54 EDT
Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA01340; Tue, 11 May 93 13:58:33 PDT
Date: Tue, 11 May 1993 13:51:17 -0700 (PDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Subject: Re: Do we need an Ombdusman? re: Censorship...
To: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
In-Reply-To: <9305111802.AA09469 at mel-brooks.empirical.com>
Message-Id: <Pine.3.05.9305111315.E28375-c100000 at nic.cerf.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
All I can say is hear, hear. Let us not lose site of the forest for the trees.
This is too important an issue to just nit pick apart. You can always find
defenders for any cause, without exception. That is the nature of human kind.
What Karl has brought up is something that is important and should be
discussed. Personal attacks won't make it go away, it just makes people go
away. Yes, you might say, good bye and good luck. But if it comes to that,
we all lose because we now stand on the frontier of a new society. What we
do today will effect many things. If we just blow off Karl without
listening and understanding, the Internet will die. The only people left
will be those who think (repeat think) they walk on water. No one walks on
water. Just try to keep an open mind. Try to be understanding, or at the
very least sympathetic if not empathetic.
Sincerly, Chuck Wegrzyn.
On Tue, 11 May 1993, Karl Auerbach, Empirical Tools and Technologies, 408/427-5280 wrote:
>
> > First, a complaint such as you apparently were intending to lodge should
> > be accompanied with a list of particulars.
>
> I have had much private mail about this issue, yesterday and over the
> last many years. The situation is one which many people seem blind
> and do not want to recognize.
>
> I did not want to put out particulars, which would simply serve to
> highlight the individuals. Rather, I am attempting to focus on the
> general problem. You should be able to appreciate that.
>
> However, I might add, that I was gratuitously blasted on the entire
> IETF and SNMP mailing lists. There are times when it is necessary to
> stand up and say "this is wrong."
>
> You have missed the entire point when you talk about snmpv2 working
> group fairness. The group itself was fair, in large part due to the
> greatly appreciated efforts of its chairman, Bob Stewart.
>
> The point is that many, many people have simply given up working with
> the snmp community at all because of the situation. Take Vince
> Fuller's note as simply the tiny tip of a very large iceberg.
>
> Overall, I am appalled that you are focusing more on the process by
> which I raised the complaint than about the substance of the
> complaint itself.
>
> --karl--
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16779;
11 May 93 17:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16775;
11 May 93 17:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24350;
11 May 93 17:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16752;
11 May 93 17:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16739;
11 May 93 17:05 EDT
Received: from INFOODS.MIT.EDU by CNRI.Reston.VA.US id aa24338;
11 May 93 17:05 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GY0SGODSS000064V at INFOODS.UNU.EDU>; Tue, 11 May 1993 17:05:01 EDT
Date: Tue, 11 May 1993 17:05:01 -0400 (EDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John C Klensin <KLENSIN at infoods.unu.edu>
Subject: Re: Do we need an Ombdusman? re: Censorship...
In-reply-to: <9305111952.AA00934 at ftp.com>
To: kasten at ftp.com
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Message-id: <737154301.412103.KLENSIN at INFOODS.UNU.EDU>
X-Envelope-to: iesg at CNRI.RESTON.VA.US, ietf at CNRI.RESTON.VA.US
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>
Status: O
Frank Kastenholz writes...
>What happens if the Ombudsman is suspected of being a member of the
>evil cabal? Do we appoint an Ombudsman**2? And if Ombudsman**2
>believed to also be a member of the evil cabal? Please note that this
>sequence can be continued to about Ombudsman**<5 or 6 *10**9> -- at
>which point we run out of people.
Actually we run out of IETF a long time before that. And out of
people who are able to spell "TCP/IP" not long after.
>What can we learn from this (admittedly extreme) example?
Frank, while I agree with your general conclusion as I understand it,
there is another lesson to be drawn from this example and the general
trend of the argument.
People who have been following the papers in the US are encouraged to
look at aspects of trial jury selection in thinking about this problem.
The obvious pool of people who are unbiased about a particular case is
that group of people who haven't heard about it and therefore have
formed no opinions. But, as a case gets more important, one rapidly
approaches the limiting case in which those who haven't heard about it
are those who have, in one way or another, gotten insulated from all
news sources, don't read things, etc. Well, in most cases, I don't want
those folks on juries--I prefer people who engage in thinking and
participating in society as a regular activity. On the other hand, when
one goes in search of people who are educated about the issue, it gets
hard to find people who haven't formed opinions.
{Begin Political Science 102 Lecture:
Democracies may not be very good models for IETF. We better care more
about right answers than about making majorities happy. Democracies
tend to lead to compromise, log-rolling, and design by committee at its
most extreme. Those are good models for lots of processes, but
technical design is not one of them.
As has been pointed out for centuries, the difference between
"democracy" and "mob rule" is very thin indeed. Avoiding mob rule
depends mostly on keeping the level of education, assumptions of mutual
trust and goodwill, and consensus about overall norms and objectives
pretty high. Ombudsmen might help in some circumstances, but they never
work as cabal-police for exactly the reasons you point out. The "high
level of education assumption" implies, precisely, that people don't
start stating positions about things that they haven't studied and
understood, and that, when they haven't, they don't take exception to
decisions that are made by people who have.
End Political Science 102 Lecture}
My conclusions, which are not operationally different from Frank's:
(i) More reading, study, and understanding before making of
suggestions would cause a lot fewer unhappy on all sides of issues.
(ii) Both for technical problems and for procedural/personality ones,
identifying the problems precisely and identifying proposed solutions
are important. It is even more desirable if one can point out reasons
why the proposed solutions would work and would work enough better than
the current situation/proposal to overcome the costs of implementing and
deploying it.
(iii) Always remember that conspiracies and cabals, especially those
that last for more than a few weeks, are hard work. This is
unfortunately an easy community in which to start feeling ganged up on
by folks who are respected in the community and loud to the point where
it feels like a conspiring cabal. I've felt like a victim of one and
speak for experience. But, realistically, I've seen very few of the
needed skills at work in IETF (unlike some X3 settings, where I've
occasionally seen people who seem to have been selected for those
skills). Examine the likely alternate hypotheses: that "they" really do
know something that you don't or that you haven't done a good enough job
of explaining why your solution is better in a way that "they" can
understand.
Now, I'm going to try to get back to doing useful work, and hope that
others will soon do likewise.
john
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16897;
11 May 93 17:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24425;
11 May 93 17:07 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16877;
11 May 93 17:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16811;
11 May 93 17:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24355;
11 May 93 17:05 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16806;
11 May 93 17:05 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, 12-16, July 1993/Amsterdam
Date: Tue, 11 May 93 17:05:48 -0400
X-Orig-Sender: mdavies at CNRI.Reston.VA.US
Message-ID: <9305111705.aa16806 at IETF.CNRI.Reston.VA.US>
Status: O
Dear IETFers:
Following this message (1a) you will receive four more, the contents of
which follow:
IETF MAILING 1b: HOTEL RESERVATION FORM. This form must be returned via
fax to the RAI HOTEL SERVICE by May 31st in order to
guarantee a room. DO NOT SEND THIS FORM TO THE IETF
SECRETARIAT.
IETF MAILING 1c: IETF RSVP FORM. Payment DOES NOT need to accompany the
RSVP Form, but the Form must be received by June 11th
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 1d: DRAFT AT-A-GLANCE. This is still in draft form.
IETF MAILING 1e: DRAFT AGENDA. Please keep in mind that this is only
a draft and is subject to frequent changes.
The IETF Social is scheduled for Monday evening.
The Local Host will be announcing that shortly.
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 CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18554;
11 May 93 17:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25166;
11 May 93 17:19 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18540;
11 May 93 17:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18461;
11 May 93 17:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25077;
11 May 93 17:17 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18456;
11 May 93 17:17 EDT
To: IETF-Announce: ;
REPLY-TO: ietf-rsvp at CNRI.Reston.VA.US
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
FROM: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 1b: Hotel Reservation Form: 12-16, July 1993/Amsterdam
Date: Tue, 11 May 93 17:17:10 -0400
X-Orig-Sender: mdavies at CNRI.Reston.VA.US
Message-ID: <9305111717.aa18456 at IETF.CNRI.Reston.VA.US>
Status: O
Dear IETF'ers:
July 12-16, 1993 is the 27th Internet Engineering Task Force which
will be held in Amsterdam at the RAI Congress Centre. The RAI has
it's own Hotel Service which was able to negotiate lower Hotel rates
than I was able to. To obtain these lower rates you MUST register
through the RAI Hotel Service. They have provided the form below,
which I have slightly modified. Please fill out the form according
to the instructions and fax or mail it to the RAI. DO NOT RETURN YOUR
FORM TO THE SECRETARIAT.
I have already begun scheduling working groups for the Amsterdam
IETF. A Draft Agenda is available in the remote directories
under 0mtg-agenda.ams.txt
Megan
P.S. According to our local host :>> In Europe there are only two sorts
of rooms:
>> SINGLE - contains one bed of aprox. 3 feet wide
>> DOUBLE - contains either two beds of 3 feet each,
or 1 bed of min. 6 feet
>>
>> (We don't do Queens or King Size)
HOTEL BOOKING FORM (page 1 of 2) - 29th IETF, 12-16, July 1993 - (Please Print)
Return this HOTEL BOOKING FORM before May 31, 1993 to: RAI HOTEL SERVICE
Europaplein, NL 1078 GZ AMSTERDAM. Phone: +31 (0) 205491927
Fax : +31 (0) 206462840
***After May 31st***, hotel accommodation cannot be guaranteed, though
requests will still be accepted.
Surname_____________________________________________ Initials___________
Organization____________________________________________________________
Address_________________________________________________________________
_________________________________________________________________
Postal Code and City____________________________________________________
Country_________________________________________________________________
Telephone______________________________ Facsimile_______________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Date of Arrival in Amsterdam_____________ Date of Departure____________
Single Room_____________ Double Room_____________
Preferred Hotel_________________________________ (see page two)
"I prefer the following hotel which is not listed on the HOTEL BOOKING FORM."
Hotel Name:_______________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
DEPOSIT: A guarantee via credit card, a cheque* made out to the RAI HOTEL
SERVICE, or a deposit of Dfl. 250 per room is required. After
receipt of your payment/credit card details, a voucher will be
forwarded to you. Payment must be made in Dutch Guilders. All
costs to transmitter's charge (approx. Dfl. 25 per transfer)
NO ROOMS CAN BE CONFIRMED UNTIL YOUR HOTEL DEPOSIT/CREDIT CARD
GUARANTEE HAS BEEN RECEIVED!!!!!
AMEX____ Diners____ Master____ Visa____ Eurocard ____ Access____
Account No._____________________________ Expiration Date_________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
___Remitted by enclosed cheque payable to RAI HOTEL SERVICE (* personal
cheques cannot be accepted.) The deposit paid will be deductible from
your hotel bill upon presentation of this voucher at the reception desk
of the hotel.
___Remitted to RAI HOTEL SERVICE account No. 54.96.42.528 with the ABN-AMRO
Bank at Amsterdam, the Netherlands,
IETF93, Mr./Ms.____________________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
HOTEL BOOKING FORM (page 2 of 2) - 29th IETF, 12-16, July 1993
Hotel accommodation at reduced rates can be reserved in the following hotels:
Hotel Name Stars Single Double Bkfst Incl.
--------------------------------------------------------
Holiday Inn (1) 5 Dfl. 210 Dfl. 255 No
Novotel (1) 4 Dfl. 210 Dfl. 240 Yes
Altea (2) 3 Dfl. 220 Dfl. 220 Yes
(1) Hotel located within walking distance of the RAI.
(2) Hotel located near the RAI.
CANCELLATION: Notification of cancellation must be sent in writing, (postal
mail or facsimile) no later than 72 hours (three days) prior
to originally scheduled arrival time. Notification after this
time will automatically result in a charge of Dfl. 250.
REFUNDS : Refunds, minus administration costs of Dfl. 50, will be dealt
with after the conference.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18697;
11 May 93 17:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25223;
11 May 93 17:21 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18679;
11 May 93 17:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18624;
11 May 93 17:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25213;
11 May 93 17:20 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18619;
11 May 93 17:20 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: IETF RSVP FORM: 12-16, July 1993/Amsterdam
Date: Tue, 11 May 93 17:20:16 -0400
X-Orig-Sender: mdavies at CNRI.Reston.VA.US
Message-ID: <9305111720.aa18619 at IETF.CNRI.Reston.VA.US>
Status: O
REGISTRATION FORM
27th Internet Engineering Task Force - Page 1 of 2
12-16, July 1993
Amsterdam, The Netherlands
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, 11 July NEWCOMER'S ORIENTATION at
16:30?
YES___ NO___
Do you plan to attend the Sunday, 11 July reception at 18:00?
YES___ NO___
$200.00 ($200.00 + $20.00 late fee) Registration postmarked after
Friday, 11 June 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 - 27th IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
REGISTRATION FORM
27th Internet Engineering Task Force - Page 2 of 2
12-16, July 1993
Amsterdam, The Netherlands
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 Wednesday, 7 July, 1993.
8. Requests for refunds must be received by Wednesday, 7 July, 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: 27th IETF Meeting - Amsterdam, The Netherlands.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18926;
11 May 93 17:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26098;
11 May 93 17:38 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18911;
11 May 93 17:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18876;
11 May 93 17:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26066;
11 May 93 17:36 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18871;
11 May 93 17:36 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 AT-A-GLANCE: 12-16 July 1993/Amsterdam
Date: Tue, 11 May 93 17:36:38 -0400
X-Orig-Sender: mdavies at CNRI.Reston.VA.US
Message-ID: <9305111736.aa18871 at IETF.CNRI.Reston.VA.US>
Status: O
27th INTERNET ENGINEERING TASK FORCE Mailing Date : 5/10/93
DRAFT AT-A-GLANCE Mailing Number: 1d
DATES: July 12-16, 1993 HOST(S):
Erik Huizer/SURFnet
MEETING SITE: RAI Congress Centre
Europaplein
NL-1078 GZ Amsterdam
Phone: +31.(0) 20.5491212
HOTEL: Refer to IETF MAILING 1b for Hotel information.
Also available via ftp: 0mtg-hotel-ams.txt
NEWCOMER'S Sunday, 11 July, 1993
ORIENTATION: 16:30pm - 17:30
Location: TBD
PRE-REGISTRATION: Sunday, 11 July, 1993
18:00 - 20:00 (reception during)
RAI Congress Centre
Location: TBD
REGISTRATION: Monday - Friday, 12-16, July 1993
08:00 - 18:00
RAI Congress Centre
Location: TBD
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
$220.00 if registered AFTER 11 June 1993
CAR RENTAL: Don't rent a car. Public transportation is
very easy. Cabs work too.
AIRPORT: Schiphol Airport
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19045;
11 May 93 17:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19041;
11 May 93 17:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26229;
11 May 93 17:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19030;
11 May 93 17:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19026;
11 May 93 17:44 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa26224;
11 May 93 17:44 EDT
Received: by xap.xyplex.com id <AA21520 at xap.xyplex.com>; Tue, 11 May 93 18:16:55 -0500
Date: Tue, 11 May 93 18:16:55 -0500
Message-Id: <9305112316.AA21520 at xap.xyplex.com>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
In-Reply-To: Chuck Wegrzyn's message of Tue, 11 May 1993 13:51:17 -0700 (PDT) <Pine.3.05.9305111315.E28375-c100000 at nic.cerf.net>
Subject: Re: Do we need an Ombdusman? re: Censorship...
Status: O
So far we have glowing principles, broad generalities, applehood, and mother
pie. We also have a brandy new structure in place that appoints responsible
people for limited terms, and we avoided setting up a rigid recall structure.
As Dave Crocker said, we can't deal with this based on broad generalities,
either as goals or problem definitions. If some individual has been
intimidated into not offering useful contributions, then (preferably) that
individual should take their case to the IESG, with specifics of time, place,
identity of intimidator, and the words and actions that caused the problem.
Note that I said "IESG", not the whole IETF mailing list. Save that for when
you decide that the IESG is ignoring you and you truly have to raise the
rabble and start the revolution.
Otherwise this is all exactly the sort of electron-wasting, brain-cell
consuming blabber-jabber that Marshall was trying to discourage.
Bob
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19157;
11 May 93 17:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26413;
11 May 93 17:51 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19143;
11 May 93 17:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19114;
11 May 93 17:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26368;
11 May 93 17:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19109;
11 May 93 17:50 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 1e: DRAFT AGENDA: 12-16 July 1993/Amsterdam
Date: Tue, 11 May 93 17:50:14 -0400
X-Orig-Sender: mdavies at CNRI.Reston.VA.US
Message-ID: <9305111750.aa19109 at IETF.CNRI.Reston.VA.US>
Status: O
Agenda of the Twenty-Seventh IETF - as of 5/11/93 - 5:30pm
(12-16 July 1993)
MONDAY, 12 July 1993
0800-0900 IETF Registration and Continental Breakfast
0900-0930 Introductions
0930-1200 Technical Presentations
o TBD
Breaks Coffee available throughout morning.
1330-1530 Afternoon Sessions I
APP OSI Directory Services WG (osids)
(Steve Hardcastle-Kille/ISODE)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)*
RTG OSI IDRP for IP over IP WG (ipidrp) (Sue Hares/Merit)*
OPS Operational Statistics WG (opstat) (Phill Gross/ANS
and Bernhard Stockman/SUNET)
SEC Security Area Advisory Group (saag) (Steve Crocker/TIS)
USV WHOIS and Network Information Lookup Service WG (wnils)
(Joan Gargano/UCDavis)
1530-1600 Break (Refreshments provided)
1600-1800 Afternoon Sessions II
APP OSI Directory Services WG (osids)
(Steve Hardcastle-Kille/ISODE)
INT Simple Internet Protocol WG (sip)
(Steve Deering/Xerox PARC and Christian Huitema/INRIA)
OPS Operational Statistics WG (opstat) (Phill Gross/ANS
and Bernhard Stockman/SUNET)
USV Uniform Resource Identifiers WG (uri)
(Alan Emtage/Bunyip and Jim Fullton/UNC)
1930-2200 Evening Sessions
INT IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
MGT Mail and Directory Management WG (madman)
(Steve Hardcastle-Kille/UCL)
USV Integration of Internet Information Resources WG (iiir)
(Chris Weider/Merit)
NOTE: Monday evening's sessions may be moved as the IETF Social has been
scheduled at that time.
TUESDAY, 13 July 1993
0830-0900 Continental Breakfast
0900-1200 Morning Sessions
APP Conferencing Control (mmusic) (Eve Schooler/ISI
and Abel Weinrib/Bellcore)
INT P. Internet Protocol WG (pip) (Paul Francis/Bellcore)
MGT NM Directorate (nmdir) (Marshall Rose/DBC)
USV Integrated Directory Services WG (ids) (Tim Howes/UMich
and Chris Weider/Merit)
USV User Services WG (uswg) (Joyce K. Reynolds/ISI)
Breaks Coffee available throughout morning.
1330-1530 Afternoon Sessions I
APP MHS-DS WG (mhsds) (Kevin Jordan/CDC and
Harald Alvestrand/SINTEF DELAB)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
INT P. Internet Protocol WG (pip) (Paul Francis/Bellcore)
USV Uniform Resource Identifiers WG (uri)
(Alan Emtage/Bunyip and Jim Fullton/UNC)
1530-1600 Break (Refreshments provided)
1600-1800 Afternoon Sessions II
APP MHS-DS WG (mhsds) (Kevin Jordan/CDC and
Harald Alvestrand/SINTEF DELAB)
INT IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)
INT Point-to-Point Protocol Extensions WG (pppext)
(Fred Baker/ACC) *
INT TCP/UDP over CLNP-addressed Networks WG (tuba)
(Peter Ford/LANL and Mark Knopper/Merit)
RTG Border Gateway Protocol WG (bgp) (Yakov Rekhter/IBM)*
RTG OSI IDRP for IP over IP WG (ipidrp) (Sue Hares/Merit)*
USV User Documents WG (userdoc2) (Ellen Hoffman/UMich
and Lenore Jackson/NASA)
1930-2200 Tuesday, 13 July 1993 - Evening Sessions
WEDNESDAY, 14 July 1993
0830-0900 Continental Breakfast
0900-1200 Morning Sessions
APP Conferencing Control (mmusic) (Eve Schooler/ISI and
Abel Weinrib/Bellcore)
APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and
Tony Genovese/LLNL)
INT IP over Large Public Data Networks WG (iplpdn)
(George Clapp/Ameritech)*
INT Point-to-Point Protocol Extensions WG (pppext)
(Fred Baker/ACC) *
RTG Source Demand Routing Protocol (sdr)
(Deborah Estrin/USC and Tony Li/cisco)
USV Uniform Resource Identifiers WG (uri)
(Alan Emtage/Bunyip and Jim Fullton/UNC)
Breaks Coffee available throughout morning.
1330-1530 Afternoon Sessions I
APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and
Tony Genovese/LLNL)
INT IP over ATM WG (atm) (Bob Hinden/Sun)
INT Inter-Domain Multicast Routing BOF (idmr)
(Tony Ballardie/UCL)
MGT Chassis MIB WG (chassis) (Bob Stewart/Xyplex)
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 IFIP Electronic Mail Management BOF (emailmgt)
(Einar Stefferud/NMA and Paul Brusil/MITRE)
RTG IP Routing for Wireless/Mobile Hosts WG (mobileip)
(Steve Deering/Xerox PARC)
SEC Authorization and Access Control BOF (aac)
(Cliff Neuman/ISI)
USV Network Information Services Infrastructure WG (nisi)
(April Marine/SRI and Pat Smith/Merit)
1930-2200 Wednesday, 14 July 1993 - Evening Session
INT IPng Decision Process BOF (ipdecide)
(Brian Carpenter/CERN and Tim Dixon/RARE)
MGT IFIP Electronic Mail Management BOF (emailmgt)
(Einar Stefferud/NMA and Paul Brusil/MITRE)
* IPLPDN and PPPEXT will be meeting in joint session.
THURSDAY, 15 July 1993
0830-0900 Continental Breakfast
0900-0930 Technical Presentations
o TBD
0930-1200 Morning Sessions
APP Minimal OSI Upper-Layers WG (thinosi)
(Peter Furniss/Consultant)
APP X.400 Operations WG (x400ops) (Alf Hansen/Sintef and
Tony Genovese/LLNL)
INT Point-to-Point Protocol Extensions WG (pppext)
(Fred Baker/ACC) *
RTG IP Routing for Wireless/Mobile Hosts WG (mobileip)
(Steve Deering/Xerox PARC)
USV Network Training Materials WG (trainmat)
(Ellen Hoffman/Merit
and Jill Foster/UNewcastle-Upon-Tyne)
Breaks Coffee available throughout the morning.
1330-1530 Afternoon Sessions I
MGT IFIP Electronic Mail Management BOF (emailmgt)
(Einar Stefferud/NMA and Paul Brusil/MITRE)
OPS Operational Area Directorate (orad) (Phill
Gross/ANS and Bernhard Stockman/SUNET)
RTG Multicast Extensions to OSPF WG (mospf)
(Steve Deering/Xerox PARC)
SEC Security Area Advisory Group (saag) (Steve Crocker/TIS)
USV Internet School Networking WG (isn)
(John Clement/EDUCOM, Connie Stout/TheNet and
Art St. George/UNM)
1530-1600 Break (Refreshments provided)
1600-1800 Technical Presentations
o TBD
1930-2200 Open Plenary and IESG
NOTE: Plenary may be shifted to Friday.
FRIDAY, 16 July 1993
0830-0900 Continental Breakfast
0900-1200 Technical Presentations
TBD
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21692;
11 May 93 19:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21688;
11 May 93 19:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29962;
11 May 93 19:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21678;
11 May 93 19:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21674;
11 May 93 19:27 EDT
Received: from qdeck.com by CNRI.Reston.VA.US id aa29957; 11 May 93 19:27 EDT
Received: from angel.qdeck.com by rockall.qdeck.com (4.1/SMI-4.1)
id AA24020; Tue, 11 May 93 16:27:36 PDT
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jordan Brown <jbrown at qdeck.com>
To: wegrzyn at nic.cerf.net, ietf at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
Cc: iesg at CNRI.Reston.VA.US
X-Mailer: ScoMail 1.0
Date: Tue, 11 May 1993 16:23:27 -0700 (PDT)
Message-Id: <9305111623.aa12830 at angel.qdeck.com>
Status: O
> I wish to iterate that the most important part of the moderator is to be
> neutral! They only direct the discussion, not participate.
In the voluminous discussion resulting from this, I'm surprised that nobody
has mentioned one of the obvious issues.
Being a moderator/leader/whatever is work. Often hard, thankless work.
Why in the world would anybody do such a thing if they were disinterested
in the results? If ISOC were able to hire neutral moderators and pay them
to moderate that would be great, but it doesn't seem likely. Until that
happens, WG chairs/moderators/whatevers will be people who have for one
reason or another an agenda. We can ask them to be fair and respect all
viewpoints, but we cannot reasonably demand that they be completely
neutral.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21909;
11 May 93 19:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21871;
11 May 93 19:55 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa00809;
11 May 93 19:55 EDT
Received: from rwa.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA01122>; Tue, 11 May 1993 16:48:41 -0700
Message-Id: <199305112348.AA01122 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: ietf at CNRI.Reston.VA.US
Subject: April Internet Monthly Report
Reply-To: cooper at isi.edu
Date: Tue, 11 May 93 16:48:34 PDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Ann Westine Cooper <cooper at isi.edu>
Status: O
April 1993
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
This report is for Internet information purposes only, and is not
to be quoted in other publications without permission from the
submitter.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to:
Ann Westine Cooper (Cooper at ISI.EDU)
NSF Regional reports - To obtain the procedure describing how to
submit information for the Internet Monthly Report, send an email
message to mailserv at is.internic.net and put "send imr-procedure" in
the body of the message (add only that one line; do not put a
signature).
Requests to be added or deleted from the Internet Monthly report list
should be sent to "imr-request at isi.edu".
Details on obtaining the current IMR, or back issues, via FTP or
EMAIL may be obtained by sending an EMAIL message to "rfc-
info at ISI.EDU" with the message body "help: ways_to_get_imrs". For
example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
Cooper [Page 1]
Internet Monthly Report April 1993
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 4
Internet Projects
ANSNET/NSFNET BACKBONE ENGINEERING . . . . . . . . . . . page 10
BARRNET . . . . . . . . . . . . . . . . . . . . . . . . . page 13
BOLT BERANEK AND NEWMAN, INC., . . . . . . . . . . . . . page 14
CONCERT . . . . . . . . . . . . . . . . . . . . . . . . . page 17
CSUNET (CALIFORNIA STATE UNIVERSITY NETWORK). . . . . . . page 18
ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 19
JVNCNET . . . . . . . . . . . . . . . . . . . . . . . . . page 21
MERIT/NSFNET ENGINEERING. . . . . . . . . . . . . . . . . page 24
MERIT/NSFNET/INFORMATION SERVICES . . . . . . . . . . . . page 27
NEARNET (NEW ENGLAND ACADEMIC AND RESEARCH NETWORK) . . . page 28
NNSC, UCAR/BOLT BERANEK and NEWMAN, INC., . . . . . . . . page 29
OARNET. . . . . . . . . . . . . . . . . . . . . . . . . . page 30
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 31
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 32
Cooper [Page 2]
Internet Monthly Report April 1993
INTERNET ARCHITECTURE MESSAGE
IAB POSITIONS
The Internet Activities Board (IAB) has selected Christian Huitema
as its chair for the coming year.
Other IAB positions are as follows:
* Chair of Internet Research Task Force (IRTF): Jon Postel
* RFC Editor: Jon Postel
* Internet Assigned Numbers Authority (IANA): Jon Postel
* Executive Director: Bob Braden
* Liaisons to IESG: Christian Huitema, Yakov Rekhter
* Representative to CCIRN: Barry Leiner
LIAISON WITH ISO AND ITU
At its Tuesday evening open IAB meeting at Columbus in March, there
was a discussion of possible liaisons between the IETF standards
making activities and ISO, and between IETF and ITU.
According to its charter, the IAB is responsible for liaison
arrangements between the Internet standards process and other
standards agencies. The IAB has agreed that detailed negotiations
with ISO and CCITT may be conducted by the ISOC President Vint
Cerf, in consultation with the IAB. If agreement is reached,
liaison would be effected by a formal agreement between that
standards body and the Internet Society, the legal entity that
would represent the IAB/IESG/IETF for this purpose.
The IAB, selected by the IETF membership under the new process,
intends to be fully responsive to the needs and desires of the IETF
and the Internet community. The IAB wishes to strongly affirm
that:
(1) No agreement should or will be made with another standards
body that will in any way impede progress or change the style
of operation of the IETF.
(2) The primary purpose of any such relationship, if it were to be
established, would be to benefit the Internet through official
recognition of the reality that the IETF is an important
source of international computer communication standards.
(3) The outcome of the IPng discussions should in no way be
tied to the progress of such relationship.
Cooper [Page 3]
Internet Monthly Report April 1993
Detailed negotiations on these matters are being conducted by the
ISOC President Vint Cerf, on behalf of the IAB/IESG/IETF. Two
different liaison relationships with ISO are possible for the ISOC,
Category A and Category C. Category A would simply recognize that
the ISOC/IAB/IETF is "another source of international standards",
while Category C would allow liaison at the working group level.
With the advice and consent of the IAB, the ISOC Board of Trustees
previously initiated a request for category A liaison with ISO, and
this request is pending. In an unrelated action, Jack Holdsworth
brought an offer from ISO/IEC JTC1/SC6 for Category C liaison.
Since the Columbus meeting, it has been erroneously reported in
parts of the trade press that the IAB agreed to pursue Category C
liaison with ISO. This is not correct. The IAB has decided to
delay action on the ISO category C liaison offer until negotiations
on Category A are concluded. Furthermore, there were many issues
and concerns raised by IAB and IETF members attending the Columbus
meeting. Before Category C liaison could proceed, these issues
must be settled to the satisfaction of the Internet community, and
there must be general agreement that such liaison is in the best
interests of the IETF.
The IAB is preparing a more complete statement about these issues.
Bob Braden (Braden at ISI.EDU)
INTERNET ENGINEERING REPORTS
----------------------------
1. Let me remind everyone that the next meeting of the IETF will
be held in Amsterdam, The Netherlands, and is being co-hosted
by SURFnet and RARE. The meeting will run from July 12-16, 1993.
This will be the first time an IETF meeting has been held
outside of North America. The attendee fee for the Amsterdam
IETF meeting will be $200 (USD) and pre-registration and
prepayment is being encouraged.
2. I am pleased to announce that Scott Bradner, Lyman Chapin,
Brewster Kahle, Allison Mankin, and Marshall Rose, have joined
the IESG. The current IESG members are:
Phill Gross IETF Chairman
Brewster Kahle Applications Area
Erik Huizer Applications Area
David Crocker Service Applications Area
Allison Mankin Transport Area
Marshall Rose Network Management Area
Cooper [Page 4]
Internet Monthly Report April 1993
Robert Hinden Routing Area
Stev Knowles Internet Area
David Piscitello Internet Area
Joyce Reynolds User Services Area
Scott Bradner Operational Requirements Area
Stephen Crocker Security Area
Lyman Chapin Standards Management
3. The IESG approved or recommended the following 19 actions during
the month of April, 1993:
o Multiprotocol Interconnect over ATM Adaptation Layer 5 as a
Proposed Standard.
o Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2) as a Proposed Standard.
o Introduction to version 2 of the Internet-standard Network
Management Framework as a Proposed Standard.
o Transport Mappings for version 2 of the Simple Network
Management Protocol (SNMPv2) as a Proposed Standard.
o Structure of Management Information for version 2 of the
Simple Network Management Protocol (SNMPv2) as a Proposed
Standard.
o Coexistence between version 1 and version 2 of the
Internet-standard Network Management Framework as a Proposed
Standard.
o Textual Conventions for version 2 of the Simple Network
Management Protocol (SNMPv2) as a Proposed Standard.
o Manager to Manager Management Information Base as a Proposed
Standard.
o Management Information Base for version 2 of the Simple
Network Management Protocol (SNMPv2) as a Proposed Standard.
o Conformance Statements for version 2 of the Simple Network
Management Protocol (SNMPv2) as a Proposed Standard.
o Party MIB for version 2 of the Simple Network Management
Protocol (SNMPv2) as a Proposed Standard.
o Security Protocols for version 2 of the Simple Network
Management Protocol (SNMPv2) as a Proposed Standard.
o Administrative Model for version 2 of the Simple Network
Management Protocol (SNMPv2) as a Proposed Standard.
o Definitions of Managed Objects for Administration of SNMP
Parties has a status of Historic.
o SNMP Security Protocols has a status of Historic.
o SNMP Administrative Model has a status of Historic.
o SNMP Security Protocols has a status of Historic.
o FYI on Introducing the Internet--A Short Bibliography of
Introductory Internetworking Readings for the Network Novice
as an Informational RFC.
o FYI on "What is the Internet?" as an Informational RFC.
Cooper [Page 5]
Internet Monthly Report April 1993
4. The IESG issued 4 Last Calls to the IETF during the month of
April, 1993:
o RPC: Remote Procedure Call Protocol specification <RFC1050>
o NFS: Network File System Protocol specification <RFC1094>
o An Echo Function for ISO 8473 <draft-ietf-noop-echo-02>
o SNMP MIB extension for MultiProtocol Interconnect over X.25
<draft-ietf-x25mib-ipox25mib-05>
5. The IESG approved the formation or re-activation of the
following seven (7) new Working Groups:
Character MIB (charmib)
DECnet Phase IV MIB (decnetiv)
Modem Management (modemmgt)
Frame Relay Service MIB (frnetmib)
Mail and Directory Management (madman)
ATM MIB (atommib)
Telnet TN3270 Enhancements (tn3270e)
Additionally, the following two Working Groups were concluded:
Internet Accounting (acct)
Office Document Architecture (oda)
6. Forty-three (43) Internet Draft actions were taken during the
month of April, 1993:
(Revised draft (o), New Draft (+) )
WG I-D Title <Filename>
------ --------------------------------------------------
(telnet) o Telnet Authentication and Encryption Option
<draft-ietf-telnet-encryption-02.txt>
(cat) o Generic Security Service Application Program
Interface <draft-ietf-cat-genericsec-04.txt>
(cat) o The Kerberos Network Authentication Service (V5)
<draft-ietf-cat-kerberos-02.txt, .ps>
(x25mib) o SNMP MIB extension for MultiProtocol Interconnect
over X.25 <draft-ietf-x25mib-ipox25mib-05.txt>
(x400ops) o Routing coordination for X.400 MHS services within
a multi protocol / multi network environment Table
Format V3 for static routing
<draft-ietf-x400ops-mhs-service-06.txt>
(pppext) o The PPP Internetwork Packet Exchange Control
Protocol (IPXCP) <draft-ietf-pppext-ipxcp-03.txt>
(pppext) o The Definitions of Managed Objects for the Bridge
Network Control Protocol of the Point-to-Point
Cooper [Page 6]
Internet Monthly Report April 1993
Protocol <draft-ietf-pppext-bridgemib-02.txt>
(pppext) o The Definitions of Managed Objects for the IP
Network Control Protocol of the Point-to-Point
Protocol <draft-ietf-pppext-ipcpmib-02.txt>
(pppext) o The Definitions of Managed Objects for the Security
Protocols of the Point-to-Point Protocol
<draft-ietf-pppext-secmib-02.txt>
(pppext) o The Definitions of Managed Objects for the Link
Control Protocol of the Point-to-Point Protocol
<draft-ietf-pppext-lcpmib-02.txt>
(osids) o DSA Metrics <draft-ietf-osids-dsa-metrics-01.txt>
(mimemhs) o HARPOON: Rules for downgrading messages from
X.400/88 to X.400/84 when MIME content-types are
present in the messages
<draft-ietf-mimemhs-harpoon-02.txt>
(none) o IP and ARP on Fibre Channel (FC)
<draft-rekhter-fibre-channel-01.txt>
(noop) o An Echo Function for ISO 8473
<draft-ietf-noop-echo-02.txt>
(none) o ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of Internet MIB-II (RFC1213) to
ISO/CCITT GDMO MIB (IIMCMIB-II)
<draft-labarre-iimc-mibii-01.txt, .ps>
(wnils) o Architecture of the Whois++ Index Service
<draft-ietf-wnils-whois-01.txt>
(none) o ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of Internet MIBs to ISO/CCITT
GDMO MIBs (IIMCIMIBTRANS)
<draft-labarre-internetmib-iso-01.txt, .ps>
(pem) o MIME-PEM Interaction <draft-ietf-pem-mime-02.txt>
(none) o ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of ISO/CCITT GDMO MIBs to
Internet MIBs (IIMCOMIBTRANS)
<draft-newnan-isomib-internet-01.txt, .ps>
(none) o ISO/CCITT and Internet Management Coexistence
(IIMC): Translation of Internet Party MIB (RFC1353)
to ISO/CCITT GDMO MIB (IIMCPARTY)
<draft-labarre-iimc-party-01.txt, .ps>
(none) o ISO/CCITT and Internet Management Coexistence
(IIMC): ISO/CCITT to Internet Management Proxy
(IIMCPROXY) <draft-chang-iimc-proxy-01.txt, .ps>
(none) o DNS NSAP RRs <draft-manning-dns-nsap-01.txt>
(pppext) o Compressing IPX Headers Over WAN Media (CIPX)
<draft-ietf-pppext-cipx-03.txt>
(appleip) o AppleTalk Management Information Base II
<draft-ietf-appleip-mib2-01.txt>
(iplpdn) o Multiprotocol Interconnect over Frame Relay
<draft-ietf-iplpdn-framerelay-03.txt>
Cooper [Page 7]
Internet Monthly Report April 1993
(822ext) o MIME (Multipurpose Internet Mail Extensions) Part
One: Mechanisms for Specifying and Describing the
Format of Internet Message Bodies
<draft-ietf-822ext-mime2-02.txt, .ps>
(822ext) o The text/enriched MIME Content-type
<draft-ietf-822ext-text-enriched-02.txt, .ps>
(sip) + SIP Program Interfaces for BSD Systems
<draft-ietf-sip-bsd-api-00.txt>
(822ext) o The Content-MD5 Header
<draft-ietf-822ext-md5-02.txt>
(telnet) o Telnet Environment Option
<draft-ietf-telnet-envmnt-option-01.txt>
(none) o Post Office Protocol - Version 3
<draft-rose-pop3-01.txt>
(cat) o FTP Security Extensions
<draft-ietf-cat-ftpsec-01.txt>
(pip) + The Multi-Level Path Vector Routing Scheme
<draft-ietf-pip-vector-00.txt>
(telnet) + Telnet Environment Option Interoperability Issues
<draft-ietf-telnet-interoperability-00.txt>
(uswg) + FYI on "What is the Internet?"
<draft-ietf-uswg-fyi-00.txt>
(none) + Using the Domain Name System To Store Arbitrary
String Attributes
<draft-rosenbaum-dns-storage-00.txt, .ps>
(none) + Exchanging Routing Information Across
Provider/Subscriber Boundaries in the CIDR
Environment <draft-rekhter-cidr-environment-00.txt>
(mospf) + MOSPF: Analysis and Experience
<draft-ietf-mospf-analysis-00.txt>
(sip) + Administrative Allocation of the 64-bit Number Space
<draft-ietf-sip-64bit-plan-00.txt>
(none) + Connection Multiplexing Protocol (CMP)
<draft-cameron-cmp-00.txt>
(sip) + SIP System Discovery
<draft-ietf-sip-discovery-00.txt>
(uri) + Uniform Resource Locators
<draft-ietf-uri-url-00.txt, .ps>
(tuba) + Assignment of System Identifiers for TUBA/CLNP Hosts
<draft-ietf-tuba-sysids-00.txt>
Cooper [Page 8]
Internet Monthly Report April 1993
7. One (1) RFC was published during the month of April, 1993.
RFC St WG Title
------- -- -------- -------------------------------------
RFC1453 I (none) A Comment on Packet Video Remote
Conferencing and the Transport/Network
Layers
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( E) Experimental
( I) Informational
Steve Coya (scoya at cnri.reston.va.us)
Cooper [Page 9]
Internet Monthly Report April 1993
INTERNET PROJECTS
-----------------
ANSNET/NSFNET BACKBONE ENGINEERING
----------------------------------
Network Status Summary
======================
The deployment of the AIX 3.2 operating system on the T3 routers began
on April 30th. The deployment will continue through May 21st. This
software will increase the on-card forwarding table capacity to
support 12,000 destinations, and the subsequent release of AIX 3.2
software scheduled for summer '93 will increase the forwarding table
capacity to support 25,000 destinations.
Backbone Traffic and Routing Statistics
=======================================
The total inbound packet count for the network (measured using SNMP
interface counters) was 36,527,140,345 on T3 ENSS interfaces, up 15.2%
from March. The total packet count into the network including all
ENSS serial interfaces was 40,788,225,452.
As of April 30, the number of networks configured in the Merit Policy
Routing Database was 11248 for the T3 backbone. Of these, 2846 were
never announced to the T3 backbone (e.g. silent nets). The maximum
number of networks announced to the T3 backbone during the month (from
samples collected every 15 minutes) was 8239, up 6.1% from February.
Average announced networks on 4/30 were 8181.
AIX 3.2 Migration Plan Status
=============================
The T3 backbone software upgrade to support the AIX 3.2
operating system began on April 30th. A revised postscript file
illustrating the phased deployment at each POP CNSS and adjacent
ENSS is located on ftp.ans.net in /pub/info/aix32dpmap.ps and may
be summarized as follows:
Phase I (April 30) - Washington D.C.
Phase II (May 7) - Seattle/Denver, San Francisco/Los Angeles
Phase III (May 14) - Greensboro/Atlanta, Houston/St. Louis
Phase IV (May 21) - Hartford/New York City, Cleveland/Chicago
Cooper [Page 10]
Internet Monthly Report April 1993
Rcp_routed Routing Software Changes
===================================
During April two versions of the T3 router software daemon,
rcp_routed, were deployed. The first entitled "Third Party Routes"
primarily addressed problems handling third party routes advertised
by peer routers. Deployment of this began in March and ended in
early April. A second version called "AIX 3.2 Multipath" addressed
multipath routing in AIX 3.2, generated third party routes, and
fixed some memory leaks. Release notes are available in:
ftp.ans.net:/pub/info/t3-rcp_routed/Release-Notes
FDDI Problem
============
During April, there were a few problems experienced at ENSS sites
that use FDDI interfaces. There was a problem identified on E145
(also observed on E133) where packets are blocked from traversing
an ENSS FDDI->Ethernet path. The problem has occurred three times
during April. We are working on a fix for this, and the an
automatic FDDI interface reset has been instrumented in the
interim.
Routing Stability Measured on the T3 Network
============================================
Internal routing stability measurements are made by monitoring
short term disconnect times (disconnects of five minutes duration
or less). During February the overall stability approached 99% (no
internal disconnects in any part of the network 99% of the time)
and all individual nodes reported 99.8% stability or better.
Overall stability in March was down to 97.5% or 99.1% excluding
instability during the configuration windows. Overall stability in
April was 96.1% or 97.2% excluding instability during the
configuration windows.
E206 (CERN - Geneva, Switzerland) remained the most unstable node
due to recurring T1 circuit problems. CERN was only stable 97.9%
of the time which accounted for much of the overall 96.1% figure.
Of the 15 hours, 10 hours was outside the config window (9:58 98.6%
stable). Much of the remaining time was during the config window
when the circuit was taken for testing.
E130 (Argonne) and E128 (BARRnet) each experienced instability due
to a memory paging problem (described below). E130 experienced
5.25 hours of instability (5:28 99.2% stable) of which 4 hours was
outside of the config window (4:02 99.5% stable). E128 experienced
Cooper [Page 11]
Internet Monthly Report April 1993
3.5 hours of instability (3:35 99.5% stable) with 2.5 hours outside
the config window (2:38 99.7% stable).
A new installation, E229, saw 2.5 hours of instability, mostly
early in April just prior to the production activation of the node.
A few nodes suffered adapter hardware or microcode problems. These
were E133 (Cornell) with 1:35 (99.78% stable), E145, (Fix-E) with
1:04 (99.85% stable), E136 (College Park) with 1:03 (99.85%
stable), and E168 (OARnet) with 0:56 (99.87% stable). E133 only
experienced 0.5 minutes of instability outside the config window,
since the outage fell within the window. E145 had 0:18, E136 had
0:20, E168 had 0:25 minutes of instability outside the config
windows. These are all better than 99.9%. The outages time
incurred when replacing a failing interface is generally much
longer than the outage that the failing interface causes,
consequently the bulk of the instability is during the config
window.
Of the remaining routers, 24 reported between 15-60 minutes of
outage time. The remaining 57 reported under 15 minutes of
instability (better than 99.97%). If the config windows are
excluded, only 4 routers, E206, E130, E128, and E229 reported over
26 minutes of outage. There were 9 routers that reported 10-26
minutes of instability.
Paging Problem at E130 (Argonne) and E128 (Barrnet)
===================================================
On April 6th-9th, E130 experienced intermittent routing
instability. Most of this outage occurred during weekend hours. On
April 17-20 E128 (BARRnet) experienced similar problems. There
were a number of problems occurring which in combination caused AIX
software memory paging problems.
One problem on E128 had to do with the FDDI ring going down. A
larger than normal number of internal buffers (mbufs) used by the
networking code were consumed while this condition existed. This
reduces the amount of memory available for normal processes such as
the routing daemon and network management programs, etc. This was
addressed by reducing the requirement for mbufs for TCP buffering
for BGP sessions, and by correcting problems with the FDDI ring.
This improved but did not solve the problem.
The next problem involved flapping FDDI peers which caused a great
deal of logging that resulted in a very large system messages file
created on April 17. The reading of the system messages file by
another process induced routing daemon memory paging problems on
the node. The solution to the problem involved both reducing the
Cooper [Page 12]
Internet Monthly Report April 1993
routing daemon memory size (since the problem was associated with
paging), and the splitting of the large log file. A new version of
the routing software will be deployed in mid May.
Notable Outages in April '93
============================
E132 (Pittsburgh) lost T3 connectivity due to power problems on
4/11.
E168 (OARnet) suffered an extended outage to hardware failure on
4/23.
E173 (ITESM) suffered extended outages due to power problems on
4/5, 4/11, and due to radio fade on 4/16.
E206 (CERN) suffered extended circuit outages on 4/13, 4/16, 4/23.
Xlink (Germany) suffered an extended circuit outage on 4/6.
C11 (San Francisco) became unreachable on 4/3 causing an outage to
E159, E178, E187, E229.
C17 (Los Angeles) suffered an HSSI card hang on 4/10 causing an
outage to E156, E170, E215, E216.
Jordan Becker <becker at ans.net>
BARRNET
-------
Membership Update
Date: 5/3/93
Member Organizations: 168
New Members, April: California Academy of Sciences,
Austin Scientific, Affymax
Research, Walnut Creek CD ROM,
Electronics For Imaging
Publications
BARRNet has resumed publication of its newsletter, The BARRNetter,
distributed quarterly to its members. The BARRNetter covers the
latest Internet news, noteworthy current events, graphics, maps,
and BARRNet news.
The Spring edition is due out in May.
Cooper [Page 13]
Internet Monthly Report April 1993
BARRNet began publication of its electronic newsletter, "Heard on
the Net" (HOTN), which is distributed via email to BARRNet's
membership. By agreement with Newsbytes News Network, HOTN carries
selected Newsbytes articles relevant to the Internet community, as
well as an eclectic selection of news, resources, reviews,
interviews, opinions, humor, and other items of interest to
BARRNet's membership.
The first issue of BARRTech Notes, technical papers of interest to
the technical personnel of BARRNet's membership organizations, was
published in April, addressing NTP (Network Time Protocol).
The BARRNetter, "Heard on the Net", and BARRTech notes are edited
by John Hoag (jhoag at barrnet.net), BARRNet Communications
Coordinator. Submissions and comments are welcome.
BARRNet info at barrnet.net
Pine Hall, Rm 115 Phone: 415-725-1790
Stanford University Fax: 415-723-0010
Stanford, CA 94305-4122
John Hoag (jhoag at barrnet.net)
BOLT BERANEK AND NEWMAN INC.
----------------------------
Defense Simulation Internet (DSI)
The DSI supported three demonstrations this month as well as
ongoing testing for a major demonstration in May. These were all
successful.
The ST2 software release is in beta test. Some bugs still exist,
but these are being fixed as the beta test period continues. More
sites will be added to the beta test over the next couple of weeks.
Several WPSen were relocated to different sites to help reduce
backbone circuit costs. In addition, a second WPS was added to the
D.C. area and another was installed in Norfolk, VA to support the
large number of sites in this area.
A new release of Wideband Packet Switch (WPS) code to support ST2
was deployed on all 11 WPSen.
Increased usage on the network is exceeding the capacity of the T1
backbone. The planning process for increasing the backbone
capacity has begun.
Cooper [Page 14]
Internet Monthly Report April 1993
Scaleability
Work is progressing on adding statistics collection to the flow-
level network simulator, and we are working on an analysis
environment for analyzing simulation results.
(See December '92 Internet Monthly Report for more details about
this project and the toolset being developed.)
Real-time Multicast Communications and Applications
We are currently implementing the shared streams service, using the
Fair Share resource reservation code as a basis for resource
enforcement. An initial version of Resource Coordination Objects
(RCOs) is being designed and implemented to support user-level
reservation for shared streams.
We are also looking at additional applications for the four real-
time multicast services in this project (anycasting, multi-level
flows, shared streams, RCOs). One possibility is the use of RCOs
for network-wide resource reservation, a need that has become
apparent in some DARTnet experiments.
During the month of March, we also worked on improvements to the
video server in two areas. First, we substantially improved the
interface between the workstations that control the Parallax codecs
used to convert analog video to digital video, transmit the digital
video across a wide area network, and receive and display the video
in a window on a workstation. This work provides the basis for two
new capabilities.
First, the video server can make use of multicast communications to
support multiple people viewing the same video simultaneously. In
earlier versions of the video server, if multiple people requested
the same video, a separate unicast data connection was initiated
for each user. In the new version of the video server, if a user
requests the same video (for example, a broadcast channel) as is
being transmitted to another user, then the initial unicast data
connection is broken and a multicast data connection is established
to the two or more users who have requested the same video.
Second, multicast digital video streams can now be broken into
multi-level (i.e. multi-bandwidth) encodings. The multi-level data
stream capability will allow multiple users to receive the same
video stream over different bandwidth connections; one user may
receive a high quality, high bandwidth video stream over high
bandwidth network connections, while another user can
simultaneously view the same video at a lower quality over lower
Cooper [Page 15]
Internet Monthly Report April 1993
bandwidth network connections. One network mechanism that can be
used to support this work is the multi-level flows communications
service that we are developing as part of this project.
In the past month, we have also made improvements to the video
catalog service, a distributed service which catalogs text
information used to index video. In earlier versions of the video
server, the host name of all video catalogs was stored at a well
known host, referred to as the catalog of catalogs. The video
applications used unicast communications to contact the catalog of
catalogs and obtain the names of hosts that contained video
catalogs. In the new catalog service, workstations that contain
video catalogs join the video catalog multicast group; thus, the
information as to where video catalogs are located resides with the
servers and not with the applications. Applications send queries
to locate video information directly to a video catalog multicast
address and the applications receive responses from all servers
that contain video information relevant to the request.
The use of multicast for this service provides an important
capability for wide area video information servers. The multicast
capability allows video server sites to change the machines hosting
catalog services, and it allows sites to add and remove video
servers (and their associated catalogs) without having to modify
video applications and without having to update a centralized
database of video service locations.
(See January '93 and March '93 Internet Monthly Reports for more
details about the application and communications services being
developed.)
Inter-Domain Policy Routing
During the month of April, we completed the IDPR pilot
installation. Many thanks to Brad Passwaters, Shehzad Merchant,
Walt Prue, Tony Ballardie, and Jeff Burgan for assistance in
providing and booting machines and installing software.
The IDPR pilot demonstration will run through May 1993. We will
provide an informational RFC on the pilot and the perceived
results, at the conclusion of this time period.
Cooper [Page 16]
Internet Monthly Report April 1993
We have also been proceeding with the design of multicasting in a
policy-based environment. In particular, we have been making
modifications to both the route generation procedure and the path
control protocol portions of IDPR, in order to accommodate
multicast. We plan to experiment in the DARTnet this summer with
prototype software and to release an Internet Draft describing the
modifications necessary to do multicasting in the context of IDPR.
Karen Seo <kseo at BBN.COM>
CONCERT
-------
The number of accounts connected to the CONCERT network grew by 21
percent during the first quarter of 1993.
CONCERT is currently testing the LARSE Mega-T inverse multiplexer
to deliver a 4Mbs V.35 link using three T1s between the UNC-
Charlotte campus and the CONCERT hub at Research Triangle Park.
For the past several weeks CNIDR (Clearinghouse for Networked
Information Discovery and Retrieval) has provided an alternate
server site for the popular Veronica resource discovery software
developed at the University of Nevada-Reno by Steve Foster and Fred
Barrie. Veronica (very easy rodent-oriented net-wide index to
computerized archives) is an "archie for gopher." The CNIDR server
receives approximately 5000 queries daily from people searching
gopherspace menus.
On April 9, 1993, CNIDR released freeWAIS 0.1, the first upgrade to
WAIS in over 6 months. freeWAIS incorporates many of the
enhancements such as Boolean searching, phrase searching, stemming,
access control, and better document relevance scoring, and a
redundant directory-of-servers. freeWAIS-0.1 is designed to be a
"backwards compatibility" module for freeWAIS-1.0, which will
provide full Z39.50-92 support and is nearing completion. freeWAIS
0.1 is available via anonymous ftp from ftp.cnidr.org. For general
information and timely announcements about CNIDR, send e-mail to
info at cnidr.org.
During the month of April, VISTAnet (one of the five testbeds
sponsored by CNRI) achieved partial connectivity over an
experimental Broadband ISDN network operating at 622Mbps.
The VISTAnet network operates between the CRAY-YMP at the North
Carolina Supercomputing Center, the Pixel Planes-5 graphics
processing engine at University of North Carolina at Chapel Hill,
and a medical workstation at UNC Memorial Hospital Radiation
Cooper [Page 17]
Internet Monthly Report April 1993
Oncology department. Networking services are provided by Bell
South and GTE. The driving application for VISTAnet is real-time
radiation therapy planning.
The VISTAnet network connects the three computational resources
using HiPPI to a Network Terminal Adapter (NTA). The NTA acts as a
HiPPI-to-ATM/SONET modem at SONET rates of OC-12c (622Mbps). Two
switching nodes will provide switched services, a Fast Circuit
Switch provided by GTE and an ATM switch provided by Bell South.
Only partial connectivity was achieved since the GTE circuit switch
must still be added to the network. Using HiPPI test equipment and
the endpoint hosts, data was transmitted and received data at rates
of up to 400Mbps with an acceptable quality of service. For
VISTAnet the target quality of service is less than 4 lost/errored
HiPPI packets in 1 hour of operation.
Also experimented with were the ability and limitations of a BISDN
network to handle very high speed burst data traffic in tandem with
low speed traffic. These experiments gave some insights into the
limitations of statistical multiplexing of ATM networks. We also
developed some guidelines for traffic shaping for both high speed
and low speed traffic.
by Tom Sandoski <tom at concert.net>
CSUNET (THE CALIFORNIA STATE UNIVERSITY NETWORK)
-----------------------------------------------
The California State University Network has some newly signed
members for Internet access via CSUnet:
C* Kern County Office of Education (KCOE) [Bakersfield, CA]
C* San Diego County Supt of Schools (SDCSS)
C* Ventura County Supt of Schools (VCSS)
O* Far West Labs (FWL) [San Francisco, CA]
O* Kern High School District (KHSD) [Bakersfield, CA]
P* Taft Community College (TAFT) [Bakersfield, CA]
C* Sonoma County Library (SCL)
*status: C=contract completed, O= operational, P=contract pending
The county educations offices' plan to provide Internet access for
their districts and schools through the new connection to CSUnet.
Cooper [Page 18]
Internet Monthly Report April 1993
New projects: As the POSSIBLE 21st campus of the California State
University, the planning office of CSU Monterey Bay (CSUMB) is
being connected to CSUnet as soon as possible. CSUnet is designing
a Macintosh network to connect the new campus to other CSU campuses
and government offices using the existing CSUnet AppleTalk WAN.
CSUMB wants to move very quickly (ie. they plan to start classes in
28 months!). Networking equipment will be purchased by April 15,
1993.
Mike Marcinkevicz (mdm at CSU.net)
ISI
---
GIGABIT NETWORKING
Infrastructure
Joyce Reynolds atteded the NASA-NSI workshop in San Diego, April
27-29th.
Thirteen RFCs were published this month.
RFC 1441: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Introduction
to version 2 of the Internet-standard Network Management
Framework", April 1993.
RFC 1442: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Structure
of Management Information for version 2 of the Simple
Network Management Protocol (SNMPv2), April 1993.
RFC 1443: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Textual
Conventions for version 2 of the Simple Network
Management Protocols (SNMPv2)", April 1993.
RFC 1444: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Conformance
Statements for version 2 of the Simple Network
Management Protocol (SNMPv2)", April 1993.
Cooper [Page 19]
Internet Monthly Report April 1993
RFC 1445: Galvin, J., (Trusted Information Systems), K. McCloghrie
(HUGHES LAN Systems), " Administrative Model for version
2 of the Simple Network Management Protocol (SNMPv2)",
April 1993.
RFC 1446: Galvin, J., ((Trusted Information Systems), K. McCloghrie
(HUGHES LAN Systems), "Security Protocols for version
2 of the Simple Network Management Protocol (SNMPv2)",
April 1993.
RFC 1447: McCloghrie, K., (HUGHES LAN Systems), J. Galvin, (Trusted
Information Systems) Party MIB for version 2 of the
Simple Network Management Protocol (SNMPv2)", April 1993.
RFC 1448: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Protocol
Operations for version 2 of the Simple Network Management
Protocol (SNMPv2)", April 1993.
RFC 1449: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Transport
Mappings for version 2 of the Simple Network Management
Protocol (SNMPv2)", April 1993.
RFC 1450: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Management
Information Base for version 2 of the Simple Network
Management Protocol (SNMPv2"), April 1993.
RFC 1451: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Manager-to-
Manager Management Information Base", April 1993.
RFC 1452: Case, J., (SNMP Research, Inc.), K. McCloghrie (HUGHES
LAN Systems), M. Rose, (Dover Beach Consulting, Inc.)
S. Waldbusser (Carnegie Mellon University), "Coexistence
between version 1 and version 2 of the Internet-standard
Network Management Framework", April 1993.
RFC 1453: Chimiak, W., (BGSM), "A Comment on Packet Video Remote
Conferencing and the Transport/Network Layers",
April 1993.
Ann Westine Cooper (Cooper at ISI.EDU)
Cooper [Page 20]
Internet Monthly Report April 1993
MULTIMEDIA CONFERENCING
This month, the Real-time Tranport Protocol (RTP) was integrated
into PVP, ISI's packet video program. Now implemented in several
real-time packet audio and video programs, RTP has allowed
interoperation among different implementations of these tools. A
parameter -N was added to PVP to allow a name to be transmitted in
the RTP protocol so nv will display it when PVP and nv
interoperate. In addition, enhancements were made to PVP to make
it more readily configurable to work with a Bolter codec or a
PictureTel codec.
Steve Casner gave a talk "Internet Video -- Meltdown or the Next
Email?" at the National Net '93 conference in Washington, D.C.
Eve Schooler, Steve Casner (schooler at isi.edu, casner at isi.edu)
JVNCNET
-------
JvNCnet-Global Enterprise Services, Inc.
B6 von Neumann Hall, Princeton, NJ 08544
1-800-35-TIGER
I. New Information
A. New on-line members (fully operational April 1993)
BASF Corp., Parsippany, NJ
Datacom Global Communications, Princeton,NJ
Transwitch Corporation, Shelton, CT
Cape Henlopen High School, Lewes, DE
DC Public Schools/Center for Educational Change,
Washington, DC
Dobbins Area Voc-Tech, Philadelphia, PA
DunsNet, Wilton, CT
EIRC, Sewell, NJ
Francis Scott Key High School, Unionbridge, MD
George School, Newtown, PA
George Washington High School, Philadelphia, PA
Gibbs and Cox, New York, NY
Haddonfield Memorial High School, Haddonfield, NJ
MCIU, Erdenheim, PA
Mount Saint Joseph Academy, Flourtown, PA
Neshaminy Schools Ed Services Center, Langhorne, PA
Parkview Elementary, Westville, NJ
Riverview Middle School, Denton, MD
Souderton Middle School, Souderton, PA
Springfield Schools, Philadelphia, PA
Cherry Semiconductor, E. Greenwich, RI
Cooper [Page 21]
Internet Monthly Report April 1993
EMCORE, Somerset, NJ
Health Research & Educational Trust, Princeton, NJ
Knight Ridder Financial. New York, NY
Macro Corp., Horsham, PA
Prism, Middletown, NY
Pros from Dover, Hopewell, NJ
Science Press, Ephrata, PA
TMA, Princeton, NJ
VA Medical Center (UMDNJ), East Orange, NJ
T. Wallace, Wilton, CT
D&Z Inc., Philadelphia, PA
Electronic Systems Associates, New York, NY
II. JvNCnet Symposia: All seminars are open to the public.
Location for seminars: Princeton Marriott Forrestal Village
College Road, Plainsboro, NJ
A. Title: Network management and operations
Date: May 26, 1993
Time: 8:30 to 4:30
Audience: Network operations and technical staff of
TCP/IP-based networks including system administrators
who need to know how to organize a well-functioning
operations system and proper networking monitoring.
Anyone in the Internet community interested in learning
about network operations management will benefit.
What You Will Learn
The attendee will learn the fundamentals associated with
network management and operations:
_ LAN and WAN management including
_ Variables to monitor and associated monitoring process
_ Troubleshooting for corrective and preventative fixes
_ Network weaknesses and planning
_ Capabilities of network monitoring software including
JvNCnet-authored software and technical overviews of
commercial network monitoring packages.
Speakers include: Christopher Tengi, Princeton University;
John Scoggin, Delmarva Power and Light; Heidi Iacurto,
Cisco Systems; Vikas Aggarwal and Steven Williams,
GES, Inc.
B. Title: Systems administration on the Internet
Date: June 29, 1993
Time: 8:30 to 4:30
Cooper [Page 22]
Internet Monthly Report April 1993
Audience: Network technical staff including system
administrators of TCP/IP-based networks who are
responsible for setting up network services at their
site, people who will be managing a new Internet system,
and anyone new to Internet who is interested in learning
about systems administration.
What You Will Learn
sendMail architecture and the anatomy of an email message,
Sendmail and nameservers, Sendmail configuration basics,
Rewrite rules, Domain hiding, reverse aliasing, Versions
of sendmail, and Sources of information and help.
_NEWS: CNews, NNTP reference implementation, INN, and
introduction to newsreaders.
__Domain Name Service includes redundancy and delegation,
primary, secondary and subdomains; types of records
(such as SOA, MX records, CName), initial and final
nameservers, reverse name lookups, nameserver updating,
and troubleshooting.
Attendees will receive explicit concepts to properly set up
these services on a new system and ways to streamline a
current system.
Speakers: Neil Rickert, Northern Illinois University;
Richard Salz, Open Software Foundation; and
Thomas Brisco, Rutgers University
REGISTRATION: Pre-registration preferred. Check or money order
payable to Global Enterprise Services, Inc. Mastercard/Visa
accepted or fax registration to: 609-258-2424.
Mail to: GES, Inc., Attn; R. Hammer,
B6 von Neumann Hall
Princeton, NJ 08544
Early bird registration by May 14 for the May 26 class and by June
15 for the June 29 class.
Early bird rate: One Day After early bird rate: One day
JvNCnet members $250 JvNCnet members $295
Non-members $275 Non-members $325
Continental breakfast, lunch, course documentation and/or book
complementing each protocol will be provided for each attendee.
by Rochelle Hammer (hammer at jvnc.net)
Cooper [Page 23]
Internet Monthly Report April 1993
MERIT/NSFNET ENGINEERING
------------------------
During April, the set of major activities included use of the Informix
database system for all NSFNET configuration services; changes to the
international IP network registration process; progress on automating
the submission of database update requests from midlevels; further
analysis of active and inactive network routing announcements;
progress in implementation of IDRP; and progress in testing and
implementation of TUBA.
Informix Database System in Production
======================================
Full production for the new Policy Routing Database (PRDB) and NSFNET
Configuration System began with the configuration run on April 2. The
system is used for registration of network routing announcements as
well as topology configuration for the ANSNET. A set of tools for
parsing and automatically entering database updates from e-mail
templates is now in production.
Automated Submission of Network Announcement Change Requests
============================================================
Requests for network numbers to be added to the NSFNET PRDB have
traditionally been handled by submitting templates via e-mail to the
Merit staff. Recently we have significantly improved the productivity
of configuration operators by automating much of the handling of the
requests and subsequent database entry process.
Our current focus is on the submission process. We are working on a
tool which will allow a midlevel network engineer to interactively
generate a template. Initially it will available as a 'login' style
service on a host at Merit, as a server that allows the information
fields for network information to be filled in.
The interactive program will perform some of the validation and
advance lookups of information to avoid manual cross-checking by
operators. For example, the InterNIC has provided a machine- parsable
output format for whois queries, which can be used to allow the
organizational or point-of-contact information to be directly copied
from whois into the Merit database. The program will also query
Merit's PRDB server to present the current routing configuration
relevant to the reqest being built.
We expect the first release of the interactive process to be available
in early May.
Cooper [Page 24]
Internet Monthly Report April 1993
Changes to International IP Network Registration
================================================
Merit's "IPREGISTER" service is provided to network operators and
administrators in countries which are becoming connected or need
assistance in connecting to the Internet and NSFNET. The goal is to
assist in achieving connectivity to the NSFNET as quickly and
efficiently as possible within contraints of agency policies.
The service was orginally established when IP numbers were allocated
with a "connected" or "unconnected" flag. At that time, NSF had to
sponsor an organization in order for them to receive an IP number with
the "connected" flag. It was important for non-domestic networks to
receive this classification if they desired to communicate with
scientists and researchers via the NSFNET backbone. "Connected"
status was a requirement for routing traffic on the NSFNET backbone.
Since NSF was unable to know the appropriateness of sponsoring each
and every non-domestic network, and there was not a consolidated
European, Asian, South American, and other regional networking
organization to consult, NSF established reciprocal agreements with
designated representatives within countries. This action translated
into a procedure which was implemented by Merit. One of the steps of
the procedure was to delay addition of non-domestic networks into the
NSFNET routing database until the designated representatives from that
country acknowledged and confirmed this addition.
While this procedure served us well during the days when "connected"
status existed and when the IEPG (Intercontinental Engineering
Planning Group), the RIPE NCC, and the EBONE were non-existant, the
procedure was out-dated and delayed the desired connectivity.
Merit has revised its procedure so that we eliminate the requests for
concurrence to designated representatives of foreign countries when
configuring the NSFNET routing tables. We no longer need to delay
routing of non-domestic networks into the NSFNET routing database
while waiting for responses to such requests.
At the same time, it is no longer necessary for NSF to preapprove
access on a network by network basis. Except for a list of specific
countries, all non-US routing requests are handled without any
approval delay. A bi-weekly report is now produced listing all of the
non-US networks added during the configuration run. This works nicely
with the automated processing of routing announcement change templates
that has been added recently.
One important task of IPREGISTER has not changed, and that is in
helping non-domestic networks obtain various network services. Among
Cooper [Page 25]
Internet Monthly Report April 1993
these are submitting requests to the InterNIC or RIPE for IP numbers,
and making sure the whois entry is updated and that it corresponds to
what is in the Merit Policy Routing Database as well as the RIPE
entry, if appropriate.
Further Analysis of Active/Inactive Routing Announcements
=========================================================
Known as "silent nets", a substantial population of networks in the
configuration database are not announced to the backbone. While we are
confident that the backbone router tables will not overflow due to
growth in announced networks, it is our goal to limit the set of
networks in the backbone configuration files to those which are
actually expected to be announced by midlevels to the backbone.
A similar goal has been to analyze the routing tables over time and
determine whether the configuration of Autonomous System path
preference for each network matches the actual announced preference.
In response to our messages to AS administrators, we have received
requests to delete over 400 silent nets. We have also been able to
reconfigure the announcement preferences for many networks to bring
the number of primary network announcements matching the configured
path to 99%.
The "OFFNET" database process collects routing table dumps every 15
minutes from the backbone for analysis. A summary of reports and
information generated from this database follows. Graphs showing
growth of configured networks as compared to actual announcements, and
the AS path preference comparison, can be found via anonymous FTP from
the directory merit.edu:pub/nsfnet/offnet.
OFFNET statistics summary:
04/30/93 11248 configured networks
8824 configured minus April "silent nets" (see below)
8239 maximum announced
8181 average announced
7969 minimum announced
04/01/93 95.0 average % configured primary matches announced primary
04/30/93 99.1
Cooper [Page 26]
Internet Monthly Report April 1993
The maximal number of announced networks of each month:
MONTH MAX RATE(%)
===== ==== ======
07/92 4596
08/92 4866 5.9
09/92 5070 4.2
10/92 5432 7.1
11/92 5772 6.3
12/92 6239 8.1
01/93 6654 6.7
02/93 7037 5.8
03/93 7767 10.4
04/93 8239 6.1
(Avg monthly growth rate: 6.7%)
Networks Silent for 30 days (04/01 - 04/30): 2424
Networks Silent for 7 days (04/27 - 05/04): 2846
IDRP and TUBA Implementation Status
===================================
Some Merit staff have been involved with implementation of OSI
protocols, including TUBA (TCP and UDP over CLNP) and IDRP. The
IDRP implementation is progressing well, and a demonstration was
given to the FAA and Mitre staff on April 20. Merit will
participate in the European JENC conference demo of TUBA in May.
Mark Cochran of IBM visited Merit to assist in AIX 3.2 kernel
development for TUBA, IDRP and CLNP.
Mark Knopper, (mak at merit.edu)
MERIT/NSFNET/INFORMATION SERVICES
---------------------------------
During the month of April, Romania and Bulgaria were the most
recent nations to begin routing traffic over the NSFNET Backbone
Service, as a result of their reclassification to favored nation
status by COCOM.
The text of the report "Review of NSFNET" by the Office of
Inspector General of the National Science Foundation, followed by
the text of NSF's response to the OIG report, is available for
Anonymous FTP from the host nic.merit.edu as /nsfnet/ig.report .
This document is also available via electronic mail by sending a
message to
Cooper [Page 27]
Internet Monthly Report April 1993
nis-info at nic.merit.edu
and specifying
send ig.report
as the first line of text (not subject) of the message.
"Extending the Benefits," the National Net '93 program held April
14 through 16 at Loews L'enfant Plaza Hotel, Washington, D.C. was
attended by Jim Williams, Merit Associate Director for National
Networking; Ellen Hoffman, Merit Manager of Information Services;
and Laura Kelleher and Steve Burdick of Merit's Information
Services staff. Kelleher and Burdick presented demonstration and
discussion of Merit's "Cruise of the Internet." The colorful,
computer-based tutorial, developed for new and experienced users of
the Internet, is available in Gopherspace and via Anonymous FTP
from the host nic.merit.edu. The Cruise for the Macintosh and
associated readme file are in the directory /resources/cruise.mac.
The DOS Windows version of the Cruise with readme files is found in
the directory /resources/cruise.dos.
Kelleher also spoke at a meeting of the Delaware Library
Association, where she presented "A Cruise of the Internet,"
overviewing the many and varied resources of the Internet and the
means to discover them.
Elise Gerich, of Merit Internet Engineering, attended meetings of
the IEPG and RIPE held in Amsterdam, The Netherlands.
Jo Ann Ward (jaw at merit.edu)
NEARNET (NEW ENGLAND ACADEMIC AND RESEARCH NETWORK)
---------------------------------------------------
During the week of April 12, NEARnet held a semi-annual security
test. The test involved calling the designated security contacts
at all NEARnet sites to confirm our readiness in the event of a
Network Security Emergency. The test went very well with
approximately 87% of the sites contacting NEARnet personnel in
response to the test.
As part of the FARNET "Service Excellence" program, two groups of
NEARnet liaisons participated in a focus group which analyzed their
perspectives of NEARnet/Internet services and concentrated on
suggested areas for improvement.
The NEARnet User Services staff has distributed a copy "The Whole
Internet User's Guide and Catalog" by Ed Krol, free of charge, to
the information liaison at every NEARnet member organization as
Cooper [Page 28]
Internet Monthly Report April 1993
part of the information and training services for 1993.
The April issue of the "NEARnet This Month" bulletin has been
distributed. Past issues are available via anonymous FTP at
nic.near.net, in the directory newsletters/nearnet-this-month.
by Corinne Carroll <ccarroll at nic.near.net>
NNSC, UCAR/BOLT BERANEK and NEWMAN, INC.
----------------------------------------
The new InterNIC team begin providing user and information services
on April 1st. The transition from NNSC to the new InterNIC team,
which was announced in the March 1933 Internet Monthly Report, has
been proceeding smoothly. The last issue of the NNSC-produced
newsletter should be available in May.
* NNSC Help Desk
The NNSC Telephone Hotline Number, 1-617-873-3400, is now
forwarded to 1-800-444-4345. The Electronic Help Mailbox
address now forwards mail for nnsc at nnsc.nsf.net to
info at internic.net.
* Important files from the /usr/ftp directory on nnsc.nsf.net
have been moved to the InterNICs.
At INFORMATION SERVICES <is.internic.net>
Pathname below /usr/ftp Pathname below /usr/ftp
on nnsc.nsf.net on is.internic.net
nsfnet/referral-list infosource/getting_started/
getting_connected/providers_na/
internet-access-provider-list
Internet Monthly Reports (yy=year mm=month)
nsfnet/report-yymm
infosource/internet_info_for_everybody/
imr/report-yymm
At DIRECTORY AND DATABASE SERVICES <ds.internic.net>
Directory pathnames below /usr/ftp are the same as they were on
nnsc.nsf.net, except for the-scientist.
Cooper [Page 29]
Internet Monthly Report April 1993
Description of Directories Pathname on
ds.internic.net
Internet Resource Guide resource-guide
Internet Policies and Procedures for
Educational Organizations policies-procedures
"Shadow" or "Mirror" Directories
Internet Engineering Steering Group iesg
Internet Engineering Task Force ietf
Internet Drafts (documents in the
process of becoming RFCs) internet-drafts
Internet Society documents isoc
Request for Comments reports rfc
Online version of THE SCIENTIST,
a bimonthly newspaper for scientists pub/the-scientist
* NSF Network Newsletter
The NNSC is in the process of publishing its final issue of
the NSF Network Newsletter, which will appear in May 1993.
This issue will include the NSF Network map and site list.
* Other Services
For information about NNSC services not mentioned here. please
call the new InterNIC phone number 800-444-4345.
Charlotte Mooers <mooers at nnsc.nsf.net>
OARNET
------
IETF Meeting in Late March
The 26th Internet Engineering Task Force meeting was held at
Columbus, OH, hosted by OARnet and The Ohio State University. The
conference was very well attended, and went off excellently. The
terminal room was stocked with 25 PCs, running software donated by
FTP Software, Inc. In addition, there were terminal server ports,
ethernet and appletalk connectors for people bringing in their own
laptops. As an experiment, dialup IP access was provided for all
who requested so. A total of 45 hours of async PPP access, and 11
hours of async SLIP access were logged by the attendees.
Cooper [Page 30]
Internet Monthly Report April 1993
In keeping with the IETF tradition, all the plenaries, and at least
two of each session was simulcast to the Internet using packet
audio and video. Cameras and a VCR for this purpose were donated by
the Ohio Visualisation Laboratory.
To provide reliable access, LCI International, and Ohio Bell
telephone company donated a total of 3 T1 circuits for the IETF.
One of the T1s was used to carry multicast traffic for the
simulcast exclusively, and connected the terminal room directly to
the OARnet POP at Cleveland, while another one carried unicast
traffic from the terminal room to the nearest OARnet backbone POP;
the third T1 was used to interconnect the OARnet POP at Cleveland
to the ANS POP at North Royalton. At peak periods, OARnet offered
approximately 400Kb/sec of IETF audio and video traffic to the ANS
backbone and about 100Kb/sec of IETF terminal room traffic, or
about 500Kb/sec in total.
At this IETF, most of the major "IPv7" contenders, PIP, TUBA, and
SIP/IPAE also demonstrated current implementation status.
Ashley Burns <ashley at oar.net>
UCL
----
1. The INRIA Video Conferencing System Software has been merged
with our CODEC software so we can now generate video from a sparc
or SGI and send over IP (multicast) and receive, encapsulate in
H.221 (with CRCs!) and hand to a CODEC, and vice versa. Currently,
this is working at 64kbps and 128 kbps - we will move to higher
speeds as and when.
2. We hosted one of the schools for the Global Schoolhouse
Project's first video class over the Internet on April the 26th
succesfully (after a number of successful demos where the first hop
was running over our campus FDDI, on the day, this broke and we had
to fallbacvk to a copper voicegrade line (driven at 256kbps!) from
UCL to the UK international gateway with some clever last minute
re-routing. Details reports no doubt will appear elsewhere. Many
thanks to the Cornell people for introducing us to CUSeeMe (yet
another neat conferencing program!). J Crowcroft now knows more
about MACs than he cares to admit.
3. We hosted the first SuperJANET demonstration day on te 28th - as
reported before, this net is now being bought up, and many high
speed applications were shown to the various sponsors.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
Cooper [Page 31]
Internet Monthly Report April 1993
CALENDAR
--------
Readers are requested to send in dates of events that are appropriate
for this calendar section. Please send your submissions to
(cooper at isi.edu).
1993 CALENDAR
Mar 29 - Apr 2, IETF, Columbus, Ohio
Apr 5-19 TCOS WG, Boston (tentative)
Apr 14-16 National Net'93, Wash D.C. (net93 at educom.edu)
Apr 18-23 IFIP WG 6.6 Third International Symposium
on Integrated Network Management, Sheraton
Palace Hotel, San Francisco, CA (kzm at hls.com)
Apr 20-22 ANSI X3S3.3, Orlando, FL
May 10-13 4th Joint European Networking COnf., JENC93
Trondheim, Norway
May 13-14 RARE Council of Administration, Trondheim
May 23-26 ICC'93, Geneva, Switzerland
May 25-28 IFIP WG6.1 13th Intl. Symposium; Protocol
Specification Testing and Verification
Liege Belgium
May-Jun PSTV-XIII, University of Liege.
Contact: Andre Danthine,
Jun 2-4 ANSI X3S3.3, Raleigh, NC
Jun 7-11 OIW, NIST, Gaithersburg, MD
Jun 15-30 ISO/IEC JTC1/SC21, Yokohama
Jun 21-25 USENIX, Cincinnati
Jun 30 RARE Technical Committee, Amsterdam
Jul 12-16 IETF, Amsterdam, The Netherlands
Jul 12-16 IEEE802 Plenary, Sheraton Denver Tech
Center,Denver, CO
Jul 12-16 TCOS WG, Hawaii (tentative)
Aug 1-6 Multimedia '93, Anaheim, CA
Aug 17-20 INET 93 San Francisco,(Request at inet93.stanford.edu)
Aug 23-27 INTEROP93, San Francisco
Dan Lynch (dlynch at interop.com)
Sep 13-17 SIGCOMM 93, San Francisco
Sep ?? 6th SDL Forum, Darmstadt
Ove Faergemand (ove at tfl.dk)
Sep 8-9 ANSI X3S3.3, Boulder, CO
Sep 13-17 OIW, NIST, Gaithersburg, MD
Sep 14 -? IFIP TC6. GMD-Fokus, 2nd Intl Conf.
on Open Distributed Processing, ICODP12, Berlin
Sep 20-31 ISO/IEC JTC1/SC6, Seoul, Korea.
Sep 28-29 September RIPE Technical Days, TBC
Oct INTEROP93, Paris, France
Cooper [Page 32]
Internet Monthly Report April 1993
Oct 5-6 IFIP WG 6.6 Intl Workshop on Distributed Systems:
Operations and Management DSOM'93.
Oct 12-14 Conference on Network Information Processing,
Sofia, Bulgaria; Contact: IFIP-TC6
Oct 18-22 TCOS WG, Atlanta, GA (tentative)
Nov 2-4 ANSI X3S3.3, TBD
Nov 2-4 EMAIL World, Einar Steffurd <stef at nma.com>
Nov 9-13 IEEE802 Plenary, Crown Sterling Suites,
Ft. Lauderdale, FL
Nov 15-19 Supercomputing 93, Portland, OR
Dec 6-10 OIW, NIST, Gaithersburg, MD
1994 CALENDAR
Feb 3-4 ISOC Symposium on Network and Distributed
System Security, San Diego, (nessett at llnl.gov)
2-6 May NetWorld+INTEROP 94, Las Vegas, Nevada
Dan Lynch (dlynch at interop.com
Jun 1-3 IFIP WG 6.5 ULPAA, Barcelona, Spain
Einar Stefferud (stef at nma.com)
Aug 28-Sep 2 IFIP World Computer Congress
Hamburg, Germany; Contact: IFIP
Sep 12-14 NetWorld+INTEROP 94, Atlanta, Georgia
Dan Lynch (dlynch at interop.com)
1995 CALENDAR
Sep 18-22 INTEROP95, San Francisco, CA
Dan Lynch (dlynch at interop.com)
1996 CALENDAR
Sep 2-6 14th IFIP World Computer Congress
Canberra, Australia Contact: IFIP
========================================================================
Cooper [Page 33]
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21938;
11 May 93 19:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00828;
11 May 93 19:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21911;
11 May 93 19:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21865;
11 May 93 19:55 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa00808;
11 May 93 19:55 EDT
Received: from rwa.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA01104>; Tue, 11 May 1993 16:47:06 -0700
Message-Id: <199305112347.AA01104 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: IETF-Announce: ;, cooper at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Subject: Internet Monthly Report Availability via FTP and EMAIL
Reply-To: cooper at isi.edu
Date: Tue, 11 May 93 16:47:03 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Ann Westine Cooper <cooper at isi.edu>
Status: O
--NextPart
Internet Monthly Report Availability via FTP and EMAIL
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
IMR Retrieval using RFC-INFO Service
------------------------------------
The EMail retrieval system "RFC-Info" will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from VENERA.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where "yymm" refers to the date of
the IMR. For example IMR9207.TXT is the report for July 1992). Login
with FTP username "anonymous" and password "ftp".
Requests to be added or deleted from the Internet Monthly Report list
should be sent to "imr-request at isi.edu".
Requests to be added or deleted from the IETF list should be sent to
"ietf-request at nri.reston.va.us".
. . .
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9304
--OtherAccess
Content-Type: Message/External-body;
name="imr9304.txt";
site="venera.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22006;
11 May 93 20:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21984;
11 May 93 20:02 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa00923;
11 May 93 20:02 EDT
Received: from jarrah.itd.adelaide.edu.au by venera.isi.edu (5.65c/5.61+local-12)
id <AA04938>; Tue, 11 May 1993 17:02:32 -0700
Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.26)
id AA05117; Wed, 12 May 1993 09:31:33 +0930
Message-Id: <9305120001.AA05117 at jarrah.itd.adelaide.edu.au>
To: "Al Costanzo"@CNRI.Reston.VA.US,
Associate Director - Computer Services <AKC at turbo.prime.com>
Cc: ietf at isi.edu
Subject: Re: InterNIC Plans for a White-pages Directory
In-Reply-To: Your message of "11 May 1993 10:11:39 EST."
<199305111411.AA17100 at venera.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 12 May 1993 09:31:33 +0930
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Mark Prior <mrp at itd.adelaide.edu.au>
Status: O
Are YOU going to pay my vendor to implement x.500 directory service on
all my hosts? If not, lets keep this optional for a number of years
and put the Whois database back together, Please.
The fact that the InterNIC are going to use X.500 to store that data
shouldn't affect you as long as they also provide gateways onto that
service, such as whois, gopher etc. (I have already written a X.500 to
whois++ gateway).
Moving to X.500 is a good idea, especially if that means I get change
control on my entry.
Mark.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24416;
11 May 93 23:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24411;
11 May 93 23:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05906;
11 May 93 23:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24400;
11 May 93 23:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24396;
11 May 93 23:42 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa05898; 11 May 93 23:42 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Tue, 11 May 93 20:42:12 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA00352; Tue, 11 May 93 20:42:27 PDT
Date: Tue, 11 May 93 20:42:27 PDT
Message-Id: <9305120342.AA00352 at mel-brooks.empirical.com>
To: kasten at ftp.com
Subject: Conflict of interest rules? Was Re: Do we need an Ombdusman?...
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
I think we need to trust WG chairs. -- Besides, we don't have enough
WG chair volunteers as is.
However, at the IESG level, we ought to have a conflict of interest
rule. Here's one formulation:
No member of the IESG should take part in any IESG vote, action, or
discussion in which any of the following situations obtain:
1. That IESG member has acted in any of the following roles with
respect to the matter at hand:
a. Working group chairman, or
b. Major proponent of the material on which the working group
is acting, or
c. Editor of the working group documents.
2. That IESG member(*) has a financial or similar interest in the
content of the matter at hand or in the date on which the matter is
resolved.
(*) One could argue that financial conflict of interest should also
apply should the IESG member have a family member or be part of a
company which has a financial interest.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25265;
12 May 93 1:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25260;
12 May 93 1:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07990;
12 May 93 1:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25250;
12 May 93 1:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25246;
12 May 93 1:34 EDT
Received: from uu.psi.com by CNRI.Reston.VA.US id aa07985; 12 May 93 1:34 EDT
Received: from acec.com by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via SMTP;
id AA22276 for iesg at CNRI.Reston.VA.US; Wed, 12 May 93 01:33:48 -0400
Date: Wed, 12 May 1993 00:58:43 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Natale <natale at acec.com>
Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. )
id AA20748; Wed, 12 May 1993 00:58:43 -0400
Message-Id: <9305120458.AA20748 at nips.acec.com>
To: karl at empirical.com
Subject: Re: Conflict of interest rules? Was Re: Do we need an Ombdusman?...
Cc: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
Status: O
> Date: Tue, 11 May 93 20:42:27 PDT
> From: <karl at empirical.com>
> Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
>
> I think we need to trust WG chairs. -- Besides, we don't have enough
> WG chair volunteers as is.
>
I think everyone can agree to those points...keep them in mind when
reading below....
> However, at the IESG level, we ought to have a conflict of interest
> rule.
Maybe...maybe not. But Karl's message is definitely a sensible
place to start the discussion.
> Here's one formulation:
>
> No member of the IESG should take part in any IESG vote, action, or
> discussion in which any of the following situations obtain:
>
> 1. That IESG member has acted in any of the following roles with
> respect to the matter at hand:
> a. Working group chairman, or
> b. Major proponent of the material on which the working group
> is acting, or
> c. Editor of the working group documents.
>
I can see how a reasonable person would consider this a reasonable
set of criteria. I do not agree with them, however, mainly due to
the importance of Karl's opening (valid) assertion about the need
for qualified, capable, and willing WG chairs. As a congenital
Platonist, I think the only criteria for net leadership positions
should be: Intelligence, ability, competence, commitment,
productivity, and delivery (i.e., bringing home the bacon).
> 2. That IESG member(*) has a financial or similar interest in the
> content of the matter at hand or in the date on which the matter is
> resolved.
>
I wish I had a better formulation of my reasons for not supporting
this otherwise attractive criterion...I mean, on the surface it seems
fairly reasonable. But I just think that--almost universally--we
all have an economic stake in many/most of the important decisions
made by the net leadership today...whether as vendors, authors,
consultants, professors, grad students, net management people as
users and buyers, and so forth. It's hard for me to imagine--
although I will admit that I have not really tried to do so!--
how we would further refine this criterion to apply to some of
the foregoing occupations/roles and not others.
> (*) One could argue that financial conflict of interest should also
> apply should the IESG member have a family member or be part of a
> company which has a financial interest.
>
One could, but I hope that in the interest of continued sensibility
in the discussion of this general topic--i.e., conflict of
interest rule--we don't carry things that far.
> --karl--
I should have put this statement at the beginning, I guess, so that
you could have deleted this message before working thru my comments
above (and maybe you did!), but I acknowledge that I am really not
(yet) a veteran of many of the experiences that rest behind this
whole thread and, therefore, I might be somewhat irrelevant to
the discussion (for now). But I happened to be working my e-mail
rather late when Karl's thoughtful proposal popped up and thought
I would try to lodge a respectful retort to keep the ball rolling
(as tho' it's going to need any help :-) ).
BobN
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Bob Natale American Computer 301-258-9850 [tel]
Director 209 Perry Pkwy 301-921-0434 [fax]
Network Mgmt Products Gaithersburg MD 20877 natale at acec.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00733;
12 May 93 3:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00728;
12 May 93 3:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01555;
12 May 93 3:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00718;
12 May 93 3:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00712;
12 May 93 3:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01550;
12 May 93 3:21 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa00707;
12 May 93 3:21 EDT
To: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
cc: Chuck Wegrzyn <wegrzyn at nic.cerf.net>,
Einar Stefferud <Stef=ietf at nma.com>, ietf at CNRI.Reston.VA.US,
iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
In-reply-to: Your message of "Tue, 11 May 93 14:24:51."
<9305111824.AA12978 at black-ice.cc.vt.edu>
Date: Wed, 12 May 93 03:21:07 -0400
X-Orig-Sender:iesg-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: <9305120321.aa00707 at IETF.CNRI.Reston.VA.US>
Status: O
I hesitate to enter another message into the barrage. Just
wanted to observe that most of our technical progress on the
Internet has been made by people who believe passionately in
what they do. I sure wasn't neutral as regards TCP/IP!!
Along the way, though, I have encountered many people with
whom I have not agreed but whose opinions I respected.
They often had good reasons for their views and different
experiences or circumstances that led them there. I hope
we can learn to tolerate diversity, appreciate our differences,
and recognize that we cannot necessarily expect to agree on
everything.
Vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02952;
12 May 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02948;
12 May 93 8:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06945;
12 May 93 8:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02938;
12 May 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02934;
12 May 93 8:02 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa06940;
12 May 93 8:02 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa22669;
12 May 93 11:58 GMT
Date: Wed, 12 May 93 11:57 GMT
X-Orig-Sender:iesg-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 CNRI.Reston.VA.US>
Cc: iesg <iesg at CNRI.Reston.VA.US>
Subject: Re: Do we need an Ombdusman? re: Censorship...
Message-Id: <93930512115739/0003858921NA4EM at mcimail.com>
Status: O
>> I wish to iterate that the most important part of the moderator is to be
>> neutral! They only direct the discussion, not participate.
>In the voluminous discussion resulting from this, I'm surprised that nobody
>has mentioned one of the obvious issues.
>Being a moderator/leader/whatever is work. Often hard, thankless work.
>Why in the world would anybody do such a thing if they were disinterested
>in the results?
I have a 'theory':
An end-user of a technology can make a very good moderator.
The end-user knows why they want the technology and how it may end up being
used. A given end-user might not know all such, but will listen closely to
other end-users. This sort of moderator could then challenge the engineers
into producing an end-user oriented technology.
I am testing out this theory now...
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04187;
12 May 93 8:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04183;
12 May 93 8:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07909;
12 May 93 8:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04173;
12 May 93 8:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04168;
12 May 93 8:28 EDT
Received: from NR-TECH.CIT.CORNELL.EDU by CNRI.Reston.VA.US id aa07904;
12 May 93 8:28 EDT
Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3)
id AB21852; Wed, 12 May 93 08:28:24 EDT
Message-Id: <9305121228.AB21852 at mitchell.cit.cornell.edu>
Date: Wed, 12 May 1993 08:27:52 -0500
To: karl at empirical.com
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Scott Brim <swb at nr-tech.cit.cornell.edu>
Subject: Re: Conflict of interest rules? Was Re: Do we need an Ombdusman?...
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Status: O
Karl: Very nice in principle, but (i) we don't have a lot of people, if
any, who are both good enough to be on the IESG and are *not* a major
proponent of something; (ii) if we are going to recognize the increasing
role of commercial providers we have to allow for conflict of interest to
be acceptable. There are plenty of other organizations with similar
problems. As long as conflict of interest is revealed up front it can be
taken into account, and if it is not revealed it can be exposed, and *that*
series of events can be taken into account.
Oh, if IESG decisions are made by *voting* then of course there will be
problems -- but it's ridiculous to think that the fate of the Internet
should be decided by something as crude as IESG voting. If a consensus
can't be reached in a group with the strengths of the IESG then either an
issue is not ready to be decided, or they have to learn to talk to each
other better. So far the IETF doesn't have the burdens of X3, and we
should keep trying to work without them or we will have the same
difficulties they do in producing great visionary standards.
>No member of the IESG should take part in any IESG vote, action, or
>discussion in which any of the following situations obtain:
>
> 1. That IESG member has acted in any of the following roles with
> respect to the matter at hand:
> a. Working group chairman, or
> b. Major proponent of the material on which the working group
> is acting, or
> c. Editor of the working group documents.
>
> 2. That IESG member(*) has a financial or similar interest in the
> content of the matter at hand or in the date on which the matter is
> resolved.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07823;
12 May 93 9:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07819;
12 May 93 9:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10083;
12 May 93 9:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07809;
12 May 93 9:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07805;
12 May 93 9:30 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa10061; 12 May 93 9:30 EDT
Received: by ftp.com
id AA07178; Wed, 12 May 93 09:30:38 -0400
Date: Wed, 12 May 93 09:30:38 -0400
Message-Id: <9305121330.AA07178 at ftp.com>
To: karl at empirical.com
Subject: Re: Conflict of interest rules?
X-Orig-Sender:iesg-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: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Status: O
I would like to point out that many of us have financial interests in
the companies we work for (or worked for in the past), and that these
companies all derive their financial well-being from the net so, if I
were on the IESG, would I have to recuse my self from any discussions
about the protocols that we implement or are planning to implement?
About all that I could discuss under these rules would be user-
services stuff and routing protocols.
Would Karl have to recuse himself from all discussions on SNMP (don't
your products use SNMP Karl?)
> 2. That IESG member(*) has a financial or similar interest in the
> content of the matter at hand or in the date on which the matter is
> resolved.
>
> (*) One could argue that financial conflict of interest should also
> apply should the IESG member have a family member or be part of a
> company which has a financial interest.
>
> --karl--
--
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 aa07862;
12 May 93 9:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07858;
12 May 93 9:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10100;
12 May 93 9:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07847;
12 May 93 9:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07843;
12 May 93 9:31 EDT
Received: from nic.cerf.net by CNRI.Reston.VA.US id aa10094; 12 May 93 9:31 EDT
Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA09294; Wed, 12 May 93 06:35:21 PDT
Date: Wed, 12 May 1993 06:28:10 -0700 (PDT)
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Subject: Re: Do we need an Ombdusman? re: Censorship...
To: Jordan Brown <jbrown at qdeck.com>
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
In-Reply-To: <9305111623.aa12830 at angel.qdeck.com>
Message-Id: <Pine.3.05.9305120608.D7950-b100000 at nic.cerf.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
Yes, being a WG chair is hard work irregardless of being neutral or not.
Notice that I didn't say they were disinterested in the outcome, only that
they themselves can vote on an issue, nor express any opinions (other than
that necessary to make sure the work gets done).
The question that should be raised is "Why does anyone want to chair a WG?"
Is it because they want to control the outcome? Maybe to see their name in
print? Maybe to affect the outcome of the WG? If it is the first case,
then we are in big trouble. If it is the second case, then no problem
here; names are still in the RFCs themselves. If it is the third case,
well that is more difficult. Everyone in a WG can participate (if the
correct environment is supported). What should be noticed is that a good
leader is one that stands back allows others to take the glory, but only
takes the blame.
I think the WGs would do better with a simple rule that states that the
chairs can express no opinion over the matters being discussed, and can't
vote on its outcome. Their role is simply as a facilitator, nothing more
nor less.
Chuck.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08214;
12 May 93 9:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08149;
12 May 93 9:39 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa10345;
12 May 93 9:39 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA01035; Wed, 12 May 93 06:39:33 -0700
Message-Id: <9305121339.AA01035 at Mordor.Stanford.EDU>
To: Bob Natale <natale at acec.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Conflict of interest rules? Was Re: Do we need an Ombdusman?...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 12 May 93 00:58:43 -0400. <9305120458.AA20748 at nips.acec.com>
Date: Wed, 12 May 93 06:39:33 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
Status: O
Bob & Scott Brim,
You both raise important points about IESG operation. Financial
interest turns out to be tough to avoid in a small community. And
formal voting simply isn't the IETF style of doing things. (The IESG
does occasionally take votes, but they are not a major part of IESG
life and are used more to bring difficult debates to a close than
to determine the statistics of group preference.)
In general, IESG operation is sensistive to IESG member conflict of
interest and the semantic part of voting -- i.e., attempting to sway
the rest of the IESG -- is in fact not allowed when the IESG member
has a role in the topic under discussion.
>From several recent activities, we seem to have developed the rule,
for example, that an Area Director may not chair a working group in
their own area. (For working groups with a likelihood of controversy,
I tend to believe that the chair should restrict their role to that
of moderator, rather than contributor, as has been suggested by
some of yesterday's mail.) The goal, here, is to make sure that there
are clean lines of appeal available.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09773;
12 May 93 9:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09769;
12 May 93 9:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10733;
12 May 93 9:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09759;
12 May 93 9:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09755;
12 May 93 9:48 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa10726;
12 May 93 9:48 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA01105; Wed, 12 May 93 06:48:47 -0700
Message-Id: <9305121348.AA01105 at Mordor.Stanford.EDU>
To: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 12 May 93 06:28:10 -0700. <Pine.3.05.9305120608.D7950-b100000 at nic.cerf.net>
Date: Wed, 12 May 93 06:48:46 -0700
X-Orig-Sender:iesg-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
Status: O
Chuck,
---- Included message:
I think the WGs would do better with a simple rule that states that the
chairs can express no opinion over the matters being discussed, and can't
vote on its outcome. Their role is simply as a facilitator, nothing more
nor less.
For the working group chair training that I did, for the first time,
at the last IETF, I decided to describe the leadership functions as:
1. Process Management
2. Technical Management
3. Editing
The first is the moderator role that you are describing. The second is
usually not an explicitly identified person, but is a role that usually
resides with the person writing the spec. The last role is that author.
I see the Technical Management role as being the keeper of the technical
vision which is driving the effort, and also being the voice that
pushes to resolve controversy by choosing between alternatives. (As always,
this requires wg consensus, but sometimes it needs a strong voice to
move the group from deep debate into the resolve to make SOME decision.)
One of the benefits of IETF operation is the potential to have very
streamlined working group activity. It isn't as simple as it used to
be, but it is much less cumbersome that most standards groups. I think
it is essential that that remain possible. This means that some working
groups should have a working group chair who does all 3 functions. If
that works, it should be allowed.
My opinion is that splitting the functions up (usually into two people
suffices) is appropriate when there is the potential or the presence
of serious controversy. The IETF already has this range of operational
style, but has not been overly explicit about the criteria for different
working group configurations.
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09840;
12 May 93 9:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09836;
12 May 93 9:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10777;
12 May 93 9:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09826;
12 May 93 9:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09822;
12 May 93 9:49 EDT
Received: from mitsou.inria.fr by CNRI.Reston.VA.US id aa10770;
12 May 93 9:49 EDT
Received: by mitsou.inria.fr
(5.65c/IDA-1.2.8) id AA12511; Wed, 12 May 1993 15:51:14 +0200
Message-Id: <199305121351.AA12511 at mitsou.inria.fr>
To: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Cc: Jordan Brown <jbrown at qdeck.com>, ietf at CNRI.Reston.VA.US,
iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
In-Reply-To: Your message of "Wed, 12 May 93 06:28:10 PDT."
<Pine.3.05.9305120608.D7950-b100000 at nic.cerf.net>
Date: Wed, 12 May 93 15:51:12 +0200
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Christian Huitema <Christian.Huitema at sophia.inria.fr>
Status: O
> Is it because they want to control the outcome? Maybe to see their name in
> print? Maybe to affect the outcome of the WG?
What about "because they want the outcome to actually come out"?
Christian Huitema
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10831;
12 May 93 10:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12382;
12 May 93 10:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10792;
12 May 93 10:31 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10683;
12 May 93 10:28 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-ipcpmib-03.txt
Date: Wed, 12 May 93 10:28:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305121028.aa10683 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the IP
Network Control Protocol of the Point-to-Point
Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-ipcpmib-03.txt
Pages : 18
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it describes managed objects
used for managing the IP Network Control Protocol on subnetwork
interfaces using the family of Point-to-Point Protocols.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-ipcpmib-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-pppext-ipcpmib-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-pppext-ipcpmib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-ipcpmib-03.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 aa10843;
12 May 93 10:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10833;
12 May 93 10:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12381;
12 May 93 10:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10794;
12 May 93 10:31 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10646;
12 May 93 10:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-822 at dimacs.rutgers.edu
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-chon-korean-encoding-00.txt
Date: Wed, 12 May 93 10:28:15 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305121028.aa10646 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Korean Character Encoding for Internet Messages
Author(s) : K. Chon, H. Je Park, U. Choi
Filename : draft-chon-korean-encoding-00.txt
Pages : 5
This document describes the encoding method being used to represent
the Hangul, Korean character, in both header and body part of the
internet electronic mail system. This encoding method was specified in
System Development Network (SDN) in 1991, and has since then been
used, it has widely spread from SDN to other Korean IP networks.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-chon-korean-encoding-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-chon-korean-encoding-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-chon-korean-encoding-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-chon-korean-encoding-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 aa12317;
12 May 93 10:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12311;
12 May 93 10:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12766;
12 May 93 10:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12171;
12 May 93 10:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12153;
12 May 93 10:41 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa12751; 12 May 93 10:41 EDT
Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA22193 for iesg at cnri.reston.va.us; Wed, 12 May 93 10:41:24 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA25516; Wed, 12 May 93 07:40:51 PDT
Message-Id: <9305121440.AA25516 at aland.bbn.com>
To: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: re: Conflict of interest rules? Was Re: Do we need an Ombdusman?...
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 12 May 93 07:40:50 -0700
X-Orig-Sender: craig at aland.bbn.com
Status: O
Karl:
Thanks for putting a concrete proposal forward. It's an interesting
thought piece.
> ... Besides, we don't have enough WG chair volunteers as is.
>
> However, at the IESG level...
Actually, we had a shortage of IESG recruits in the last recruiting drive
too. About 75% of those asked if they'd be willing to serve said no.
Let's not make the life of future nominating committees even harder.
No member of the IESG should take part in any IESG vote, action, or
discussion in which any of the following situations obtain:
> 1. That IESG member has acted in any of the following roles with
> respect to the matter at hand:
> a. Working group chairman, or
> b. Major proponent of the material on which the working group
> is acting, or
> c. Editor of the working group documents.
As I read (b) an IESG member can't even have a strong opinion on a topic.
That's clearly undesirable. Rule (a) seems reasonable. Rule (c) may
be -- finding editors is hard and I'd like to allow an AD to step in and
get a draft out the door if needed.
> 2. That IESG member(*) has a financial or similar interest in the
> content of the matter at hand or in the date on which the matter is
> resolved.
I think this rule is untenable. Almost all of us have financial interests -
namely who employs us, most of whom produce a range of internetworking
products. Many folks own stock in companies (especially their employers).
So, under a strict interpretation of this rule, most IETFers would be
unable to serve as IESG members for almost any matter before the IESG.
Indeed, I suspect this rule would force us to search for IESG members
solely among the ranks of independently wealthy individuals such as
heirs and heiresses, and very successful book authors (:-)).
Craig
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13109;
12 May 93 10:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12996;
12 May 93 10:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13054;
12 May 93 10:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12353;
12 May 93 10:42 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-ipcpmib-03.txt
Date: Wed, 12 May 93 10:42:08 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305121042.aa12353 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the IP
Network Control Protocol of the Point-to-Point
Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-ipcpmib-03.txt
Pages : 18
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it describes managed objects
used for managing the IP Network Control Protocol on subnetwork
interfaces using the family of Point-to-Point Protocols.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-ipcpmib-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-pppext-ipcpmib-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-pppext-ipcpmib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-ipcpmib-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 aa13198;
12 May 93 10:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13020;
12 May 93 10:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13126;
12 May 93 10:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12403;
12 May 93 10:42 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-bridgemib-03.txt
Date: Wed, 12 May 93 10:42:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305121042.aa12403 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the Bridge
Network Control Protocol of the Point-to-Point
Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-bridgemib-03.txt
Pages : 23
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it describes managed objects
used for managing the bridge Network Control Protocol on subnetwork
interfaces using the family of Point-to-Point Protocols.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-bridgemib-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-pppext-bridgemib-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-pppext-bridgemib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-bridgemib-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 aa13200;
12 May 93 10:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13019;
12 May 93 10:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13144;
12 May 93 10:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12433;
12 May 93 10:43 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-lcpmib-03.txt
Date: Wed, 12 May 93 10:43:01 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305121043.aa12433 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the Link
Control Protocol of the Point-to-Point Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-lcpmib-03.txt
Pages : 34
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it describes managed objects
used for managing the Link Control Protocol and Link Quality
Monitoring on subnetwork interfaces that use the family of
Point-to-Point Protocols.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-lcpmib-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-pppext-lcpmib-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-pppext-lcpmib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-lcpmib-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 aa13258;
12 May 93 10:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13048;
12 May 93 10:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13235;
12 May 93 10:47 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12482;
12 May 93 10:43 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-secmib-03.txt
Date: Wed, 12 May 93 10:43:21 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305121043.aa12482 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The Definitions of Managed Objects for the Security
Protocols of the Point-to-Point Protocol
Author(s) : Frank Kastenholz
Filename : draft-ietf-pppext-secmib-03.txt
Pages : 21
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it describes managed objects
used for managing the Security Protocols on subnetwork interfaces
using the family of Point-to-Point Protocols.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-pppext-secmib-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-pppext-secmib-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-pppext-secmib-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-secmib-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 aa13291;
12 May 93 10:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13059;
12 May 93 10:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13253;
12 May 93 10:47 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12571;
12 May 93 10:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rmonmib at jarthur.claremont.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-rmonmib-trmib-00.txt
Date: Wed, 12 May 93 10:43:47 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305121043.aa12571 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Remote LAN Monitoring
Working Group of the IETF.
Title : Token Ring Extensions to the Remote Network
Monitoring MIB
Author(s) : S. Waldbusser
Filename : draft-ietf-rmonmib-trmib-00.txt
Pages : 62
This memo defines extensions to the Remote Network Monitoring MIB for
managing 802.5 Token Ring networks.
The Remote Network Monitoring MIB, RFC1271, 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. RFC1271
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.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-rmonmib-trmib-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-rmonmib-trmib-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-rmonmib-trmib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmonmib-trmib-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 aa14364;
12 May 93 11:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14358;
12 May 93 11:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14832;
12 May 93 11:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14341;
12 May 93 11:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14337;
12 May 93 11:23 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at IETF.CNRI.Reston.VA.US>
cc: ietf-ppp at ucdavis.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: The Protocol of the Point-to-Point Protocol MIBs to
Proposed Standard
Date: Wed, 12 May 93 11:23:13 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305121123.aa14337 at IETF.CNRI.Reston.VA.US>
Status: O
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider the Internet Drafts
o "The Definitions of Managed Objects for the Bridge Network Control
Protocol of the Point-to-Point Protocol"
<draft-ietf-pppext-bridgemib-03.txt>
o "The Definitions of Managed Objects for the IP Network Control
Protocol of the Point-to-Point Protocol"
<draft-ietf-pppext-ipcpmib-03.txt>
o "The Definitions of Managed Objects for the Link Control Protocol of
the Point-to-Point Protocol" <draft-ietf-pppext-lcpmib-03.txt>
o "The Definitions of Managed Objects for the Security Protocols of
the Point-to-Point Protocol" <draft-ietf-pppext-secmib-03.txt>
as a 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
May 26th.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15832;
12 May 93 12:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15828;
12 May 93 12:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17226;
12 May 93 12:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15818;
12 May 93 12:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15814;
12 May 93 12:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17221;
12 May 93 12:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15809;
12 May 93 12:32 EDT
To: IETF-Announce: ;
Cc: IESG at CNRI.Reston.VA.US
Cc: ietf-ppp at ucdavis.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call2: TCP/IP Header Compression to Draft Standard
Date: Wed, 12 May 93 12:32:31 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305121232.aa15809 at IETF.CNRI.Reston.VA.US>
Status: O
The IESG is considering RFC 1144 "Compressing TCP/IP headers for
low-speed serial links" for Draft Standard status. RFC 1144 was
published as a Proposed Standard in December 1990.
The IESG is aware of several errors in the example code. A revised
version with version of this RFC will be published upon approval as a
Draft Standard. The expected "diffs" are included as an appendix to
this message.
The IESG plans to issue a recommendation in the next few weeks, and
solicits final comments on this elevation. Please send any comments to
the iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
May 26th.
Greg Vaudreuil
IESG Secretary
Appendix
Line numbers of rfc1144.txt
--- 2042,2049 ----
comp->last_cs = lcs;
hlen += th->th_off;
hlen <<= 2;
+ if (hlen > m->m_len) return (TYPE_IP);
goto uncompressed;
found:
/* Found it -- move to the front on the connection list. */
if (lastcs == cs)
--- 2070,2076 ----
deltaS = hlen;
hlen += th->th_off;
hlen <<= 2;
+ if (hlen > m->m_len) return (TYPE_IP);
if (((u_short *) ip)[0] != ((u_short *) &cs->cs_ip)[0] ||
((u_short *) ip)[3] != ((u_short *) &cs->cs_ip)[3] ||
((u_short *) ip)[4] != ((u_short *) &cs->cs_ip)
--- 2527,2533 ----
*/
comp->last_recv = 255;
comp->last_xmit = 255;
+ comp->flags = SLF_TOSS;
}
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15944;
12 May 93 12:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15940;
12 May 93 12:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17307;
12 May 93 12:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15924;
12 May 93 12:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15920;
12 May 93 12:35 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa17302; 12 May 93 12:35 EDT
Received: by ftp.com
id AA14326; Wed, 12 May 93 12:35:53 -0400
Date: Wed, 12 May 93 12:35:53 -0400
Message-Id: <9305121635.AA14326 at ftp.com>
To: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman?
X-Orig-Sender:iesg-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
Status: O
> Is it because they want to control the outcome? Maybe to see their name in
> print? Maybe to affect the outcome of the WG?
How about "they have a higher sense of civic duty and wish to help in
the continuing growth and evolution of Internet technology"?
--
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 aa16256;
12 May 93 12:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14274;
12 May 93 11:18 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa14650;
12 May 93 11:18 EDT
Received: by xap.xyplex.com id <AA28096 at xap.xyplex.com>; Wed, 12 May 93 11:51:09 -0500
Date: Wed, 12 May 93 11:51:09 -0500
Message-Id: <9305121651.AA28096 at xap.xyplex.com>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280"'s message of Mon, 10 May 93 12:19:47 PDT <9305101919.AA08423 at mel-brooks.empirical.com>
Subject: Re: Do we need an Ombdusman? re: Censorship...
Status: O
I know this is already a bit stale, but I couldn't let it just sit.
Karl said:
>I do not agree with Bob Stewart that people who were intimidated
>ought to have have had the guts to complain. And that since few have
>complained, there is no problem. (My paraphrase).
Although I'll concede that a tendency to be intimidated and the encouragement
to complain are somewhat at odds, I believe people must take responsibility
for themselves and not shift blame. No one is shutting anyone else up.
People choose to shut themselves up. Adult responsibility.
I didn't say there was no problem. I meant to imply that the solution lies
with those who believe they are wronged. They must bring their own complaints
to the IESG, IAB, or ISoc. I don't believe in either class action suits on
behalf of those who won't defend themselves, nor trying to make laws, er,
rules to protect victims who are not well identified, and may be victimizing
themselves. That sounds like the sort of stuff lawyers do to make work for
lawyers. (Karl told me privately we needed a lawyer joke. He suggested
that lawyers are a joke. No Comment.)
This is not a personal attack on Karl, and he knows it. He defends himself.
On a side note, is there any benefit whatsoever in cross-posting this to the
IETF and IESG mailing lists? Somehow I suspect all the IESG members are on
the IETF mailing list, so I removed the cross post from my reply.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23941;
12 May 93 14:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23937;
12 May 93 14:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20642;
12 May 93 14:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23927;
12 May 93 14:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23923;
12 May 93 14:21 EDT
Received: from burdell.cc.gatech.edu by CNRI.Reston.VA.US id aa20637;
12 May 93 14:21 EDT
Received: from terminus.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA01425
(5.65c/IDA-1.4.4); Wed, 12 May 1993 14:21:42 -0400
Received: by terminus.cc.gatech.edu id AA05632
(5.65c/IDA-1.4.4); Wed, 12 May 1993 14:21:40 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Cheryl Krupczak <cheryl at cc.gatech.edu>
Message-Id: <199305121821.AA05632 at terminus.cc.gatech.edu>
Subject: Re: Do we need an Ombdusman? re: Censorship...
To: karl at empirical.com
Date: Wed, 12 May 93 14:21:39 EDT
Cc: dcrocker at mordor.stanford.edu, ietf at CNRI.Reston.VA.US,
iesg at CNRI.Reston.VA.US
In-Reply-To: <9305111802.AA09469 at mel-brooks.empirical.com>; from "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" at May 11, 93 11:02 am
X-Mailer: ELM [version 2.3 PL11]
Status: O
I feel _my_ time has come where I need to stand up and say:
"this is not right."
Karl is forcing us to take a look at some of the ugliness going on,
and although it makes life much happier and easier if we just turn
away and overlook the ugliness, we would be shirking our responsibilities
as members of the community if we ignore the problems in favor
of the safe haven of naivete and "Polly-Anna" smiles.
>> First, a complaint such as you apparently were intending to lodge should
>> be accompanied with a list of particulars.
>I have had much private mail about this issue, yesterday and over the
>last many years. The situation is one which many people seem blind
>and do not want to recognize.
>
>I did not want to put out particulars, which would simply serve to
>highlight the individuals. Rather, I am attempting to focus on the
>general problem. You should be able to appreciate that.
I strongly agree with Karl on this point. There is no reason to
name-names and attack personal characters if we can recognize
a problem without descending to the level of reporting names and
particulars (although the archives are full of examples if the
IESG really feels this is necessary). Addressing the PROBLEM directly,
and not the people, is a much more graceful, less antagonistic
approach to handling the situation.
>However, I might add, that I was gratuitously blasted on the entire
>IETF and SNMP mailing lists. There are times when it is necessary to
>stand up and say "this is wrong."
Every time I have stood up to say "this is wrong", I get flamed
(expected - water off the back of a duck) AND, I get plenty
of email from people, too intimidated to post publically, who thank
me for standing up (disappointedly expected).
Asking people who have been intimidated into silence to publically
post to say they have been intimidated is an oxymoron.
The problem is that certain individuals have taken to attacking
the personal character of others. They have accused others of
malicious intent, they have set themselves up as judges of
worthiness of contribution of the messages of others, and they
have publically humiliated those that disagree with them.
And we, the community, are responsible because we allowed it to
happen.
(NOTE: Karl did not accuse an INDIVIDUAL of bad behavior, he
accused the COMMUNITY of allowing intimidation to prevent the
freedom of free speech.)
What we need is a parent-figure (IESG) to reprimand these
mis-behaving children.
>The point is that many, many people have simply given up working with
>the snmp community at all because of the situation. Take Vince
>Fuller's note as simply the tiny tip of a very large iceberg.
I too have followed the postings of many people whose opinions
I grew to respect, only to watch them get chased out of the snmp
community because their opinions differed from others and they
finally had enough of the public ridicule and character-attacks.
Our credibility as a working group has suffered. The response
I used to get from people when I told them I'm a member of the
IETF snmp working group was - "Oh..." (interested), now the
response I get is - "Oh. That political mess." (turned off).
I would like to see our community clean up its own act --
(hopefully these messages will make us all exert a little more
self-control) so we can regain our credibility instead of
being the laughing stock of the IETF.
- Cheryl Krupczak
cheryl at cc.gatech.edu
--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25454;
12 May 93 15:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25450;
12 May 93 15:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24403;
12 May 93 15:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25440;
12 May 93 15:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25436;
12 May 93 15:47 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa24396;
12 May 93 15:47 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA04059; Wed, 12 May 93 12:47:28 -0700
Message-Id: <9305121947.AA04059 at Mordor.Stanford.EDU>
To: Cheryl Krupczak <cheryl at cc.gatech.edu>
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 12 May 93 14:21:39 -0400. <199305121821.AA05632 at terminus.cc.gatech.edu>
Date: Wed, 12 May 93 12:47:27 -0700
X-Orig-Sender:iesg-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
Status: O
Cheryl,
---- Included message:
I strongly agree with Karl on this point. There is no reason to
name-names and attack personal characters if we can recognize
a problem without descending to the level of reporting names and
particulars (although the archives are full of examples if the
If it were possible to clearly identify a concrete problem and develop
concrete corrections to it, without the use of particulars, I would
agree with you. But our community -- and I believe most communities --
deal with abstractions very poorly. Our technical successes come
from technical concreteness and immediate utility. I believe that
recent changes to IETF structure and processes have developed in the
same way. The solutions, such as the Selection Committee, represent
an extraordinary innovation in staffing a volunteer standards
organization, but the innovation suits the style of the IETF.
Similarly whatever deficiencies you, Karl or others see in general
IETF activities or specific working group functions, suggestions for
change need to be concrete and focussed and they need to be based
on clear, focused analysis of clear, specific events/data. The
point that I have been trying to make for the last two days is that
such detail has been missing. This leaves me with no doubt that Karl
and some other folks are unhappy, but no clear sense of the specific
causes. Therefore, there is no way to evaluate the likely utility of
any suggested changes.
Frankly, the only specifics I've heard is that some people said some
unpleasant things in public. While I am not a fan of personal
attacks, it's tough to know what action can be taken to prevent
their occurrence.
At worst, we end up with complaints that simply look like sour
grapes from losers of arguments. To the extent that there are real
problems which need to be solved, this means the IETF loses an
opportunity to improve.
IESG really feels this is necessary). Addressing the PROBLEM directly,
and not the people, is a much more graceful, less antagonistic
approach to handling the situation.
I agree that we should not try to engage in personal attacks. By the
same token, we need to know the specifics of any problems or else we
cannot possible develop specific changes to prevent recurrence.
Every time I have stood up to say "this is wrong", I get flamed
The snmpv2 email transcript that I read showed only one major flammage
that you received. I noted some other submissions from you, later,
which expressed dissatisfaction with the process and I don't recall
that you got blasted in response.
(expected - water off the back of a duck) AND, I get plenty
of email from people, too intimidated to post publically, who thank
me for standing up (disappointedly expected).
Asking people who have been intimidated into silence to publically
post to say they have been intimidated is an oxymoron.
Two points:
1. Erik Huizer's public query did not ask for public responses. In
fact, it promised confidentiality. Still, he received very limited
input and none at the level that is currently being claimed.
2. Our community is based on making progress from direct
contributions. We generally do not "proactively" solicit input
or ideas. We assemble some folks, let them rant and rave for awhile,
and have them produce some specs. We are, in other words, a community
which requires assertive participation. While it might be more
humane and sensitive of us to make more effort to gather more input
from those who are milder and less assertive, we don't have much
history doing so. I definitely do not believe that this should serve
as an excuse for unprofessional conduct, but the reality is that
those who remain silent have lost their vote.
The problem is that certain individuals have taken to attacking
the personal character of others. They have accused others of
Each and every occurrence of this should be challenged and stopped.
But we can't "legislate" it away. We have to train each offender.
And some of us take longer than others. And many of us backslide
and have to be reminded of the politically correct behavior -- errrr,
the professionally correct behavior.
And some folks need to understand the difference between heated
debate and personal attack.
malicious intent, they have set themselves up as judges of
worthiness of contribution of the messages of others, and they
have publically humiliated those that disagree with them.
Cheryl, there is an enormous amount of that in this community. It
is one of the rough edges which I readily share your dislike of, but
which is very ingrained.
And we, the community, are responsible because we allowed it to
happen.
And here's the rub. If the community allows it then it is not
reasonable to come back months later and make a complaint. The fact
that the community did not pursue any of the various paths available
to remedy problems with the process means that the problems weren't
there or that there was not a sufficient constituency which felt that
it required fixing. Generic assertions of being intimidated into
silence simply do not form a basis for pursuing any action.
What we need is a parent-figure (IESG) to reprimand these
mis-behaving children.
Yikes! This is a professional organization. While we may have
occurrences of unprofessional behavior, models of parental censure
are unlikely to work very well, here.
However, perhaps your assessment suggests a core source of some of
the tension. I hope I'm not over-interpreting here, but:
Reference to a parental role suggests an environment in which we,
the individual members, can rely on basic safety and solid points
of reference. The parents are (or should be) the safe haven, and
the arbiters of ethics and expectations. Such a model is used in
many places.
But not in the IETF.
We work by rough consensus. And both meanings of 'rough' apply. If
someone transgresses, there is no absolute authority who will make
that assessment. There is a community which might develop
a consensus about it, but that consensus has to be built. The IESG
is formally tasked to be in the chain of appeal for receiving
complaints, and forumulating an assessment on behalf of the
implied community consensus. But it is important to note that
individuals who disagree with the IESG assessment are free to
take the matter up with the IAB or the IETF.
So, yes, we do have formal appeals procedures, but I suspect we end
up missing the boat if we consider the agencies for those appeals
to be given overly exhalted status.
On the other hand, I'll note that one of the reasons I believe that
the current round of complaint is having such difficulty is that the
designated agencies weren't used. Apparently, it was easier to make a
generic complaint to the entire IETF than to incur the overhead of
carefully formulating a specific challenge and bringing it before the
IESG.
I too have followed the postings of many people whose opinions
I grew to respect, only to watch them get chased out of the snmp
community because their opinions differed from others and they
finally had enough of the public ridicule and character-attacks.
I don't recall Erik Huizer's query as having been given any reports
of such occurrences.
Our credibility as a working group has suffered. The response
I used to get from people when I told them I'm a member of the
IETF snmp working group was - "Oh..." (interested), now the
response I get is - "Oh. That political mess." (turned off).
Yup. Quite a lot of back-channel, private bad-mouthing. Remarkably
little up-front, direct criticism.
Curious style of doing business. One wonders how much of that bad
mouthing is from people with a direct basis for the assessment,
versus from people who have experieced back-channel bad-mouthing
my others.
being the laughing stock of the IETF.
Cheryl, no one is laughing. I guarantee it.
D/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25991;
12 May 93 16:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25878;
12 May 93 16:09 EDT
Received: from nic.cerf.net by CNRI.Reston.VA.US id aa25151; 12 May 93 16:09 EDT
Received: by nic.cerf.net (4.1/CERFnet-1.0) id AA07408; Wed, 12 May 93 13:13:54 PDT
Date: Wed, 12 May 1993 13:10:02 -0700 (PDT)
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
X-Orig-Sender: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Reply-To: Chuck Wegrzyn <wegrzyn at nic.cerf.net>
Subject: Re: Do we need an Ombdusman? re: Censorship...
To: Cheryl Krupczak <cheryl at cc.gatech.edu>
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <199305121821.AA05632 at terminus.cc.gatech.edu>
Message-Id: <Pine.3.05.9305121358.D5689-a100000 at nic.cerf.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Status: O
I too agree with Cheryl. Find people to blame and castigate seems silly.
There is a problem and it should be fixed; if we need martyrs every time
we will get no were and accomplish nothing.
What we should be looking at is the underlying problems. If there have
been "mumblings" of intimidation, then let us fix it. Don't let us try to
find out who they are, that seems like blaming a rape on the victim.
What we need to do is remember that this is a COOPERATIVE network of
individuals. Each with opinions, many marchers to different drummers. We
should be able to see that neutrality and politeness make the world a
better place. That rudeness and believes that only one way is right do
nothing other than make us smaller, more insignificant people.
Chuck Wegrzyn.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28138;
12 May 93 17:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28132;
12 May 93 17:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29163;
12 May 93 17:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28116;
12 May 93 17:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28107;
12 May 93 17:37 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa29145; 12 May 93 17:37 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Wed, 12 May 93 14:37:48 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA01127; Wed, 12 May 93 14:38:02 PDT
Date: Wed, 12 May 93 14:38:02 PDT
Message-Id: <9305122138.AA01127 at mel-brooks.empirical.com>
To: kasten at ftp.com
Subject: Yes, everybody has some conflict. Was Re: Conflict of interest rules?
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
> I would like to point out that many of us have financial interests in
> the companies we work for (or worked for in the past), and that these
> companies all derive their financial well-being from the net so, if I
> were on the IESG, would I have to recuse my self from any discussions
> Would Karl have to recuse himself from all discussions on SNMP (don't
> your products use SNMP Karl?)
Yes, under these rules, I would almost certainly have to be
disqualified, if not on the financial basis then on the fact that I
have been a major part of the vociferous but loyal opposition (some
will take issue with the word "loyal".)
But what you say is true. There is no clear line between much
conflict and less conflict. But even if we can't define the line, we
all recognize the limiting cases when we see them. That is true of
much in life, and we get by.
Now, here's how one might refine the rules to resolve the problem.
Basically let's start with the principal that people are to be
trusted and believed unless there is evidence to the contrary.
Thus, I would leave it to any given member of the IESG to recognize
that a potential conflict may exist. In addition, it is possible
that others could suggest that such a conflict may exist.
In this situation, the member would be able to make his/her own
determination whether the conflict was, in fact, sufficient. However
the arguments and reasoning would have to be made public. At that
point, the decision would be presented to the chair of the iesg or
ietf who would accept or reject it.
Thus, to be more concrete, assume I were somehow to decide or vote on
whether SNMPv2 were to be promoted up the standards ladder.
Well, I wasn't a major proponent (and if you read the record, I have
been a loud commentator, but not a major opponent), I wasn't
chairman, nor was I editor. (In fact, my name isn't even listed in
the RFC's as a contributor or member of the WG.)
I no longer have any financial interest in Epilogue Technology. But
I do use SNMP in my products. I will be getting SNMPv2 at no
additional cost except the cost of incorporating it, which won't be
cheap because of the memory squeeze. (It is exactly the memory
squeeze issue which is causing me to ask so many questions whether we
really need all the V2 features.) I probabably could gain an
unmeasurable, but probably rather small, gain by a delay in V2. On
the other hand, these V2 issues are distracting me from getting the
real products I want to build. So, I may incurr an unmeasurable long
term loss if the standard is delayed.
Overall, my opinion is that my level of conflict is relatively small.
However, since it is clearly borderline, I personally, would go
beyond the rules and ask the working group/mailing list for their
opinion whether that constituted a disqualifying conflict.
I think this process would have to occur whenever a substantial
matter arose because the balancing of the conflicts will vary from
situation to situation.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01401;
12 May 93 23:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01397;
12 May 93 23:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07709;
12 May 93 23:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01387;
12 May 93 23:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01383;
12 May 93 23:26 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa07704; 12 May 93 23:26 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA21693; Wed, 12 May 93 20:26:20 PDT
Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1)
id AA05478; Wed, 12 May 93 04:27:34 PDT
Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1)
id AA18679; Wed, 12 May 93 04:27:30 PDT
Date: Wed, 12 May 93 04:27:30 PDT
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Hinden <Bob.Hinden at eng.sun.com>
Message-Id: <9305121127.AA18679 at bigriver.Eng.Sun.COM>
To: karl at empirical.com
Cc: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
In-Reply-To: <9305120342.AA00352 at mel-brooks.empirical.com>
Subject: re: Conflict of interest rules?
content-length: 802
Status: O
Karl,
The problem I see with a set of rules like this is that it will eliminate
the people who know the most about a topic from its discussion. For some
topics, there might not even be a quorum. I think the community is best
served by knowledgeable IESG members who are involved in the work. They
should have opinions on important topics. If we were to eliminate this
from the IESG, there wouldn't be much content left. I don't think we
want bureaucrats.
I think a better approach is for IESG members to state their conflicts(s)
up front. Most are obvious and are easy to deal with. For example I
work for Sun. I chair the IPoverATM working group and am a active member
of the SIP and IPAE working groups. None of this is a secret and when I
speak in the IESG it is taken into account.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01905;
12 May 93 23:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01791;
12 May 93 23:40 EDT
Received: from pobox.synoptics.com by CNRI.Reston.VA.US id aa08078;
12 May 93 23:40 EDT
Received: from donatello (donatello.synoptics.com) by synoptics.com (4.1/SMI-4.1)
id AA04972; Wed, 12 May 93 20:40:04 PDT
Received: by donatello (4.1/2.0N)
id AA04639; Wed, 12 May 93 20:40:03 PDT
Message-Id: <9305130340.AA04639 at donatello>
Date: Wed, 12 May 93 20:40:03 PDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Andrew Bierman <abierman at synoptics.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
Status: O
I've been reluctant to respond to this volatile thread, but here goes:
Making sure the process is fair is not only the "right" thing to do,
it's required by law...
Consider a 1980 case in the state of New York--
Hydrolevel Corporation vs. The American Society of Mechanical Engineers,
in which Hydrolevel sued ASME for conspiring to restrain compitition
and was awarded $7.5 million in damages. (I think this bankrupted
ASME.)
Apparently, a Hydrolevel proposal for a standard for the Boiler and
Pressure Vessel Code was dismissed without getting the same level
of consideration as other proposals. The judge found ASME liable
for the loss of revenue that Hydrolevel supposedly was denied
due to the actions of the ASME working group. A subsequent appeal
by ASME was denied.
My point is that the decisions made in IETF working groups can affect
the prosperity of the commercial entities involved. We better be
damn sure that the playing field is level.
It is probably unrealistic to expect WG chairs to be completely
neutral in the outcome of their groups, but it is not unreasonable
to expect the AD and above to be completely impartial when
overseeing each WG. That means no financial interest whatsoever in the
outcome of any WG in his/her area. This may also be unrealistic,
but I don't see any other way to insure impartiality.
Karl has made a specific proposal for "fairness guidelines". I think
it should be taken seriously.
--andy;
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02763;
13 May 93 4:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02690;
13 May 93 3:54 EDT
Received: from mitsou.inria.fr by CNRI.Reston.VA.US id aa02479;
13 May 93 3:54 EDT
Received: by mitsou.inria.fr
(5.65c/IDA-1.2.8) id AA13958; Thu, 13 May 1993 09:58:10 +0200
Message-Id: <199305130758.AA13958 at mitsou.inria.fr>
To: Andrew Bierman <abierman at synoptics.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
In-Reply-To: Your message of "Wed, 12 May 93 20:40:03 PDT."
<9305130340.AA04639 at donatello>
Date: Thu, 13 May 93 09:58:09 +0200
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Christian Huitema <Christian.Huitema at sophia.inria.fr>
Status: O
Andrew,
The case you cite (Hydrolevel Corporation vs. The American Society of
Mechanical Engineers) was precisely taken into consideration in the
formalization of "The Internet Standards Process". RFC 1310 is currently
pending revision for alignment with the "new world order", but the section on
"Conflict Resolution and Appeals" precisely try to devise a conflict
resolution mechanism and make sure that everybody gets a fair hearing. A
number of people, and in particular Vint Cerf and Lyman Chapin, took great
care in the drafting of such rules.
There are indeed many cases of conflicts that may appear, and RFC-1310
list 3 broad categories:
- lack of adequate discussion within a working group,
- technical inadequacy of an Internet proposed or draft standard,
- reasonable difference in technical approach.
IETF participants should indeed try first to resolve their conflicts
within the working group. Should this fail, they can place a complaint to
the area director. Should the area director be unable to resolve the conflict,
then the case should be brought to the IAB, which will either:
- attempt to determine the actual nature and extent of discussion that took
place within the working Group, based upon the working Group's written
record and upon comments of other working Group members,
- develop an independent assessment and then if this assessment demonstrate
a "technical inadequacy" recommend that the IESG and working Group
re-consider an alternate technical choice.
- encourage the "minority members" of the working group to create their own
group and develop an alternative approach -- letting then "the market"
rather than "the process" choose.
Indeed, such complaints should be substantiated. Vague comments like "he
ridiculed me in public" or "he is such a bully" make poor cases. The
"Hydrolevel Corporation vs. The American Society of Mechanical Engineers" case
was very well substantiated -- the society had elaborated a standard that
effectively ruled out of the market the design elaborated by "Hydrolevel
Corporation", without being able to prove that this design was effectively
inadequate. Complaints should be something like "the proposed standard does
not support option foo that is essential to the operation of my product, and
my attempts to voice that opinion in the WG were not taken seriously in
consideration", or "the proposed standard incorporates algorithm A which was
proven incorrect by professor X in his communication to the Foobar Society".
Note that, in the new world order, there is also a procedure to remove
somebody from office -- Marshall Rose was precisely one of the persons that
requested such a procedure during the Poised discussions. But that is not part
of the processing of standard. And, here also, you better have a precise and
documented complaint!
Christian Huitema
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04027;
13 May 93 8:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03958;
13 May 93 8:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07909;
13 May 93 8:04 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03952;
13 May 93 8:04 EDT
To: Christian Huitema <Christian.Huitema at sophia.inria.fr>
cc: Andrew Bierman <abierman at synoptics.com>, ietf at CNRI.Reston.VA.US
Subject: Re: Do we need an Ombdusman? re: Censorship...
In-reply-to: Your message of "Thu, 13 May 93 09:58:09 +0200."
<199305130758.AA13958 at mitsou.inria.fr>
Date: Thu, 13 May 93 08:04:04 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9305130804.aa03952 at IETF.CNRI.Reston.VA.US>
Status: O
Christian,
thank you for a helpful summary. The Society is interested in
assuring that the standards procedures are demonstrably fair
and that provision has been made to deal with legitimate and
documentable complaints. Constructive suggestions for
improvement will be taken seriously.
Vint
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08136;
13 May 93 9:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11703;
13 May 93 9:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08026;
13 May 93 9:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07882;
13 May 93 9:32 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: sip at caldera.usc.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-sip-discovery-01.txt
Date: Thu, 13 May 93 09:32:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305130932.aa07882 at IETF.CNRI.Reston.VA.US>
Status: O
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Simple Internet Protocol
Working Group of the IETF.
Title : SIP System Discovery
Author(s) : W. Simpson
Filename : draft-ietf-sip-discovery-01.txt
Pages : 22
This document specifies ICMP messages for the identification and
location of adjacent SIP systems. This is intended to replace ARP,
ICMP Router Advertisement, ICMP Redirect, ICMP Information, ICMP Mask,
and OSPF Hello in the SIP environment. There are also elements of the
OSI ES-IS and IS-IS Hello.
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-sip-discovery-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-sip-discovery-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-sip-discovery-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-sip-discovery-01.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 aa14979;
13 May 93 10:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14878;
13 May 93 10:30 EDT
Received: from [134.9.48.4] by CNRI.Reston.VA.US id aa14228; 13 May 93 10:30 EDT
Received: from framsparc.ocf.llnl.gov.ocf by ocfmail.ocf.llnl.gov (4.1/SMI-4.0)
id AA01266; Thu, 13 May 93 07:30:54 PDT
Received: by framsparc.ocf.llnl.gov.ocf (4.1/SMI-4.1)
id AA19945; Thu, 13 May 93 07:30:48 PDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Mark Boolootian <booloo at framsparc.ocf.llnl.gov>
Message-Id: <9305131430.AA19945 at framsparc.ocf.llnl.gov.ocf>
Subject: CCITT Dissolved? (fwd)
To: ietf at CNRI.Reston.VA.US
Date: Thu, 13 May 1993 07:30:48 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL17]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 666
Status: O
The following message appeared on the telecom mailing list. Does anyone
have any idea if this is true?
>From: rdippold at qualcomm.com (Ron "Asbestos" Dippold)
>Subject: CCITT Dissolved?
>Organization: Qualcomm, Inc., San Diego, CA
>Date: Wed, 12 May 1993 21:10:14 GMT
>
>
>According to several sources at communications firms (mostly modem),
>the CCITT is gone. The standards have been inherited by the
>International Telephone Union, Telecommunications Standards Sector
>(ITU-TSS).
>
>a) Is this true?
>b) Why?
>c) Who is this ITU-TSS?
>d) What does this do to Recommendataions in progress (or new ones)?
>
>I'm particularly interested in Group XVII and V.fast.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15402;
13 May 93 10:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15263;
13 May 93 10:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14947;
13 May 93 10:45 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15256;
13 May 93 10:45 EDT
To: Mark Boolootian <booloo at framsparc.ocf.llnl.gov>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: CCITT Dissolved? (fwd)
In-reply-to: Your message of "Thu, 13 May 93 07:30:48 PDT."
<9305131430.AA19945 at framsparc.ocf.llnl.gov.ocf>
Date: Thu, 13 May 93 10:45:25 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9305131045.aa15256 at IETF.CNRI.Reston.VA.US>
Status: O
CCITT was part of ITU. ITU re-organized its standards
making structure and renamed it Telecommunications Standards
Sector, ITU-TSS. The same people are still involved and the
working groups mostly survived.
Vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15965;
13 May 93 11:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15960;
13 May 93 11:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15732;
13 May 93 11:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15945;
13 May 93 10:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15941;
13 May 93 10:59 EDT
Received: from OERV01.er.doe.gov by CNRI.Reston.VA.US id aa15708;
13 May 93 10:59 EDT
Received: by er.doe.gov (5.57/OER-V1.0)
id AA01607; Thu, 13 May 93 06:07:45 -0400
Date: Thu, 13 May 93 06:07:45 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Hitchcock <hitchcoc at oerv01.er.doe.gov>
Message-Id: <9305131007.AA01607 at er.doe.gov>
To: cheryl at cc.gatech.edu, dcrocker at mordor.stanford.edu
Subject: Re: Do we need an Ombdusman? re: Censorship...
Cc: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
Status: O
Before starting the following disclaimer is important:
I am not a member of the SNMP wg and nothing I say should
be taken to mean that everything that's happened there is
clear of conflict of interest, greed, overly large ego's,...
The first thing to remember is that the Internet is a large operational, multi-
vendor, multitechnology family of interconnected networks. Having standards which enable a vendor to write code which has a reasonable chance of interoperating
with all the other parts of the network places a very strong constraint on
the standards themselves... for example the ISO-way of adding options to
reslove political and other problems is simply not viable. As has been said
several times before this was all much simpler when this was a small research
effort and no one stood to make any serious money from these products.
Conflict of interest is inevitable... most ISO wg's have editors who are there TO PROTECT THE FINANCIAL interest of their employer.
However, note that there are some built in safeguards. First, the way
in which a vendor makes money from a product is by producing it as inexpensively
as possible and selling it to the largest number of people. Thus, while there
is some advantage to having your own ongoing development become the basis for
a standard in terms of reducing your time to market and development cost there is
also a real advantage to having as many other folks implement whatever so you
can interface with them and expand your market.
Much of the work of the IETF goes on over E-mail which is well known to
lack some of the things which moderate other forms of human interaction this
means that responses are more extreme (flaming) than they might be
otherwise.
The IETF is a self selected group of network researchers and engineers...
This community tends to be blunt. These folks are not lawyers, marketeers,
investment bankers, social workers...
As someone who has followed this activity for a while I would like to propose
the following principles.
1) As Sir Thomas Moore said (Just before Henry VIII chopped his head off)
the maxim of the law is "qui tacit consentirit, " he who is silent
consents. A corollary to this is that to my knowledge no one has ever
been fatally injured by E-mail 2) Standards which are so closely aligned with some particular point
of view that they take a long time to become widely implemented don't
let anyone expand their market or make any money.
3) The goal of allowing real people to connect their equipment to the net
and actually have it interoperate with other equipment means that real
choices need to be made and all paths cannot be accomodated.
4) The best way to make money is to increae volume and expand the market!
DanHitchcock
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16899;
13 May 93 11:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16786;
13 May 93 11:19 EDT
Received: from jazz.concert.net by CNRI.Reston.VA.US id aa16473;
13 May 93 11:19 EDT
Received: by jazz.concert.net (5.59/tas-concert/8-12-92)
id AA09493; Thu, 13 May 93 11:19:31 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Fengmin Gong <gong at concert.net>
Message-Id: <9305131519.AA09493 at jazz.concert.net>
Subject: Re: CCITT Dissolved? (fwd)
To: Mark Boolootian <booloo at framsparc.ocf.llnl.gov>
Date: Thu, 13 May 1993 11:19:31 -0400 (EDT)
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9305131430.AA19945 at framsparc.ocf.llnl.gov.ocf> from "Mark Boolootian" at May 13, 93 07:30:48 am
X-Mailer: ELM [version 2.4 PL20]
Content-Type: text
Content-Length: 1153
Status: O
Mark Boolootian wrote in a previous message:
>
>
>The following message appeared on the telecom mailing list. Does anyone
>have any idea if this is true?
>
>
>>From: rdippold at qualcomm.com (Ron "Asbestos" Dippold)
>>Subject: CCITT Dissolved?
>>Organization: Qualcomm, Inc., San Diego, CA
>>Date: Wed, 12 May 1993 21:10:14 GMT
>>
>>
>>According to several sources at communications firms (mostly modem),
>>the CCITT is gone. The standards have been inherited by the
>>International Telephone Union, Telecommunications Standards Sector
>>(ITU-TSS).
>>
>>a) Is this true?
>>b) Why?
>>c) Who is this ITU-TSS?
>>d) What does this do to Recommendataions in progress (or new ones)?
>>
>>I'm particularly interested in Group XVII and V.fast.
>
Yes, I heard from Ed Elleson of IBM that some IBM representatives
were at ITU-TSS meeting last week in Geneva. My understanding is
that none of the standard activities will be affected, only the
name of the body has changed.
I don't know why they changed it.
Fengmin
--
Fengmin Gong E-mail: gong at concert.net
Network Research Engineer Phone: 919 248-9214
MCNC Center for Communications FAX: 919 248-1405
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18885;
13 May 93 12:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18825;
13 May 93 12:32 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa19162;
13 May 93 12:32 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA19537; Thu, 13 May 93 12:32:49 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA00827; Thu, 13 May 93 12:34:28 EDT
Message-Id: <9305131634.AA00827 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: Mark Boolootian <booloo at framsparc.ocf.llnl.gov>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: CCITT Dissolved? (fwd)
In-Reply-To: Your message of "Thu, 13 May 93 07:30:48 PDT."
<9305131430.AA19945 at framsparc.ocf.llnl.gov.ocf>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 May 93 12:34:28 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
Status: O
Where on earth did they get enough acid?
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19087;
13 May 93 12:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19053;
13 May 93 12:45 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa19557; 13 May 93 12:45 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Thu, 13 May 93 09:45:23 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA01668; Thu, 13 May 93 09:45:38 PDT
Date: Thu, 13 May 93 09:45:38 PDT
Message-Id: <9305131645.AA01668 at mel-brooks.empirical.com>
To: Christian.Huitema at sophia.inria.fr
Subject: Re: Do we need an Ombdusman? re: Censorship...
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: abierman at synoptics.com, ietf at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
> There are indeed many cases of conflicts that may appear, and RFC-1310
> list 3 broad categories:
>
> - lack of adequate discussion within a working group,
The point which I have been trying to make is this: people have been
so abused, or have observed so much abuse over a long period, that
they have simply determined that participation in a WG (whether in
person or on a mailing list) or would be, at best, a waste of their
time and, at worst, potentially subjecting themselves to ridicule and
intimidation aimed at them personally.
I have collected numerous testimonials from individuals attesting to
this fact. (You all saw the note from Vince Fuller.) But after
trying to present those quietly, it appears that such are
automatically discounted and discarded.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20152;
13 May 93 13:21 EDT
Received: from gatekeeper.nsc.com by IETF.CNRI.Reston.VA.US id aa20118;
13 May 93 13:18 EDT
Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP;
id AA24062 for ietf at ietf.nri.reston.va.us; Thu, 13 May 93 10:19:08 -0700
Received: from berlioz.nsc.com by nsc.nsc.com (5.61/1.34) with SMTP
id AA17400 for ietf at ietf.nri.reston.va.us; Thu, 13 May 93 10:19:32 -0700
Received: from laplace.nsc.com by berlioz.nsc.com (4.1/SMI-4.1)
id AA08396; Thu, 13 May 93 10:18:54 PDT
Date: Thu, 13 May 93 10:18:54 PDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Chung-Lin Dai <chunglin at berlioz.nsc.com>
Message-Id: <9305131718.AA08396 at berlioz.nsc.com>
To: ietf at ietf.nri.reston.va.us
Subject: request infor about July's IETF meeting
Cc: chunglin at berlioz.nsc.com
Status: O
Hi,
I apologize if this message shouldn't be directed to you. If that
is the case, I would much appreciate if you can give me an idea where
I should turn to for help.
I heard about the 27th IETF meeting is going to be held in this July.
I am planning to go. Unfortunatly, I don't have much information about
the meeting (agenda, specific dates, place, etc). So, let me know if
you can help me out on this. Thanks!
+-chung National Semiconductor
(408)721-4286
chunglin at berlioz.nsc.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20772;
13 May 93 13:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20719;
13 May 93 13:42 EDT
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa22405;
13 May 93 13:42 EDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA15094; Thu, 13 May 93 10:43:15 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA13014; Thu, 13 May 93 10:43:08 -0700
Date: Thu, 13 May 1993 10:21:06 -0700 (PDT)
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: Do we need an Ombdusman? re: Censorship...
To: ietf at CNRI.Reston.VA.US
In-Reply-To: <9305131645.AA01668 at mel-brooks.empirical.com>
Message-Id: <MailManager.737313666.11642.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
There is a standards working group in which the egos of all concerned are
carefully stoked, so that no one can fear ridicule and intimidation aimed at
them personally. No matter how absurd or inane the idea, or how much it
favors one vendor to the detriment of all others, each and ever idea will be
given careful consideration and, whenever possible, it will be incorporated
into the final standard.
That standards working group is ISO.
IETF is for people who desire to get useful work done, and are not reduced to
tears they didn't get their own way.
In my nearly 20 years with IETF and NWG before it, I've won many hard-fought
battles and I've lost many. A few times, a battle that I lost because it was
``me against the world'' got revived and won, when subsequent technical
experience proved me right and ``everyone else wrong''. IETF consists of
people who are honest enough to admit their mistakes and embrace concepts that
they had bitterly denounced only a few days earlier. There is also very
little ``I told you so.''
The process has delivered results. By and large, most people leave a
completed effort with warm and fuzzy feelings about the work. Nobody ever
leaves with what they wanted coming in.
I find it difficult to comprehend that in a world of corporate takeovers,
Strategic Lawsuits Against Public Participation, ethnic cleansing, & etc. that
one can nurse such a fragile ego that is so easily shatted by an e-mail
message.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21532;
13 May 93 14:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23674;
13 May 93 14:10 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21507;
13 May 93 14:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21455;
13 May 93 14:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23519;
13 May 93 14:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21448;
13 May 93 14:07 EDT
To: IETF-Announce: ;
Cc: if-mib at thumper.bellcore.com
Subject: WG ACTION: Interfaces MIB (ifmib)
Date: Thu, 13 May 93 14:07:51 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil <gvaudre at CNRI.Reston.VA.US>
Message-ID: <9305131407.aa21448 at IETF.CNRI.Reston.VA.US>
Status: OR
A new Working Group has been formed in the Network Management Area of
the IETF. For more information, please contact the working group
chairman or the area director.
Greg Vaudreuil
IESG Secretary
Interfaces MIB (ifmib)
----------------------
Charter
Chair(s):
Ted Brunner <tob at thumper.bellcore.com>
Network Management Area Director(s)
Marshall Rose <mrose.iesg at dbc.mtview.ca.us>
Mailing lists:
General Discussion:if-mib at thumper.bellcore.com
To Subscribe: if-mib-request at thumper.bellcore.com
Archive:
Description of Working Group:
The Interfaces MIB working group is chartered to accomplish two tasks.
First, to develop a collection of managed objects which model the
relation between different entities in the datalink and physical
layers. The working group will explore different modeling
approaches in order to develop a collection of objects which is
both correct in the modeling sense and has an acceptable impact (if
any) on the interfaces table from MIB-II and all media MIB modules
on the standards track or under development by a working group.
The objects defined by the working group will be consistent with
the SNMP framework.
Second, to prepare a recommendation to the IESG evaluating RFCs
1229 (the if-extensions MIB), 1231 (the token-ring MIB), 1304 (the
SMDS MIB), and 1398 (the ether-like MIB) with respect to the
standards track.
The recommendation will document implementation, interoperability,
and deployment experience. If this experiences suggests that
changes should be made to the documents, new drafts may be
prepared.
For RFCs 1229, 1231, and 1304, the recommendation will report one
of four outcomes for each RFC: that the RFC should be advanced
from proposed to draft status, without changes (if no problems are
found); that a draft prepared by the working group, should replace
the RFC, and be designated a draft standard (if only minor changes
are made); that a draft prepared by the working group, should
replace the RFC, and be designated a proposed standard (if major
changes or feature enhancements are made); or, that the RFC should
be designated as historic (if this technology is problematic).
For RFC 1398, the recommendation will report one of five outcomes:
that the RFC should be advanced from draft to full status, without
changes (if no problems are found); that a draft prepared by the
working group, should replace the RFC, and be designated a full
standard (if only editorial changes are made); that a draft
prepared by the working group, should replace the RFCs, and be
designated a draft standard (if only minor changes are made); that
a draft prepared by the working group, should replace the RFC, and
be designated a proposed standard (if major changes or feature
enhancements are made); or, that the RFC should be designated as
historic (if this technology is problematic).
Goals and Milestones:
Jul 93 Post the if layering document as an Internet Draft.
Sep 93 Submit the if layering document to the IESG for consideration as a
Proposed Standard.
Sep 93 Issue a call for implementation and operations experience with RFCs
1229, 1231, 1304, and 1398.
Oct 93 Evaluate experience and if necessary post revised MIBs as Internet
Drafts.
Dec 93 Submit recommendations on the various MIBs to the IESG.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22083;
13 May 93 14:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24298;
13 May 93 14:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22068;
13 May 93 14:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21988;
13 May 93 14:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24096;
13 May 93 14:21 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21979;
13 May 93 14:21 EDT
To: IETF-Announce: ;
Cc: snadlcmib at apertus.com
Subject: WG ACTION: SNA DLC Services MIB (snadlc)
Date: Thu, 13 May 93 14:21:52 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil <gvaudre at CNRI.Reston.VA.US>
Message-ID: <9305131421.aa21979 at IETF.CNRI.Reston.VA.US>
Status: O
A new working group has been formed in the Network Management Area of
the IETF. Please contact the network management area director or the
working group chairman for more information.
Greg Vaudreuil
IESG Secretary
SNA DLC Services MIB (snadlc)
-----------------------------
Charter
Chair(s):
Jeff Hilgeman <jeffh at apertus.com>
Network Management Area Director(s)
Marshall Rose <mrose at dbc.mtview.ca.us>
Area Advisor
Ken Key <key at cs.utk.edu>
Mailing lists:
General Discussion:snadlcmib at apertus.com
To Subscribe: snadlcmib-request at apertus.com
Archive:
Description of Working Group:
The SNA DLC working group is chartered to define a set of managed
objects for the SDLC and LLC-2 data link controls for SNA
networks. These objects will be the minimum necessary to provide
the ability to monitor and control those devices, providing fault,
configuration, and performance management, and will be consistent
with the SNMP framework and existing SNMP standards.
The working group will consider existing enterprise-specific MIB modules
that define objects which support management of these devices. The
working group may choose to consider any work done by the IEEE in the
area of managed object definition for LLC-2. It will also make sure
that its work is aligned with the SNA NAU Services MIB WG, due to the
close relationship between the devices being worked on by the two
groups.
The working group recognizes that managed objects for other SNA data
link controls and related components (e.g., QLLC, Syetem/370 Channel,
DLS (Data Link Switching) and ESCON) may need to be identified in the
future. These objects are out of scope for the current charter;
however, once the working group completes its charter, a new charter
identifying some or all of these components may be considered.
Goals and Milestones:
Apr 93 Mailing List discussion of vendor proprietary MIBs.
Jul 93 Post an Internet Draft of the SNA DLC MIB.
Dec 93 Submit the SNA DLC MIB to the IESG for consideration as a Proposed
Standard.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22155;
13 May 93 14:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22098;
13 May 93 14:25 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa24435;
13 May 93 14:25 EDT
Received: from LOCALHOST by black-ice.cc.vt.edu (AIX 3.2/UCB 5.64/4.03)
id AA16135; Thu, 13 May 1993 14:25:41 -0400
Message-Id: <9305131825.AA16135 at black-ice.cc.vt.edu>
To: Simon E Spero <ses at tipper.oit.unc.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: CCITT Dissolved? (fwd)
In-Reply-To: Your message of "Thu, 13 May 1993 12:34:28 EDT."
<9305131634.AA00827 at tipper>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 May 1993 14:25:41 +22312049
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
Status: O
On Thu, 13 May 1993 12:34:28 EDT, Simon E Spero said:
> Where on earth did they get enough acid?
set mode/humor/full
Same place they always have - I'm sure plenty of acid was
consumed in the creation of X.400(84)....
Determining the requisite pH and other chemical properties of
said acid is left as an excersize for the practicing chemical
engineers....
set mode/humor/off
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22401;
13 May 93 14:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24855;
13 May 93 14:32 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22385;
13 May 93 14:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22354;
13 May 93 14:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24772;
13 May 93 14:30 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa22348;
13 May 93 14:30 EDT
To: IETF-Announce: ;
Cc: snanaumib at thumper.bellcore.com
Subject: WG ACTION: SNA NAU Services MIB (snanau)
Date: Thu, 13 May 93 14:30:49 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil <gvaudre at CNRI.Reston.VA.US>
Message-ID: <9305131430.aa22348 at IETF.CNRI.Reston.VA.US>
Status: O
A new working group has formed in the Network Management Area. Please
contact the working group chair or the network management area
director for more information.
Greg Vaudreuil
IESG Secretary
SNA NAU Services MIB (snanau)
-----------------------------
Charter
Chair(s):
Zbigniew Kielczewski <zbig at eicon.qc.ca>
Deirde Kostick <dck2 at sabre.bellcore.com>
Network Management Area Director(s)
Marshall Rose <mrose at dbc.mtview.ca.us>
Area Advisor
David Perkins <dperkins at synoptics.com>
Mailing lists:
General Discussion:snanaumib at thumper.bellcore.com
To Subscribe: snanaumib-request at thumper.bellcore.com
Archive:
Description of Working Group:
The SNA NAU Services MIB Working Group is chartered to define a
set of managed objects for PU type 2.0, and LU type 1, 2, and 3
devices for SNA networks. These objects will be the minimum
necessary to provide the ability to monitor and control those
devices, providing fault, configuration, and performance
management, and will be consistent with the SNMP framework and
existing SNMP standards.
The working group will consider existing enterprise-specific MIB
modules that define objects which support management of these
devices. It will also make sure that its work is aligned with the
SNA DLC Services MIB WG, due to the close relationship between the
devices being worked on by the two groups.
The working group recognizes that managed objects for other
components (e.g., PU Type 4, PU Type 5, LU Types 1, 3, 4, 6.2
(APPC), APPN EN, APPN NN and APPI) may need to be identified in
the future. These objects are out of scope for the current
charter; however, once the working group completes its charter, a
new charter identifying some or all of these components may be
considered.
Goals and Milestones:
Jul 93 Begin discussion of proprietary MIBS and develop a single proposal.
Oct 93 Post an Internet Draft of the SNA NAU Services MIB.
Dec 93 Submit the SNA NAU Services MIB to the IESG fo consideration as a
Proposed Standard.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22875;
13 May 93 14:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22832;
13 May 93 14:42 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa25300; 13 May 93 14:42 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Thu, 13 May 93 11:42:24 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA01926; Thu, 13 May 93 11:42:39 PDT
Date: Thu, 13 May 93 11:42:39 PDT
Message-Id: <9305131842.AA01926 at mel-brooks.empirical.com>
To: MRC at panda.com
Subject: You gotta be Macho Man. Was Re: Do we need ...
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: ietf at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
Status: O
> IETF is for people who desire to get useful work done, and are not reduced to
> tears they didn't get their own way.
I'm rather bothered by this "you gotta be macho and take the abuse"
excuse.
What has been occuring must not be dismissed as "mere theatrics" or
posturing, but taken for what it is, brutal bullying.
Personal abuse, and ridicule must not be tolerated.
--karl--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29834;
13 May 93 15:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28483;
13 May 93 15:22 EDT
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa26690;
13 May 93 15:22 EDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA15158; Thu, 13 May 93 12:22:42 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA13279; Thu, 13 May 93 12:22:35 -0700
Date: Thu, 13 May 1993 11:53:53 -0700 (PDT)
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: re: You gotta be Macho Man. Was Re: Do we need ...
To: karl at empirical.com
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9305131842.AA01926 at mel-brooks.empirical.com>
Message-Id: <MailManager.737319233.11642.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: O
On Thu, 13 May 93 11:42:39 PDT, karl at empirical.com wrote:
> I'm rather bothered by this "you gotta be macho and take the abuse"
> excuse.
>
> What has been occuring must not be dismissed as "mere theatrics" or
> posturing, but taken for what it is, brutal bullying.
>
> Personal abuse, and ridicule must not be tolerated.
Dear Karl,
I consider this response abusive, bullying, and containing personal ridicule.
Rather than making any thoughtful commentary, the response attacks a strawman
that in no way represents my statements or my position. I particularly object
to emotional and context-free language such as ``you gotta be macho.''
I will make my own Politically Incorrect speech, thank you. I do not need it
shoved in my mouth.
Under such circumstances, I don't think that any further discussion between us
on this subject would be productive. In the interest of possible further work
together, I will consider that this exchange did not take place.
You may wish to consider a similar strategy. It is much easier on one's state
of mind than carrying a long-term grudge.
Regards,
-- Mark --
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05339;
13 May 93 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05292;
13 May 93 16:16 EDT
Received: from chipcom.com by CNRI.Reston.VA.US id aa28932; 13 May 93 16:16 EDT
Received: from teach.stealth ([151.104.9.58]) by chipcom.com (4.1/SMI-4.0)
id AA06500; Thu, 13 May 93 16:15:25 EDT
Received: by teach.stealth (4.1/SMI-4.1)
id AA13790; Thu, 13 May 93 16:17:32 EDT
Date: Thu, 13 May 93 16:17:32 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Horowitz <witz at chipcom.com>
Message-Id: <9305132017.AA13790 at teach.stealth>
To: karl at empirical.com, MRC at panda.com
Subject: re: You gotta be Macho Man. Was Re: Do we need ...
Cc: ietf at CNRI.Reston.VA.US
Can we PLEASE take the discussion off of the mailing list ?
Karl has a serious topic that he (and others) want addressed.
Can the powers that be please suggest the appropriate channels with
which Karl's concerns can be resolved ?
All of this mail discussion is not progressing to a solution.
-- Steve
Entertaining or not, it does get out of hand.
> From ietf-request at ietf.nri.reston.va.us Thu May 13 15:55:12 1993
> Return-Path: <ietf-request at ietf.nri.reston.va.us>
> Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by chipcom.com (4.1/SMI-4.0)
> id AA06334; Thu, 13 May 93 15:55:09 EDT
> Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28701;
> 13 May 93 15:23 EDT
> Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28483;
> 13 May 93 15:22 EDT
> Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa26690;
> 13 May 93 15:22 EDT
> Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
> (NX5.67c/UW-NDC Revision: 2.27.MRC ) id AA15158; Thu, 13 May 93 12:22:42 -0700
> Received: from localhost by Ikkoku-Kan.Panda.COM
> (NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA13279; Thu, 13 May 93 12:22:35 -0700
> Date: Thu, 13 May 1993 11:53:53 -0700 (PDT)
> Sender: ietf-request at IETF.CNRI.Reston.VA.US
> From: Mark Crispin <MRC at panda.com>
> X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
> Subject: re: You gotta be Macho Man. Was Re: Do we need ...
> To: karl at empirical.com
> Cc: ietf at CNRI.Reston.VA.US
> In-Reply-To: <9305131842.AA01926 at mel-brooks.empirical.com>
> Message-Id: <MailManager.737319233.11642.mrc at Ikkoku-Kan.Panda.COM>
> Mime-Version: 1.0
> Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII>
> Content-Length: 1110
> X-Lines: 31
> Status: RO
>
> On Thu, 13 May 93 11:42:39 PDT, karl at empirical.com wrote:
> > I'm rather bothered by this "you gotta be macho and take the abuse"
> > excuse.
> >
> > What has been occuring must not be dismissed as "mere theatrics" or
> > posturing, but taken for what it is, brutal bullying.
> >
> > Personal abuse, and ridicule must not be tolerated.
>
> Dear Karl,
>
> I consider this response abusive, bullying, and containing personal ridicule.
>
> Rather than making any thoughtful commentary, the response attacks a strawman
> that in no way represents my statements or my position. I particularly object
> to emotional and context-free language such as ``you gotta be macho.''
>
> I will make my own Politically Incorrect speech, thank you. I do not need it
> shoved in my mouth.
>
> Under such circumstances, I don't think that any further discussion between us
> on this subject would be productive. In the interest of possible further work
> together, I will consider that this exchange did not take place.
>
> You may wish to consider a similar strategy. It is much easier on one's state
> of mind than carrying a long-term grudge.
>
> Regards,
>
> -- Mark --
>
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06605;
13 May 93 16:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06317;
13 May 93 16:46 EDT
Received: from boa.gsfc.nasa.gov by CNRI.Reston.VA.US id aa00119;
13 May 93 16:46 EDT
Received: by boa.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3)
id AA28668; Thu, 13 May 1993 16:46:21 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Dick desJardins <desjardi at boa.gsfc.nasa.gov>
Message-Id: <9305132046.AA28668 at boa.gsfc.nasa.gov>
Subject: Re: Do we need an Ombudsman?
To: ietf at CNRI.Reston.VA.US
Date: Thu, 13 May 1993 16:46:20 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1206
Mark Crispin wrote:
There is a standards working group in which the egos of all concerned
are
carefully stoked, so that no one can fear ridicule and intimidation
aimed at
them personally. No matter how absurd or inane the idea, or how much it
favors one vendor to the detriment of all others, each and ever idea
will be
given careful consideration and, whenever possible, it will be
incorporated
into the final standard.
That standards working group is ISO.
IETF is for people who desire to get useful work done, and are not
reduced to
tears they didn't get their own way.
---
This is not a valid characterization of ISO.
This is the type of hyperbolic characterization
on email distribution lists that people are referring to
when they use words like "ridicule". Surely this statement
ridicules ISO, and ridicules the people who work within
the ISO framework.
Anybody who would now want to say anything supportive
about ISO would be reduced to flinging back something
equally hyperbolic about IETF.
Here's what ISO can learn from IETF: Online discussion,
online drafts, working implementations before standards
are approved.
Here's what IETF can learn from ISO: Civility.
Dick desJardins
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab09925;
13 May 93 17:45 EDT
Received: from runix.runit.sintef.no by IETF.CNRI.Reston.VA.US id aa09884;
13 May 93 17:43 EDT
Received: from runit.sintef.no by runix.runit.sintef.no with SMTP (PP)
id <16804-0 at runix.runit.sintef.no>; Thu, 13 May 1993 23:42:48 +0200
Received: from localhost by spurv (4.1/Runit-cl-1.0) id AA20774;
Thu, 13 May 93 23:42:45 +0200
Message-Id: <9305132142.AA20774 at spurv>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: Variable length subnet masks
Date: Thu, 13 May 1993 23:42:44 +0200
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Havard Eidnes <Havard.Eidnes at runit.sintef.no>
Hi,
I am currently writing a paper which partly concerns itself with how to
increase the utilization of the address space an organization has been
allocated. One technique which could be of utility in this regard is the
use of variable length subnet masks. However, when I try to inspect the
more or less authoritative sources of information on this (RFCs and the
internet draft archives) I find that this has apparently not been specified
thoroughly anywhere. In the OSPFv2 spec, I find approximately one and a
half paragraph on this issue, finishing up with:
"There are many possible ways of dividing up a class A, B, and C
network into variable sized subnets. The precise procedure for
doing so is beyond the scope of this specification."
The other place I could find more-or-less substantial mention of this
technique, is in the current draft of the "Requirements for IP Routers",
which classifies the use of variable length subnet masks as "an open issue
in the IP architecture." This section of the draft concludes with:
"Proper use of variable width subnet masks is the subject of a
(hopefully) forthcoming Internet Draft originating outside of the
Router Requirements WG."
Can anyone point me to an ongoing work to fulfill the hope in this
paragraph, or has this not been started yet?
Anyway, it appears that on a short term I am left with a shortage of
supporting documentation, and I thought I should therefore get a sanity
check of my perception of variable length subnet masks (VLSMs). Please
redirect me if this is an inappropriate forum for taking up this in.
I have the following comments which I would like reactions to:
- RFC 1122 (Internet Requirements for Hosts -- Communication Layers),
section 3.2.1.3 seems to imply that a network can only have a single
subnet mask -- clearly, if we are to support VLSMs, this section will
have to be revised or superseded.
RFC 1122 also specifies that subnets "0" and "-1" are unusable for
assigning to networks. I think that this rule will have to be slightly
modified to fit with use of VLSMs. If you eg. subnet a class C network
with subnet mask 0xffffff80, you can use subnet "0" under this subnet
mask and subnet that further, with eg. 0xfffffff0. However, for a given
subnet mask, you cannot use the subnets having "0" or "-1" in the subnet
field and assign these to networks using that subnet mask. So under
0xfffffff0, the networks identified with y.y.y.0 and y.y.y.240 could not
be used, but the rest could, even though some of them would come out as
subnet "0" or subnet "-1" under the subnet mask 0xffffff80 in use for
other parts of the subnetted network.
- RFC 1247 (OSPF version 2 specification) says that "Subnet masks must be
assigned so that the best match for any IP destination is unambiguous."
I am somewhat uncertain of under what circumstances one can assign
subnet masks and create an unambiguous "best match." Does this
situation only occur when one allow non-contiguous subnet masks? If
this is true, I would suggest that non-contiguous subnet masks be
depreciated. The reasons for this would be ease of understanding (this
is difficult enough as it is!), and that dual IS-IS would have problems
supporting non-contiguous subnet masks (?since it uses address/prefix-
length instead of address/mask??? -- sorry, I do not know dual IS-IS all
that well).
Other than this, VLSMs should be fairly straight-forward and uncontro-
versial, right? 1/2 :-)
Please include me in any replies, since I'm not on the IETF list.
- Havard
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11063;
13 May 93 18:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11018;
13 May 93 18:25 EDT
Received: from uu5.psi.com by CNRI.Reston.VA.US id aa04407; 13 May 93 18:25 EDT
Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
id AA12551 for ; Thu, 13 May 93 18:11:45 -0400
Date: Thu, 13 May 93 17:39:49 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Chip Sharp 6424 <hhs at teleoscom.com>
Received: by teleoscom.com (4.1/3.2.083191-Teleos Communications Inc.)
id AA15980; Thu, 13 May 93 17:39:49 EDT
Message-Id: <9305132139.AA15980 at teleoscom.com>
To: booloo at framsparc.ocf.llnl.gov
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: Mark Boolootian's message of Thu, 13 May 1993 07:30:48 -0700 (PDT) <9305131430.AA19945 at framsparc.ocf.llnl.gov.ocf>
Subject: CCITT Dissolved? (fwd)
CCITT has not "gone" as an organization. They have basically
consolidated the standards setting activities of the CCIR and CCITT
into a new organization called the Telecommunications Standards Sector
(TSS). As far as I know, the Study Groups will remain the same.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13951;
13 May 93 23:15 EDT
Received: from GINGER.LCS.MIT.EDU by IETF.CNRI.Reston.VA.US id aa13915;
13 May 93 23:12 EDT
Received: by ginger.lcs.mit.edu
id AA13398; Thu, 13 May 93 23:12:30 -0400
Date: Thu, 13 May 93 23:12:30 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9305140312.AA13398 at ginger.lcs.mit.edu>
To: Havard.Eidnes at runit.sintef.no, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Variable length subnet masks
Cc: jnc at ginger.lcs.mit.edu
"Proper use of variable width subnet masks is the subject of a
(hopefully) forthcoming Internet Draft originating outside of the
Router Requirements WG."
Can anyone point me to an ongoing work to fulfill the hope in this
paragraph, or has this not been started yet?
Ah, yes, specification of variable width subnet masks. A pet peeve of mine for
many years. (You can all throw rocks at me for not getting this dealt with
when I was AD; sorreee.... There wasn't major interest on anyone's part to do
it, which was part of the problem.)
There was a BoF on the topic of variable width subnet masks at the 21st IETF
(Atlanta, July/August 1992). The results of that Bof are in the Proceedings,
pages 104-106. It more or less answers your questions. (Any volunteers to
turn those notes into an RFC? Nudge, nudge? :-)
RFC 1122 also specifies that subnets "0" and "-1" are unusable for
assigning to networks. I think that this rule will have to be slightly
modified to fit with use of VLSMs.
I don't think I understand your point here completely, partially because
you've picked a pretty pathological case. Your "top-level" subnet mask is only
one bit, so there are no "not 0 and not -1" subnets.
Let's use the terminology of the Proceedings, with subnet numbers A, B.x and
B.y; A and B are differing values of a high fixed part of the rest field, and
x and y are different values of a lower fixed part of the rest field. Are you
asking "is it OK for the bit value of B to be 0 or -1"? (This is distinct from
allowing A to to 0 or -1, which I don't think we should allow.)
Since we decided not to have B.* appear as a contiguous object, but to have
all B.* appear as individual entities, it should be OK to have B assume those
values, as long no B.x is 0 or -1. This would be good, since when splitting
up small pieces of the address space (like a class C), holding out all 0 and
-1 values takes up a lot of the available room.
On the other hand, OSPF (at least, other IGP's may as well, and I don't know
about CIDR) does allow aggregation of routing entries; i.e. if all B.* are in
an OSPF level 1 area, it is possible to only advertise B outside that area.
Doing so could produce routing advertisments of what *appear* to be subnets
with 0 or -1 values.
There thus isn't a clear answer. I don't think there is any good architectural
reason to disallow use of 0 and -1 subnet numbers, and it does consume space
to no good end, since we don't use the "all subnets" concept. However, I'm not
sure how much deployed code would get confused if they saw those used as
subnet numbers.
My guess would thus be to a) disallow it for now, b) decide if we want to punt
on the concept of "all-subnets", and if so c) mark it as "obsolescent", so
we can eventually d) allow them as valid subnet numbers.
I am somewhat uncertain of under what circumstances one can assign
subnet masks and create an unambiguous "best match." Does this
situation only occur when one allow non-contiguous subnet masks?
I think so.
I would suggest that non-contiguous subnet masks be depreciated.
The BoF concurred.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19265;
14 May 93 1:41 EDT
Received: from GINGER.LCS.MIT.EDU by IETF.CNRI.Reston.VA.US id aa19229;
14 May 93 1:38 EDT
Received: by ginger.lcs.mit.edu
id AA13851; Fri, 14 May 93 01:38:55 -0400
Date: Fri, 14 May 93 01:38:55 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9305140538.AA13851 at ginger.lcs.mit.edu>
To: Havard.Eidnes at runit.sintef.no, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Variable length subnet masks
Cc: jnc at ginger.lcs.mit.edu
at the 21st IETF (Atlanta, July/August 1992)
Ooops. Make that "1991". My, how time flies when you are having fun!
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00500;
14 May 93 2:53 EDT
Received: from lager.cisco.com by IETF.CNRI.Reston.VA.US id aa00428;
14 May 93 2:47 EDT
Received: by lager.cisco.com; Thu, 13 May 1993 23:31:05 -0700
Date: Thu, 13 May 1993 23:31:05 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Tony Li <tli at cisco.com>
Message-Id: <199305140631.AA09954 at lager.cisco.com>
To: Havard Eidnes <Havard.Eidnes at runit.sintef.no>
Cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Variable length subnet masks
Havard,
First, I would like to point you at draft-fuller-cidr-strategy-01.txt.
In it, we outline a strategy for using variable length subnet masks
for optimizing the use of address space.
I have the following comments which I would like reactions to:
- RFC 1122 (Internet Requirements for Hosts -- Communication Layers),
section 3.2.1.3 seems to imply that a network can only have a single
subnet mask -- clearly, if we are to support VLSMs, this section will
have to be revised or superseded.
I reread that section and did not find that implication at all. Could
you please point it out? We should definitely fix it.
RFC 1122 also specifies that subnets "0" and "-1" are unusable for
assigning to networks. I think that this rule will have to be slightly
modified to fit with use of VLSMs. If you eg. subnet a class C network
with subnet mask 0xffffff80, you can use subnet "0" under this subnet
mask and subnet that further, with eg. 0xfffffff0. However, for a given
subnet mask, you cannot use the subnets having "0" or "-1" in the subnet
field and assign these to networks using that subnet mask. So under
0xfffffff0, the networks identified with y.y.y.0 and y.y.y.240 could not
be used, but the rest could, even though some of them would come out as
subnet "0" or subnet "-1" under the subnet mask 0xffffff80 in use for
other parts of the subnetted network.
Actually, I think the text here does EXACTLY what you want. It says:
IP addresses are not permitted to have the value 0 or -1 for
any of the <Host-number>, <Network-number>, or <Subnet-
number> fields (except in the special cases listed above).
This implies that each of these fields will be at least two
bits long.
Note that I would not construe the size of the fields to be fixed by
this description and I don't think anything in this section attempts
to imply that. Perhaps we should clarify this somehow by pointing out
that variable length subnet masks is NOT creating subnets of subnets,
and that you must refer only to the subnet mask of the local media
when interpreting an address.
- RFC 1247 (OSPF version 2 specification) says that "Subnet masks must be
assigned so that the best match for any IP destination is unambiguous."
I am somewhat uncertain of under what circumstances one can assign
subnet masks and create an unambiguous "best match." Does this
situation only occur when one allow non-contiguous subnet masks? If
this is true, I would suggest that non-contiguous subnet masks be
depreciated. The reasons for this would be ease of understanding (this
is difficult enough as it is!), and that dual IS-IS would have problems
supporting non-contiguous subnet masks (?since it uses address/prefix-
length instead of address/mask??? -- sorry, I do not know dual IS-IS all
that well).
Non-contiguous masks were deprecated at a BOF a while ago, and we're
waiting for someone to write it up and for it to become an RFC. In
some sense, this is irrelevant, as most users find variable length
subnet masks to be a sufficient intellectual challenge.
Other than this, VLSMs should be fairly straight-forward and uncontro-
versial, right? 1/2 :-)
I believe so... unless you want to discuss interaction between
mask-less and mask-full routing protocols. ;-)
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01118;
14 May 93 4:43 EDT
Received: from munnari.OZ.AU by IETF.CNRI.Reston.VA.US id aa01076;
14 May 93 4:39 EDT
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
id AA13284; Fri, 14 May 1993 18:37:31 +1000 (from kre at munnari.OZ.AU)
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: Havard.Eidnes at runit.sintef.no, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Variable length subnet masks
In-Reply-To: Your message of "Thu, 13 May 1993 23:12:30 -0400."
<9305140312.AA13398 at ginger.lcs.mit.edu>
Date: Fri, 14 May 1993 18:37:23 +1000
Message-Id: <10921.737368643 at munnari.OZ.AU>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Robert Elz <kre at munnari.oz.au>
Date: Thu, 13 May 93 23:12:30 -0400
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-ID: <9305140312.AA13398 at ginger.lcs.mit.edu>
There was a BoF on the topic of variable width subnet masks at the 21st IETF
(Atlanta, July/August 1992). The results of that Bof are in the Proceedings,
pages 104-106. It more or less answers your questions. (Any volunteers to
turn those notes into an RFC? Nudge, nudge? :-)
At the BOF (91), I volunteered myself for this, which I suspect
that Noel well knows, I just haven't managed to find the time to
actually do it yet - however I will do it, so you can treat
me as volunteering again, if you're willing - I'll try not to
let it take another two years...
Nothing in the draft will be at odds with anything that either
Noel or Tony have said in their messages on this subject.
kre
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03949;
14 May 93 9:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09456;
14 May 93 9:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03928;
14 May 93 9:47 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03851;
14 May 93 9:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: frftc at nsco.network.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-frnetmib-fr-00.txt
Date: Fri, 14 May 93 09:41:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305140941.aa03851 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 Frame Relay Service MIB
Working Group of the IETF.
Title : Definitions of Managed Objects for Frame Relay
Service
Author(s) : T. Cox
Filename : draft-ietf-frnetmib-fr-00.txt
Pages : 39
This memo defines an extension to the Management Information Base
(MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing the Frame
Relay Service. This memo does not specify a standard for the
Internet community.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-frnetmib-fr-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-frnetmib-fr-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-frnetmib-fr-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-frnetmib-fr-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 aa06635;
14 May 93 12:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06627;
14 May 93 12:39 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa14259;
14 May 93 12:39 EDT
Received: by bitsy.MIT.EDU
id AA03183; Fri, 14 May 93 12:24:24 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA03177; Fri, 14 May 93 12:24:22 EDT
Received: from m2xenix.psg.com by MIT.EDU with SMTP
id AA11717; Fri, 14 May 93 12:24:20 EDT
Received: by m2xenix.psg.com (/\==/\ Smail3.1.25.1 #25.4)
id <m0nu2YK-00047jC at m2xenix.psg.com>; Fri, 14 May 93 09:24 PDT
Message-Id: <m0nu2YK-00047jC at m2xenix.psg.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Beauchemin <bobb at psg.com>
To: cat-ietf at mit.edu
Subject: Subscribe
Date: Fri May 14 09:24:08 1993
I would like to subscribe to the mailing list of parties interested on
the Generic Security Service API (GSSAPI). Please subscribe me, or if this
is not the appropriate list, please point me at the right one.
THANKS,
Bob Beauchemin
OCSG
bobb at agora.rain.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06687;
14 May 93 12:42 EDT
Received: from runix.runit.sintef.no by IETF.CNRI.Reston.VA.US id aa06643;
14 May 93 12:39 EDT
Received: from runit.sintef.no by runix.runit.sintef.no with SMTP (PP)
id <00243-0 at runix.runit.sintef.no>; Fri, 14 May 1993 18:40:12 +0200
Received: from localhost by spurv (4.1/Runit-cl-1.0) id AA08234;
Fri, 14 May 93 18:40:08 +0200
Message-Id: <9305141640.AA08234 at spurv>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Variable length subnet masks
In-Reply-To: Your message of "Thu, 13 May 1993 23:12:30 EDT." <9305140312.AA13398 at ginger.lcs.mit.edu>
Date: Fri, 14 May 1993 18:40:06 +0200
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Havard Eidnes <Havard.Eidnes at runit.sintef.no>
Noel Chiappa wrote:
> There was a BoF on the topic of variable width subnet masks at the 21st IETF
> (Atlanta, July/August 1992). The results of that Bof are in the Proceedings,
> pages 104-106.
It is also available via ftp in
ietf.cnri.reston.va.us:ietf/jul91/subnetsbof-minutes-91jul.txt
for those (like I) who don't have a paper copy of the proceedings of the
IETF meetings.
> I don't think I understand your point here completely, partially because
> you've picked a pretty pathological case. Your "top-level" subnet mask is
> only one bit, so there are no "not 0 and not -1" subnets.
Ah, yes. I realized this shortly after sending the message, but I do not
have an "unsend" command available, unfortunately. :-) I meant to use a
two-bit wide subnet mask in the example, thus substituting "c" for "8".
> Let's use the terminology of the Proceedings, with subnet numbers A, B.x
> and B.y; A and B are differing values of a high fixed part of the rest
> field, and x and y are different values of a lower fixed part of the rest
> field. Are you asking "is it OK for the bit value of B to be 0 or -1"?
Yes, thank you, this is indeed what I was asking, and there seems to be
consensus to permit this (no?).
> (This is distinct from allowing A to be 0 or -1, which I don't think we
> should allow.)
Right, agree.
> On the other hand, OSPF (at least, other IGP's may as well, and I don't know
> about CIDR) does allow aggregation of routing entries; i.e. if all B.* are in
> an OSPF level 1 area, it is possible to only advertise B outside that area.
> Doing so could produce routing advertisments of what *appear* to be subnets
> with 0 or -1 values.
> ...
> Since we decided not to have B.* appear as a contiguous object, but to
> have all B.* appear as individual entities, it should be OK to have B
> assume those values, as long no B.x is 0 or -1. This would be good, since
> when splitting up small pieces of the address space (like a class C),
> holding out all 0 and -1 values takes up a lot of the available room.
Well, these routing protocols (OSPF and other newer IGPs and CIDR-modified
EGPs) shouldn't really care about the values in the subnet field, since
these protocols essentially try to do away with the whole concept of class,
and thus with "subnet", and instead represent all routing table entries
(conceptually) as a combination of an address and a mask. Surely the fact
that the masked portion of the address of a routing table entry has
multiple trailing zeroes (or ones) should be of little or no concern.
Furthermore, since the aggregation of all B.*'s into B where B may be 0 or
-1 will only be visible to routers which do not have a direct connection to
any of the B.*'s (won't this always be the case? I think it will for OSPF),
there should be no need to disallow these aggregated routing table entries.
You only need to care about broadcasts if you have a direct connection to
the target network of a broadcast.
> There thus isn't a clear answer. ... My guess would thus be to a)
> disallow it for now...
Does this only concern the question of whether it is legal to aggregate B.*
into B where B is either 0 or -1? In that case I'm not sure I like the
conclusion -- first this is getting too complicated, and second, this will
(as you say) waste a lot of address space. If the above comments concern
themselves with use of B.* where B may be 0 or -1 under the A mask, I think
this is a too strict interpretation of the current state of affairs.
> b) decide if we want to punt on the concept of "all-subnets"...
The current draft of the router requirements draft makes a suggestion in
this direction (configuration option to support all-subnets broadcast).
But maybe we should go further?
To finish off, let me pick a quote over from another mailing list by a
well-known proponent of OSPF (sorry, no prize for guessing who :-):
Down with class! Up with route egalitarianism! :-)
I tend to agree.
- Havard
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07203;
14 May 93 13:19 EDT
Received: from runix.runit.sintef.no by IETF.CNRI.Reston.VA.US id aa07169;
14 May 93 13:17 EDT
Received: from runit.sintef.no by runix.runit.sintef.no with SMTP (PP)
id <01519-0 at runix.runit.sintef.no>; Fri, 14 May 1993 19:17:52 +0200
Received: from localhost by spurv (4.1/Runit-cl-1.0) id AA08661;
Fri, 14 May 93 19:17:49 +0200
Message-Id: <9305141717.AA08661 at spurv>
To: Tony Li <tli at cisco.com>
Cc: ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Variable length subnet masks
In-Reply-To: Your message of "Thu, 13 May 1993 23:31:05 PDT." <199305140631.AA09954 at lager.cisco.com>
Date: Fri, 14 May 1993 19:17:46 +0200
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Havard Eidnes <Havard.Eidnes at runit.sintef.no>
> First, I would like to point you at draft-fuller-cidr-strategy-01.txt.
> In it, we outline a strategy for using variable length subnet masks
> for optimizing the use of address space.
Yes, I am aware of that draft (I've already read it), but the way I perceive
it, it doesn't talk much about using variable-sized network masks inside an
AS or network, at least not to the level of detail needed to get me to fully
understand what the legal address assignments are. So call me dense! :-)
> - RFC 1122 (Internet Requirements for Hosts -- Communication Layers),
> section 3.2.1.3 seems to imply that a network can only have a single
> subnet mask -- clearly, if we are to support VLSMs, this section will
> have to be revised or superseded.
>
> I reread that section and did not find that implication at all. Could
> you please point it out? We should definitely fix it.
Hmm. I reread it now for the n'th time, and I agree, there isn't really
anything there to fix. Oh, well.
> Note that I would not construe the size of the fields to be fixed by
> this description and I don't think anything in this section attempts
> to imply that. Perhaps we should clarify this somehow by pointing out
> that variable length subnet masks is NOT creating subnets of subnets,
> and that you must refer only to the subnet mask of the local media
> when interpreting an address.
Agreed. Wording to this effect should perhaps go into the VLSMs to-be RFC?
> Non-contiguous masks were deprecated at a BOF a while ago, and we're
> waiting for someone to write it up and for it to become an RFC. In
> some sense, this is irrelevant, as most users find variable length
> subnet masks to be a sufficient intellectual challenge.
Exactly my perception as well.
> Other than this, VLSMs should be fairly straight-forward and uncontro-
> versial, right? 1/2 :-)
>
> I believe so... unless you want to discuss interaction between
> mask-less and mask-full routing protocols. ;-)
:-) Ok, I'll leave that out of the discussion for now.
- Havard
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11637;
14 May 93 18:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11576;
14 May 93 18:18 EDT
Received: from ds.internic.net by CNRI.Reston.VA.US id aa24334;
14 May 93 18:18 EDT
Received: by ds.internic.net (4.1/SMI-4.1)
id AA02437; Fri, 14 May 93 18:19:07 EDT
Date: Fri, 14 May 93 18:19:07 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: DDBS Admin <admin at ds.internic.net>
Message-Id: <9305142219.AA02437 at ds.internic.net>
To: ietf at CNRI.Reston.VA.US
Subject: Gopher Announcement
Cc: admin at ds.internic.net
We apologize for the multiple copies you may receive because of cross
posting.
InterNIC Directory and Database Services
The InterNIC Directory and Database Services Collection of Resource
Listings, Internet Documents such as RFCs, FYIs, STDs, and Internet
Drafts, and Publically Accessible Databases are now available via
Gopher. All our collections are waisindexed and can be searched from
the Gopher menu.
To access the InterNIC Gopher Servers, please connect to "internic.net"
port 70.
------------------------------------------------------------------------
InterNIC Directory and Database Services Administrator
email: admin at ds.internic.net
phone: (908) 688-6587
------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14471;
14 May 93 23:36 EDT
Received: from thumper.bellcore.com by IETF.CNRI.Reston.VA.US id aa14433;
14 May 93 23:33 EDT
Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7)
id <AA13308> for ietf at IETF.CNRI.Reston.VA.US; Fri, 14 May 93 23:34:03 EDT
Received: by tsuchiya.bellcore.com (4.1/4.7)
id <AA16553> for jnc at ginger.lcs.mit.edu; Fri, 14 May 93 23:34:01 EDT
Date: Fri, 14 May 93 23:34:01 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Paul Francis (formerly Paul Tsuchiya" <francis at thumper.bellcore.com>
MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US
Message-Id: <9305150334.AA16553 at tsuchiya.bellcore.com>
To: Havard.Eidnes at runit.sintef.no, ietf at IETF.CNRI.Reston.VA.US,
jnc at ginger.lcs.mit.edu
Subject: Re: Variable length subnet masks
> I am somewhat uncertain of under what circumstances one can assign
> subnet masks and create an unambiguous "best match." Does this
> situation only occur when one allow non-contiguous subnet masks?
>
> I think so.
>
I'm not suggesting that non-contiguous masks be used here, I just
want to make a point of clarification.
That is, if a scheme such as kampai is used to assign the masks,
then even with non-contiguous you still get unambiguous best match....
PX
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10423;
16 May 93 9:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10392;
16 May 93 8:58 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa02223;
16 May 93 8:58 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA02789; Sun, 16 May 93 12:57:21 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Sun, 16 May 1993 13:31:17 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille at isode.com>
Message-Id: <1355.737551877 at isode.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <199305070851.AA02600 at mitsou.inria.fr>
Subject: Re: LDAP Comments
Christian,
>From: Christian Huitema <Christian.Huitema at sophia.inria.fr>
>To: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
>Subject: Re: LDAP Comments
>Date: Fri, 07 May 93 10:51:58 +0200
>Just a note on the discussion of LIST + READ vs SEARCH. First, two facts:
>
> (1) It is true that READ can be emulated by "search base object with
> Filter: object-class present". It would not make much difference on
> the DSA side, needs almost the same number of data base accesses and
> exactly the same number of chainings. The same is also true for the
> COMPARE operation, setting the filter to the required comparison.
>
> (2) It is FALSE to believe that LIST can be equated by "search one level
> with Filter: object-class present, return only names". The LIST results
> can be returned with minimal duplications -- only need to know the RDNs
> of the subordinate entries. The SEARCH result need to access the content
> of the entry, hence require to either duplicate all subordinate entries
> on the DSA holding the base name or to chain the SEARCH request to all
> DSAs holding subordinate information. Or to recognize the particular
> kind of "match all" filters, and convert search to list in the DSA -- but
> that is hardly a standard feature!
You are wrong on 2). The operations are equivalent, and cane
therefore be implemented with the same level of efficiency.
There are two aspcts relating to the ommission of list. The first is
that it can be emulated. The second is that whilst most early DUAs
use list, most "second generation" DUAs do not. The reason is that
the list operation returns only the RDN. This is just not enough
information to return to the user. At the very least, you need
object class information, and usually enough other information so that
you get a neat one line per entry display.
Given the goals of LDAP, it seemed to be a useful simplification to
omit LIST.
>
>By the way. LDAP is been advanced to "proposed internet standard" status by
>the IESG, but the discussion seem to indicate that there is no formal
>agreement in the working group. Do you expect that there will be serious
>modifications and that the protocol should be resubmitted?
There was extensive discussion, and a formal agreement at the OSI-DS WG.
I do not expect serious modification, although I could see some
small upgrades as:
1) There are more independent implementations
2) More experience in general
3) X/.500(93) starts to appear
Certainly no changes which would require resetting the standards
process.
If there is real demand, it would be trivial to add a list operation,
or a note indicating that the server should implement the search
equivalent to list by use of the X.500 list operation. I see no need
to make this change.
>
>Christian Huitema
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10635;
16 May 93 9:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10610;
16 May 93 9:20 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa02658;
16 May 93 9:20 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA02920; Sun, 16 May 93 09:20:03 -0400
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Sun, 16 May 1993 16:13:34 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: pays at faugeres.inria.fr
Message-Id: <737554414.16188.0-faugeres.inria.fr* at MHS>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: DUA implementors guidelines
As a result of the email discussion about LDAP, it was suggested
by Tim Howes that a separate document be envisaged:
Guidelines for X.500 "clients" implementation.
This proposal was done within the LDAP context, with 2 goals
in mind:
- how to make efficient use of the LDAP set of available operations
- avoid implementation dependencies.
This issue was discussed during the WG-NAP meeting in Trondheim,
and I suggested that the goal should have to be larger.
I am really convinced that this guidelines document has to be prepared
for X.500 "clients" in general and not limited to LDAP, because
our experience with several different implementations has shown
that many existing X.500 clients are still designed without
a clear view on the impact of the algorithm used on
- specific impementations
- specific structuring and distribution of the DIT over
different DSAs
Of course a specific section will have to be devoted to LDAP
and its set of operation, but this will only have to cover
what is specific to LDAP (not too much in my mind).
The last message from Steve Kille, when talking about 1rst
and 2nd generation DUA, highlights the evolution (gained
from experience) of X.500 clients algorithms (BTW this TERM
seems to me more appropriate than DUA for this purpose).
It is really time to share and write down our experiences
in that area, because it does not only have a great impact
on "clients" design, but also -- and probably even more
important- a very high impact on the design of the servers (DSA)
themselves.
As our goal is "success" and "deployement" of X.500, it is of the highest
importance that, as soon as possible, our community is provided
with an efficient X.500 infrastructure (ie. clients + servers).
To reach this goal it is mandatory that the
- Client designers/implementors are well aware of the servers
behaviour
- Server designers/implementors are well aware of the clients
behaviour and requirements.
I don't know how this concretely could be handled, but given
the importance and consequences I suggest this activity
be started as soon as possible and associates all "players"
ie. at least osi-ds, wg-nap, and paradise interworking group.
Steve, any suggestion?
BTW: Tim Howes will give a lecture here and participate
to a working meeting (May 27th and 28th) and we have
planned to start discussion about this.
Thus some contribution might be expected as an early outcome.
Steve, would it be possible to have this item be part
of the OSI-DS agenda in Amsterdam?
best regards,
-- PAP
~h
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12545;
16 May 93 15:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12511;
16 May 93 15:35 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa10074;
16 May 93 15:34 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA04318; Sun, 16 May 93 19:34:08 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Sun, 16 May 1993 23:19:07 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: C.B.Stathopoulos at ics.forth.gr
Message-Id: <9305161719.AA00802 at danae.csi.forth.gr>
Organization: FORTH - ICS, P.O.Box 1385, Heraklio, Crete, Greece 711 10 tel:
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Using X.500 to determine presentationAddresses
Peter et al,
My apologies for such a late reply.
The open issue I see here is the naming of the machines.
During the last month I have spent many hours thinking of an
architecture for a location transparency mechanism that
will be using the X.500 to retrieve presentationAddresses
of management agents in a management platform.
Roughly speaking I want to be able to identify the
presentationAddress of a management agent (e.g. SNMP
agent) that contains management information for some
network element. (By the term "network element" I mean
equipment attached to the network (e.g. a router,
a gateway, a workstation) ).
Clearly, what I need first is a global, unique and stable
naming schema for registering network elements in the DIT.
Bearing in mind the "Charting Networks in the Directory"
(OSI-DS-37) draft document I thought that maybe a refinement
of the mechenism described there could be used for globally
naming network elements within the Directory.
Of course the above naming schema results in machine names
that are far away from user-friendly.
As Steve writes:
>The decisions on naming machines should be primarily dictated by
> 1) Reasonable names for the machines
> 2) A naming structure which permits effective allocation.
>I would expect that some key services would be named at the ARC level,
>and the majority of machines at the departmental or project level
>(i.e., org units within ARC).
I agree with these two points.
But for 2) I was expecting something related to the OSI-DS-37 idea.
What about the "nodes" mentioned there? Are we going to have finally
two places for registering machines (one under the OU level
and the other under the network level)? Don't you think that all kinds
of information about a machine must be gathered in one place?
Although the more "natural" name for a machine under my organizational
unit is e.g. host, csi, forth, gr I would expect a seperate subtree for
the machines within an organization. Although I could have 1,000 people
entries mixed with 1,000 machine entries under the same organizational
unit subtree a more efficient design is needed (that is going to be
transparent to the user, of course).
I think that a "network" subtree under the organizationalUnit level
could be used for registering network elements. This provides also
a uniform view for a machine (= a part of the local network).
With a search operation under the "network" subtree a DUA could find
information about a machine under the OU=ICS,O=FORTH,C=GR when the
given friendly name is host, ics, forth, gr.
I am looking forward to seeing opinions on the above.
Regards,
Costas.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13136;
16 May 93 17:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13114;
16 May 93 17:20 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa12256;
16 May 93 17:20 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA04810; Sun, 16 May 93 17:20:04 -0400
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Sun, 16 May 1993 19:32:19 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "James Hong, W." <jwkhong at csd.uwo.ca>
Message-Id: <9305161932.AA27812 at mccarthy.csd.uwo.ca>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305161719.AA00802 at danae.csi.forth.gr>
Subject: Re: Using X.500 to determine presentationAddresses
>
> Peter et al,
>
> My apologies for such a late reply.
>
> The open issue I see here is the naming of the machines.
> During the last month I have spent many hours thinking of an
> architecture for a location transparency mechanism that
> will be using the X.500 to retrieve presentationAddresses
> of management agents in a management platform.
>
> Roughly speaking I want to be able to identify the
> presentationAddress of a management agent (e.g. SNMP
> agent) that contains management information for some
> network element. (By the term "network element" I mean
> equipment attached to the network (e.g. a router,
> a gateway, a workstation) ).
> Clearly, what I need first is a global, unique and stable
> naming schema for registering network elements in the DIT.
>
> Bearing in mind the "Charting Networks in the Directory"
> (OSI-DS-37) draft document I thought that maybe a refinement
> of the mechenism described there could be used for globally
> naming network elements within the Directory.
> Of course the above naming schema results in machine names
> that are far away from user-friendly.
>
> As Steve writes:
> >The decisions on naming machines should be primarily dictated by
> > 1) Reasonable names for the machines
> > 2) A naming structure which permits effective allocation.
> >I would expect that some key services would be named at the ARC level,
> >and the majority of machines at the departmental or project level
> >(i.e., org units within ARC).
>
> I agree with these two points.
> But for 2) I was expecting something related to the OSI-DS-37 idea.
> What about the "nodes" mentioned there? Are we going to have finally
> two places for registering machines (one under the OU level
> and the other under the network level)? Don't you think that all kinds
> of information about a machine must be gathered in one place?
>
> Although the more "natural" name for a machine under my organizational
> unit is e.g. host, csi, forth, gr I would expect a seperate subtree for
> the machines within an organization. Although I could have 1,000 people
> entries mixed with 1,000 machine entries under the same organizational
> unit subtree a more efficient design is needed (that is going to be
> transparent to the user, of course).
>
> I think that a "network" subtree under the organizationalUnit level
> could be used for registering network elements. This provides also
> a uniform view for a machine (= a part of the local network).
> With a search operation under the "network" subtree a DUA could find
> information about a machine under the OU=ICS,O=FORTH,C=GR when the
> given friendly name is host, ics, forth, gr.
>
> I am looking forward to seeing opinions on the above.
>
> Regards,
> Costas.
We have been investigating the use of X.500 in the Network, Systems and
Applications management frameworks for the last couple of years.
For those who are not aware yet, I would like to refer to our paper that was
presented at the 3rd International Symposium on Integrated Network Management,
San Fransisco, CA, April 1993, pp. 149-160, which discusses our experience of
using the X.500 Directory Service in the network management framework.
I can make the paper available on our ftp server if people are interested.
Let me know please.
Cheers!
James W. Hong
Research Associate / Adjunct Professor
Dept. of Computer Science jwkhong at csd.uwo.ca
Middlesex College
Univ. of Western Ontario Tel: (519) 679-2111 x6906
London, Ontario, N6A-5B7 CANADA Fax: (519) 661-3515
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19907;
17 May 93 4:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19862;
17 May 93 4:21 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa25322;
17 May 93 4:21 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA07924; Mon, 17 May 93 04:20:04 -0400
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Mon, 17 May 1993 09:24:22 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: D F Sadok <D.HadjSadok at cs.ucl.ac.uk>
Message-Id: <9305170726.AA13882 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <2674*.S=mmue.OU=komsys.OU=tik.O=ethz.PRMD=SWITCH.ADMD=ARCOM.C=CH. at MHS>
Subject: Re: Mapping e-mail address to X.500 distinguished names for PEM
>From: Markus Mueller <mmue at ch.ethz.tik.komsys>
>Subject: Re: Mapping e-mail address to X.500 distinguished names for PEM
>Date: Thu, 13 May 1993 20:43:54 +0200
>> The X.500 directory could be one such mechanism. However,
>> one difficulty that I see integrating PEM and X.500 is that the X.500
>> directory hierarchy is based on distinguished names while the e-mail
>> address has a different hierarchy (e.g. Internet Address)
>
>Good idea. Actually the mapping between RFC822 name and distinguished
>name has already been solved in the Thorn / RARE X.500 naming architecture
>proposed by S. Kille at UCL which includes the attribute "RFC822 mailbox".
>You can either read an entry via the distinguished name to get the RFC822
>mailbox name, or search via the RFC822 mailbox name to get the distinguished
>name. By adding a "Certificate" attribute to the naming architecture both
>type of queries will also return that certificate.
>
>Since UCL is also active in the development of secure e-mail I guess that
>their DSA is already supporting certificates.
Yes.
>
>Note, however, that the mapping between RFC822 name and distinguished name
>is not reliable, either because the DSA is not trustworthy or because the
>returned data was tampered with. In the current PEM version this should not
>be a problem since it is based on the Distinguished name only. You may also
>activate the OPTIONALLY SIGNED mechanism on the DSA to prevent tampering
>with the returned data.
>
Within the PASSWORD project we also have implemented authenticated
DUA (Dish, ...) to DSA access. This may be integrated into the
current UCL PEM UA to overcome some of the security problems
you mention.
> Markus Mueller
> FIDES Informatik
> Abteilung IB2
> Badenerstrasse 172
> CH-8004 Zuerich
> Switzerland
>
> SWITCH/ARPA/BITNET : mueller at komsys.tik.ethz.ch
> UUCP : mueller%komsys.tik.ethz.ch at chx400.uucp
> X.400 : S=mueller;OU=tik;O=ethz;P=switch;A=arcom;C=ch
>
> Mail account courtesy of Institut fuer Technische Informatik und
> Kommunikationsnetze, ETH, CH-8092 Zuerich, Switzerland
Jamel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21862;
17 May 93 7:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21818;
17 May 93 7:42 EDT
Received: from world.std.com by CNRI.Reston.VA.US id aa29265; 17 May 93 7:42 EDT
Received: by world.std.com (5.65c/Spike-2.0)
id AA23015; Mon, 17 May 1993 07:42:31 -0400
Date: Mon, 17 May 1993 07:39:36 -0400 (EDT)
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Nicolas J Keller <srcdc at world.std.com>
Subject: Re: CCITT Dissolved? (fwd)
To: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
Cc: Simon E Spero <ses at tipper.oit.unc.edu>, ietf at CNRI.Reston.VA.US
In-Reply-To: <9305131825.AA16135 at black-ice.cc.vt.edu>
Message-Id: <Pine.3.07.9305170734.A22555-a100000 at world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 13 May 1993, Valdis Kletnieks wrote:
> On Thu, 13 May 1993 12:34:28 EDT, Simon E Spero said:
> > Where on earth did they get enough acid?
>
> set mode/humor/full
>
> Same place they always have - I'm sure plenty of acid was
> consumed in the creation of X.400(84)....
>
> Determining the requisite pH and other chemical properties of
> said acid is left as an excersize for the practicing chemical
> engineers....
>
> set mode/humor/off
>
> Valdis Kletnieks
> Computer Systems Engineer
> Virginia Tech
Please,
Sure, X.400 denotes a rather low pH, but let's not frget some X.25, X.21
and a few Vs which denote a PH of 7 (or nearly).
Nicolas Keller
System Resources Corporation
600 Maryland Avenue SW #740
Washington, DC 20024
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22355;
17 May 93 8:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22305;
17 May 93 8:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29895;
17 May 93 8:06 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa22298;
17 May 93 8:05 EDT
To: Steve Horowitz <witz at chipcom.com>
cc: karl at empirical.com, MRC at panda.com, ietf at CNRI.Reston.VA.US
Subject: Re: You gotta be Macho Man. Was Re: Do we need ...
In-reply-to: Your message of "Thu, 13 May 93 16:17:32 EDT."
<9305132017.AA13790 at teach.stealth>
Date: Mon, 17 May 93 08:05:54 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9305170805.aa22298 at IETF.CNRI.Reston.VA.US>
A small suggestion.
Could we try to approach these questions in a concrete way
by taking up specific concerns/complaints and trying to
resolve them within the ietf/iab/isoc framework? RFC1310
is one vehicle through which we can express any procedures
we evolve as we have specific experiences. Though I am no
fan of anarchy, I have a general concern that overspecification
of procedures is a fast track towards ossification (no pun
intended here, honest :-) ).
And a small reminder. One does not need to stab the other
guy on the back to pat your own. In fact, the pat you may
be looking for could have a sharp edge on it...
Vint
p.s. if a separate mailing list is desired, we can set one
up. I agree we seem to exhausted the general list's patience
and interest.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22791;
17 May 93 8:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22686;
17 May 93 8:18 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa00648;
17 May 93 8:18 EDT
Received: by malamud.com (4.1/SMI-4.1/ccg.11.13.92)
id AA03602; Mon, 17 May 93 08:27:55 EDT
Date: Mon, 17 May 93 08:27:55 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at malamud.com>
Message-Id: <9305171227.AA03602 at malamud.com>
To: ietf at CNRI.Reston.VA.US
Subject: NPR meets the Internet
Org: Internet Talk Radio
Station: Internet Multicasting Service
Channel: Internet Town Hall
Program: National Public Radio meets the Internet
Release: May 21, 1993, 2-3PM EDT
Content: Talk of the Nation/Science Friday
On May 21, we will be joining the Internet to National Public
Radio for a special edition of Talk of the Nation/Science Friday.
Host Ira Flatow will field questions from users sitting in front
of computers as well as users sitting next to telephones. Questions
from the Internet will come from videoconferencing tools on the
Multicast Backbone (MBONE) using a gateway provided by Ron Fredrick
and Steve Deering of Xerox PARC.
(If you don't have MBONE connectivity now, you probably won't have it
by Friday. To learn more about the multicast backbone, ftp to isi.edu
and get the file /mbone/faq.txt. If you do have MBONE connectivity,
check SD for a listing for Internet Town Hall.)
In addition to the audio link, we will have two other ways to
participate. First, starting now, you can send mail to ira at radio.com
with your comments and questions. Some of this mail may be read as
part of the show. We encourage you to narrow your your comments to the
subject of the Internet, how it is used, and the future of networking
in the western world.
Second, with the help of Rick Gates, we will be conducting an Internet
Treasure Hunt and reading the results over the air. The purpose of the
hunt is to illustrate the diversity of methods and data available on
the network. The questions will be posted on the network 24 hours
before the show and will be read by Ira Flatow at the beginning of
the show.
Even if you don't participate with a computer for this show, we hope
you will listen to your local National Public Radio affiliate. Guests
will include Carl Malamud, Brewster Kahle, and Tim O'Reilly. For
those of you that have computers but no NPR affiliate, we will tape
the show and send it out as an audio file approximately 48 hours after
it airs.
Participants in the Internet Town Hall include Cornell University,
the National Press Club, the National Science Foundation, O'Reilly &
Associates, Sun Microsystems, WAIS, Inc., Xerox PARC, and many others.
Network connectivity for the Internet Town Hall is provided by UUNET
Technologies.
For information on Internet Talk Radio, write to info at radio.com.
More information on Internet Town Hall will be available shortly.
For a current, partial listing of sites, write to sites at radio.com.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27398;
17 May 93 10:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04179;
17 May 93 10:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27345;
17 May 93 10:58 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa27186;
17 May 93 10:53 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-01.txt
Date: Mon, 17 May 93 10:53:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305171053.aa27186 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-01.txt
Pages : 30
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 must 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-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-meyer-demandrouting-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-meyer-demandrouting-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-meyer-demandrouting-01.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 aa27876;
17 May 93 11:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27731;
17 May 93 11:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id bh04544;
17 May 93 11:06 EDT
Received: from dirtydog.ima.isc.com by IETF.CNRI.Reston.VA.US id aa24818;
17 May 93 9:36 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA09471; Mon, 17 May 93 13:34:35 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Mon, 17 May 1993 17:19:43 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: C.B.Stathopoulos at ics.forth.gr
Message-Id: <9305171119.AA00995 at danae.csi.forth.gr>
Organization: FORTH - ICS, P.O.Box 1385, Heraklio, Crete, Greece 711 10 tel:
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Using X.500 to determine presentationAddresses
James,
> We have been investigating the use of X.500 in the Network, Systems and
>Applications management frameworks for the last couple of years.
>
>For those who are not aware yet, I would like to refer to our paper that was
>presented at the 3rd International Symposium on Integrated Network Management,
>San Fransisco, CA, April 1993, pp. 149-160, which discusses our experience of
>using the X.500 Directory Service in the network management framework.
I got your paper two weeks ago and I have read it. It is really interesting!
But I didn't find a lot of work related to the global naming of the network
elements therein. Ok, I understand that this was not your objective, but
I suppose you have thought about a global naming schema for NEs.
Anyone who deals with such an issue as "Integrating the X.500 in the Network
Management Framework" sooner or later asks for a way to name a NE in the DIT!
Although your prototype Quipu Objects: csdDomain and csdMachine are enough
for your experiment (I have defined my own objects for my prototype, too)
a more standardized schema is needed. Any ideas on such a schema?
Cheers,
Costas.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27896;
17 May 93 11:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27728;
17 May 93 11:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id bf04544;
17 May 93 11:06 EDT
Received: from dirtydog.ima.isc.com by IETF.CNRI.Reston.VA.US id aa24748;
17 May 93 9:34 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA09419; Mon, 17 May 93 13:32:44 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Mon, 17 May 1993 11:01:56 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Kille <S.Kille at isode.com>
Message-Id: <1585.737629316 at isode.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <737554414.16188.0-faugeres.inria.fr* at MHS>
Subject: Re: DUA implementors guidelines
This initiative is a good one, which I'll gladly support. It makes sense to
have the item on the agenda. From experience, this sort of item is not
very useful unless there is a concrete plan to produce a document (i.e.,
someone to do real work....)
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02071;
17 May 93 13:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02063;
17 May 93 13:39 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa10323;
17 May 93 13:39 EDT
Received: by bitsy.MIT.EDU
id AA24423; Mon, 17 May 93 13:21:09 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA24417; Mon, 17 May 93 13:21:04 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA04071; Mon, 17 May 93 13:21:02 EDT
Received: from gza-server.aktis.com by pad-thai.aktis.com (5.67/) with SMTP
id <AA09777 at pad-thai.aktis.com>; Mon, 17 May 93 13:19:32 -0400
Received: by gza-server.aktis.com (4.1/4.7) id AA00524; Mon, 17 May 93 13:18:18 EDT
Message-Id: <9305171718.AA00524 at gza-server.aktis.com>
To: cat-ietf at mit.edu, XoTGsafe at xopen.co.uk
Cc: linn at gza.com
Subject: X/Open Security WG comments re GSS-API
Date: Mon, 17 May 1993 13:18:18 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at gza.com>
CAT fanciers and X/Open Security WG'ers:
I attended a meeting of the X/Open Security Working Group last week.
This is the group, per prior E-mail and meeting discussion, which has
been tracking evolution of GSS-API and currently intends to adopt the
base and C bindings specs into the X/Open standards process when they
reach the status of Proposed Standard RFCs. Two points were made to
me, which I agreed to carry back to the IETF community:
(1) Given observations that many clients are likely to use only
default credentials (rather than explicit cred_handles) in initiating
and accepting security contexts, and that the processes initiating
such clients may wish that they inherit properly-selected credentials,
a primitive of the following form (appreciative acknowledgment to
Piers McMahon for description) would be a useful addition:
- Description of gss_set_default_cred
This API permits a user to indicate which credential is to be
interpreted as the default.
Function definition for gss_set_default_cred:
/* set default for credentials
*/
OM_uint32 gss_set_default_cred
(
gss_cred_id_t cred_handle, /* IN */
OM_uint32* minor_status, /* OUT*/
);
Parameters for gss_set_default_cred:
cred_handle conditional handle for credentials claimed.
cred_handle refers to an authenticated principal.
Supply GSS_C_NO_CREDENTIAL to use default credentials
(which would mean that this call would be non-
functional).
minor_status Mechanism specific status code
Response from gss_set_default_cred (GSS status code)
GSS_S_COMPLETE indicates that the default can be set, and that the
default has been set.
GSS_S_NO_CRED
GSS_S_DEFECTIVE_CREDENTIAL,
GSS_S_CREDENTIALS_EXPIRED
indicates that a default credential can't be set for the reason
specified
Does anyone have comments, pro or con, about the utility of this call,
or of its implementability within end systems of interest?
(2) An observation was made that current ISO usage of the term "seal"
more closely corresponds to the function of GSS_Sign() than to
GSS_Seal(), the term "seal" being used in ISO to describe provision of
integrity without encapsulation or provision for confidentiality. It
was suggested, therefore, that GSS_Sign() be renamed GSS_Seal() to
align the terms, with a new name (GSS_Wrap?) invented and used to
describe the present GSS_Seal(). I thought this realignment in
midstream would be confusing to folks accustomed to the existing
GSS-API usage, but solicit CAT-WG comment on this point as well. If
we elect to rename the per-message routines, this would also be an
opportunity to avoid a connotation others have noted, that GSS_Sign()
suggests by its name a long-term digital signature but that few
mechanisms are likely to realize the function in this fashion.
Thoughts? Given that the current I-Ds are pending submission to the
IESG to be reviewed for advancement to Proposed Standards, I propose
that any changes made relative to these points be targeted for the
next advancement cycle (to Draft Standards) or along with any other
changes which may result from IESG review.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04431;
17 May 93 14:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04419;
17 May 93 14:25 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa12049;
17 May 93 14:25 EDT
Received: by bitsy.MIT.EDU
id AA25114; Mon, 17 May 93 14:18:10 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA25108; Mon, 17 May 93 14:18:08 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA06130; Mon, 17 May 93 14:18:07 EDT
Received: by inet-gw-2.pa.dec.com; id AA04160; Mon, 17 May 93 11:17:59 -0700
Received: by us1rmc.bb.dec.com; id AA08021; Mon, 17 May 93 14:16:05 -0400
Message-Id: <9305171816.AA08021 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Mon, 17 May 93 14:16:06 EDT
Date: Mon, 17 May 93 14:16:06 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 17-May-1993 1354" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Re: X/Open Security WG comments re GSS-API
John,
> (1) Given observations that many clients are likely to use only
> default credentials (rather than explicit cred_handles) in initiating
> and accepting security contexts, and that the processes initiating
> such clients may wish that they inherit properly-selected credentials,
> a primitive of the following form (appreciative acknowledgment to
> Piers McMahon for description) would be a useful addition:
>
> - Description of gss_set_default_cred
>
> This API permits a user to indicate which credential is to be
> interpreted as the default.
There is currently no requirement that the "default credential" should
necessarily mean the same thing to GSSAPI initiator and acceptor. In
particular, in DCE a server may register multiple identities, and a possible
use of the default acceptor credential would be to indicate a willingness to
accept a context under any registered identity (i.e. the acceptor identity is
chosen from the registered set of identities according to the client's token).
If such a call is to be introduced, I'd like to see distinct calls to set
initiator and acceptor default credentials. Or maybe a single call with two
input creds - one to set the init_sec_context default, and one to set the
accept_sec_context default, with GSS_C_NO_CREDENTIAL being allowed for either
parameter to mean "don't change this default". Also, if we're going to allow
defaults to be changed, we should provide a way for them to be restored to
their previous values, so the call should probably provide an (optional)
"previous default" output credential for both initiator and acceptor.
> Function definition for gss_set_default_cred:
>
> /* set default for credentials
> */
> OM_uint32 gss_set_default_cred
> (
> gss_cred_id_t cred_handle, /* IN */
> OM_uint32* minor_status, /* OUT*/
> );
To remain in-keeping with the other routines, minor_status ought to be the
first parameter.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12720;
17 May 93 16:27 EDT
Received: from manta.nosc.mil by IETF.CNRI.Reston.VA.US id aa12607;
17 May 93 16:22 EDT
Received: from ppc-18.nosc.mil by manta.nosc.mil (5.65/1.34)
id AA23374; Mon, 17 May 93 13:22:57 -0700
Date: Mon, 17 May 93 13:22:57 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "James W. Weatherford" <weatherf at manta.nosc.mil>
Message-Id: <9305172022.AA23374 at manta.nosc.mil>
To: IETF at IETF.CNRI.Reston.VA.US
Subject: UNSUBSCRIBE
Please remove me from any and all distribution lists regarding
IETF as soon as possible.
JWW
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12942;
17 May 93 16:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12932;
17 May 93 16:35 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa16909;
17 May 93 16:35 EDT
Received: by bitsy.MIT.EDU
id AA26744; Mon, 17 May 93 16:25:33 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA26738; Mon, 17 May 93 16:25:30 EDT
Received: from relay.pipex.net by MIT.EDU with SMTP
id AA10556; Mon, 17 May 93 16:25:23 EDT
X400-Received: by mta relay.pipex.net in /PRMD=pipex/ADMD=cwmail/C=GB/; Relayed;
Mon, 17 May 1993 21:25:14 +0100
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2));
Relayed; Mon, 17 May 1993 21:24:03 +0100
Date: Mon, 17 May 1993 21:24:03 +0100
X400-Originator: P.V.McMahon at rea0803.wins.icl.co.uk
X400-Recipients: cat-ietf at mit.edu
X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;rea0803 0000016300005675]
Original-Encoded-Information-Types: undefined (0)
X400-Content-Type: P2-1984 (2)
Content-Identifier: 5675
Priority: Urgent
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: P.V.McMahon at rea0803.wins.icl.co.uk
Message-Id: <"5675*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS>
To: cat-ietf at mit.edu
In-Reply-To: <"170519300701*/S=gateway/OU=bra0121/O=icl/PRMD=iclexpo/ADMD=gold 400/C=GB/"@MHS>
Subject: (re-tx) RE:*2 X/Open Security WG comments re GSS-API
> There is currently no requirement that the "default credential" should
> necessarily mean the same thing to GSSAPI initiator and acceptor.
Of course - where they are different ...
> In
> particular, in DCE a server may register multiple identities, and a possible
> use of the default acceptor credential would be to indicate a willingness to
> accept a context under any registered identity (i.e. the acceptor identity is
> chosen from the registered set of identities according to the client's token).
This is an interesting approach. As specified, the GSS-API doesn't appear
to support it as there is only one identity associated with a default
credential. Note that the call gss_inquire_cred() allows the single
identity and single usage of the default credential handle to be queried.
How does this call fit with the model you suggest?
> If such a call is to be introduced, I'd like to see distinct calls to set
> initiator and acceptor default credentials. Or maybe a single call with two
> input creds - one to set the init_sec_context default, and one to set the
> accept_sec_context default, with GSS_C_NO_CREDENTIAL being allowed for either
> parameter to mean "don't change this default". Also, if we're going to allow
> defaults to be changed, we should provide a way for them to be restored to
> their previous values, so the call should probably provide an (optional)
> "previous default" output credential for both initiator and acceptor.
As noted above, I believe that the model of an overloaded default credential
is of interest, but it isn't consistent with the GSS-API.
The default credential can be queried via gss_inquire_cred() should it be
wished to restore it. In practice, this is unlikely to be the case as I see
this call being used in login daemons which will contain code of the form:
gss_acquire_cred(&user_cred);
if(fork() == 0) {
gss_release_cred(NULL);
gss_set_default_cred(user_cred);
setgid(client_gid);
setuid(client_id);
exec(user_shell);
}
(Note that this code has interesting implications for cache access controls in
the implementation)
or in delegation servers which have similar code such as:
gss_accept_sec_context(&delegated_user_cred);
if(fork() == 0) {
gss_release_cred(NULL);
gss_set_default_cred(delegated_user_cred);
exec(user_command);
}
> To remain in-keeping with the other routines, minor_status ought to be the
> first parameter.
Yes - it would be better to adhere to the convention.
I would be interested in your views on the above.
Regards,
Piers 17MAY93
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13275;
17 May 93 16:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13271;
17 May 93 16:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17456;
17 May 93 16:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13261;
17 May 93 16:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13257;
17 May 93 16:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17430;
17 May 93 16:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13247;
17 May 93 16:51 EDT
To: IETF-Announce: ;
Cc: IESG <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: Last Call: RFC 1201 - IP over ARCNET to Historic
Date: Mon, 17 May 93 16:51:49 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305171651.aa13247 at IETF.CNRI.Reston.VA.US>
The IESG is considering moving RFC 1201 "Transmitting IP Traffic over
ARCNET Networks" off the standard track to Historic status. This protocol
was published as a Proposed Standard in February 1991 as a possible
replacement for the Standard RFC 1051 "Standard for the transmission
of IP datagrams and ARPpackets over ARCNET networks".
RFC 1201 has been a Proposed Standard for over two years and is being
reviewed for viability. The IESG is unaware of the existence of
multiple interoperable implementations or significant use of this
protocol in an operational environment and is therefore considering
designating this protocol as Historic.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any comments to
the iesg at cnri.reston.va.us, or ietf at cnri.reston.va.us mailing lists by
May 27.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14200;
17 May 93 17:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14192;
17 May 93 17:47 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa19192;
17 May 93 17:47 EDT
Received: by bitsy.MIT.EDU
id AA27610; Mon, 17 May 93 17:37:08 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA27604; Mon, 17 May 93 17:37:06 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA12663; Mon, 17 May 93 17:37:04 EDT
Received: by inet-gw-2.pa.dec.com; id AA17281; Mon, 17 May 93 14:36:58 -0700
Received: by us1rmc.bb.dec.com; id AA17125; Mon, 17 May 93 17:35:05 -0400
Message-Id: <9305172135.AA17125 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Mon, 17 May 93 17:35:06 EDT
Date: Mon, 17 May 93 17:35:06 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 17-May-1993 1630" <wray at tuxedo.enet.dec.com>
To: p.v.mcmahon.rea0803 at oasis.icl.co.uk
Cc: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com, wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu, p.v.mcmahon.rea0803 at oasis.icl.co.uk
Subject: RE: Re: X/Open Security WG comments re GSS-API
Piers,
>> There is currently no requirement that the "default credential" should
>> necessarily mean the same thing to GSSAPI initiator and acceptor.
>
>Of course - where they are different ...
No, what I meant to say was that, within a single process, GSS_C_NO_CREDENTIAL
may mean two different things when presented to gss_init_sec_ctx and
gss_accept_sec_ctx.
The specs do seem a little confusing in this area. Mostly, a single
process-wide (or wider) default credential is implied (the phrase "the default
credential" is used, implying only one). However, the C bindings document
allows additional implementation-defined semantics for the case where
GSS_C_NO_CREDENTIAL is presented to gss_accept_sec_ctx, but no default
credential has been established.
I think default acceptor credentials are an area that could maybe use some
tidying up, since many mechanisms don't have quite the same symmetry between
initiator and acceptor credentials that GSSAPI assumes. Considering DCE and
DASS (the two mechanisms I'm most familiar with) - As I described, DCE RPC
allows a server to register multiple "potential identities", and a client may
successfully authenticate it as any of these identities (presumably the
Kerberos native API allows this too?). In the case of DASS, there was a
mechanism-specific extension to set a default credential, and in the absence of
a prior call to this routine, a value of GSS_C_NO_CREDENTIAL presented to
gss_accept_sec_ctx meant that the host machine's credential was to be used
(subject to local access-control). Both of these behaviors can be accomodated
today via the "escape clause" in the C-bindings that allow
implementation-defined behavior for GSS_C_NO_CRED in the absence of default
credentials. However, if we're considering adding a portable way of setting
default credentials, we should make sure that we can still support asymmetric
mechanism acceptor credentials reasonably cleanly.
The purpose of default credentials is to allow "simple-minded" applications not
to have to bother with acquiring and releasing credentials. I think it's
reasonably clear what is meant by a simple-minded client application (one that
takes its identity from the user who initiated it), however I'm not so sure
what a simple-minded server is - who's identity should it run under? Ideally
use of GSS_C_NO_CREDENTIAL to gss_accept_sec_ctx should mean "whatever's normal
for servers in this implementation", just as for gss_init_sec_ctx it means
"whatever's normal for clients". For symmetric mechanisms (ones that don't
distinguish between acceptor and initiator credentials) I guess there'd be no
distinction between clients and servers; however in mechanisms where initiate
and accept credentials really are very different things, it doesn't seem right
to have the installation of a default initiate-only credential stop my
pre-existing default acceptor credential from functioning.
The main use for a GSSAPI gss_set_default_cred routine would be (as you've
pointed out) to set up a default identity for a child process. However, to do
this portably, we also have to define the scope of a credential (at the moment,
it's only guaranteed to have process-wide scope). Adding the routine
definition alone doesn't suffice.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15663;
17 May 93 20:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15607;
17 May 93 20:05 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa22477;
17 May 93 20:05 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA13714; Tue, 18 May 93 00:04:01 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Mon, 17 May 1993 23:19:02 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: terry cheung <tcheung at anduin.ocf.llnl.gov>
Message-Id: <9305172319.AA18378 at anduin.ocf.llnl.gov.ocf>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: PEM Certificate Revocation List in X.500
Hi, I want to store PEM CRLs in a X.500 Directory. I see that
RFC 1422 defines the ASN.1 syntax for a PEM CRL. I am wondering
if there is any official attribute label for such a syntax in
the Directory, and if so, is there any official OID associated
with it?
--Terry
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16363;
17 May 93 22:08 EDT
Received: from scorpion.ac.cowan.edu.au by IETF.CNRI.Reston.VA.US id aa16340;
17 May 93 22:06 EDT
Received: by ac.cowan.edu.au (AIX 2.1 2/4.03)
id AA15898; Tue, 18 May 93 12:00:21 WST
Received: From EARWIG/WORKQUEUE by charonml.ed.ac.cowan.edu.au
via Charon-4.0A-VROOM with IPX id 100.930518100556.416;
18 May 93 10:06:46 -0800
Message-Id: <MAILQUEUE-101.930518100554.384 at earwig.ed.ac.cowan.edu.au>
To: ietf at IETF.CNRI.Reston.VA.US
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Alastair Honeybun <AHONEYBUN at earwig.ed.ac.cowan.edu.au>
Organization: Education Mount Lawley
Date: 18 May 93 10:05:54 GMT+800
Subject: (Forwarded) UNSUBSCRIBE
Priority: normal
X-Mailer: Pegasus Mail v2.3 (R5).
Forwarded message:
Date: Mon, 17 May 93 13:22:57 -0700
From: "James W. Weatherford" <weatherf at manta.nosc.mil>
To: IETF at IETF.CNRI.Reston.VA.US
Subject: UNSUBSCRIBE
Please remove me from any and all distribution lists regarding
IETF as soon as possible.
JWW
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Alastair Honeybun Email: a.honeybun at cowan.edu.au
Edith Cowan University Phone: 61-9-370 6422
Perth, WESTERN AUSTRALIA Fax: 61-9-370 2910
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17628;
17 May 93 22:38 EDT
Received: from isdn.ee.ufl.edu by IETF.CNRI.Reston.VA.US id aa17604;
17 May 93 22:37 EDT
Received: by isdn.ee.ufl.edu (4.1/4.09)
id AA00397; Mon, 17 May 93 22:05:44 EDT
Date: Mon, 17 May 93 22:05:44 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Attique Ahmad <attique at isdn.ee.ufl.edu>
Message-Id: <9305180205.AA00397 at isdn.ee.ufl.edu>
To: IETF at IETF.CNRI.Reston.VA.US
Subject: Unsubscribe
kindly remove me from the ietf mailing list
Thanks
--Attique
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19929;
17 May 93 23:48 EDT
Received: from GINGER.LCS.MIT.EDU by IETF.CNRI.Reston.VA.US id aa19898;
17 May 93 23:46 EDT
Received: by ginger.lcs.mit.edu
id AA08787; Mon, 17 May 93 23:46:37 -0400
Date: Mon, 17 May 93 23:46:37 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9305180346.AA08787 at ginger.lcs.mit.edu>
To: IETF at IETF.CNRI.Reston.VA.US
Subject: Re: Unsubscribe
Cc: jnc at ginger.lcs.mit.edu
kindly remove me from the ietf mailing list
Cretins, idiots, dingbats, pinheads, dorks, losers and all other sub-normal
intelligences *PAY ATTENTION*:
For the 752nd time, you *do not* send mail to "ietf@<foo>" to be removed
from the IETF mailing list. You send mail to "ietf-request@<foo>". Got it?
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00994;
18 May 93 7:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab00876;
18 May 93 7:06 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa00680;
18 May 93 4:58 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA16306; Tue, 18 May 93 06:58:06 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Mon, 17 May 1993 18:02:10 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Thomas Johannsen <Thomas.Johannsen at ifn.et.tu-dresden.de>
Message-Id: <9305171602.AA24885 at ebzaw1.et.tu-dresden.de>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Using X.500 to determine presentationAddresses
Somehow the following mail didn't want to leave my queue to osi-ds... :-(
From thomas Mon May 17 11:01:17 1993
To: C.B.Stathopoulos at ics.forth.gr
Subject: Re: Using X.500 to determine presentationAddresses
Cc: osi-ds at cs.ucl.ac.uk
Status: R
Hi Costas,
It's been a long time since our last e-mail contact...
Bearing in mind the "Charting Networks in the Directory"
(OSI-DS-37) draft document I thought that maybe a refinement
of the mechenism described there could be used for globally
naming network elements within the Directory.
Of course the above naming schema results in machine names
that are far away from user-friendly.
As Steve writes:
>The decisions on naming machines should be primarily dictated by
> 1) Reasonable names for the machines
> 2) A naming structure which permits effective allocation.
>I would expect that some key services would be named at the ARC level,
>and the majority of machines at the departmental or project level
>(i.e., org units within ARC).
I agree with these two points.
But for 2) I was expecting something related to the OSI-DS-37 idea.
What about the "nodes" mentioned there? Are we going to have finally
two places for registering machines (one under the OU level
and the other under the network level)? Don't you think that all kinds
of information about a machine must be gathered in one place?
I would see the two possibilities as ways to FIND a node object.
It should be stored (managed etc.) only once though. Say, you
actually hold all nodes of your org in a separate network subtree
and use aliases to point from o/ou levels towards them (if you feel
the need for this reference).
Although nobody will prevent you from putting ALL nodes of
(several) networks owned by your org into ONE flat subtree (i.e.
on one level) I'd strongly encourage building network trees in the
DIT which will give the relationship between nodes and subnetworks. You
might find this useful for routing, naming, etc.
I am looking forward to seeing opinions on the above.
Regards,
Costas.
Thomas
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03309;
18 May 93 9:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07575;
18 May 93 9:46 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03287;
18 May 93 9:46 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03126;
18 May 93 9:40 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-fuller-cidr-strategy-02.txt
Date: Tue, 18 May 93 09:40:36 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305180940.aa03126 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Classless Inter-Domain Routing (CIDR): an Address
Assignment and Aggregation Strategy
Author(s) : V. Fuller, T. Li, J. Yu, K. Varadhan
Filename : draft-fuller-cidr-strategy-02.txt
Pages : 24
This memo discusses strategies for address assignment of the existing
IP address space with a view to conserve the address space and stem
the explosive growth of routing tables in default-route-free routers.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-fuller-cidr-strategy-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-fuller-cidr-strategy-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-fuller-cidr-strategy-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-fuller-cidr-strategy-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 aa04987;
18 May 93 10:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09533;
18 May 93 10:38 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04973;
18 May 93 10:38 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03113;
18 May 93 9:40 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: uri at bunyip.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-uri-resource-names-00.txt
Date: Tue, 18 May 93 09:40:33 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305180940.aa03113 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 Uniform Resource
Identifiers Working Group of the IETF.
Title : Uniform Resource Names
Author(s) : C. Weider, P. Deutsch
Filename : draft-ietf-uri-resource-names-00.txt
A Uniform Resource Name (URN) is an identifier which can be used to
uniquely identify a resource, and is designed to provide persistent
naming for networked objects. This name would stay the same no matter
what the current location(s) of the object was.
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-uri-resource-names-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-uri-resource-names-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-uri-resource-names-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-uri-resource-names-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 aa26398;
18 May 93 18:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26348;
18 May 93 17:58 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa23948;
18 May 93 17:58 EDT
Received: by malamud.com (4.1/SMI-4.1/ccg.11.13.92)
id AA07272; Tue, 18 May 93 18:08:22 EDT
Date: Tue, 18 May 93 18:08:22 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at malamud.com>
Message-Id: <9305182208.AA07272 at malamud.com>
To: ietf at CNRI.Reston.VA.US
Subject: Air Times for Science Friday
Org: Internet Talk Radio
Due to a voluminous number of questions from people,
I asked WNYC to fax me a list of some of the stations
that carry the Science Friday program.
You can also just call your local NPR affiliate and
ask them if they carry "Talk of the Nation/Science
Friday." Those entries with an asterisk are ones
where I'm not sure if they carry the first hour of
the show. (Science Friday is two hours and the segment
on the Internet is the first hour.)
Air Dates: Friday 3/21, plus on Internet Talk Radio
KSKA-FM Anchorage AK 10-11AM
KHNS-FM Hains AK 10-11AM
KOZP-FM Kenai AK 10-11AM
KSDP-AM Sand Point AK 10-11AM
KPBS-FM San Diego CA 11-12AM
KQED-FM San Francisco CA 11-12AM
KUOP-FM Stockton CA 12AM-1PM *
KRZA-FM Alamosa CO 12:30-2PM *
WAMU-FM Washington DC 2-3PM
WLRN-FM Miami FL 2-3PM
WFSU-FM Tallahassee FL 2-3PM
KIPO-FM Honolulu HI 9-10AM
KIPO-AM Pearl City HI 9-10AM
WOI-AM Ames IA 1-2PM
WSUI-AM Iowa City IA 1-2PM
KBSU-AM Bolsa ID 12-1PM
WBUR-FM Boston MA 2-3PM
WCCT-FM Harwich MA 2-3PM
WGVU-AM Grand Rapids MI 2-3PM
WSCN-FM Cloquet MN 1-2PM
KNSR-FM Collegeville MN 1-2PM
KUWS-FM Duluth MN 1-2PM
KXLC-FM La Crescent MN 1-2PM
KCCD-FM Moorhead MN 1-2PM
KZSE-FM Rochester MN 1-2PM
KNOW-FM St. Paul MN 1-2PM
KNGA-FM St. Peter MN 1-2PM
KNTN-FM Thief River F. MN 1-2PM
WKNA-FM Senatobia MS 1-2PM
WBFO-FM Buffalo NY 4-5PM
WSLU-FM Canton NY 2-3PM
WCVF-FM Fredonia NY 4-5PM *
WEOS-FM Geneva NY 2-3PM
WSLO-FM Malone NY 2-3PM
WNYC-AM New York NY 2-3PM
WRVO-FM Oswego NY 2-3PM
WXLU-FM Peru NY 2-3PM
WXXI-AM Rochester NY 2-3PM
WSLL-FM Sarnac Lake NY 2-3PM
WRVN-FM Utica NY 2-3PM
WRVJ-FM Watertown NY 2-3PM
WOSU-AM Columbus OH 8-9PM
KWGS-FM Tulsa OK 1-2PM
KSJK-AM Ashland OR 11-12AM
WHYY-FM Philadelphia PA 2-3PM
WLJK-FM Aiken SC 2-3PM
WJWJ-FM Beaufort SC 2-3PM
WLTR-FM Columbia SC 2-3PM
WHMC-FM Conway SC 2-3PM
WEPR-FM Greenville SC 2-3PM
WSCI-FM Mt. Pleasant SC 2-3PM
WNSC-FM Rook Hill SC 2-3PM
WRJA-FM Sumter SC 2-3PM
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01363;
19 May 93 8:15 EDT
Received: from [129.139.68.47] by IETF.CNRI.Reston.VA.US id aa01252;
19 May 93 8:04 EDT
Received: from cor5.pica.army.mil by COR3.PICA.ARMY.MIL id aa06238;
19 May 93 7:55 EDT
Date: Wed, 19 May 1993 07:54:54 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Ed Levinson (Contractor) <levinson at pica.army.mil>
To: announce: ;
Subject: Addressing addressing
Reply-to: email-addr at pica.army.mil
X-Mailer: MH 6.7.2
X-Comment: Please forgive the cross posting
Message-ID: <9305190755.aa06238 at COR3.PICA.ARMY.MIL>
Imagine a future in which you can send mail to anybody, anywhere;
long as thy're connected, no matter how thy're connected.
I can't see how to get to that future from where I am today but
it is a possible future. What needs to happen make that future
possible? All you need is an address; "aye, there's the rub".
Addressing across mail system boundaries is complicated.
There are lots of mail systems, directories, and gateways today;
no one of them is about to take over the world (they'd all like
to, though ;-). We will live for a long time in this situation
and by providing some direction now we can make a future we envision
possible.
The growth of electronic mail will require making addressing
easier. Adding gateways seems to make addressing harder not easier.
So it is natural to ask, is there a better way? In the discussions
I've had on this subject no clear solution has popped up, but everyone
seems convinced this is an important but difficult problem. I'm
not sure there is a solution; maybe there's a range of them,
maybe some guidelines; perhaps a direction that leads to easier
addressing.
This is an invitation participate in addressing the issues of
addressing. We can begin by trying to define the problem,
by outlining the scope (What is the universe of addressing
schemes?), and by examining the technologies (gateways are one)
that can be applied and their limitations.
I propose a mailing list (email-addr at pica.army.mil) to
begin addressing adddressing. If you are interested, send a sub-
scription request email-addr-request at pica.army.mil or to me
(levinson at pica.army.mil).
Best.../Ed
Please forgive the cross postings. I've kept this announcement short
and done my best to see that you won't receive any more mail on this
subject unless you subscribe.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05783;
19 May 93 12:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05745;
19 May 93 12:26 EDT
Received: from att-out.att.com by CNRI.Reston.VA.US id aa16832;
19 May 93 12:25 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: sri at qsun.att.com
Date: Wed, 19 May 93 12:22 EDT
Original-From: qsun!sri (Srinivas R Sataluri +1 908 949 7782)
To: ietf at CNRI.Reston.VA.US
Subject: Re: Air Times for Science Friday
Message-ID: <9305191225.aa16832 at CNRI.Reston.VA.US>
From: Carl Malamud <carl at malamud.com>
To: ietf at CNRI.Reston.VA.US
Subject: Air Times for Science Friday
Org: Internet Talk Radio
Due to a voluminous number of questions from people,
I asked WNYC to fax me a list of some of the stations
that carry the Science Friday program.
Air Dates: Friday 3/21, plus on Internet Talk Radio
WNYC-AM New York NY 2-3PM
WNYC-AM broadcasts on AM 820.
-sri (Srinivas R. Sataluri, sri at internic.net)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06865;
19 May 93 13:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06859;
19 May 93 13:33 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa19033;
19 May 93 13:33 EDT
Received: by bitsy.MIT.EDU
id AA29669; Wed, 19 May 93 13:27:08 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA29663; Wed, 19 May 93 13:27:06 EDT
Received: from relay.pipex.net by MIT.EDU with SMTP
id AA24539; Wed, 19 May 93 13:27:02 EDT
X400-Received: by mta relay.pipex.net in /PRMD=pipex/ADMD=cwmail/C=GB/; Relayed;
Wed, 19 May 1993 18:26:11 +0100
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5 text (2));
Relayed; Wed, 19 May 1993 18:25:16 +0100
Date: Wed, 19 May 1993 18:25:16 +0100
X400-Originator: P.V.McMahon at rea0803.wins.icl.co.uk
X400-Recipients: cat-ietf at mit.edu
X400-Mts-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;rea0803 0000016300005681]
Original-Encoded-Information-Types: undefined (0)
X400-Content-Type: P2-1984 (2)
Content-Identifier: 5681
Priority: Urgent
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: P.V.McMahon at rea0803.wins.icl.co.uk
Message-Id: <"5681*/I=PV/S=McMahon/OU=rea0803/O=icl/PRMD=icl/ADMD=gold 400/C=GB/"@MHS>
To: cat-ietf at mit.edu
In-Reply-To: <"170522530001*/S=gateway/OU=bra0121/O=icl/PRMD=iclexpo/ADMD=gold 400/C=GB/"@MHS>
Subject: RE*3: X/Open Security WG comments re GSS-API
John,
> However, if we're considering adding a portable way of setting
> default credentials, we should make sure that we can still support asymmetric
> mechanism acceptor credentials reasonably cleanly.
In parallel, should we adjust the semantics of gss_inquire_cred()? Does this
mean that the "usage" parameter should be made an input to this function?
> The purpose of default credentials is to allow "simple-minded" applications no
t
> to have to bother with acquiring and releasing credentials.
Yes - this is to me the main attraction of it, as it permits relatively easy
use of GSSAPI by (most) clients, and both client and server parts of "simple"
2-part distributed applications. Making GSSAPI easy to use will assist in
its takeup.
> The main use for a GSSAPI gss_set_default_cred routine would be (as you've
> pointed out) to set up a default identity for a child process. However, to do
> this portably, we also have to define the scope of a credential (at the moment
,
> it's only guaranteed to have process-wide scope). Adding the routine
> definition alone doesn't suffice.
The routine definition assumes inheritance rules (as in Kerberos/DCE/SESAME)
which permit inheritance of credentials over a fork/exec. I think that for the
GSSAPI to be useful in constructing software, the definition of portability for
credentials needs to be established as much as such rules exist for environment
variables, file descriptors, IPC references etc
Piers
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12169;
19 May 93 18:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12081;
19 May 93 18:12 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa29013;
19 May 93 18:12 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA00783; Wed, 19 May 93 22:12:53 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Wed, 19 May 1993 18:19:35 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "James Hong, W." <jwkhong at mccarthy.csd.uwo.ca>
Message-Id: <9305191819.AA27731 at mccarthy.csd.uwo.ca>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Using X.500 to determine presentationAddresses
> > We have been investigating the use of X.500 in the Network, Systems and
> > Applications management frameworks for the last couple of years.
> >
> > For those who are not aware yet, I would like to refer to our paper that was
> > presented at the 3rd Int. Symposium on Integrated Network Management,
> > San Fransisco, April 1993, pp. 149-160, which discusses our experience of
> > using the X.500 Directory Service in the network management framework.
This paper is available from ftp.csd.uwo.ca [129.100.11.252] in the pub/x.500
directory. It's called ISINM93-paper.ps.Z.
>
> I got your paper two weeks ago and I have read it. It is really interesting!
> But I didn't find a lot of work related to the global naming of the network
> elements therein. Ok, I understand that this was not your objective, but
> I suppose you have thought about a global naming schema for NEs.
> Anyone who deals with such an issue as "Integrating the X.500 in the Network
> Management Framework" sooner or later asks for a way to name a NE in the DIT!
>
> Although your prototype Quipu Objects: csdDomain and csdMachine are enough
> for your experiment (I have defined my own objects for my prototype, too)
> a more standardized schema is needed. Any ideas on such a schema?
Is there anything wrong with global machine names (for the purpose of storing
them in the Directory) such as
{Country=ca, O=UWO, OU=CSD, Domain=Syslab, Machine=rubble} ?
Am I missing something?
>
> Cheers,
> Costas.
James
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12778;
19 May 93 18:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12695;
19 May 93 18:36 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa29771;
19 May 93 18:36 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA01029; Wed, 19 May 93 22:35:15 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Wed, 19 May 1993 15:59:51 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Eric Watt Forste <arkuat at joes.garage.com>
Message-Id: <199305192159.AA28394 at joes.GARAGE.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: PEM
I recently read that free software implementing the basics of the Internet PEM standard was available, and that I could get more information by mailing to this address. I am interested in learning as much as I can about all the privacy tools currently available, so any additional information about PEM and tools that implement it would be very helpful to me. Could you send me more information?
Thanks for taking the time to read this.
Eric Watt Forste slippery at netcom.com
1800 Market St #243 San Francisco CA 94102
"Expectation foils perception." -- Pamela C. Dean
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14009;
19 May 93 19:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13954;
19 May 93 19:46 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa01492;
19 May 93 19:46 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA01565; Wed, 19 May 93 23:46:24 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Thu, 20 May 1993 04:33:09 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: C.B.Stathopoulos at ics.forth.gr
Message-Id: <9305192233.AA00585 at danae.csi.forth.gr>
Organization: FORTH - ICS, P.O.Box 1385, Heraklio, Crete, Greece 711 10 tel:
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Using X.500 to determine presentationAddresses
>Is there anything wrong with global machine names (for the purpose of storing
>them in the Directory) such as
> {Country=ca, O=UWO, OU=CSD, Domain=Syslab, Machine=rubble} ?
No, you didn't do anything wrong! But as long as there is no standard
way for registering machines in the Directory I could use other schemas
e.g. country=gr, o=FORTH, OU=ICS, machine=danae or
country=gr, o=FORTH, OU=ICS, network=ICSnet, subnet=BuildingA, machine=danae
Given these different schemas how could anyone implement a DUA that is
given as input UFNs for machines and return their entries?
>Am I missing something?
I just want to say that we need a well-defined subtree under every O or OU
level for registering machines so that anyone that writes a DUA that searches
for machine: rubble, csd, uwo, ca (this is a UFN for rubble, right?) will know
where to search. (This is because the end-user is not aware of domains or
networks.)
Regards,
Costas.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15962;
19 May 93 22:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15928;
19 May 93 22:34 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa05194;
19 May 93 22:34 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA02854; Thu, 20 May 93 02:33:45 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Thu, 20 May 1993 00:55:17 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Peter Furniss <cziwprf at pluto.ulcc.ac.uk>
Message-Id: <4899.9305200055 at pluto.ulcc.ac.uk>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305192233.AA00585 at danae.csi.forth.gr>
Reply-To: P.Furniss at ulcc.ac.uk
Subject: Re: Using X.500 to determine presentationAddresses
>
> No, you didn't do anything wrong! But as long as there is no standard
> way for registering machines in the Directory I could use other schemas
> e.g. country=gr, o=FORTH, OU=ICS, machine=danae or
> country=gr, o=FORTH, OU=ICS, network=ICSnet, subnet=BuildingA,
machine=danae
>
> Given these different schemas how could anyone implement a DUA that
is
> given as input UFNs for machines and return their entries?
>
> >Am I missing something?
>
> I just want to say that we need a well-defined subtree under every O or
OU
> level for registering machines so that anyone that writes a DUA that
searches
> for machine: rubble, csd, uwo, ca (this is a UFN for rubble, right?) will
know
> where to search. (This is because the end-user is not aware of domains or
> networks.)
1: Isn't a UFN is just a representation of a Directory Name with a default
sequence of attributes. Why is the user searching for the machine ?
Presumably because they have been told that some desired service is
accessible on it. So the name will have been presented in a form that
identifies the attribute types - either explicitly or by default according to
some set of rules.
2. By "well-defined subtree" Are you asking for all Organisations or
Organisation Units to use the same structure below their level ?
Surely not. Interaction of Locality and OU have different "obvious"
answers depending on what kind of O you are.
3. On a side issue (and at some risk of pedantry) why are we talking
about machines ? A presentation address identifies a *process*
(strictly, an application entity that is the projection of an
application process into the communications environment), and the
process may move from one machine to another. Yes, it makes sense to
think of the process as being the machine if you want to login to it,
but probably not if you after something with access to a distributed
database or the like. service = machine is rather old-fashioned.
I may be way off course here, of course.
Peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00589;
20 May 93 4:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00468;
20 May 93 3:16 EDT
Received: from [128.212.48.70] by CNRI.Reston.VA.US id aa01294;
20 May 93 3:16 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA04775; Thu, 20 May 93 06:34:35 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Thu, 20 May 1993 20:26:18 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: John Gottschalk <john at citr.uq.oz.au>
Message-Id: <9305200526.AA01249 at lemon>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: X.500 conformance testers?
Hello all,
Can anybody tell me what companies sell conformance testers for the
X.500 1988 DAP?
-- regards, John Gottschalk
=====================================================================
John Gottschalk (john at citr.uq.oz.au)
Project Manager,
Centre for Information Technology Research,
The University of Queensland, 4072,
Brisbane, Queensland, Australia,
+61 7 365 4321 (phone), +61 7 365 4399 (fax)
=====================================================================
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01741;
20 May 93 8:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01698;
20 May 93 7:58 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa05645;
20 May 93 7:58 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA06916; Thu, 20 May 93 11:58:13 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Thu, 20 May 1993 11:50:08 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Alain Zahm <zahm at osi.e3x.fr>
Message-Id: <73789133717681zahm*.S=zahm.OU=OSI.O=E3X.PRMD=E3X.ADMD=atlas.C=FR. at MHS>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Rep : X.500 conformance testers?
> Hello all,
>
> Can anybody tell me what companies sell conformance testers for the
> X.500 1988 DAP?
>
> -- regards, John Gottschalk
>
John,
Our X.500 product is currently ongoing conformance tests using the
french OSTC tester. This tester is a product developped in France by the
Sema group and should be commercialy available under the name "GENEPIX 500"
I have no more informations for the moment.
Regards
Alain Zahm
Alain Zahm: X.400 : C=FR;ADMD=ATLAS;PRMD=E3X;S=zahm
MHS-Team: X.400 : C=FR;ADMD=ATLAS;PRMD=E3X;S=E3X-tech
Commercial-Team: X.400 : C=FR;ADMD=ATLAS;PRMD=E3X;S=E3X-com
========================================================================
E3X R&D OSI OSI Research & Development
Les Algorithmes, Route des Lucioles, Bat. Pythagore A 06560 Valbonne France
Phone +33 93 65 34 65
fax +33 93 65 34 38
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01934;
20 May 93 8:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01889;
20 May 93 8:05 EDT
Received: from latour.cs.colorado.edu by CNRI.Reston.VA.US id aa05806;
20 May 93 8:05 EDT
Received: by latour.cs.colorado.edu id AA28199
(5.65c/IDA-1.4.4); Thu, 20 May 1993 06:03:32 -0600
Date: Thu, 20 May 1993 06:03:32 -0600
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Mike Schwartz <schwartz at latour.cs.colorado.edu>
Message-Id: <199305201203.AA28199 at latour.cs.colorado.edu>
To: Internet-Measurement-Report-List at latour.cs.colorado.edu
Subject: Internet service-level reachability measurement report available
The following paper is available by anonymous FTP and e-mail from
ftp.cs.colorado.edu in the directory
pub/cs/techreports/schwartz/PostScript/InetMeasStudy/Report:
M. F. Schwartz and J. S. Quarterman. A Measurement Study of
Changes in Service-Level Reachability in the Global Internet.
Technical Report CU-CS-649-93, Department of Computer Science,
University of Colorado, Boulder, Colorado, May 1993.
This is a report based on the measurement experiments announced in
Internet Request For Comments 1273 (which is also available in the
InetMeasStudy directory).
Abstract:
The Internet is currently in a period of exponential growth, as
measured by domain registrations and packet counts.
Increasingly often, people want to know how fast a particular
part of the Internet is growing - to do capacity planning, gauge
commercial promise, or simply to understand this important
change in our society. Yet, looking only at registrations and
packet counts does not uncover the full complexity of the
situation. There are a variety of ways that sites can connect
to the Internet, each offering different capabilities, costs,
and technical problems. Moreover, growing awareness of network
security problems is changing the way people think about
connecting to the Internet, based on mechanisms such as firewall
gateways. In this paper we analyze Internet growth based on
measurements of which of a dozen common TCP services could be
reached at each of over 13,000 domains worldwide, tested four
times over the course of 1992. We analyze this data as a
function of country, type of institution, and type of service.
We also derive mathematical models that can be used to project
growth and disconnection rates for individual countries and the
global Internet.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02844;
20 May 93 8:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02752;
20 May 93 8:54 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa07335;
20 May 93 8:54 EDT
Received: from malamud.com (trystero.malamud.com) by venera.isi.edu (5.65c/5.61+local-12)
id <AA10641>; Thu, 20 May 1993 05:54:23 -0700
Received: by malamud.com (4.1/SMI-4.1/ccg.11.13.92)
id AA10238; Thu, 20 May 93 09:03:31 EDT
Date: Thu, 20 May 93 09:03:31 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at malamud.com>
Message-Id: <9305201303.AA10238 at malamud.com>
To: ietf at isi.edu
Subject: The Great Internet Treasure Hunt!!
Org: Internet Multicasting Service
Station: Internet Multicasting Service
Channel: Internet Town Hall
Program: National Public Radio meets the Internet
Release: May 21, 1993, 2-3PM EDT
Content: The Great Internet Treasure Hunt!!
Test your Internet Quotient (IQ) and win fame and glory with the
Great Internet Treasure Hunt.
This message has six questions for you to answer. We're interested
not only in the right answer but *how* you get the answer. If you
can tell us many different ways of getting the same information, you
get extra credit. Creative answers also get extra credit.
Deadline for submitting questions is 3PM, Eastern Daylight Time
to hunt at radio.com. Some answers may be mentioned on Talk of the
Nation/Science Friday which will take place from 2-3PM on 5/21.
Others answers will be posted on the net and a winner declared by
3 PM EDT on Sunday.
**** SEND YOUR ENTRIES TO hunt at radio.com BY 3 PM, EDT ****
Rules of the road:
1. All answers must be obtained from the Internet. Tell
us *HOW* you got the answer! Diversity will be rewarded,
verbosity will be ignored.
2. There are no prizes. Some entries will be mentioned
on Science Friday. A more complete posting of answers
and a winner will be posted on the Internet by Sunday,
5/23.
3. All entries must be received by 3PM, EDT on Friday
May 21. We are not responsible for network outages
or delays or any other reason. No whining will be
tolerated.
4. Judging will be an arbitrary decision by the Internet
Multicasting Service. No appeals are possible and
no whining will be tolerated.
Thanks to Rick Gates from the University of California, Santa Barbara
for drafting these questions. Rick runs the regular, monthly Internet
Treasure Hunt.
**** SEND YOUR ENTRIES TO hunt at radio.com BY 3 PM, EDT ****
=========================THE QUESTIONS=========================
Q: I'm curious how the new countries in Eastern Europe are
progressing on their road towards international recognition.
Are Latvia, the Ukraine, and Bosnia and Herzegovina members of
the UN? If so, when did they get admitted?
Q: When is the next scheduled launch of the U.S. Space Shuttle
Endeavor? What is it's mission?
Q: We're thinking of moving from the Rust Belt to the Golden West
in search of economic opportunity. Could you compare the unemployment
rate in Detroit to that in Los Angeles?
Q: A friend of mine showed me a file which he called an "ASCII text
file". I asked him what the ASCII meant, and he said it means that
it's just plain text, but he figures it must stand for *something.*
What does ASCII stand for?
Q: What are the ingredients in the witches brew in Macbeth?
Q: Who did U.S. President Clinton nominate as U.S. Ambassador to
Nicaragua?
===============================================================
**** SEND YOUR ENTRIES TO hunt at radio.com BY 3 PM, EDT ****
For information on Internet Talk Radio, write to info at radio.com.
More information on Internet Town Hall will be available shortly.
For a current, partial listing of sites, write to sites at radio.com.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04680;
20 May 93 10:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09927;
20 May 93 10:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04663;
20 May 93 10:22 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04616;
20 May 93 10:19 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
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-iso2022jp-03.txt
Date: Thu, 20 May 93 10:19:04 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305201019.aa04616 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Message
Extensions Working Group of the IETF.
Title : Japanese Character Encoding for Internet Messages
Author(s) : Jun Murai, Mark Crispin, Erik van der Poel
Filename : draft-ietf-822ext-iso2022jp-03.txt
Pages : 6
This document describes the encoding used in electronic mail [RFC822]
and network news [RFC1036] messages in several Japanese networks. It
was first specified by and used in JUNET [JUNET]. The encoding is now
also widely used in Japanese IP communities.
The name given to this encoding is "ISO-2022-JP", which is intended to
be used in the "charset" parameter field of MIME headers (see [MIME1]
and [MIME2]).
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-iso2022jp-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-822ext-iso2022jp-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-822ext-iso2022jp-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-822ext-iso2022jp-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 aa05062;
20 May 93 10:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10537;
20 May 93 10:43 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05035;
20 May 93 10:43 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04953;
20 May 93 10:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ospfigp at trantor.umd.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-ospf-version2-02.txt, .ps
Date: Thu, 20 May 93 10:41:56 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305201041.aa04953 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 Open Shortest Path First
IGP Working Group of the IETF.
Title : OSPF Version 2
Author(s) : J. Moy
Filename : draft-ietf-ospf-version2-02.txt, .ps
Pages : 212
This memo documents version 2 of the OSPF protocol. OSPF is a
link-state routing protocol. It is designed to be run internal to a
single Autonomous System. Each OSPF router maintains an identical
database describing the Autonomous System's topology. From this
database, a routing table is calculated by constructing a
shortest-path tree.
OSPF recalculates routes quickly in the face of topological
changes, utilizing a minimum of routing protocol traffic.
OSPF provides support for equal-cost multipath. Separate
routes can be calculated for each IP Type of Service. An area routing
capability is provided, enabling an additional level of routing
protection and a reduction in routing protocol traffic. In addition,
all OSPF routing protocol exchanges are authenticated.
OSPF Version 2 was originally documented in RFC 1247. The differences
between RFC 1247 and this memo are explained in Appendix E. The
differences consist of bug fixes and clarifications, and are
backward-compatible in nature. Implementations of RFC 1247 and of
this memo will interoperate.
Please send comments to ospf at gated.cornell.edu.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ospf-version2-02.txt".
Or
"get draft-ietf-ospf-version2-02.ps".
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-ospf-version2-02.txt".
Or
"SEND draft-ietf-ospf-version2-02.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-ospf-version2-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ospf-version2-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 aa05102;
20 May 93 10:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10583;
20 May 93 10:44 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05087;
20 May 93 10:44 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05013;
20 May 93 10:43 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: mospf at comet.cit.cornell.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-mospf-analysis-01.txt
Date: Thu, 20 May 93 10:43:10 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9305201043.aa05013 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 Multicast Extensions to
OSPF Working Group of the IETF.
Title : MOSPF: Analysis and Experience
Author(s) : J. Moy
Filename : draft-ietf-mospf-analysis-01.txt
Pages : 14
This memo documents how the MOSPF protocol satisfies the requirements
imposed on Internet routing protocols by "Internet Engineering Task
Force internet routing protocol standardization criteria" ([RFC
1264]). This memo provides information for the Internet community.
It does not specify any Internet standard. Distribution of this memo
is unlimited.
Please send comments to mospf at gated.cornell.edu.
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-mospf-analysis-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-mospf-analysis-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-mospf-analysis-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-mospf-analysis-01.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 aa05920;
20 May 93 11:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05879;
20 May 93 11:24 EDT
Received: from mwunix.mitre.org by CNRI.Reston.VA.US id aa12164;
20 May 93 11:24 EDT
Return-Path: <A_YUAN%W035_NW at MWMGATE1.mitre.org>
Received: from mwmgate2.mitre.org by mwunix.mitre.org (5.65c/SMI-2.2)
id AA11006; Thu, 20 May 1993 11:25:07 -0400
Message-Id: <199305201525.AA11006 at mwunix.mitre.org>
Date: Thu, 20 May 93 11:23:18 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: A_YUAN%W035_NW at mwmgate1.mitre.org
To: ietf at CNRI.Reston.VA.US, Eric Watt Forste <arkuat at joes.garage.com>
Subject: Re: PEM
I'm sorry, but I do not know what you are referring to or who may have directed
you to me. I cannot help you and I don't know who I could refer you to for the
correct information. I suggest going back to your original source.
recently read that free software implementing the basics of the Internet PEM
standard was available, and that I could get more information by mailing to
this address. I am interested in learning as much as I can about all the
privacy tools currently available, so any additional information about PEM and
tools that implement it would be very helpful to me. Could you send me more
information?
Thanks for taking the time to read this.
Eric Watt Forste slippery at netcom.com
1800 Market St #243 San Francisco CA 94102
"Expectation foils perception." -- Pamela C. Dean
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08280;
20 May 93 13:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08212;
20 May 93 13:09 EDT
Received: from trystero.malamud.com by CNRI.Reston.VA.US id aa15131;
20 May 93 13:09 EDT
Received: by malamud.com (4.1/SMI-4.1/ccg.11.13.92)
id AA11008; Thu, 20 May 93 13:18:31 EDT
Date: Thu, 20 May 93 13:18:31 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Malamud <carl at malamud.com>
Message-Id: <9305201718.AA11008 at malamud.com>
To: com-priv at psi.com, ietf at CNRI.Reston.VA.US
Subject: Deadline for Treasure Hunt is Friday, May 21, at 3 PM
Org: Internet Multicasting Service
The deadline for the Great Internet Treasure Hunt is Friday, May 21,
3 PM, Eastern Daylight Time. Entries should be returned to hunt at radio.com.
Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08634;
20 May 93 13:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08630;
20 May 93 13:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15904;
20 May 93 13:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08605;
20 May 93 13:34 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08601;
20 May 93 13:34 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: x25mib at dg-rtp.dg.com
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: SNMP MIB extension for MultiProtocol
Interconnect over X.25 to Proposed Standard
Date: Thu, 20 May 93 13:34:04 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305201334.aa08601 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet Draft "SNMP MIB extension for
MultiProtocol Interconnect over X.25"
<draft-ietf-x25mib-ipox25mib-05.txt> as a Proposed Standard. This
document is the product of the X.25 Management Information Base
Working Group. The IESG contact person is Marshall Rose.
Technical Summary
The Multiprotocol Interconnect over X.25 MIB defines objects that
allow SNMP to manage the encapsulation of IP (and other link level
protocols) on X.25 as specified in RFC 1356. These objects
complement the objects in the "SNMP MIB extension for the Packet
Layer of X.25", the "SNMP MIB extension for LAPB", and the
"Definitions of Managed Objects for RS-232-like Hardware Devices", to
allow management of RFC 1356 traffic over the entire X.25 protocol
stack.
Working Group Summary
There were no outstanding issues or controversies in the working
group.
Protocol Quality
The document has been reviewed by the NM Area Director, which
resulted in some (minor) changes. There are no implementations at
present.
Note to RFC Editor
Prior to RFC publication, please remove Section 1.1 (Revision
History), as this relates information about the Internet-Drafts which
preceeded this document.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14269;
20 May 93 18:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14239;
20 May 93 18:49 EDT
Received: from BBN.COM by CNRI.Reston.VA.US id aa24391; 20 May 93 18:49 EDT
Received: from port12.sunnyvale.pub-ip.psi.net by BBN.COM id aa23971;
20 May 93 18:49 EDT
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA16589; Thu, 20 May 93 15:48:25 PDT
Message-Id: <9305202248.AA16589 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: contests...
Reply-To: Craig Partridge <craig at aland.bbn.com>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Thu, 20 May 93 15:48:25 -0700
X-Orig-Sender: craig at aland.bbn.com
Since we're having networking contests... I'm taking suggestions about
which Internet Old Boy is the caveman on the cover of the May issue of
IEEE Network (a special issue on the future of the Internet protocol).
Craig
PS: For those who don't recognize it, the diagram he's chiseling into the
wall is a map of the Arpanet as of December 1969.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14525;
20 May 93 19:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14501;
20 May 93 19:17 EDT
Received: from OPAL.ACC.COM by CNRI.Reston.VA.US id aa25330; 20 May 93 19:17 EDT
Received: by opal.acc.com (4.1/SMI-4.0)
id AA18294; Thu, 20 May 93 16:18:13 PDT
Date: Thu, 20 May 93 16:18:13 PDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Art Berggreen <art at opal.acc.com>
Message-Id: <9305202318.AA18294 at opal.acc.com>
To: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US
Subject: Re: contests...
>
>Since we're having networking contests... I'm taking suggestions about
>which Internet Old Boy is the caveman on the cover of the May issue of
>IEEE Network (a special issue on the future of the Internet protocol).
>
>Craig
>
>PS: For those who don't recognize it, the diagram he's chiseling into the
>wall is a map of the Arpanet as of December 1969.
If the reference is that early, it ought to be one of the principle people
involved in early ArpaNet development. Maybe someone like Alex McKenzie,
Steve Crocker, Vint Cerf, Jon Postel, Bob Kahn, or even Larry Roberts.
Since Steve Crocker is listed as author of RFC-1 maybe he is appropriate
(since RFCs are the bible of the Internet).
My $0.02,
Art
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14961;
20 May 93 21:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14938;
20 May 93 21:07 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa29404;
20 May 93 21:07 EDT
Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11627>; Thu, 20 May 1993 18:08:01 PDT
Received: by ecco.parc.xerox.com id <16136>; Thu, 20 May 1993 18:07:52 -0700
Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41
via MS.5.6.ecco.parc.xerox.com.sun4_41;
Thu, 20 May 1993 18:07:46 -0700 (PDT)
Message-ID: <0fz2hWQB0bH4QCVkQt at ecco.parc.xerox.com>
Date: Thu, 20 May 1993 18:07:46 PDT
X-Orig-Sender: Ron Frederick <frederic at parc.xerox.com>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Ron Frederick <frederic at parc.xerox.com>
To: rem-conf at es.net, mbone at isi.edu, ietf at CNRI.Reston.VA.US
Subject: More info on Friday NPR "Talk of the Nation" broadcast
Tomrrow, Friday May 21st, at 2:00pm Eastern (11:00am Pacific, 1800 GMT) we're
going to be broadcasting the National Public Radio show "Talk of the Nation /
Science Friday" out to the MBONE. Guests include Carl Malamud, Brewster Kahle,
and Tim O'Reilly, with the topic being the Internet, how it is used, and the
future of computer networking. Questions will also be fielded from the Internet
during the show. People from outside of the continental U.S. are especially
welcome, as it really stresses just how big the Internet is...
In order to listen, you'll need a working MBONE tunnel and a vat compatible
audio tool. Look for an 'sd' session named "Internet Town Hall." For those
without sd, here's the session info:
Internet Town Hall
NPR "Talk of the Nation/Science Friday" program about the Internet.
Address: 224.2.235.24, ttl 191
Media: vat pcm audio, port 45551, conf id 48217
If you'd like to direct a question to the program, things get a bit hairier.
You'll need to look for two other sd sessions -- one labelled "Internet Town
Hall Questions" and the other labelled "ITH -- Invitation Only." The session
info for these is:
Internet Town Hall Questions
Address: 224.2.235.25, ttl 191
Media: vat pcm audio, port 45552, conf id 48218
ITH -- Invitation Only
Address: 224.2.235.26, ttl 191
Media: vat pcm audio, port 45553, conf id 48219
The protocol for asking a question is as follows:
1) Open the "Internet Town Hall Questions" session from sd. You'll need to
quit or deactivate the regular "Internet Town Hall" session to speak
there.
2) When you join the "Internet Town Hall Questions" session, wait for a
quiet moment and let Steve Deering (the Question Coordinator) know that
you're around and interested in speaking on the show. He'll ask for
your name, location, and the nature of your question. If he's able to
hear you ok, he'll tell you to go ahead to step 3.
3) If you can be reasonably well heard at PARC, you will be told to quit
your existing "Internet Town Hall" and "Internet Town Hall Questions"
sessions and join "ITH -- Invitation Only." Once you've successfully
done so, your name will be passed to the director of the show in New
York to be put on the list of waiting callers.
In this new session, you'll be able to hear the program, and should
wait for the host to call your name, and then unmute your mike and
go ahead.
Hints for improving audio quality:
* Use headphones if at ALL possible! They'll prevent unwanted echo, and
allow a full duplex conversation between you and the host.
* If you can't use headphones, make SURE that you are in "Speakerphone"
mode, so that your microphone won't pick up & send what's coming out of
your speakers.
* Try and keep your microphone as far away as possible from fans and
other sources of noise. Keep your mike muted except when you actually
wish to speak. You should use 'vat' to do this, rather than switching
your mike on & off, as powering up a mike typically causes a loud and
annoying click.
* If you have adjusted your microphone volume by hand, remember to set it
to the _same_ value when you move over to the "ITH -- Invitation Only"
session.
* If you are listening to the program on a normal radio, make sure to
turn it off before you speak up to ask questions, to avoid any echo
or feedback problems.
If you have any questions about the above, send a note to Ron Frederick
<frederick at parc.xerox.com>...
-- Ron Frederick and Steve Deering,
your Internet gateway hosts
--
Ron Frederick
frederick at parc.xerox.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18444;
20 May 93 23:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18422;
20 May 93 23:15 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa03687; 20 May 93 23:15 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA05398; Thu, 20 May 93 20:15:38 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA10802; Thu, 20 May 93 20:17:17 pdt
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9305210317.AA10802 at hpindda.cup.hp.com>
Subject: Re: X.500 conformance testers?
To: john at citr.uq.oz.au
Date: Thu, 20 May 93 20:17:14 PDT
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9305200526.AA01249 at lemon>; from "John Gottschalk" at May 20, 93 8:26 pm
Mailer: Elm [revision: 64.9]
I know that NCC has one. I believe that other MOT providers (Danet, Alcatel)
are good candidates for having them as well. Check with the folks at NIST
in the US GOSIP Testing Program (either night at osi.ncsl.nist.gov or
favreau at osi.ncsl.nist.gov). Since they are looking at having an X.500
testing program, they likely know what is out there today.
Cheers,
Eva
>
> Hello all,
>
> Can anybody tell me what companies sell conformance testers for the
> X.500 1988 DAP?
>
> -- regards, John Gottschalk
>
> =====================================================================
> John Gottschalk (john at citr.uq.oz.au)
> Project Manager,
> Centre for Information Technology Research,
> The University of Queensland, 4072,
> Brisbane, Queensland, Australia,
> +61 7 365 4321 (phone), +61 7 365 4399 (fax)
> =====================================================================
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22754;
21 May 93 1:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22718;
21 May 93 1:01 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa07792;
21 May 93 1:01 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA12199; Fri, 21 May 93 04:59:32 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 03:57:03 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Mark Riordan <mrr at scss3.cl.msu.edu>
Message-Id: <9305210357.AA01077 at scss3.cl.msu.edu>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Triple DES
To the PEM-DEV mailing list (& friends):
We RIPEM developers plan on adding triple-DES data encryption
to an upcoming version of RIPEM. (We have received permission
to modify the RSAREF API to do this.) As RIPEM is also slated to
become PEM-compatible in the not-too-distant future, I would
like input from PEM developers on two items:
1. Just what form of "triple DES" should be used?
2. What algorithm identifier (e.g., DES-EEE-CBC) should
be used in the DEK-Info: header line of the output ciphertext?
Triple DES isn't an official PEM algorithm yet--will it/should it
ever be?
------------------------------------------------------------------------
Regarding the exact definition of triple DES: this topic has been
enthusiatically debated in the last 24 hours by several RIPEM developers.
Some candidates are:
a. encrypt(encrypt(encrypt(block,k1),k2),k3) [EEE]
b. encrypt(decrypt(encrypt(block,k1),k2),k1) [traditional EDE]
c. encrypt(decrypt(encrypt(block,k1),k2),k3) [3-key EDE]
Here are some arguments that have been advanced in the last day.
My apologies to anyone quoted out of context, but I didn't want to
requote the entire exchange:
Ray Lau says:
I prefer, in the name of possible future compability, to downgrade
to EDE w/2 keys. It's pretty clear that EDE is the one that's been
around the longest because the proof that DES is not a group under enc.
is relatively recent. And I suspect that the 2 key version is in
wider use than the 3 key version.
112 bits is enough in my book. 2**112 is pretty astronomical.
If anything else, DES will fall apart
before exhaustive search of 2**112 becomes feasible!
Mark Henderson says:
On the other hand, the 3 key version is easy to implement, and barring a
breakthrough in the cryptanalysis of MD5, should be more secure (of
course, all the key bits, IV and padding are essentially pumped out of
MD5).
As to EDE vs EEE, I don't see that it matters much. Actually,
the first time I implemented it, I did EDE (3 keys).
TIS-PEM has some hooks for DES-EDE, but there isn't any code in there
to actually implement it.
So, if people want EDE, I'm content to go back to it. On the other
hand, I'd really like to stick with three independent DES keys. We
almost certainly don't get less security, and probably get a bit more,
essentially for free.
Carl Ellison says, in essence:
Even a minimum-size RSA key for key exchange has plenty of bits for
3 DES keys, so we might as well go for a three-key triple DES and
gain the additional keyspace over a 2-key triple DES. History is riddled with
cases of minimal escalation of security allowing almost uninterrupted
cryptanalysis success.
Richard Outerbridge says:
The de facto standard for double-DES >is< 2-key EDE. If we
want to stay as close as possible to standard practise and familiar
techniques, that's the way to go. Using CBC, of course. This is
absolutely the "most standard" way to go.
If we want to take it to the limit of standard practise, we could
use 3-key EDE. EDE vs. EEE doesn't matter much anymore, I agree,
but EDE is what everyone knows and loves. So use EDE. No one
anywhere (well, in the "private" sector) contemplates or advocates
using 3-key DES in practice. Not ISO, not ANSI, not even textbooks.
If discussed at all it's sort of "If you're >really< paranoid..."
On the other hand I wouldn't be surprised to find out that somewhere
on the bleeding edge, today, exists technology that won't be commonly
available for another forty years or so.
As to what the rest of the world will be using... I still don't think
the rest of the world (at least the commercial world) will be using
double-DES for anything but keys for some time to come. Frankly,
burt, I'm pleasantly surprised that RSA has authorised it for RSAREF.
Neither Atalla nor IBM permit (i.e. they prevent) the use of
double-length data keys. From that jaded perspective it doesn't much
matter what we do: we'll be the first, and the others can follow us.
Marty Hellman says:
Regarding "triple encryption," there is no cryptographic
difference between EEE or EDE (using Mark's notation)
if K1, K2 and K3 are independent. This follows from the
fact that DES does the same operations whether encrypting
or decrypting -- the only difference is that the C and D
key registers shift left or right, depending on encrypt vs
decrypt.
However, I think Mark's question is more directed toward
finding what is the "standard" way of doing triple encryption,
and there is no standard, at least that I am aware of. If I
were implementing it, I would probably do EDE since that
has been proposed as allowing easier compatability with
single encryption: merely set K1=K2=K3.
---------------------------------------------------------------
The conclusion so far:
If no one stops me, I will select 3-key EDE DES for implementation
in RIPEM.
I propose to use the identifier DES-EDE3-CBC for the algorithm
in the PEM (actually, at this point it would be pseudo-PEM)
header line.
Thanks to Mark Henderson and Richard Outerbridge, we already have
code just about ready to go, awaiting resolution of these details.
If anyone has objections, please voice them now.
The final question relates to exactly how the RSAREF API will
be changed to accomodation the additional data encryption mode.
I propose that we simply add an additional parameter to RSAREF's
functions R_XXXPEMBlock, where XXX = Encrypt, Decrypt, Seal, and Open.
This new last parameter would specify the data encryption algorithm.
It would be a manifest constant something like R_ALG_DES_CBC or
R_ALG_DES_EDE_CBC. This ought to be cleared with RSADSI before
distribution of any RIPEM using the new RSAREF.
Opinions?
Mark Riordan mrr at ripem.msu.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22788;
21 May 93 1:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22782;
21 May 93 1:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07855;
21 May 93 1:03 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22753;
21 May 93 1:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22694;
21 May 93 1:01 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa07774;
21 May 93 1:01 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA12203; Fri, 21 May 93 04:59:37 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 04:25:09 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Carl Ellison <cme at ellisun.sw.stratus.com>
Message-Id: <9305210425.AA02802 at ellisun.sw.stratus.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Triple DES
There remain two questions:
whether the CBC feedback will be around each of the three DES instances or
will be a single feedback around the chain of three DESs;
whether the IV(s) should be carried under the RSA key or given in the open.
I would advocate having three feedback paths, three IVs and encrypting them
along with the three keys. I know that current practice is to give the
single IV in the clear (whose suggestion was this?) and that after the 1st
8 bytes, the IV is immaterial -- but 3 IVs cover the first 24 bytes of
message, enough to cover the low entropy start of the output of a decent
compression algorithm. [I know that we're not compressing today but that
doesn't mean we never will, I hope (on performance grounds, not merely on
security grounds).]
- Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02922;
21 May 93 9:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02627;
21 May 93 9:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01176;
21 May 93 9:12 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02619;
21 May 93 9:12 EDT
To: internauts: ;, isoc-interest at relay.sgi.com, ietf at CNRI.Reston.VA.US
Subject: INET'94 dates/location
Date: Fri, 21 May 93 09:12:13 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Vinton G. Cerf" <vcerf at CNRI.Reston.VA.US>
Message-ID: <9305210912.aa02619 at IETF.CNRI.Reston.VA.US>
Apologies for any duplicates of this brief announcement (to isoc
members, isoc-interest list and ietf - which definitely overlaps).
INET'94 is to be held June 13-17, 1994 in Prague, Czech Republic.
This Internet Society annual conference is held in conjunction with
the 5th Joint European Networking Conference (JENC5) and is being
organized by RARE and the Internet Society.
A brief pointer to FTP/email/gopher accessible call for papers will
be sent as soon as the preliminary program is finalized. Hope you
are able to participate.
Vint Cerf
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04173;
21 May 93 10:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04114;
21 May 93 10:17 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa03513;
21 May 93 10:17 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA02164; Fri, 21 May 93 07:16:12 -0700
Message-Id: <9305211416.AA02164 at Mordor.Stanford.EDU>
To: Art Berggreen <art at opal.acc.com>
Cc: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US
Subject: Re: contests...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Thu, 20 May 93 16:18:13 -0700. <9305202318.AA18294 at opal.acc.com>
Date: Fri, 21 May 93 07:16:12 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
---- Included message:
>PS: For those who don't recognize it, the diagram he's chiseling into the
>wall is a map of the Arpanet as of December 1969.
If the reference is that early, it ought to be one of the principle people
involved in early ArpaNet development. Maybe someone like Alex McKenzie,
Steve Crocker, Vint Cerf, Jon Postel, Bob Kahn, or even Larry Roberts.
Since Steve Crocker is listed as author of RFC-1 maybe he is appropriate
(since RFCs are the bible of the Internet).
>From this list of people, back then he also looked the most like a caveman,
including an impressive beard. On the other hand, Jon's beard has always
been an award winner, and back then he only wore sandals. Hmmm. Tough
one to decide.
Since Vint always and only wore suits, he's probably disqualified.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06782;
21 May 93 12:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05206;
21 May 93 11:03 EDT
Received: from ub-gate.UB.com by CNRI.Reston.VA.US id aa04755;
21 May 93 11:03 EDT
Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8])
id AA22662; Fri, 21 May 93 07:52:44 PDT
Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1)
id AA29501; Fri, 21 May 93 10:52:44 EDT
Received: by fenway.andr.UB.com (4.1/SMI-4.1)
id AA09740; Fri, 21 May 93 10:52:42 EDT
Date: Fri, 21 May 93 10:52:42 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Frank T Solensky <solensky at andr.ub.com>
Message-Id: <9305211452.AA09740 at fenway.andr.UB.com>
To: art at opal.acc.com, dcrocker at mordor.stanford.edu
Subject: Re: contests...
Cc: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US
>On the other hand, Jon's beard has always
>been an award winner, and back then he only wore sandals.
"Back then"? He still does, doesn't he?
-- Frank
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07429;
21 May 93 13:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07382;
21 May 93 13:02 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa08526;
21 May 93 13:02 EDT
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8149;
Fri, 21 May 93 13:02:40 EDT
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
id 6997; Fri, 21 May 1993 13:02:31 EDT
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3)
with TCP; Fri, 21 May 93 13:02:30 EDT
Received: from buoy.watson.ibm.com by cyst.watson.ibm.com (AIX 3.2/UCB 5.64/900528)
id AA45226; Fri, 21 May 1993 13:02:32 -0400
Received: by buoy.watson.ibm.com (AIX 3.2/UCB 5.64/900524)
id AA17895; Fri, 21 May 1993 13:02:13 -0400
Date: Fri, 21 May 1993 13:02:13 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: uri at watson.ibm.com
Message-Id: <9305211702.AA17895 at buoy.watson.ibm.com>
To: Mark Riordan <mrr at scss3.cl.msu.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Triple DES
In-Reply-To: <9305210357.AA01077 at scss3.cl.msu.edu>
References: <9305210357.AA01077 at scss3.cl.msu.edu>
Reply-To: uri at watson.ibm.com
Mark Riordan writes:
> 1. Just what form of "triple DES" should be used?
> Some candidates are:
> a. encrypt(encrypt(encrypt(block,k1),k2),k3) [EEE]
> b. encrypt(decrypt(encrypt(block,k1),k2),k1) [traditional EDE]
> c. encrypt(decrypt(encrypt(block,k1),k2),k3) [3-key EDE]
Well, certainly not a). I personally prefer c), but
The most fitting to the circumstances is b), thus I
vote for b).
> 2. What algorithm identifier (e.g., DES-EEE-CBC) should
> be used in the DEK-Info: header line of the output ciphertext?
> Triple DES isn't an official PEM algorithm yet--will it/should it
> ever be?
My opinion - certainly it should. Identifier - how about
DES-EDE-CBC
DES-EDE-CFB (in 64-bit mode)
> Mark Henderson says:
> On the other hand, the 3 key version is easy to implement, and barring a
> breakthrough in the cryptanalysis of MD5, should be more secure (of
> course, all the key bits, IV and padding are essentially pumped out of
> MD5).
>
> As to EDE vs EEE, I don't see that it matters much. Actually,
> the first time I implemented it, I did EDE (3 keys).
I think it does [somewhat].
> So, if people want EDE, I'm content to go back to it. On the other
> hand, I'd really like to stick with three independent DES keys. We
> almost certainly don't get less security, and probably get a bit more,
> essentially for free.
We gain more security, but lose some compatibility, since as
Richard Outerbridge says:
> The de facto standard for double-DES >is< 2-key EDE. If we
> want to stay as close as possible to standard practise and familiar
> techniques, that's the way to go. Using CBC, of course. This is
> absolutely the "most standard" way to go.
> If no one stops me, I will select 3-key EDE DES for implementation
> in RIPEM.
Sure, go ahead! (:-)
> I propose to use the identifier DES-EDE3-CBC for the algorithm
> in the PEM (actually, at this point it would be pseudo-PEM)
> header line.
I'd rather didn't have "3" in that identifier, y'know...
> The final question relates to exactly how the RSAREF API will
> be changed to accomodation the additional data encryption mode.
> I propose that we simply add an additional parameter to RSAREF's
> functions R_XXXPEMBlock, where XXX = Encrypt, Decrypt, Seal, and Open.
> This new last parameter would specify the data encryption algorithm.
> It would be a manifest constant something like R_ALG_DES_CBC or
> R_ALG_DES_EDE_CBC. This ought to be cleared with RSADSI before
> distribution of any RIPEM using the new RSAREF.
Suggestion: be ready to add some more algorithm-defining
constants, so when we go to quadruple DES, or to tripple
IDEA, we won't need to change too much... [No, I'm not
joking :-]
> Opinions?
Super! (:-)
Regards,
Uri.
------------
<Disclaimer>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07884;
21 May 93 13:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07755;
21 May 93 13:27 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa09540;
21 May 93 13:27 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA17390; Fri, 21 May 93 17:25:16 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 16:37:00 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: TCJones at dockmaster.ncsc.mil
Message-Id: <930521163713.070100 at DOCKMASTER.NCSC.MIL>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: DES EDE vs. EEE
>However, I think Mark's question is more directed toward >finding what
is the "standard" way of doing triple encryption, >and there is no
standard, at least that I am aware of. If I >were implementing it, I
would probably do EDE since that >has been proposed as allowing easier
compatibility with >single encryption: merely set K1=K2=K3.
The Banking Industry (ABA & ANSI X9) do use EDE2 as a standard for key
distribution. If you decide to use EDE3, please write the standard such
that 112 bits only must be securely chosen, then the EDE2 will satisfy
the EDE3 proposal. Our company is writing an API which supports EDE2
and not EDE3. Also chips are now available which do EDE encryption
directly, so EEE is not a viable commercial option. If anyone here
cares about commercial products, they will opt for EDE2 over EDE3.
>I would advocate having three feedback paths, three IVs and encrypting
them >along with the three keys. I know that current practice is to
give the >single IV in the clear (whose suggestion was this?) and that
after the 1st >8 bytes, the IV is immaterial -- but 3 IVs cover the
first 24 bytes of >message, enough to cover the low entropy start of the
output of a decent >compression algorithm. [I know that we're not
compressing today but that >doesn't mean we never will, I hope (on
performance grounds, not merely on >security grounds).]
As I have stated before, most standards in business and banking insist
that the IV be sent encrypted. Note that in the case where the start of
the message is most likely not to vary from one message to the next, but
variability starts prior to the sixteenth byte (not the eighth), that
security IS IMPROVED with encrypted IV's.
Tom Jones - Lemcom Systems, Inc dockmaster.ncsc.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08994;
21 May 93 14:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08886;
21 May 93 14:03 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa10718;
21 May 93 14:03 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA17591; Fri, 21 May 93 18:02:13 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 09:20:03 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Stephen D Crocker <crocker at tis.com>
Message-Id: <9305211720.AA03994 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: TIS/PEM will probably have exprimental support for EDE
It turns that we've been thinking about stronger encryption too. We
added EDE2 to our internal "to do" list several days ago, but it's not
on our critical path. (We are very busy wrapping up the next version
of TIS/PEM so we can get it distributed broadly ASAP. EDE2 will
probably not be included, but we will get to it pretty quickly. As
has been noted, the PEM specs and our PEM code are quite modular at
this level, so it's pretty easy to add. Choosing the identifier may
consume more time than the actual implementation :-)
Our default choice is EDE2. However, this is definitely something for
the community to discuss. It seems to me the right criteria are:
(1) cryptographic strength and
(2) agreement among implementors (including availability of hardware products).
With respect to (1), it would be helpful to have input from
knowledgeable cryptographers. It's clearly desirable that whatever
cryptography is chosen not have a flaw or be weaker than expected.
It's also desirable, in my view, not to engage in needless overkill.
In the present discussion, the question on the table seems to be
whether EDE2 is adequate or whether EDE3 is the wiser choice. (If
others see other questions, that's fine; I'm not trying to constrain
the discussion.)
Quite a bit of judgment is involved in these decisions, so inviduals
may disagree.
Question (2) is also important, particularly if there are multiple
choices which are strong enough.
It would be good to get some informed opinion on record here...
Steve
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09369;
21 May 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11131;
21 May 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09316;
21 May 93 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09146;
21 May 93 14:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11017;
21 May 93 14:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09141;
21 May 93 14:10 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, 12-16, July 1993/Amsterdam
Date: Fri, 21 May 93 14:10:33 -0400
X-Orig-Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9305211410.aa09141 at IETF.CNRI.Reston.VA.US>
Dear IETFers:
Following this message (2a) you will receive three more, the contents of
which follow:
IETF MAILING 2b: HOTEL RESERVATION FORM. This form must be returned via
fax to the RAI HOTEL SERVICE by May 31st in order to
guarantee a room. DO NOT SEND THIS FORM TO THE IETF
SECRETARIAT.
IETF MAILING 2c: IETF RSVP FORM. Payment DOES NOT need to accompany the
RSVP Form, but the Form must be received by June 11th
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 2d: DRAFT AT-A-GLANCE. This is still in draft form.
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 CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09375;
21 May 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11135;
21 May 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09313;
21 May 93 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09219;
21 May 93 14:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11066;
21 May 93 14:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09209;
21 May 93 14:11 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: ietf-rsvp at CNRI.Reston.VA.US
REPLY-TO: ietf-rsvp at CNRI.Reston.VA.US
Subject: IETF MAILING 2d: DRAFT AT-A-GLANCE: 12-16 July 1993/Amsterdam
Date: Fri, 21 May 93 14:11:19 -0400
X-Orig-Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9305211411.aa09209 at IETF.CNRI.Reston.VA.US>
27th INTERNET ENGINEERING TASK FORCE Mailing Date : 5/21/93
DRAFT AT-A-GLANCE Mailing Number: 2d
DATES: 12-16 July 1993 HOST(S):
Erik Huizer/SURFnet
MEETING SITE: RAI Congress Centre
Europaplein
NL-1078 GZ Amsterdam
Phone: +31.(0) 20.5491212
HOTEL: Refer to IETF MAILING 2b for Hotel information.
Also available via ftp: 0mtg-hotel-ams.txt
NEWCOMER'S Sunday, 11 July 1993
ORIENTATION: 16:30pm - 17:30
Location: TBD
PRE-REGISTRATION: Sunday, 11 July 1993
18:00 - 20:00 (reception during)
RAI Congress Centre
Location: TBD
REGISTRATION: Monday, 12 July 1993
08:00 - 18:00
Tuesday, 13 July - Thursday, 15 July 1993
08:30 - 18:00
Friday, 16 July 1993
08:30 - 12:00
RAI Congress Centre
Location: TBD
ATTENDANCE FEE: PAYMENT BY: Credit Card or Check
$200.00 if registered on or before 11 June 1993
$220.00 if registered AFTER 11 June 1993
CAR RENTAL: Don't rent a car. Public transportation is
very easy. Cabs work too.
AIRPORT: Schiphol Airport
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09390;
21 May 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11130;
21 May 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09311;
21 May 93 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09163;
21 May 93 14:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11028;
21 May 93 14:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09157;
21 May 93 14:10 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 2b: Hotel Reservation Form: 12-16, July 1993/Amsterdam
Date: Fri, 21 May 93 14:10:47 -0400
X-Orig-Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9305211410.aa09157 at IETF.CNRI.Reston.VA.US>
Dear IETF'ers:
July 12-16, 1993 is the 27th Internet Engineering Task Force which
will be held in Amsterdam at the RAI Congress Centre. The RAI has
it's own Hotel Service which was able to negotiate lower Hotel rates
than I was able to. To obtain these lower rates you MUST register
through the RAI Hotel Service. They have provided the form below,
which I have slightly modified. Please fill out the form according
to the instructions and fax or mail it to the RAI. DO NOT RETURN YOUR
FORM TO THE SECRETARIAT.
Megan
P.S. According to our local host :>> In Europe there are only two sorts
of rooms:
>> SINGLE - contains one bed of aprox. 3 feet wide
>> DOUBLE - contains either two beds of 3 feet each,
or 1 bed of min. 6 feet
>>
>> (We don't do Queens or King Size)
HOTEL BOOKING FORM (page 1 of 2) - 29th IETF, 12-16, July 1993 - (Please Print)
Return this HOTEL BOOKING FORM before May 31, 1993 to: RAI HOTEL SERVICE
Europaplein, NL 1078 GZ AMSTERDAM. Phone: +31 (0) 205491927
Fax : +31 (0) 206462840
***After May 31st***, hotel accommodation cannot be guaranteed, though
requests will still be accepted.
Surname_____________________________________________ Initials___________
Organization____________________________________________________________
Address_________________________________________________________________
_________________________________________________________________
Postal Code and City____________________________________________________
Country_________________________________________________________________
Telephone______________________________ Facsimile_______________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Date of Arrival in Amsterdam_____________ Date of Departure____________
Single Room_____________ Double Room_____________
Preferred Hotel_________________________________ (see page two)
"I prefer the following hotel which is not listed on the HOTEL BOOKING FORM."
Hotel Name:_______________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
DEPOSIT: A guarantee via credit card, a cheque* made out to the RAI HOTEL
SERVICE, or a deposit of Dfl. 250 per room is required. After
receipt of your payment/credit card details, a voucher will be
forwarded to you. Payment must be made in Dutch Guilders. All
costs to transmitter's charge (approx. Dfl. 25 per transfer)
NO ROOMS CAN BE CONFIRMED UNTIL YOUR HOTEL DEPOSIT/CREDIT CARD
GUARANTEE HAS BEEN RECEIVED!!!!!
AMEX____ Diners____ Master____ Visa____ Eurocard ____ Access____
Account No._____________________________ Expiration Date_________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
___Remitted by enclosed cheque payable to RAI HOTEL SERVICE (* personal
cheques cannot be accepted.) The deposit paid will be deductible from
your hotel bill upon presentation of this voucher at the reception desk
of the hotel.
___Remitted to RAI HOTEL SERVICE account No. 54.96.42.528 with the ABN-AMRO
Bank at Amsterdam, the Netherlands,
IETF93, Mr./Ms.____________________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
HOTEL BOOKING FORM (page 2 of 2) - 29th IETF, 12-16, July 1993
Hotel accommodation at reduced rates can be reserved in the following hotels:
Hotel Name Stars Single Double Bkfst Incl.
--------------------------------------------------------
Holiday Inn (1) 5 Dfl. 210 Dfl. 255 No
Novotel (1) 4 Dfl. 210 Dfl. 240 Yes
Altea (2) 3 Dfl. 220 Dfl. 220 Yes
(1) Hotel located within walking distance of the RAI.
(2) Hotel located near the RAI.
CANCELLATION: Notification of cancellation must be sent in writing, (postal
mail or facsimile) no later than 72 hours (three days) prior
to originally scheduled arrival time. Notification after this
time will automatically result in a charge of Dfl. 250.
REFUNDS : Refunds, minus administration costs of Dfl. 50, will be dealt
with after the conference.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09395;
21 May 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11146;
21 May 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09318;
21 May 93 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09182;
21 May 93 14:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11038;
21 May 93 14:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09175;
21 May 93 14:11 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 2c: IETF RSVP FORM: 12-16, July 1993/Amsterdam
Date: Fri, 21 May 93 14:11:04 -0400
X-Orig-Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9305211411.aa09175 at IETF.CNRI.Reston.VA.US>
REGISTRATION FORM
27th Internet Engineering Task Force - Page 1 of 2
12-16 July 1993
Amsterdam, The Netherlands
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, 11 July NEWCOMER'S ORIENTATION at
16:30?
YES___ NO___
Do you plan to attend the Sunday, 11 July reception at 18:00?
YES___ NO___
$200.00 Registration postmarked on or BEFORE Friday, 11 June 1993.
$220.00 ($200.00 + $20.00 late fee) Registration postmarked after
Friday, 11 June 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 - 27th IETF Meeting
1895 Preston White Drive, Suite 100
Reston, VA 22091-5434 USA
^L
REGISTRATION FORM
27th Internet Engineering Task Force - Page 2 of 2
12-16 July 1993
Amsterdam, The Netherlands
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 Wednesday, 7 July, 1993.
8. Requests for refunds must be received by Wednesday, 7 July, 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: 27th IETF Meeting - Amsterdam, The Netherlands.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09658;
21 May 93 14:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09611;
21 May 93 14:25 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa11461;
21 May 93 14:25 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA17784; Fri, 21 May 93 18:23:36 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 17:42:13 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Ellison <cme at ellisun.sw.stratus.com>
Message-Id: <9305211742.AA04369 at ellisun.sw.stratus.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: TIS/PEM will probably have exprimental support for EDE
I, personally, see nothing wrong with implementing both EDE2 and EDE3
as options.
The coding time is almost nil.
Both sides of the discussion are satisfied.
Anyone using software DES can send and receive all options.
Someone with single DES hardware can send and receive all options.
Anyone with EDE3 hardware can send and receive all options.
Anyone with EDE2 hardware can send all options (using (k1,k2,k1) as his
EDE3 key) and can receive E1 and EDE2 at full speed. If an EDE3 message is
received, the recipient would have to use the EDE2 hardware as straight DES
hardware and run the message through it three times. So, decryption would
take 3x the time. If this were a problem, that recipient could make it
known that EDE2 is the preferred mode when talking with him/her.
However, this reopens my question about number of IVs and the scope of
the CBC feedback path.
If someone were to decrypt an EDE3 message through single-DES hardware or
EDE2 in single-DES mode, it would be maximally convenient to have the chip
run in CBC mode for each pass and therefore to have an individual IV for
each pass.
- Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10400;
21 May 93 14:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10336;
21 May 93 14:48 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa12458;
21 May 93 14:48 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18064; Fri, 21 May 93 18:49:07 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 10:09:54 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Kent <kent at bbn.com>
Message-Id: <9305211811.AA20575 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305210425.AA02802 at ellisun.sw.stratus.com>
Subject: Re: Triple DES
Carl,
I'm confused by your set of "two more questions." I assumed
that Mark was proposing use of DES as a three pass code book (e.g., in
EDE or EEE). This use would still encrypt a single, 8-byte block of
user data or generate a single, 8-byte block of key stream for each
invocation of the underlying code book. So, if one were using this as
the code book for CBC, I would expect there to be exactly one feedback
stream generated by the (now 3-pass) codebook. Similarly, I would
expect there to be exactly one, 8-byte IV to "prime" this mode.
Finally,I have not seen a message clearly defining what added security
accrues from encrypting the IV, assuming that good IV generation
procedures are employed. We know that encryption of the IV is
important in an application with no anciliary integrity mechansims,
but this is not the case for PEM.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10549;
21 May 93 14:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10494;
21 May 93 14:53 EDT
Received: from uu3.psi.com by CNRI.Reston.VA.US id aa12657; 21 May 93 14:53 EDT
Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA09876 for ietf at CNRI.Reston.VA.US; Fri, 21 May 93 14:53:30 -0400
Date: Fri, 21 May 1993 14:53:53 -0400
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Bob Natale <natale at acec.com>
Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. )
id AA12129; Fri, 21 May 1993 14:53:53 -0400
Message-Id: <9305211853.AA12129 at nips.acec.com>
To: ietf at CNRI.Reston.VA.US
Subject: DES *related* NIST policy comments
If you do not care to read a long exchange giving some official (?)
US Government input *related* to the recent DES thread, delete this
message now.
I apologize for posting this message to the ietf list if indeed
the DES thread has died or at least gone into medicinal hibernation,
or if the I have misjudged the level of interest evidenced by the
number of recent messages.
In any case, the following is from the TELECOM DIGEST mailing
list. It is mostly a discussion of NIST's view of the Clipper
Chip technology. Interesting references are made to DES export
policy, the President's "Encryption Policy Management" directive,
and an imminent Government review of "cryptographic policy".
To avoid "out-of-context" problems, I have included the full
text of the complete message.
----- Begin included message -----
Date: Mon, 17 May 1993 16:44:28 -0400 (EDT)
From: ROBACK at ECF.NCSL.NIST.GOV
Subject: Answers to Your Questions
To: jim at RSA.COM
To: Mr. Jim Bidzos, RSA Data Security, Inc.
From: Ed Roback, NIST
Mr. Ray Kammer asked me to forward to you our answers to the questions
you raised in your e-mail of 4/27.
We've inserted our answers in your original message.
------------------------------------------------------
From: SMTP%"jim at RSA.COM" 27-APR-1993 03:13:12.75
To: clipper at csrc.ncsl.nist.gov
Subj: Clipper questions
Date: Tue, 27 Apr 93 00:11:50 PDT
From: jim at RSA.COM (Jim Bidzos)
Here are some questions about the Clipper program I would like to
submit.
Much has been said about Clipper and Capstone (the term Clipper will
be used to describe both) recently. Essentially, Clipper is a
government-sponsored tamper-resistant chip that employs a classified
algorithm and a key escrow facility that allows law enforcement, with
the cooperation of two other parties, to decipher Clipper-encrypted
traffic. The stated purpose of the program is to offer
telecommunications privacy to individuals, businesses, and government,
while protecting the ability of law enforcement to conduct
court-authorized wiretapping.
The announcement said, among other things, that there is currently no
plan to attempt to legislate Clipper as the only legal means to
protect telecommunications. Many have speculated that Clipper, since
it is only effective in achieving its stated objectives if everyone
uses it, will be followed by legislative attempts to make it the only
legal telecommunications protection allowed. This remains to be seen.
>>>> NIST: There are no current plans to legislate the use of Clipper.
lipper will be a government standard, which can be - and
likely will be - used voluntarily by the private sector. The
option for legislation may be examined during the policy
review ordered by the President.
The proposal, taken at face value, still raises a number of serious
questions.
What is the smallest number of people who are in a position to
compromise the security of the system? This would include people
employed at a number of places such as Mikotronyx, VSLI, NSA, FBI, and
at the trustee facilities. Is there an available study on the cost
and security risks of the escrow process?
>>>> NIST: It will not be possible for anyone from Mykotronx, VLSI,
NIST, NSA, FBI (or any other non-escrow holder) to
compromise the system. Under current plans, it would be
necessary for three persons, one from each of the escrow
trustees and one who knows the serial number of the Clipper
Chip which is the subject of the court authorized electronic
intercept by the outside law enforcement agency, to conspire
in order to compromise escrowed keys. To prevent this, it
is envisioned that every time a law enforcement agency is
provided access to the escrowed keys there will be a record
of same referencing the specific lawful intercept
authorization (court order). Audits will be performed to
assure strict compliance. This duplicates the protection
afforded nuclear release codes. If additional escrow agents
are added, one additional person from each would be required
to compromise the system. NSA's analysis on the security
risks of the escrow system is not available for public
dissemination.
How were the vendors participating in the program chosen? Was the process
open?
>>>> NIST: The services of the current chip vendors were obtained in
accordance with U.S. Government rules for sole source
procurement, based on unique capabilities they presented.
Criteria for selecting additional sources will be
forthcoming over the next few months.
AT&T worked with the government on a voluntary basis to use
the "Clipper Chip" in their Telephone Security Device. Any
vendors of equipment who would like to use the chips in
their equipment may do so, provided they meet proper
government security requirements.
A significant percentage of US companies are or have been the subject
of an investigation by the FBI, IRS, SEC, EPA, FTC, and other
government agencies. Since records are routinely subpoenaed,
shouldn't these companies now assume that all their communications are
likely compromised if they find themselves the subject of an
investigation by a government agency? If not, why not?
>>>> NIST: No. First of all, there is strict and limited use of
subpoenaed material under the Federal Rules of Criminal
Procedure and sanctions for violation. There has been no
evidence to date of Governmental abuse of subpoenaed
material, be it encrypted or not. Beyond this, other
Federal criminal and civil statutes protect and restrict the
disclosure of proprietary business information, trade
secrets, etc. Finally, of all the Federal agencies cited,
only the FBI has statutory authority to conduct authorized
electronic surveillance. Electronic surveillance is
conducted by the FBI only after a Federal judge agrees that
there is probable cause indicating that a specific
individual or individuals are using communications in
furtherance of serious criminal activity and issues a court
order to the FBI authorizing the interception of the
communications.
What companies or individuals in industry were consulted (as stated in
the announcement) on this program prior to its announcement? (This
question seeks to identify those who may have been involved at the
policy level; certainly ATT, Mikotronyx and VLSI are part of industry,
and surely they were involved in some way.)
>>>> NIST: To the best of our knowledge: AT&T, Mykotronx, VLSI, and
Motorola. Other firms were briefed on the project, but not
"consulted," per se.
Is there a study available that estimates the cost to the US
government of the Clipper program?
>>>> NIST: No studies have been conducted on a government-wide basis to
estimate the costs of telecommunications security
technologies. The needs for such protection are changing
all the time.
There are a number of companies that employ non-escrowed cryptography
in their products today. These products range from secure voice,
data, and fax to secure email, electronic forms, and software
distribution, to name but a few. With over a million such products in
use today, what does the Clipper program envision for the future of
these products and the many corporations and individuals that have
invested in and use them? Will the investment made by the vendors in
encryption-enhanced products be protected? If so, how? Is it
envisioned that they will add escrow features to their products or be
asked to employ Clipper?
>>>> NIST: Again, the Clipper Chip is a government standard which can
be used voluntarily by those in the private sector. We also
point out that the President's directive on "Public
Encryption Management" stated: "In making this decision, I
do not intend to prevent the private sector from developing,
or the government from approving, other microcircuits or
algorithms that are equally effective in assuring both
privacy and a secure key-escrow system." You will have to
consult directly with private firms as to whether they will
add escrow features to their products.
Since Clipper, as currently defined, cannot be implemented in
software, what options are available to those who can benefit from
cryptography in software? Was a study of the impact on these vendors
or of the potential cost to the software industry conducted? (Much of
the use of cryptography by software companies, particularly those in
the entertainment industry, is for the protection of their
intellectual property.)
>>>> NIST: You are correct that, currently, Clipper Chip functionality
can only be implemented in hardware. We are not aware of a
solution to allow lawfully authorized government access when
the key escrow features and encryption algorithm are
implemented in software. We would welcome the participation
of the software industry in a cooperative effort to meet
this technical challenge. Existing software encryption use
can, of course, continue.
Banking and finance (as well as general commerce) are truly global
today. Most European financial institutions use technology described
in standards such as ISO 9796. Many innovative new financial products
and services will employ the reversible cryptography described in
these standards. Clipper does not comply with these standards. Will
US financial institutions be able to export Clipper? If so, will
their overseas customers find Clipper acceptable? Was a study of the
potential impact of Clipper on US competitiveness conducted? If so, is
it available? If not, why not?
>>>> NIST: Consistent with current export regulations applied to the
export of the DES, we expect U.S. financial institutions
will be able to export the Clipper Chip on a case by case
basis for their use. It is probably too early to ascertain
how desirable their overseas customers will find the Clipper
Chip. No formal study of the impact of the Clipper Chip has
been conducted since it was, until recently, a classified
technology; however, we are well aware of the threats from
economic espionage from foreign firms and governments and we
are making the Clipper Chip available to provide excellent
protection against these threats. As noted below, we would
be interested in such input from potential users and others
affected by the announcement. Use of other encryption
techniques and standards, including ISO 9796 and the ISO
8730 series, by non-U.S. Government entities (such as
European financial institutions) is expected to continue.
I realize they are probably still trying to assess the impact of
Clipper, but it would be interesting to hear from some major US
financial institutions on this issue.
>>>> NIST: We too would be interested in hearing any reaction from
these institutions, particularly if such input can be
received by the end of May, to be used in the
Presidentially-directed review of government cryptographic
policy.
Did the administration ask these questions (and get acceptable
answers) before supporting this program? If so, can they share the
answers with us? If not, can we seek answers before the program is
launched?
>>>> NIST: These and many, many others were discussed during the
development of the Clipper Chip key escrow technology and
the decisions-making process. The decisions reflect those
discussions and offer a balance among the various needs of
corporations and citizens for improved security and privacy
and of the law enforcement community for continued legal
access to the communications of criminals.
------------------------------
----- End included message -----
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10643;
21 May 93 14:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10586;
21 May 93 14:55 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa12737;
21 May 93 14:54 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18134; Fri, 21 May 93 18:53:39 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 10:16:12 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Kent <kent at bbn.com>
Message-Id: <9305211817.AA21071 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <930521163713.070100 at DOCKMASTER.NCSC.MIL>
Subject: Re: DES EDE vs. EEE
I agree with Tom's suggestion for EDE as the preferred approach, and
for avoiding overkill (fi we have not already passed that point).
Availability of hardware that does EDE is certainly a reasonable input
to the decision process. I disagree with the suggestion for any need
to encipher the IV, and note my previous message about using EDE as a
code book, in which there would be just one IV and only the first 8
bytes of the message would be involved, as is currently the case.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10869;
21 May 93 15:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10825;
21 May 93 14:59 EDT
Received: from osi-west.es.net by CNRI.Reston.VA.US id aa13026;
21 May 93 14:59 EDT
Received: from viipuri.nersc.gov by osi-west.es.net with SMTP (PP)
id <29110-0 at osi-west.es.net>; Fri, 21 May 1993 11:59:23 +0000
Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA11648;
Fri, 21 May 93 11:59:20 PDT
Date: Fri, 21 May 93 11:59:20 PDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Ari Ollikainen <ari at es.net>
Message-Id: <9305211859.AA11648 at viipuri.nersc.gov>
To: art at opal.acc.com, dcrocker at mordor.stanford.edu, solensky at andr.ub.com
Subject: Re: contests...
Cc: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US
> >On the other hand, Jon's beard has always
> >been an award winner, and back then he only wore sandals.
>
> "Back then"? He still does, doesn't he?
> -- Frank
>
Ummm..."Back then" Jon Postel went mostly barefoot. I wore the sandals...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ari Ollikainen ari at es.net National Energy Research Supercomputer Center
ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory
510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11321;
21 May 93 15:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11219;
21 May 93 15:09 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa13456;
21 May 93 15:09 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18308; Fri, 21 May 93 19:08:07 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 17:28:42 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Ellison <cme at ellisun.sw.stratus.com>
Message-Id: <9305211728.AA04337 at ellisun.sw.stratus.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: DES EDE vs. EEE
>Date: Fri, 21 May 93 12:37 EDT
>From: TCJones at DOCKMASTER.NCSC.MIL
>Subject: DES EDE vs. EEE
>Message-Id: <930521163713.070100 at DOCKMASTER.NCSC.MIL>
>The Banking Industry (ABA & ANSI X9) do use EDE2 as a standard for key
>distribution. If you decide to use EDE3, please write the standard such
>that 112 bits only must be securely chosen, then the EDE2 will satisfy
>the EDE3 proposal.
I don't understand this request. Could you be specific? EDE2 is clearly a
subset of EDE3. If one user had EDE2 hardware and was talking to an EDE3
user, the EDE2 user could send (k1,k2,k1) as the key. However, the EDE3
user would still send (k1,k2,k3).
Is that OK?
If not, aren't you asking for an EDE2 option as well as (or instead of) the
EDE3 option?
> Our company is writing an API which supports EDE2
>and not EDE3. Also chips are now available which do EDE encryption
>directly, so EEE is not a viable commercial option. If anyone here
>cares about commercial products, they will opt for EDE2 over EDE3.
Are you suggesting that someone may want to use those EDE chips rather
than software DES for PEM?
>As I have stated before, most standards in business and banking insist
>that the IV be sent encrypted.
Bravo.
What does any standard say about the number of IVs for chained DES
(EDE2 or EDE3)?
- Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11524;
21 May 93 15:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11426;
21 May 93 15:11 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa13650;
21 May 93 15:11 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18419; Fri, 21 May 93 19:09:55 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 10:30:36 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Stephen D Crocker <crocker at tis.com>
Message-Id: <9305211830.AA21619 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305211742.AA04369 at ellisun.sw.stratus.com>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
It's highly preferable to avoid unnecessary proliferation. If EDE2
and EDE3 are both defined, anyone who can *receive* both is in good
shape, but if you want to be sure your intended recipient can handle
what you're sending, you pretty have to choose EDE2.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11589;
21 May 93 15:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11460;
21 May 93 15:11 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa13690;
21 May 93 15:11 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18423; Fri, 21 May 93 19:10:03 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 10:29:45 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Kent <kent at bbn.com>
Message-Id: <9305211831.AA21679 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305211728.AA04337 at ellisun.sw.stratus.com>
Subject: Re: DES EDE vs. EEE
Carl,
You've been a fan of encrypting IVs in several messages.
Could you provide an explanation of why this would be an important
feature, in the context of PEM? The general "rules of thumb" under
which cryptoalgorithms have been evaluated for some time (and which
Diffie and Hellman described in publications about 15 years ago),
assume that a good algorithm shuld be resistant to attack even in the
face of known of chosen plaintext. Thus, the observation that data at
the beginning of an encrypted message may be highly predictable is
generally regarded as not an especially serious concern (relative to
recovery of the encryption key). The thrust of the arguments being
made seems to be that we should encrypt the IV to provide more
protection for the first block of plaintext being enciphered vs. layer
blocks (since the IV for a later block is just the preceeding
ciphertext block). If one can identify highly predictable data in the
second or third block, this argument for enciphering the IV becomes
obviously silly. I would suggest that the likelihood of such
predictable data in subsequent (8-byte) blocks is increasing all the
time, e.g., as a result of PEM-MIME formats, and thus any benefits of
associated with encrypting the IV are too minor to warrent the effort.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11806;
21 May 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11745;
21 May 93 15:17 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa13998;
21 May 93 15:17 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18491; Fri, 21 May 93 19:16:05 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 18:42:20 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Ellison <cme at ellisun.sw.stratus.com>
Message-Id: <9305211842.AA04445 at ellisun.sw.stratus.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Triple DES
>Message-Id: <9305211810.AA08601 at transfer.stratus.com>
>Subject: Re: Triple DES
>Date: Fri, 21 May 93 14:09:54 -0400
>From: Steve Kent <kent at BBN.COM>
Steve,
there are two ways to define triple DES in EDE mode. As a thought
experiment, they use three DES chips in sequence.
In the mode you define, the three chips are run in ECB mode and some
logic outside the three chips can be added to provide CBC feedback and
initialization (IV).
In the other mode, the three chips are run in CBC mode, each with its
own IV.
In the second case, you have 3 IVs rather than 1. You also have the
possibility to use a chip which implements single DES-CBC in a full pass
over the data. In the mode you described, you would have to use the
one chip in ECB mode and keep changing keys for every block in order to
get the final ciphertext to XOR with the next plaintext block.
As to whether to encrypt the IV under the RSA key, to my preference we
should encrypt by default since we have the space within a single operation
of RSA with the minimum key length. I know that the IV is irrelevant after
the first bytes of the stream because CBC is designed to re-sync, but there
are families of messages (compressed ones, for example) which have
increasing entropy as the message stream proceeds -- so that there is
reason to protect the start of the message more thoroughly than you would
protect the middle or end. A secret IV does just that.
- Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12528;
21 May 93 15:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12425;
21 May 93 15:35 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa14936;
21 May 93 15:35 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18719; Fri, 21 May 93 19:35:00 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 10:57:21 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Stephen D Crocker <crocker at tis.com>
Message-Id: <9305211857.AA23012 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305211847.AA04459 at ellisun.sw.stratus.com>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
>> If he's receiving something very large, I would expect (from
>> netiquette) that large thing to have a very small distribution
>> list. In that case, the recipients are known and presumably their
>> performance preferences are also.
I think your last sentence crosses an important threshold and may have
fairly bad consequences. It's indeed true that I can't send
*anything* to you that's encrypted unless I know important things
about you, viz your public key and your e-mail address. However, I
don't feel at all comfortable suggesting that I need to know whether
you can handle EDE3 as easily as EDE2. This means I have to build up
and maintain this extra piece of information, and there's no good
infrastructure for doing so.
Further, the vast majority of people are not in a position to know
whether EDE2 is good enough. I think it's our responsibility to say
something useful in this arena. If EDE2 is good enough, then we ought
not be shy about using it. If EDE2 is not good enough, then we ought
not promote it.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12535;
21 May 93 15:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12433;
21 May 93 15:35 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa14960;
21 May 93 15:35 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18723; Fri, 21 May 93 19:35:11 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 10:57:11 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Kent <kent at bbn.com>
Message-Id: <9305211858.AA23108 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305211830.AA21619 at TIS.COM>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
I concur with Steve Crocker's observation: we do not want to
proliferate modes unnecessarily. The form of the argunent should not
be "if it's only a little more work let's do it" but rather "what will
adding yet another variant buy us?"
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12800;
21 May 93 15:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12686;
21 May 93 15:41 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa15176;
21 May 93 15:41 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18791; Fri, 21 May 93 19:39:49 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 18:59:10 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Ellison <cme at ellisun.sw.stratus.com>
Message-Id: <9305211859.AA04494 at ellisun.sw.stratus.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: DES EDE vs. EEE
>Message-Id: <9305211830.AA09473 at transfer.stratus.com>
>Subject: Re: DES EDE vs. EEE
>Date: Fri, 21 May 93 14:29:45 -0400
>From: Steve Kent <kent at BBN.COM>
Steve,
you wrote:
> You've been a fan of encrypting IVs in several messages.
>Could you provide an explanation of why this would be an important
>feature, in the context of PEM? The general "rules of thumb" under
>which cryptoalgorithms have been evaluated for some time (and which
>Diffie and Hellman described in publications about 15 years ago),
>assume that a good algorithm shuld be resistant to attack even in the
>face of known of chosen plaintext.
Yes, this is true. It's also a rule of thumb that a cryptosystem should be
strong even if the system is known by the enemy. However, that does not
mean that the system should always be published. The NSA keeps algorithms
secret. It's a small roadblock for a determined enemy, but a roadblock.
It certainly stops us, for example, in finding holes in Skipjack.
In the case of IVs, this is a small roadblock. A system strong under
chosen plaintext is even less vulnerable under ciphertext-only. I can't
quantify the difference but I can be certain that it's < and not <=.
In the specific case of IVs with PEM, I noticed when I started seeing PEM
messages that the IV (in hex) stood out as a field. There was no reason,
to my mind, to single it out or to publish it in the clear. There is
plenty of room inside the RSA encrypted key for 3 full DES keys and 3 full
IVs (or 2 or 1). Putting the IV(s) there shortens the PEM header and
simplifies it. It lumps together the parameters which would be passed to
the DES routines in one place. They become available all at once (in a
single structure?) and that structure could be handed to the DES routines
intact. Therefore, if I were designing this code, I would have placed all
this information there -- if only for cleanliness of design. Granted, this
is personal preference of the worst sort: programming style. I have no
desire to call someone else's style wrong. I'm just trying to answer your
question about why I'm a fan of putting the IV in with the key under RSA.
I fully agree that a system should not count in any way on secrecy of the
IV for its security. That would imply a fatal weakness in the system, I
believe. However, that doesn't mean that there's something wrong with
transmitting the IV encrypted under the RSA key.
- Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12845;
21 May 93 15:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12747;
21 May 93 15:42 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa15240;
21 May 93 15:42 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA18902; Fri, 21 May 93 19:43:07 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 19:09:44 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Ellison <cme at ellisun.sw.stratus.com>
Message-Id: <9305211909.AA04524 at ellisun.sw.stratus.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: TIS/PEM will probably have exprimental support for EDE
>Message-Id: <9305211857.AA23012 at TIS.COM>
>Subject: Re: TIS/PEM will probably have exprimental support for EDE
>Date: Fri, 21 May 93 14:57:21 -0400
>From: Stephen D Crocker <crocker at TIS.COM>
Steve,
I think you've hit the nail with this one:
>Further, the vast majority of people are not in a position to know
>whether EDE2 is good enough. I think it's our responsibility to say
>something useful in this arena. If EDE2 is good enough, then we ought
>not be shy about using it. If EDE2 is not good enough, then we ought
>not promote it.
We have no way of knowing whether any given algorithm is "good enough". I
suspect that if anyone could answer that, he'd also be able to answer
?P=NP? and a number of other interesting questions.
What we know is that EDE2 is better than E1. We also know that EDE3 is
better than EDE2. We also know that EDE3 is the same work as EDE2, unless
someone happens to have a chip which implements EDE2 and doesn't allow
EDE3. Since I don't have such a chip, only today heard that there was
one on the market and doubt that I would buy one, I'm not a major fan of
EDE2 over EDE3. For me, EDE3 being the same work as EDE2 and being more
secure is enough to make my decision.
>However, I
>don't feel at all comfortable suggesting that I need to know whether
>you can handle EDE3 as easily as EDE2. This means I have to build up
>and maintain this extra piece of information, and there's no good
>infrastructure for doing so.
I agree that there is no such machinery. However, I'm not suggesting that
any of us needs to know whether the other person can handle EDE3 as easily as
EDE2. We don't know today if the recipient has H/W or S/W DES. The only
way we would find out would be by being told.
What I suspect, for my own use, is that if I were sending small encrypted
messages (a few K long), the 3x for someone who has DES hardware is a drop
in the bucket. It's when I'm sending something very long (100K+) that
it matters. In my situation, the time I'd send something that large is
when sending it to our other engineering centers. It wouldn't be one transfer
but would be one of a large number of similar transfers (part of normal
traffic). For that pattern of traffic, if my buddy at the far end finds
that his machine is taking too long to decrypt, he could suggest to me
that I use EDE2 mode -- and in that exceptional case, I would do so.
However, I see this as a very exceptional case. For all normal traffic,
I envision using EDE3.
- Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13276;
21 May 93 16:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13181;
21 May 93 16:02 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa16095;
21 May 93 16:02 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA19134; Fri, 21 May 93 19:57:27 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 19:01:00 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: TCJones at dockmaster.ncsc.mil
Message-Id: <930521190135.067745 at DOCKMASTER.NCSC.MIL>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Non-repudiation
Gentle PEM nuts:
As I wait for a TIS-PEM distribution, which never seems to come, I have
been experimenting with decoding some of the PEM messages which have
been sent to this list. Interestingly enough, I have found that the
TIS-PEM messages appear to follow the standard, however they do not
exhibit the property of non-repudiation. I list below what I have found
in the hope that someone can show how this could be.
RFC11421 says: ----------------------------------------------------
3. Services, Constraints, and Implications
This RFC defines mechanisms to enhance privacy for electronic mail
transferred in the Internet. The facilities discussed in this RFC
provide privacy enhancement services on an end-to-end basis between
originator and recipient processes residing at the UA level or above.
No privacy enhancements are offered for message fields which are
added or transformed by intermediate relay points between PEM
processing components.
If an originator elects to perform PEM processing on an outbound
message, all PEM-provided security services are applied to the PEM
message's body in its entirety; selective application to portions of
a PEM message is not supported. Authentication, integrity, and (when
asymmetric key management is employed) non-repudiation of origin
services are applied to all PEM messages; confidentiality services
are optionally selectable.
.
.
.
Based on these principles, the following facilities are provided:
1. disclosure protection,
2. originator authenticity,
3. message integrity measures, and
4. (if asymmetric key management is used) non-repudiation of
origin,
4.6.1.1.1 ENCRYPTED
The "ENCRYPTED" specifier signifies that confidentiality,
authentication, integrity, and (given use of asymmetric key
management) non-repudiation of origin security services have been
applied to a PEM message's encapsulated text. ENCRYPTED messages
require a "DEK-Info:" field and individual Recipient-ID and "Key-
Info:" fields for all message recipients.
---------------------------------------------------------------------
First of all I should note that there is a discrepancy about when
non-repudiation is actually provided, but, be that as it may, it is my
contention that non-repudiation is only present in the case where the
"Originator-Certificate" Field is provided. In the case where
"Originator-ID-Asymmetric" Field is provided, there is no protected name
of the originator, thus there is no origin to protect. Now some may say
that the "To:" field in the header could provide this, but that field is
not protected against alteration, and, in fact, mail gateways are in the
very business of altering that field. My own copy of the pem-dev
mailings does not including anything like a meaningful "To:" field which
is why I have had to ask several people who a message in pem-dev was
authored by.
Some may also say that knowing the Issuing-Authority (from the
"Originator-ID-Asymmetric" Field) is sufficient to nail down the origin,
but that is only true if I can request the the name of the owner just by
having the public component of the key. That looks like "caller-ID" and
it certainly doesn't look like PEM (ie PRIVACY ENHANCED Mail). In any
case, I don't know why a CA would give me a name just knowing the value.
All-in-all, I would say that PEM cannot make the claim that "...,
non-repudiation of origin services are applied to all PEM messages" as
RFC1421 does.
Tom Jones - ViaCrypt div. of Lemcom Sys dockmaster.ncsc.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13576;
21 May 93 16:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13502;
21 May 93 16:21 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa16961;
21 May 93 16:21 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA19411; Fri, 21 May 93 16:20:10 -0400
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 07:30:32 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Brad Huntting <huntting at advtech.uswest.com>
Message-Id: <9305211930.AA03195 at futureworld.advtech.uswest.com.advtech.uswest.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305211857.AA23012 at TIS.COM>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
> Further, the vast majority of people are not in a position to know
> whether EDE2 is good enough. I think it's our responsibility to say
> something useful in this arena. If EDE2 is good enough, then we ought
> not be shy about using it. If EDE2 is not good enough, then we ought
> not promote it.
Regarless of wheather EDE2 is "good enough" today, will it last as long
as EDE3? It seems likely that EDE2 will be compromised long before
EDE3 is simply because of it's smaller key size.
Let's avoid any unnessesary "planed obsolesence" and stick to the
strongest encryption methods reasonably available, ok?
brad
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13578;
21 May 93 16:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13542;
21 May 93 16:21 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa16993;
21 May 93 16:21 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA19407; Fri, 21 May 93 16:20:03 -0400
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 18:47:24 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Ellison <cme at ellisun.sw.stratus.com>
Message-Id: <9305211847.AA04459 at ellisun.sw.stratus.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: TIS/PEM will probably have exprimental support for EDE
>Message-Id: <9305211830.AA21619 at TIS.COM>
>Subject: Re: TIS/PEM will probably have exprimental support for EDE
>Date: Fri, 21 May 93 14:30:36 -0400
>From: Stephen D Crocker <crocker at TIS.COM>
Steve,
you wrote:
>It's highly preferable to avoid unnecessary proliferation. If EDE2
>and EDE3 are both defined, anyone who can *receive* both is in good
>shape, but if you want to be sure your intended recipient can handle
>what you're sending, you pretty have to choose EDE2.
I understand. However, even a person with only an EDE2 chip can receive
all modes. That's one reason EDE was chosen -- so that it knew how to
operate as a single E.
Therefore, there is no reason for the sender to choose EDE2 unless he
has a request from some recipient to do so for performance reasons.
I would expect that to be extremely unlikely. If a recipient has DES
hardware, he's already far ahead of me in performance. If he's receiving
something very large, I would expect (from netiquette) that large thing to
have a very small distribution list. In that case, the recipients are known
and presumably their performance preferences are also.
- Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13710;
21 May 93 16:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13673;
21 May 93 16:33 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa17215;
21 May 93 16:33 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA19540; Fri, 21 May 93 20:31:31 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 20:40:06 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Raymond Lau <raylau at mit.edu>
Message-Id: <9305211950.AA18735 at MIT.EDU>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Triple DES
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
MIIBxTCCAWECARIwDQYJKoZIhvcNAQECBQAwTTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJzb25hIENl
cnRpZmljYXRlMB4XDTkzMDQxMjIyNTI1N1oXDTk1MDQxMjA1MDAwMFowYzELMAkG
A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
VQQLExNQZXJzb25hIENlcnRpZmljYXRlMRQwEgYDVQQDEwtSYXltb25kIExhdTB5
MAoGBFUIAQECAgMAA2sAMGgCYQC4Lq5eHwr4u4bY7VggmpOwmyqhq9nMVR7VuaUy
4MOTPLPHi/dZM5E2gdODG1uV2YoGDNNTuVFRO4osQwxTOWMt9oEththrXOYI6oZ8
lzyYfmgLVL15S7HCV/GYJdlPuO0CAwEAATANBgkqhkiG9w0BAQIFAANPAAUVNpom
zLBp6r72gqG6bBU1eFbv9bNKk4WSQCXYRbulGmhyLCXItASYloprlBxKHm8EP178
P8z1rlbRNAoWw2G5q2550I6UUiJ5OOkVwB==
MIC-Info: RSA-MD5,RSA,
lTseoQ7YapjkRdsuA8YgFUP2MILA7WIMhLwyZVo2dvmYyeRewagzLzlm1cTwU74n
RIsG50Fa/RJmzxukw08ojOVuBeEfTO/h263Fm5lhvHrv1FHKuW2sCl5JgzhswK8d
Here're my more refined thoughts based on what I've read on this topic.
1. Without question, EDE is to be preferred over EEE. The remnants from
the "before DES was shown not to be a group," and hence the origin of
EDE, seem to be more widely understood and even in some use. I can see
no benefit for doing EEE over EDE.
2. EDE should be treated as a new cipher, in cookbook mode as Steve Kent
mentions, and CBC should be performed on the output of the whole thing.
To perform DES-CBC/encrypt followed by DES-CBC/decrypt followed by
DES-CBC/encrypt, which is what I think Carl is suggesting, does not offer
any proven benefit (and only marginal skeptical benefit) and is certainly
incompatible with any systems which may exist for doing EDE. Doing this
strange variant of CBC will probably raise more doubts than offer
reassurances.
3. Encrypted IVs. I agree that they cannot hurt, security-wise, but do not
feel that they contribute any added security except in the case where
no signature is included and hence the first block may be manipulated if
known to the attacker. To say that they help substantially in attacking
the first block implies that DES is vulnerable to known pt attacks and
my response would be to jump ship. Furthermore, non-encrypted IVs are
in conformance with PEM as it stands now.
4. 2 vs 3 keys. This one is the real toss up. While I feel comfortable with
2 keys security-wise, I do not see why we need to cripple ourselves by not
going the full 3 key route unless there're good compatibility reasons.
However, all indications are that the existing systems which use 2 keys
will not be used for PEM so we free to play this one as we wish. I am
tempted then to go for 3 keys.
5. On the identifier -- I agree with the proposals so far as they clearly
identify EDE and 3 keys. (Although the 3 looks out of place! :-)
6. On RSAREF interfaces -- I don't think that's an important issue worth
occupying bandwidth on this list.
-Ray
-----END PRIVACY-ENHANCED MESSAGE-----
Created with RIPEM Mac.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13801;
21 May 93 16:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13766;
21 May 93 16:39 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa17416;
21 May 93 16:39 EDT
Received: by xap.xyplex.com id <AA15896 at xap.xyplex.com>; Fri, 21 May 93 16:40:49 -0500
Date: Fri, 21 May 93 16:40:49 -0500
Message-Id: <9305212140.AA15896 at xap.xyplex.com>
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: Carl Ellison's message of Fri, 21 May 1993 17:42:13 GMT <9305211742.AA04369 at ellisun.sw.stratus.com>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
Isn't this stuff a bit too deep to be dumping on the entire IETF mailing list?
Shouldn't you guys go talk in a conference room instead of shouting in the
hall outside everybody's office?
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14012;
21 May 93 16:51 EDT
Received: from regal.cisco.com by IETF.CNRI.Reston.VA.US id aa13978;
21 May 93 16:50 EDT
Received: by regal.cisco.com; Fri, 21 May 1993 13:50:51 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Walter Griffeth <wgriff at cisco.com>
Message-Id: <199305212050.AA29170 at regal.cisco.com>
Subject: UNSUBSCRIBE
To: ietf at IETF.CNRI.Reston.VA.US
Date: Fri, 21 May 93 13:50:50 PDT
X-Mailer: ELM [version 2.3 PL11]
Please remove me from all distribution lists for IETF.
Walt
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14087;
21 May 93 16:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14050;
21 May 93 16:55 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa18117;
21 May 93 16:55 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA19748; Fri, 21 May 93 20:55:03 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 20:19:03 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Dusse <spock at rsa.com>
Message-Id: <9305212019.AA27422 at RSA.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <930521190135.067745 at DOCKMASTER.NCSC.MIL>
Subject: DES modes...
Howdy all,
Let me place my firm vote in the camp to NOT proliferate more modes
than are absolutely necessary. Most users of PEM will not even be
able to spell DES much less keep track of their intended recipient's
preferred algorithm, software/hardware availability, restrictions,
etc.
As far as how many keys to use, if 3 keys are better than 2 (which
seems to be true by assertion) than why not use 4 or 5. What is the
tradeoff ? If 2^112 (a big f*ing number) is not acceptable, what
makes 2^168 acceptable ? If DES is broken by some means other than
brute force, then the extra burden if another DES operation may do
very little to the security.
My preference would be to go with a single standard (even at the risk
of phasing-out current use of single-DES) which balances security,
ease of implementation, and (my favorite) export issues. (Have we
forgotten our place in the global Internet community ? Shall we doom
all US PEM manufacturers to the "support multiple versions or don't sell
outside the US" curse ?)
Cheers,
Steve D.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14749;
21 May 93 17:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14719;
21 May 93 17:23 EDT
Received: from [128.212.48.70] by CNRI.Reston.VA.US id aa19081;
21 May 93 17:23 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA19966; Fri, 21 May 93 21:21:41 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 12:46:33 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Stephen D Crocker <crocker at tis.com>
Message-Id: <9305212046.AA00702 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305212019.AA27422 at RSA.COM>
Subject: Export???? (Was Re: DES modes... )
Steve,
You wrote:
>> My preference would be to go with a single standard (even at the risk
>> of phasing-out current use of single-DES) which balances security,
>> ease of implementation, and (my favorite) export issues. (Have we
>> forgotten our place in the global Internet community ? Shall we doom
>> all US PEM manufacturers to the "support multiple versions or don't sell
>> outside the US" curse ?)
I agree with this list. However, this thread is discussing how to get
an algorithm that is noticeably stronger than DES, so I've assumed
we're foregoing all possibility of export. Do see any hope of
choosing an algorithm in the EDE2 range or better that will be
exportable?
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15552;
21 May 93 18:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15505;
21 May 93 18:08 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa20340;
21 May 93 18:08 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA20356; Fri, 21 May 93 22:06:01 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 20:15:36 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Carl Ellison <cme at ellisun.sw.stratus.com>
Message-Id: <9305212015.AA04688 at ellisun.sw.stratus.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Triple DES
>Message-Id: <9305211950.AA18735 at MIT.EDU>
>Date: Fri, 21 May 93 15:40:06 EST
>From: raylau at MIT.EDU (Raymond Lau)
>Subject: Re: Triple DES
Ray,
the only place I really take exception is with:
>2. EDE should be treated as a new cipher, in cookbook mode as Steve Kent
> mentions, and CBC should be performed on the output of the whole thing.
> To perform DES-CBC/encrypt followed by DES-CBC/decrypt followed by
> DES-CBC/encrypt, which is what I think Carl is suggesting, does not offer
> any proven benefit (and only marginal skeptical benefit) and is certainly
> incompatible with any systems which may exist for doing EDE. Doing this
> strange variant of CBC will probably raise more doubts than offer
> reassurances.
If someone has a DES chip which does CBC mode by itself, it is *far* more
efficient to encrypt a batch with k1, then do the batch with k2 and then
do the batch with k3. In brutal detail:
If you define CBC for EDE as a single feedback path around all three then
you are forced to use the single chip as:
XOR 8 bytes of plaintext with the IV
set key 1
do 8 bytes
set key 2
do 8 bytes
set key 3
do 8 bytes
save the ciphertext as the next IV
If you define CBC mode for EDE3 as CBC around each instance, then you can
set key 1 and IV1
do a batch of bytes in CBC mode
save the final ciphertext 8 bytes as the next IV1
set key 2 and IV2
do a batch of bytes in CBC mode
save the final ciphertext 8 bytes as the next IV2
set key 3 and IV3
do a batch of bytes in CBC mode
save the final ciphertext 8 bytes as the next IV3
The batch size depends on your buffer capacity.
- Carl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15824;
21 May 93 18:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15786;
21 May 93 18:34 EDT
Received: from [128.212.48.70] by CNRI.Reston.VA.US id aa20918;
21 May 93 18:34 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA20601; Fri, 21 May 93 22:33:03 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 21:26:00 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: TCJones at dockmaster.ncsc.mil
Message-Id: <930521212616.425714 at DOCKMASTER.NCSC.MIL>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: EDE and encrypted IV's
>>The Banking Industry (ABA & ANSI X9) do use EDE2 as a standard for key
>>distribution. If you decide to use EDE3, please write the standard
such >>that 112 bits only must be securely chosen, then the EDE2 will
satisfy >>the EDE3 proposal.
>I don't understand this request. Could you be specific? EDE2 is
clearly a >subset of EDE3. If one user had EDE2 hardware and was
talking to an EDE3 >user, the EDE2 user could send (k1,k2,k1) as the
key. However, the EDE3 >user would still send (k1,k2,k3).
My request is not related to the syntax issues, which are, as you point
out, proper subset questions, but rather to the accompanying standard
which may require full (pseudo)random generation of all 168 bits of EDE3
as opposed to the 112 independent bits in EDE2.
- -
>> Our company is writing an API which supports EDE2 >>and not EDE3.
Also chips are now available which do EDE encryption >>directly, so EEE
is not a viable commercial option. If anyone here >>cares about
commercial products, they will opt for EDE2 over EDE3.
>Are you suggesting that someone may want to use those EDE chips rather
>than software DES for PEM?
Right on! and for several reasons (eg. security perimeters)
- -
>>As I have stated before, most standards in business and banking insist
>>that the IV be sent encrypted.
>What does any standard say about the number of IV's for chained DES
>(EDE2 or EDE3)?
The EDE standards currently only address ECB mode and none of the
chained modes that are in discussion here. The chained modes that
required encrypted IV's are only used with single key DES. I know of no
chained EDE standard.
- -
>If someone were to decrypt an EDE3 message through single-DES hardware
or >EDE2 in single-DES mode, it would be maximally convenient to have
the chip >run in CBC mode for each pass and therefore to have an
individual IV for >each pass.
I know of no hardware which will chain and triple encrypt.
- -
> You've been a fan of encrypting Iv's in several messages. >Could you
provide an explanation of why this would be an important >feature, in
the context of PEM? The general "rules of thumb" under >which
cryptoalgorithms have been evaluated for some time (and which >Diffie
and Hellman described in publications about 15 years ago), >assume that
a good algorithm should be resistant to attack even in the >face of
known of chosen plaintext.
Please distinguish between an attempt by academics to evaluate good
algorithms by making simplifying assumptions, and the real-world
question of "Is one approach significantly more efficacious than some
other approach?" As you point out the question can only be answered in
the context of PEM (or some other real-world encryption problem.)
- -
> Thus, the observation that data at >the beginning of an encrypted
message may be highly predictable is >generally regarded as not an
especially serious concern (relative to >recovery of the encryption
key). The thrust of the arguments being >made seems to be that we
should encrypt the IV to provide more >protection for the first block of
plaintext being enciphered vs. layer >blocks (since the IV for a later
block is just the preceding >ciphertext block). If one can identify
highly predictable data in the >second or third block, this argument for
enciphering the IV becomes >obviously silly. I would suggest that the
likelihood of such >predictable data in subsequent (8-byte) blocks is
increasing all the >time, e.g., as a result of PEM-MIME formats, and
thus any benefits of >associated with encrypting the IV are too minor to
warrant the effort.
Note that from a practical point (not from that of a theoretical
"how-good-is-this-algorithm" point), if the first 8 bytes of subsequent
messages were always identical, (and protected by good encrypted IV's)
then 1) if the next 8 bytes were also identical we would have a known-
plaintext attack on one block of data, but 2) if the next 8 bytes
differed by 1 bit between subsequent messages, the known-plaintext
attack would suffer a work factor increase of 100% and 3) if the next 8
bytes differed by 2 bits, the known-plaintext attack would increase in
work factor by 300% (and so on.)
This does not seem "too minor to warrant the effort."
Tom Jones - ViaCrypt div. of Lemcom Sys dockmaster.ncsc.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16399;
21 May 93 19:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16360;
21 May 93 19:07 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa21761;
21 May 93 19:07 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA20885; Fri, 21 May 93 23:05:11 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 14:29:05 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Kent <kent at bbn.com>
Message-Id: <9305212230.AA06849 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305211857.AA23012 at TIS.COM>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
Steve,
Your observation about extra pieces of information (what
algorithm suites do you support) gets at the heart of a concern of
mine. I agree completely. I do fear that this EDE2 vs. EDE3 vs.
vanilla DES discussion is not easily resolved in terms of "how good is
good enough."
Despite papers describing how one might attack DES using
massively parallel machines, and with parameters based on known
plaintext attacks against ECB mode, we have never seen any indication
of such devices being developed, the thorough analysis of the
feasiblity of building and maintaining them, the added work factor
implied by use of CBC or CFB, etc. I was a member of a
(NIST-assembled) group that investigated the DES over 15 years ago
when many of these discussions were first taking place. I've seen no
substantive progress on breaking a full, 16-round DES reported
anywhere, despite a decade and a half of work by a wide variety of
very talented people around the world. So, a decision to move from
this point and adopt a higher work factor algorithm (with degraded
performence) is not likely to be justified by good some quantitative
measure of risk.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16605;
21 May 93 19:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16525;
21 May 93 19:11 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa21907;
21 May 93 19:11 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA08646; Fri, 21 May 93 16:11:22 -0700
Message-Id: <9305212311.AA08646 at Mordor.Stanford.EDU>
To: Steve Kent <kent at bbn.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: TIS/PEM will probably have exprimental support for EDE
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Fri, 21 May 93 10:57:11 +0000. <9305211858.AA23108 at TIS.COM>
Date: Fri, 21 May 93 16:11:21 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Mts: smtp
A point about human factors, which is intended to add to the arguments
from both Steve's:
---- Included message:
From: Steve Kent <kent at bbn.com>
I concur with Steve Crocker's observation: we do not want to
proliferate modes unnecessarily. The form of the argunent should not
be "if it's only a little more work let's do it" but rather "what will
adding yet another variant buy us?"
Combinatorials kill utility. A major contributing factor to the
success of the Internet protocols is the CAREFULLY chosen, LIMITED
set of options. That is, the sub-text to Steve K's phrasing of the
important question "what will it buy us?" is: "and it better be
really wonderful".
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16945;
21 May 93 19:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16886;
21 May 93 19:19 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa22228;
21 May 93 19:19 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA20986; Fri, 21 May 93 23:18:25 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 14:39:14 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Steve Kent <kent at bbn.com>
Message-Id: <9305212240.AA07205 at TIS.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305211859.AA04494 at ellisun.sw.stratus.com>
Subject: Re: DES EDE vs. EEE
Carl,
When PEM was developed, we tried to design it for use in both
symmetric and asymmetric key management environments, and the first
PEM implementations were based on symmetric key management.
Your observation about room for an IV, or several IVs and
multiple keys in a single block encrypted under RSA is true in this
case, but need not be true in general. Thus, from the standpoint of
trying to design a protocol that is largely algorithm independent, it
would be undesirable to specify encryption of the IV along with the
message key, unless there was strong motivation to do so. The
argument of "it fits" might not always be true. Also, there is a
design goal of using techniques which are amenable to hardware as well
as software implementation. Many good comsec module designs strongly
separate KEKs vs. DEKs and IVs. The modules usually follow the
modified "Roach Motel" principle: "keys go in but they don't come
out." Encrypting an IV along with the DEK requires the module to tell
the two apart and to use each appropriately. This potential problem
is avoided by keeping what gets enciphered under a KEK (in this case,
the public key of the recipient) to be just the DEK (the message key).
Admittedly this may not be a high priority now in the Internet, but it
is a good design principle to follow.
So, there is more than a matter of coding taste involved here.
There are broader design goals that motivate the specific structure
adopted in PEM. I believe they are still relevant.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17629;
21 May 93 19:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17570;
21 May 93 19:51 EDT
Received: from HQ.TGV.COM by CNRI.Reston.VA.US id aa23085; 21 May 93 19:51 EDT
Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ;
Fri, 21 May 93 16:51:37 PDT
Received: from karl.sheriff-bart.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1)
id AA08043; Fri, 21 May 93 16:51:55 PDT
Date: Fri, 21 May 93 16:51:55 PDT
Message-Id: <9305212351.AA08043 at mel-brooks.empirical.com>
To: kent at bbn.com
Subject: Re: Triple DES
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Reply-To: karl at empirical.com
cc: ietf at CNRI.Reston.VA.US
X-Orig-Sender: karl at mel-brooks.empirical.com
Repository: empirical.com
Originating-Client: sheriff-bart.empirical.com
A related set of questions that have never received an answer in the
15 years I've been asking is:
If DES is run multi-pass in block mode, is the result the same as
some single pass with a different key?
If DES is run multi-pass in the various block or feedback modes, is
the result the same as some single pass with a different key and/or
IV?
Boiled down, the question is "Does multi pass DES" really buy any
increased security?"
--karl--
> I'm confused by your set of "two more questions." I assumed
> that Mark was proposing use of DES as a three pass code book (e.g., in
> EDE or EEE). This use would still encrypt a single, 8-byte block of
> user data or generate a single, 8-byte block of key stream for each
> invocation of the underlying code book. So, if one were using this as
> the code book for CBC, I would expect there to be exactly one feedback
> stream generated by the (now 3-pass) codebook. Similarly, I would
> expect there to be exactly one, 8-byte IV to "prime" this mode.
> Finally,I have not seen a message clearly defining what added security
> accrues from encrypting the IV, assuming that good IV generation
> procedures are employed. We know that encryption of the IV is
> important in an application with no anciliary integrity mechansims,
> but this is not the case for PEM.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17664;
21 May 93 19:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17611;
21 May 93 19:52 EDT
Received: from bridge2.NSD.3Com.COM by CNRI.Reston.VA.US id aa23095;
21 May 93 19:52 EDT
Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA07872
(5.65c/IDA-1.4.4nsd for <ietf at CNRI.Reston.VA.US>); Fri, 21 May 1993 16:52:40 -0700
Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA22133
(5.65c/IDA-1.4.4-910725 for <ietf at CNRI.Reston.VA.US>); Fri, 21 May 1993 16:52:38 -0700
Message-Id: <199305212352.AA22133 at remmel.NSD.3Com.COM>
To: ietf at CNRI.Reston.VA.US
Subject: Re: DES EDE vs. EEE
In-Reply-To: Your message of "Fri, 21 May 93 18:59:10 GMT."
<9305211859.AA04494 at ellisun.sw.stratus.com>
Date: Fri, 21 May 93 16:52:38 -0700
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: tracym at nsd.3com.com
I have found some of this discussion interesting, but it seems to be
generating a lot of mail for the general ietf list. Could it be moved
back to a more appropriate (and private;-) list? Thanks,
Tracy
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18307;
21 May 93 20:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18236;
21 May 93 20:28 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa23987;
21 May 93 20:28 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA21510; Sat, 22 May 93 00:26:05 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 21:07:29 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Raymond Lau <raylau at mit.edu>
Message-Id: <9305212012.AA19617 at MIT.EDU>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: Re: Non-repudiation
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric:
ME0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
LjEcMBoGA1UECxMTUGVyc29uYSBDZXJ0aWZpY2F0ZQ==,12
MIC-Info: RSA-MD5,RSA,
O7HHAVx5U3n3/6mwYT9erNdG2nI7NKTCu43ROghKxkUlvGs6SIHaSORuWqe/MCdn
eaNzAuywk3LdAA6cjE0fgOomn7aGYqf5vKpyBlqQ7b5mt0Q6YIAfrbFsu1eqlfUb
> In the case where
> "Originator-ID-Asymmetric" Field is provided, there is no protected name
> of the originator, thus there is no origin to protect.
When Originator-ID-Asymmetric is used, it points to a specific certificate
and presumes that the recipient already has or is able to obtain that
certificate. (Or you can follow up with a msg. to the purported
originator asking for his certificates...)
Thus, it's substitutable for a certificate.
For example, in a previous msg., I had included a certificate so if you had
ran that msg. through a PEM implementation, it would've cached the certificate.
Thus, you can verify that this msg. was signed by the same certificate.
If you didn't care to run my previous msg. through PEM and have since disposed
of it, you can always ask me to send you my certificates. Or, if the RSA
Persona CA provided retrieval services, which it doesn't, you may be able
to send it a request for the certificate identified in this msg.
-Ray
-----END PRIVACY-ENHANCED MESSAGE-----
Created with RIPEM Mac.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18332;
21 May 93 20:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18250;
21 May 93 20:28 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa24008;
21 May 93 20:28 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA21501; Sat, 22 May 93 00:25:59 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Fri, 21 May 1993 07:01:36 GMT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Ned Freed <NED at sigurd.innosoft.com>
Message-Id: <01GYFXNWAFHG8ZDVUL at SIGURD.INNOSOFT.COM>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305211720.AA03994 at TIS.COM>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
Note: This may be something that most PEM-DEV readers are already aware of -- if
so, I apologize.
> However, this is definitely something for
> the community to discuss. It seems to me the right criteria are:
> (1) cryptographic strength and
> With respect to (1), it would be helpful to have input from
> knowledgeable cryptographers. It's clearly desirable that whatever
> cryptography is chosen not have a flaw or be weaker than expected.
> It's also desirable, in my view, not to engage in needless overkill.
A paper was published a few years back (in Cryptologia, I think -- my journals
are presently in boxes in my garage so it is difficult for me to check) on the
subject of whether or not the set of 2^56 permutations DES can perform forms a
subgroup of the enormously larger permutation group of order 2^64.
(For those of you who are not inclined towards group theory a brief explanation
may be appropriate here. One of the key properties of a group or subgroup is
called closure, which means that the composition of any two elements of the
group produces another element of the group. In DES terms this would mean that
multiple applications of DES would be exactly equivalent to a single
application of DES with some different key. This would be a Bad Thing, since it
would mean that multiple applications of DES are meaningless since they would
always be equivalent to some single applications of DES, albeit with a
different key.)
Complete analysis of DES has thus far proved to be an intractable problem (at
least in the open literature ;-), so the authors of this papers used an
approach suggested by some recent results in computational and probabalistic
group theory. Specifically, if you apply a particular permutation operation
enough times it will eventually produce the value you started with. And the
number of applications on average tends to fall within certain ranges of values
if you are taking the permutations from a group.
The authors hooked up some DES chips and set them to cycling; this is a very
fast operation and it does not take too long to find the cycle lengths. And
lo and behold the cycle lengths turned out to be very different from what
you'd expect a subgroup of the permutation to produce. This therefore offers
extremely strong evidence (not a proof, mind you, but the chances of getting
bogus results here are very small) that set of permutations DES can perform
is not a subgroup of the permutation group.
Stacking multiple DES operations appears to be a Good Thing as a result; it
appears to be roughly equivalent to having a system that actually has a 56*N
bit key.
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19160;
21 May 93 21:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19138;
21 May 93 21:43 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa25479;
21 May 93 21:43 EDT
Received: from itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-12)
id <AA07419>; Fri, 21 May 1993 18:43:55 -0700
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA08559; Fri, 21 May 93 21:43:53 EDT
Date: Fri, 21 May 93 21:43:53 EDT
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Ran Atkinson <atkinson at itd.nrl.navy.mil>
Message-Id: <9305220143.AA08559 at itd.nrl.navy.mil>
To: ietf at isi.edu
Subject: PEM discussions invade IETF list
Could you PEM folks please mv your discussion to a PEM Developers
list or some other suitable place and get it out of the IETF main list ???
It really is a lot like talking very loudly in the hallway when a
conference room is available...
Yours for low volume lists,
Ran
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25291;
21 May 93 23:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25219;
21 May 93 23:42 EDT
Received: from SIGURD.INNOSOFT.COM by CNRI.Reston.VA.US id aa28022;
21 May 93 23:42 EDT
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992)
id <01GYG7B8TZBK8ZDV1W at SIGURD.INNOSOFT.COM>; Fri, 21 May 1993 20:42:18 PDT
Date: Fri, 21 May 1993 20:20:47 -0700 (PDT)
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: Ned Freed <NED at sigurd.innosoft.com>
Subject: RE: Triple DES
In-reply-to: Your message dated "Fri, 21 May 1993 16:51:55 -0700 (PDT)"
<9305212351.AA08043 at mel-brooks.empirical.com>
To: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" <karl at empirical.com>
Cc: kent at bbn.com, ietf at CNRI.Reston.VA.US
Message-id: <01GYG87UKCMS8ZDV1W at SIGURD.INNOSOFT.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
> A related set of questions that have never received an answer in the
> 15 years I've been asking is:
> If DES is run multi-pass in block mode, is the result the same as
> some single pass with a different key?
In general the answer is no. (There's always a slight chance that things will
cancel out, but it is *extremely* unlikely). See my earlier posting on this
topic for details. I also checked out the proper reference for this and it is:
B.S. Kalinski, R. L. Rivest, A. T. Sherman, "Is DES a Group?", Journal
of Cryptology, Volume 1 Number 1, 1988.
> If DES is run multi-pass in the various block or feedback modes, is
> the result the same as some single pass with a different key and/or
> IV?
Again, no.
> Boiled down, the question is "Does multi pass DES" really buy any
> increased security?"
While there's no absolute proof of this I'm aware of, the evidence that it does
buy you much greater security is pretty overwhelming.
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20145;
24 May 93 4:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20141;
24 May 93 4:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21202;
24 May 93 4:39 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20124;
24 May 93 4:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20087;
24 May 93 4:33 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa21133;
24 May 93 4:33 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.00668-0 at bells.cs.ucl.ac.uk>; Mon, 24 May 1993 09:33:30 +0100
To: Stephen D Crocker <crocker at tis.com>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: Export???? (Was Re: DES modes... )
In-reply-to: Your message of "Fri, 21 May 93 12:46:33 GMT." <9305212046.AA00702 at TIS.COM>
Date: Mon, 24 May 93 09:33:25 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Message-ID: <9305240433.aa21133 at CNRI.Reston.VA.US>
>>> outside the US" curse ?)
this inundation, while laudably technical, must surely be on a narrower
topic than befits this broad focus list
by it, you are also exporting an extradordinary amount of crypto-expertise
from the US:-)
jon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23532;
24 May 93 9:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23528;
24 May 93 9:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27821;
24 May 93 9:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23516;
24 May 93 9:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23510;
24 May 93 9:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27811;
24 May 93 9:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa23504;
24 May 93 9:51 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: mospf at comet.cit.cornell.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: IP Multicast over Token-Ring Local Area Networks
to Proposed Standard
Date: Mon, 24 May 93 09:51:52 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305240951.aa23504 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Multicast Extensions to OSPF
Working Group to consider <draft-pusateri-tokenring-lan-02.txt> "IP
Multicast over Token-Ring Local Area Networks" 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
June 7th.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26527;
24 May 93 12:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26523;
24 May 93 12:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03939;
24 May 93 12:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26502;
24 May 93 12:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26421;
24 May 93 12:03 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa03733;
24 May 93 12:03 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA07294; Mon, 24 May 93 16:02:28 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Mon, 24 May 1993 06:43:23 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald T. Davis" <don at gza.com>
Message-Id: <9305241443.AA19126 at pad-thai.aktis.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
Subject: subscription request
don davis geer zolot assoc., 1 main st. cambridge ma 02142
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27057;
24 May 93 12:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27053;
24 May 93 12:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05540;
24 May 93 12:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27032;
24 May 93 12:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26967;
24 May 93 12:30 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa05471;
24 May 93 12:30 EDT
Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1457;
Mon, 24 May 93 12:30:49 EDT
Received: from YKTVMH by watson.vnet.ibm.com with "VAGENT.V1.0"
id 3543; Mon, 24 May 1993 12:30:39 EDT
Received: from cyst.watson.ibm.com by yktvmh.watson.ibm.com (IBM VM SMTP V2R3)
with TCP; Mon, 24 May 93 12:30:26 EDT
Received: from buoy.watson.ibm.com by cyst.watson.ibm.com (AIX 3.2/UCB 5.64/900528)
id AA55207; Mon, 24 May 1993 12:29:21 -0400
Received: by buoy.watson.ibm.com (AIX 3.2/UCB 5.64/900524)
id AA19961; Mon, 24 May 1993 12:29:15 -0400
Date: Mon, 24 May 1993 12:29:15 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: uri at watson.ibm.com
Message-Id: <9305241629.AA19961 at buoy.watson.ibm.com>
To: Carl Ellison <cme at ellisun.sw.stratus.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Triple DES
In-Reply-To: <9305212015.AA04688 at ellisun.sw.stratus.com>
References: <9305212015.AA04688 at ellisun.sw.stratus.com>
Reply-To: uri at watson.ibm.com
Carl Ellison writes:
> >2. EDE should be treated as a new cipher, in cookbook mode as Steve Kent
> > mentions, and CBC should be performed on the output of the whole thing.
>
> If someone has a DES chip which does CBC mode by itself, it is *far* more
> efficient to encrypt a batch with k1, then do the batch with k2 and then
> do the batch with k3.
I definitely agree with Carl. Whatever mode you choose, it better
not be ECB... Besides, DES chips indeed are available now, while
special EDE-capable hardware may take time to arrive (if ever :-).
Regards,
Uri.
------------
<Disclaimer>
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28128;
24 May 93 13:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09886;
24 May 93 13:39 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28114;
24 May 93 13:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28015;
24 May 93 13:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09849;
24 May 93 13:36 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa28009;
24 May 93 13:36 EDT
To: IETF-Announce: ;
Subject: Amsterdam IETF Social Event Announcement
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: train at rare.nl
Date: Mon, 24 May 93 13:36:26 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9305241336.aa28009 at IETF.CNRI.Reston.VA.US>
AMSTERDAM IETF SOCIAL EVENT
"Training through The Netherlands"
12 juli 1993
Summary
--------
This is to announce the Amsterdam IETF Social event. IETF
participants, their partners and their children are welcome. Note that
participation is limited to 150 people, so register fast for this
social and do it to the correct mailaddress: <train at rare.nl> any mail
on this subject to any other mailbox will be ignored! Registrations
should state Name, amount of people and if (any) vegetarian(s).
Introduction
------------
There are three forms of transport that are characteristic for The
Netherlands:
- Boats; We have a long history as a sailing nation.
- Bicycles; lots and lots of them.
- Trains. One of the best countrywide infrastructures in the world,
and it can barely cope.
Of these the first is already often used for IETF social events, and is
as such not very original. The second does not fit well with food,
drinks and groupconversation, so we decided on the third.
The Event
---------
On monday night 12 July 1993, at 17:55 (that's 5:55 pm local time) a
train especially reserved for this event will depart from RAI station
for a trip around The Netherlands. Those who will be aboard will have a
chance to see most of The Netherlands due to the fact that The
Netherlands is relatively small, and the fact that in July, the sun
does not disappear until 23:00 (11:00 pm).
The train will take the following route (static routing) through The
Netherlands:
Amsterdam RAI-Weesp
along the outskirts of Amsterdam, with some
views of the IJsselmeer
Weesp-Amersfoort
along the beautifull village of Naarden (famous for
it's old fort), the Gooise nature reserve and
through the Gooise forrest.
Amersfoort-Apeldoorn
On to the Veluwe, forrests, moors and sanddunes
Apeldoorn-Deventer
Crossing the IJssel, one of the famous rivers
Deventer-Arnhem
Along the IJssel valley, typical Dutch picturesque views
Arnhem-'s-Hertogenbosch
Farmers country and so flat!
's-Hertogenbosch-Breda
Southern villages
Breda-Rotterdam
The biggest port in the World. Some of it's most impressive
architecture right alongside the tracks.
Rotterdam-The Hague
Seat of the Dutch Government, passes through Delft
perhaps the most beautifull city in The Netherlands
The Hague-Schiphol
along the Tulip fields, alas they blossom in May
Schiphol- Amsterdam RAI
arrival at around 23:00 (11:00 pm).
Food and Drinks
---------------
Unfortunately, due to the holiday season we do not have the
availabillity over enough Dining cars to serve warm food at tables.
Therefore assorted food will be served on special plates. The view
will certainly make up for the possible loss of quality in the food,
and otherwise the drinks will. To make sure that drinking arrangements
are optimal two Bar coaches will be available.
Costs
-----
This is a Dutch treat :-)
Participation costs are 65 Dutch guilders per person (that is $ 35 at
the current rate). This includes the traintrip, the food AND all the
drinks. The 65 guilders are to be payed in cash (only!) at the Sunday
Night IETF reception on the 11th of July, or the next morning before
noon. After 12 July noon people on the Waiting list will be allowed
to fill in the remaining places. Payment can be made at a special desk
right beside the IETF registration Desk.
Registration for the Social event
---------------------------------
There are only 150 places available for IETF participants and their
partners. The first 150 requests to arrive at the mailbox
<train at rare.nl> will be awarded. All subsequent requests will be put
on a waiting list. To register send mail to <train at rare.nl> stating
your name, the amount of people (max 4) and whether any vegetarian
food is required. Registration does mean a commitment to pay the 65
guilders per person! Once the limit of 150 participants is reached a
list of people registered for the social event will be send out to
ietf-announce.
Sponsors
--------
Of course a train rental is much more expensive than 65 guilders per
person. The following sponsors have contributed to make it possible
anyhow:
SURFnet bv
RARE
------------
Erik Huizer
SURFnet bv
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28916;
24 May 93 14:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28912;
24 May 93 14:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10816;
24 May 93 14:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28886;
24 May 93 14:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28814;
24 May 93 14:01 EDT
Received: from dirtydog.ima.isc.com by CNRI.Reston.VA.US id aa10789;
24 May 93 14:01 EDT
Received: by dirtydog.ima.isc.com (5.61/1.34)
id AA08194; Mon, 24 May 93 17:59:43 GMT
Received: from GATEWAY by dirtydog with netnews
for ietf at nri.reston.va.us (ietf at nri.reston.va.us)
To: ietf at CNRI.Reston.VA.US
Date: Mon, 24 May 1993 08:48:05 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Geer <geer at gza.com>
Message-Id: <9305241648.AA22247 at pad-thai.aktis.com>
Organization: INTERACTIVE/SHL
X-Orig-Sender: ietf-request at CNRI.Reston.VA.US
References: <9305241443.AA19126 at pad-thai.aktis.com>
Subject: Re: subscription request
don davis geer zolot assoc., 1 main st. cambridge ma 02142
we already get this in a newgroup here at gza
--dan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00945;
24 May 93 15:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00939;
24 May 93 15:23 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa14036;
24 May 93 15:23 EDT
Received: by bitsy.MIT.EDU
id AA26182; Mon, 24 May 93 15:07:26 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA26176; Mon, 24 May 93 15:07:25 EDT
Received: from inet-gw-2.pa.dec.com by MIT.EDU with SMTP
id AA01697; Mon, 24 May 93 15:07:22 EDT
Received: by inet-gw-2.pa.dec.com; id AA23983; Mon, 24 May 93 12:07:17 -0700
Received: by us1rmc.bb.dec.com; id AA28969; Mon, 24 May 93 15:05:25 -0400
Message-Id: <9305241905.AA28969 at us1rmc.bb.dec.com>
Received: from tuxedo.enet; by us1rmc.enet; Mon, 24 May 93 15:05:26 EDT
Date: Mon, 24 May 93 15:05:26 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "John Wray, Digital DPE, (508) 486-5210 24-May-1993 1357" <wray at tuxedo.enet.dec.com>
To: "cat-ietf at mit.edu"@gwy$internet.enet.dec.com
Cc: wray at tuxedo.enet.dec.com
Apparently-To: cat-ietf at mit.edu
Subject: Re: Default credentials
Piers,
>> However, if we're considering adding a portable way of setting
>> default credentials, we should make sure that we can still support asymmetric
>> mechanism acceptor credentials reasonably cleanly.
>
>In parallel, should we adjust the semantics of gss_inquire_cred()?
That would be my preference.
>Does this mean that the "usage" parameter should be made an input to this
>function?
That would be one way to do it. Usage=INIT would request info on the default
initiator credential, Usage=ACCEPT would inquire about the default acceptor
credential. However, Usage=BOTH is ambiguous. That may not be important - we
could just make it illegal in this context, or it could fail unless the same
credential is installed for both initiator and acceptor use.
I think we have two options:
1) Decide that there are really two separate default credentials, and
then have separate calls for each credential, or a single call with a
usage input parameter to determine which default is being
interrogated. We should do this for both gss_inquire_cred and
the proposed gss_set_default_cred routine(s).
or 2) Use the usage-type of the credential to determine what its behavior as
a default should be. For example, assume I have credentials A, B and C.
A is Initiate-only, B is Accept-only, and C is Both.
Calls to gss_set_default_cred(A) would set only the default for
gss_init_accept_context, gss_set_default_cred(B) would set only the
default for gss_accept_sec_context, but gss_set_default_cred(C) would
change both defaults. gss_inquire_default_cred would have to be
changed in a similar way to (1).
Since (2) only solves the problem for the gss_set_default_cred case, but
doesn't help for gss_inquire_default_cred, I prefer the first method.
>> The main use for a GSSAPI gss_set_default_cred routine would be (as you've
>> pointed out) to set up a default identity for a child process. However, to
>>do this portably, we also have to define the scope of a credential (at the
>> moment, it's only guaranteed to have process-wide scope). Adding the routine
>> definition alone doesn't suffice.
>
>The routine definition assumes inheritance rules (as in Kerberos/DCE/SESAME)
>which permit inheritance of credentials over a fork/exec. I think that for the
>GSSAPI to be useful in constructing software, the definition of portability for
>credentials needs to be established as much as such rules exist for
>environment variables, file descriptors, IPC references etc
The trouble with that is that these are all platform-specific concepts. For
example, I worked on a GSSAPI implemention over MS-DOS. fork/exec don't have
direct analogs in DOS. Also, even on a Unix-like system, to require
file-descriptor inheritance behavior pretty-well means that either credentials
have to be stored in files or environment variables, or the OS has to maintain
them (so that they may be copied on a fork and preserved on an exec). These
are severe constraints to place on an implementor.
DCE RPC preserves only the default login context (RPC-equivalent of an
initiate-only credential) across a fork/exec; non-default login-contexts and
server-side credentials (registered server table) aren't inherited at all.
DASS implemented inheritance of all credentials and contexts across fork/exec,
and it was a huge effort to do it without having to put credentials and
contexts in files, which we didn't consider secure enough.
I think that all we can really require from a GSSAPI implementation is that
credentials & contexts have program-wide scope. Inheritance of credentials and
contexts (particularly default credentials) across both fork and exec (or
chain, or whatever) should be encouraged, since it allows one to write
"wrapper" programs that set up security data for apps that have little or no
security knowledge. But I don't think we can require this behavior, in which
case applications that rely on it aren't portable.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00616;
25 May 93 6:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00612;
25 May 93 6:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02408;
25 May 93 6:33 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00598;
25 May 93 6:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00526;
25 May 93 6:24 EDT
Received: from wraith.internode.com.au by CNRI.Reston.VA.US id aa02226;
25 May 93 6:24 EDT
Received: from simon.Brain-Space.internode.com.au by wraith.internode.com.au with DMSP (5.64+1.3.1+0.50/UA-5.23)
id AA07637; Tue, 25 May 1993 19:53:22 +0930
Date: Tue, 25 May 1993 19:53:22 +0930
Message-Id: <9305251023.AA07637 at wraith.internode.com.au>
To: ietf at CNRI.Reston.VA.US
Subject: OSI Multicast? (esp. DECnet/OSI) -available?
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon Hackett <simon at internode.com.au>
X-Orig-Sender: simon at internode.com.au
Repository: internode.com.au
Originating-Client: Brain-Space.internode.com.au
I have some consulting work I'm doing involving my specifying an IP
multicast based solution for a large project. Nothing to do with
audio/video as it happens, this one is just a situation where there
will be 30-40mbits/sec of realtime data from remote sampling stations
running around an FDDI ring (actually around 4-6 rings), being
listened to by about half of the machines on the ring. We want to
avoid bothering some machines on the ring who don't want to hear the
noise - hence multicast. The data rates here are so high that even
though we'll probably be using Alpha cpu's, we want to use multicast
at the hardware level to avoid hammering the cpu's of the machines
that don't want to hear the stuff.
The people I'm working with wondered if it's actually possible to buy
OSI based solutions (particularly DECnet/OSI) which support multicast
on FDDI and Ethernet hardware.
Any DECnet/OSI gurus out there want to tell me if I can buy OSI
multicast for Vax/VMS?
As an ancillary question, does anyone know of I can buy OSI multicast
for _any_ commercial platform? (i.e. other than DECnet/OSI, on other
cpu's and operating systems?)
Thanks!
Simon
{------------------------------------------------}
{ Simon Hackett, Internode Systems Pty Ltd }
{ E-mail: simon at internode.com.au }
{ Phone: +61 8 373 1339 Fax: +61 8 373 4911 }
{ Mail: PO Box 69, Daw Park, SA 5041 AUSTRALIA }
{------------------------------------------------}
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02667;
25 May 93 9:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02663;
25 May 93 9:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06110;
25 May 93 9:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02643;
25 May 93 9:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02570;
25 May 93 9:08 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa05946;
25 May 93 9:08 EDT
Received: by xap.xyplex.com id <AA17680 at xap.xyplex.com>; Mon, 24 May 93 18:39:21 -0500
Date: Mon, 24 May 93 18:39:21 -0500
Message-Id: <9305242339.AA17680 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: Carl Ellison's message of Fri, 21 May 1993 19:09:44 GMT <9305211909.AA04524 at ellisun.sw.stratus.com>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
Am I the only person on the IETF mailing list that finds these tomes on DES
and EDEwhatevertheheckitis to be not useful and annoying?
Although any IETF business is of potential interest to any member, we don't
have one big meeting when we get together, we don't have one mailing list for
everything, and we don't have one big working group. People specialize.
Please stop filling links, routers, and mailboxes with what you imagine to be
of interest to far more people than it really is.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02802;
25 May 93 9:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02798;
25 May 93 9:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06290;
25 May 93 9:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02784;
25 May 93 9:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02715;
25 May 93 9:12 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa06232;
25 May 93 9:11 EDT
Received: by xap.xyplex.com id <AA17749 at xap.xyplex.com>; Mon, 24 May 93 18:43:18 -0500
Date: Mon, 24 May 93 18:43:18 -0500
Message-Id: <9305242343.AA17749 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: Raymond Lau's message of Fri, 21 May 1993 20:40:06 GMT <9305211950.AA18735 at MIT.EDU>
Subject: Re: Triple DES
>-----BEGIN PRIVACY-ENHANCED MESSAGE-----
>Proc-Type: 4,MIC-CLEAR
>Content-Domain: RFC822
>Originator-Certificate:
> MIIBxTCCAWECARIwDQYJKoZIhvcNAQECBQAwTTELMAkGA1UEBhMCVVMxIDAeBgNV
> BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYDVQQLExNQZXJzb25hIENl
> cnRpZmljYXRlMB4XDTkzMDQxMjIyNTI1N1oXDTk1MDQxMjA1MDAwMFowYzELMAkG
> A1UEBhMCVVMxIDAeBgNVBAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMRwwGgYD
> VQQLExNQZXJzb25hIENlcnRpZmljYXRlMRQwEgYDVQQDEwtSYXltb25kIExhdTB5
> MAoGBFUIAQECAgMAA2sAMGgCYQC4Lq5eHwr4u4bY7VggmpOwmyqhq9nMVR7VuaUy
> 4MOTPLPHi/dZM5E2gdODG1uV2YoGDNNTuVFRO4osQwxTOWMt9oEththrXOYI6oZ8
> lzyYfmgLVL15S7HCV/GYJdlPuO0CAwEAATANBgkqhkiG9w0BAQIFAANPAAUVNpom
> zLBp6r72gqG6bBU1eFbv9bNKk4WSQCXYRbulGmhyLCXItASYloprlBxKHm8EP178
> P8z1rlbRNAoWw2G5q2550I6UUiJ5OOkVwB==
>MIC-Info: RSA-MD5,RSA,
> lTseoQ7YapjkRdsuA8YgFUP2MILA7WIMhLwyZVo2dvmYyeRewagzLzlm1cTwU74n
> RIsG50Fa/RJmzxukw08ojOVuBeEfTO/h263Fm5lhvHrv1FHKuW2sCl5JgzhswK8d
I'm in danger of getting really nasty. How nice for Richard Lau that he is so
important that his mail is authenticated. Is such a glop of cybercrud to
become standard at the front of every message we peasants get from the
authenticated elite.
Will you guys go fluff your egos elsewhere.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03173;
25 May 93 9:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03169;
25 May 93 9:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06950;
25 May 93 9:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03149;
25 May 93 9:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03104;
25 May 93 9:29 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa06869;
25 May 93 9:29 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA21590; Tue, 25 May 93 09:30:16 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA23843; Tue, 25 May 93 09:32:04 EDT
Message-Id: <9305251332.AA23843 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: ietf at CNRI.Reston.VA.US
Subject: Flights to Schipol
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 25 May 93 09:32:03 -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>
Does anybody have any information on good prices to Amsterdam? I'm trying to
work out whether it's cheaper to go via London and Eurail as opposed to
flying direct?
Apologies for low cryptography content; maybe I should include my O(ln N)
algorithm for cracking DES? It's really simple you just
Connection closed by remote host
NO CARRIER
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03532;
25 May 93 9:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03524;
25 May 93 9:53 EDT
Received: from TIS.COM by CNRI.Reston.VA.US id aa07720; 25 May 93 9:53 EDT
Received: by TIS.COM (4.1/SUN-5.64)
id AA28852; Tue, 25 May 93 09:55:16 EDT
Received: from TIS.COM by TIS.COM (4.1/SUN-5.64)
id AA28842; Tue, 25 May 93 09:55:14 EDT
Message-Id: <9305251355.AA28842 at TIS.COM>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: List Master (agent: David Balenson) <pem-dev-request at tis.com>
To: Bob Stewart <rlstewart at eng.xyplex.com>
Cc: ietf at CNRI.Reston.VA.US, pem-dev at tis.com
Subject: Re: Triple DES
In-Reply-To: Your message of Mon, 24 May 93 18:43:18 CDT.
<9305242343.AA17749 at xap.xyplex.com>
Date: Tue, 25 May 93 09:55:09 -0400
X-Orig-Sender: pem-dev-relay at tis.com
> I'm in danger of getting really nasty. ... Will you guys go fluff
> your egos elsewhere.
I sympathize with your concerns about the traffic on the ietf mailing
list. I think there's a simple explanation to this and that we can try
to avoid nastiness.
The "Triple DES" discussion was appropriately started on the PEM-DEV
mailing list. That list exists precisely for such discussions.
Somewhere along the way, someone contributed to the discussion with a
message to the IETF list, either because it was of potential general
interest to that list, or simply by mistake. I think that folks, have,
in turn, been responding without realizing the full extent of their
audience.
So, I'd like to request that PEM-DEV'ers be very cautious about posting
or cross-posting to the IETF mailing list, and for subsequent PEM-DEV
responders to be even more careful about posting or cross-posting their
responses to the IETF mailing list.
Indeed, PEM-DEV is a much more appropriate list for this discussion.
Thanks.
-David Balenson <pem-dev-request at tis.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04251;
25 May 93 10:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04247;
25 May 93 10:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08920;
25 May 93 10:26 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04230;
25 May 93 10:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04158;
25 May 93 10:24 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa08856;
25 May 93 10:24 EDT
Received: by xap.xyplex.com id <AA18890 at xap.xyplex.com>; Mon, 24 May 93 19:56:11 -0500
Date: Mon, 24 May 93 19:56:11 -0500
Message-Id: <9305250056.AA18890 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: Bob Stewart's message of Mon, 24 May 93 18:43:18 -0500 <9305242343.AA17749 at xap.xyplex.com>
Subject: Re: Triple DES
I should have finished catching up on my mail before I waxed poetic with my
poison pen. I meant no personal attack on Raymond Lau (and didn't even get
his name right), and apologize to him.
Even so, I still wonder if we're going to see a large increase in the
cybercrud content of mail headers, filling up the precious lines on our
screens. That's probably a topic for a specialized mailing list, but those
who consider authentication really really important need to understand that
the vast majority probably don't care.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05162;
25 May 93 11:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05158;
25 May 93 11:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10643;
25 May 93 11:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05144;
25 May 93 11:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05122;
25 May 93 11:11 EDT
Received: from SYNW03.elettra.trieste.it by CNRI.Reston.VA.US id aa10605;
25 May 93 11:11 EDT
Date: Tue, 25 May 1993 17:10:44 +0200 (WET-DST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Claudio Allocchio - +39 40 3758523 <ALLOCCHIO at elettra.trieste.it>
Message-Id: <930525171044.32400564 at elettra.trieste.it>
Subject: Re: Flights to Schipol
To: ietf at CNRI.Reston.VA.US
X-Vmsmail-To: SMTP%"ietf at CNRI.Reston.VA.US"
Hallo,
I just by chance got yesterday one announce from Continental Airlines
announcing "new great opportunities" to fly to Amsterdam in a cheaper
way thanks to their collaboration with KLM - Royal Dutch Airlines.
Try to ask Continental il KLM direclty... you know, advertisement is
advertisement... better to check first, and believe later on.
regards
Claudio
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05903;
25 May 93 11:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05899;
25 May 93 11:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11713;
25 May 93 11:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05878;
25 May 93 11:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05836;
25 May 93 11:55 EDT
Received: from regal.cisco.com by CNRI.Reston.VA.US id aa11690;
25 May 93 11:55 EDT
Received: by regal.cisco.com; Tue, 25 May 1993 08:55:21 -0700
Date: Tue, 25 May 1993 08:55:21 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199305251555.AA22033 at regal.cisco.com>
To: simon at internode.com.au
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: Simon Hackett's message of Tue, 25 May 1993 19:53:22 +0930 <9305251023.AA07637 at wraith.internode.com.au>
Subject: OSI Multicast? (esp. DECnet/OSI) -available?
OSI multicast is in the process of being defined, so I would be surprised if
there was any product available.
Date: Tue, 25 May 1993 19:53:22 +0930
Sender: ietf-request at IETF.CNRI.Reston.VA.US
From: Simon Hackett <simon at internode.com.au>
X-Orig-Sender: simon at internode.com.au
Repository: internode.com.au
Originating-Client: Brain-Space.internode.com.au
I have some consulting work I'm doing involving my specifying an IP
multicast based solution for a large project. Nothing to do with
audio/video as it happens, this one is just a situation where there
will be 30-40mbits/sec of realtime data from remote sampling stations
running around an FDDI ring (actually around 4-6 rings), being
listened to by about half of the machines on the ring. We want to
avoid bothering some machines on the ring who don't want to hear the
noise - hence multicast. The data rates here are so high that even
though we'll probably be using Alpha cpu's, we want to use multicast
at the hardware level to avoid hammering the cpu's of the machines
that don't want to hear the stuff.
The people I'm working with wondered if it's actually possible to buy
OSI based solutions (particularly DECnet/OSI) which support multicast
on FDDI and Ethernet hardware.
Any DECnet/OSI gurus out there want to tell me if I can buy OSI
multicast for Vax/VMS?
As an ancillary question, does anyone know of I can buy OSI multicast
for _any_ commercial platform? (i.e. other than DECnet/OSI, on other
cpu's and operating systems?)
Thanks!
Simon
{------------------------------------------------}
{ Simon Hackett, Internode Systems Pty Ltd }
{ E-mail: simon at internode.com.au }
{ Phone: +61 8 373 1339 Fax: +61 8 373 4911 }
{ Mail: PO Box 69, Daw Park, SA 5041 AUSTRALIA }
{------------------------------------------------}
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07154;
25 May 93 13:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07147;
25 May 93 13:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14748;
25 May 93 13:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07125;
25 May 93 13:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07081;
25 May 93 13:52 EDT
Received: from TSX-11.MIT.EDU by CNRI.Reston.VA.US id aa14696;
25 May 93 13:52 EDT
Received: by tsx-11.MIT.EDU
with sendmail-5.61/1.2, id AA08188; Tue, 25 May 93 13:52:31 EDT
Date: Tue, 25 May 93 13:52:31 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at athena.mit.edu>
Message-Id: <9305251752.AA08188 at tsx-11.MIT.EDU>
To: Bob Stewart <rlstewart at eng.xyplex.com>
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: Bob Stewart's message of Mon, 24 May 93 19:56:11 -0500,
<9305250056.AA18890 at xap.xyplex.com>
Subject: Re: Triple DES
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Mon, 24 May 93 19:56:11 -0500
Sender: ietf-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
Even so, I still wonder if we're going to see a large increase in the
cybercrud content of mail headers, filling up the precious lines on our
screens.
The same could be said about MIME headers, or indeed Received header
lines as well. Yet I haven't heard anyone seriously propose that we
should eliminate Received header lines, either.
I would think the right answer would be to have MUA's suppress
"cybercrud", much like Received lines are currently being suppressed
today by most MUA's. Hopefully, the MUA's eventually will be modified
to actually process said PEM and MIME headers. But in the meantime, it
shouldn't be that hard to get them to suppress said headers.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07836;
25 May 93 14:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07832;
25 May 93 14:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15474;
25 May 93 14:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07818;
25 May 93 14:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07778;
25 May 93 14:17 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa15444;
25 May 93 14:17 EDT
Received: by xap.xyplex.com id <AA22274 at xap.xyplex.com>; Mon, 24 May 93 23:49:14 -0500
Date: Mon, 24 May 93 23:49:14 -0500
Message-Id: <9305250449.AA22274 at xap.xyplex.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Stewart <rlstewart at eng.xyplex.com>
To: ietf at CNRI.Reston.VA.US
In-Reply-To: Theodore Ts'o's message of Tue, 25 May 93 13:52:31 EDT <9305251752.AA08188 at tsx-11.MIT.EDU>
Subject: Re: Cybercrud Mail Headers (was: Triple DES)
>The same could be said about MIME headers, or indeed Received header
>lines as well. Yet I haven't heard anyone seriously propose that we
>should eliminate Received header lines, either.
I'll be happy to say the same thing about MIME. Cybercrud cybercrud
cybercrud. I have to sort out the message text from amongst the weeds. I'll
admit that I look at received headers twice a year, and I don't have to look
at them the rest of the time because GNU emacs suppresses them.
OK. So I've calmed down and I'm willing to admit that what I call cybercrud
someone else calls really neat instructions to make his whizbang mailer do
neat stuff, but the only way I get a new mailer is when some other nice person
appropriately updates GNU Emacs, and I go through the pain of once again
trying to figure out how to build it. And I can figure that out. The
Internet world is overflowing with people who can't figure out they're
supposed to append "-request" when they want on or off a mailing list.
Having overdone my curmudgeon act, I'll also admit that I don't have a better
idea of how to move to a richer email capability. This was just may day to
complain.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10721;
25 May 93 17:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10717;
25 May 93 17:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22766;
25 May 93 17:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10686;
25 May 93 17:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10651;
25 May 93 17:56 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa22719;
25 May 93 17:56 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA03383>; Tue, 25 May 1993 14:56:21 -0700
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA02487; Tue, 25 May 93 17:56:19 -0400
Received: from nkosi.well.sf.ca.us by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA27639; Tue, 25 May 93 17:56:17 -0400
Received: from well.sf.ca.us ([192.132.30.2]) by nkosi.well.sf.ca.us with SMTP id <24456>; Tue, 25 May 1993 14:56:04 -0700
Received: by well.sf.ca.us id AA16597
(5.65c/IDA-1.5 for info-ietf at uunet.uu.net); Tue, 25 May 1993 14:55:36 -0700
Date: Tue, 25 May 1993 14:55:36 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Geoff Collyer <geoff at well.sf.ca.us>
Message-Id: <199305252155.AA16597 at well.sf.ca.us>
To: info-ietf at uunet.uu.net
Subject: Re: Cybercrud Mail Headers (was: Triple DES)
References: <9305251752.AA08188 at tsx-11.MIT.EDU> <9305250449.AA22274 at xap.xyplex.com>
>>The same could be said about MIME headers, or indeed Received header
>>lines as well. Yet I haven't heard anyone seriously propose that we
>>should eliminate Received header lines, either.
Then allow me to be the first to seriously propose that we should
eliminate Received header lines. In a dozen years of running mail
systems, some of which had quite odd connections, I don't think I've
found Received useful even once.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10992;
25 May 93 18:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10988;
25 May 93 18:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23767;
25 May 93 18:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10973;
25 May 93 18:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10948;
25 May 93 18:35 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa23727;
25 May 93 18:35 EDT
Received: from LOCALHOST by black-ice.cc.vt.edu (AIX 3.2/UCB 5.64/4.03)
id AA15156; Tue, 25 May 1993 18:36:03 -0400
Message-Id: <9305252236.AA15156 at black-ice.cc.vt.edu>
To: Geoff Collyer <geoff at well.sf.ca.us>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Cybercrud Mail Headers (was: Triple DES)
In-Reply-To: Your message of "Tue, 25 May 1993 14:55:36 EDT."
<199305252155.AA16597 at well.sf.ca.us>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 25 May 1993 18:36:01 +22312049
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
On Tue, 25 May 1993 14:55:36 EDT, you said:
> Then allow me to be the first to seriously propose that we should
> eliminate Received header lines. In a dozen years of running mail
> systems, some of which had quite odd connections, I don't think I've
> found Received useful even once.
Geoff:
Care to share your secret with us? All us *other* beleagured
postmasters are continually getting hit with the most incredibly
arcane header manglings, and find Received: useful. Could you
tell us how you managed to run e-mail for a dozen years and never
get something so mangled you had to look at the Received: tags
to figure out who clobbered it?
btw - your note as it arrived here had a tag:
>To: info-ietf at uunet.uu.net
unlike all the other IETF mail that shows up here, which has:
>To: ietf at CNRI.Reston.VA.US
I guess it's a good thing that the header re-write worked correctly
as otherwise, we'd have to try to figure out *which* of the machines
at uu.net was the offender...
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA03383>; Tue, 25 May 1993 14:56:21 -0700
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA02487; Tue, 25 May 93 17:56:19 -0400
Received: from nkosi.well.sf.ca.us by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA27639; Tue, 25 May 93 17:56:17 -0400
Would be fun tracking it through the uunet swamp without these babies. ;)
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11046;
25 May 93 18:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11042;
25 May 93 18:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23842;
25 May 93 18:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11027;
25 May 93 18:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11000;
25 May 93 18:39 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa23797;
25 May 93 18:39 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA04685>; Tue, 25 May 1993 15:39:40 -0700
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA05179; Tue, 25 May 93 18:39:38 -0400
Received: from Athena.MIT.EDU (via ATHENA-AS-WELL.MIT.EDU) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA17808; Tue, 25 May 93 18:39:43 -0400
Received: from SOS.MIT.EDU by Athena.MIT.EDU with SMTP
id AA04973; Tue, 25 May 93 18:39:35 EDT
Received: by SOS (5.57/4.7) id AA10206; Tue, 25 May 93 18:39:34 -0400
Date: Tue, 25 May 93 18:39:34 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Theodore Ts'o <tytso at athena.mit.edu>
Message-Id: <9305252239.AA10206 at SOS>
To: Geoff Collyer <geoff at well.sf.ca.us>
Cc: info-ietf at uunet.uu.net
In-Reply-To: Geoff Collyer's message of Tue, 25 May 1993 14:55:36 -0700,
<199305252155.AA16597 at well.sf.ca.us>
Subject: Re: Cybercrud Mail Headers (was: Triple DES)
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Date: Tue, 25 May 1993 14:55:36 -0700
From: Geoff Collyer <geoff at well.sf.ca.us>
Then allow me to be the first to seriously propose that we should
eliminate Received header lines. In a dozen years of running mail
systems, some of which had quite odd connections, I don't think I've
found Received useful even once.
Really? I'm surprised. I've found them useful quite often....
* when trying to figure out someone's true email address, when
they have a misconfigured mailer which didn't include a
fully-qualified domain name in the From field.
* when tracking down who sent faked email (for example, after
someone gets a faked email of the form "you have been
laid off; please contact your supervisor immediately",
and they complain to the postmaster)
* when tracking down a mail loop, or a mail<->USENET loop
* when trying to figure out where a message was delayed for
several hours, days, weeks, or months
The times that I find them useful are after the mail system has screwed
up in some way. If things never went wrong, sure, they wouldn't be
needed. But when things do go wrong, it is an extremely helpful
debugging tool.
- Ted
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11210;
25 May 93 18:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11206;
25 May 93 18:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24189;
25 May 93 18:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11192;
25 May 93 18:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11129;
25 May 93 18:54 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa24123;
25 May 93 18:54 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA05157>; Tue, 25 May 1993 15:55:16 -0700
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA06113; Tue, 25 May 93 18:55:15 -0400
Received: from Mordor.Stanford.EDU by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA21984; Tue, 25 May 93 18:55:20 -0400
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA24965; Tue, 25 May 93 15:55:12 -0700
Message-Id: <9305252255.AA24965 at Mordor.Stanford.EDU>
To: Geoff Collyer <geoff at well.sf.ca.us>
Cc: info-ietf at uunet.uu.net
Subject: Re: Cybercrud Mail Headers (was: Triple DES)
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 25 May 93 14:55:36 -0700. <199305252155.AA16597 at well.sf.ca.us>
Date: Tue, 25 May 93 15:55: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
---- Included message:
In a dozen years of running mail
systems, some of which had quite odd connections, I don't think I've
found Received useful even once.
Among Internet email operators, you are in the minority.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11316;
25 May 93 19:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11312;
25 May 93 19:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24436;
25 May 93 19:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11298;
25 May 93 19:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11276;
25 May 93 19:08 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa24408;
25 May 93 19:08 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA05593>; Tue, 25 May 1993 16:08:30 -0700
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA06725; Tue, 25 May 93 19:08:29 -0400
Received: from albert.gnu.ai.mit.edu by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA25388; Tue, 25 May 93 19:08:34 -0400
Received: from nutrimat.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
id <AA24175 at albert.gnu.ai.mit.edu>; Tue, 25 May 93 19:08:25 -0400
Received: by nutrimat.gnu.ai.mit.edu (15.11/4.0)
id <AA14399 at nutrimat.gnu.ai.mit.edu>; Tue, 25 May 93 19:08:23 edt
Date: Tue, 25 May 93 19:08:23 edt
Message-Id: <9305252308.AA14399 at nutrimat.gnu.ai.mit.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noah Friedman <friedman at gnu.ai.mit.edu>
X-Orig-Sender: friedman at gnu.ai.mit.edu
Cc: info-ietf at uunet.uu.net
Subject: Re: Cybercrud Mail Headers
Reply-To: friedman at gnu.ai.mit.edu
In-Reply-To: <9305252239.AA10206 at SOS> (tytso at athena.mit.edu)
This discussion of Received headers shows up on comp.mail.headers every
once in awhile. Every sane person who has ever been postmaster for even a
week knows that Received headers are indispensible.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12086;
25 May 93 21:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12082;
25 May 93 21:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27169;
25 May 93 21:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12068;
25 May 93 21:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12043;
25 May 93 21:46 EDT
Received: from him3.cc.umich.edu by CNRI.Reston.VA.US id aa27154;
25 May 93 21:46 EDT
Date: Tue, 25 May 93 21:45:42 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Joseph.Gelinas at um.cc.umich.edu
To: geoff at well.sf.ca.us
Cc: ietf at nri.reston.va.us
Message-ID: <23262613 at um.cc.umich.edu>
X-MTS-Userid: HLR0
Subject: RE: Recieved header lines (was: Re Cybercrud Mail Headers (was ...))
>Posted: 5:55pm EDT, Tue May 25/93, imported: 6:06pm EDT, Tue May 25/93
>Subject: Re: Cybercrud Mail Headers (was: Triple DES)
>To: ietf-standards, info-ietf at uunet.uu.net
>From: geoff at well.sf.ca.us
>Sender: ietf-request at IETF.CNRI.Reston.VA.US
>
>>>The same could be said about MIME headers, or indeed Received header
>>>lines as well. Yet I haven't heard anyone seriously propose that we
>>>should eliminate Received header lines, either.
>
>Then allow me to be the first to seriously propose that we should
>eliminate Received header lines. In a dozen years of running mail
>systems, some of which had quite odd connections, I don't think I've
>found Received useful even once.
I would rather they remain. As a postmaster, I have found them
useful for explaining, if not correcting, why someone got several
copies of the same message. By comparing the Received header lines
in the several copies, I can show which two machines failed to
complete the message transfer. In the year I've been doing this,
I've yet to see a pattern that called for any further action, but
that shouldn't be taken to mean that I won't see such a pattern in
the future.
----------------------------
Joseph L. Gelinas, Jr.
Internet: Gelinas at umich.edu
BITNET: UserJLG at UMICHUM
----------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12301;
25 May 93 22:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12297;
25 May 93 22:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27625;
25 May 93 22:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12283;
25 May 93 22:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12261;
25 May 93 22:16 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa27615;
25 May 93 22:16 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA10456>; Tue, 25 May 1993 19:17:09 -0700
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA14561; Tue, 25 May 93 22:17:02 -0400
Received: from sigurd.innosoft.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA10532; Tue, 25 May 93 22:17:04 -0400
Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992)
id <01GYLBSHECV48ZE2XK at SIGURD.INNOSOFT.COM>; Tue, 25 May 1993 19:16:41 PDT
Date: Tue, 25 May 1993 19:05:35 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ned Freed <NED at sigurd.innosoft.com>
Subject: RE: Cybercrud Mail Headers (was: Triple DES)
In-Reply-To: Your message dated "Tue, 25 May 1993 14:55:36 -0700"
<199305252155.AA16597 at well.sf.ca.us>
To: Geoff Collyer <geoff at well.sf.ca.us>
Cc: info-ietf at uunet.uu.net
Message-Id: <01GYLQE2ZT6O8ZE2XK at SIGURD.INNOSOFT.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
> Then allow me to be the first to seriously propose that we should
> eliminate Received header lines. In a dozen years of running mail
> systems, some of which had quite odd connections, I don't think I've
> found Received useful even once.
You are going to get a lot of mail telling you why this is a really bad idea
and how useful Received: headers are. However, I'm going to take a slightly
different tack and talk about what is known to happen when you do eliminate
them.
The company I work for sells email interconnection software. A very popular
user agent on the platform we support has absolutely no understanding of
headers and tirelessly displays each one of them to all and sundry, no matter
what.
Needless to say, users don't like this. Bowing to immense pressure, we
eventually implemented mechanisms for eliminating selected headers and/or
eliminating all headers. Now, by "eliminate" I don't mean don't display, I mean
that they are *gone*. When we did this we issued stern warnings about the
dangers of doing this, why it is a bad idea, etc. etc. We knew all along that
this was a really bad idea, but people really wanted it, so...
Quite a few sites now use these options. Every so often one of them calls up
wanting help diagnosing a problem of some kind. Sometimes we get lucky, but in
quite a few cases the ability to diagnose the problem was seriously hindered or
even completely blocked by lack of necessary header information. Often as not
it was a Received: header that would have been the most useful thing to have.
On a couple of occasions we have even had to go so far as to reenable
full headers on these systems (which can be a really unpleasant surprise
for the users).
The inescapable conclusion, then, is that not only is this information useful,
it can even be indispensable.
Ned
P.S. We have since implemented a replacement user agent that duplicates the
interface of the old one but understands about headers and how to (not) display
them.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00692;
26 May 93 3:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00688;
26 May 93 3:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01947;
26 May 93 3:46 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00674;
26 May 93 3:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00623;
26 May 93 3:36 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa01801;
26 May 93 3:36 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA15740>; Wed, 26 May 1993 00:37:03 -0700
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA03029; Wed, 26 May 93 03:36:54 -0400
Received: from ecrc.de by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA12024; Wed, 26 May 93 03:36:47 -0400
Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA27921
(5.65c/IDA-1.4.4 for <info-ietf at uunet.uu.net>); Wed, 26 May 1993 09:36:40 +0200
Received: by acrab25.ecrc (4.1/SMI-3.2)
id AA00785; Wed, 26 May 93 09:34:48 +0200
Date: Wed, 26 May 93 09:34:48 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Morton <Dave.Morton at ecrc.de>
Message-Id: <9305260734.AA00785 at acrab25.ecrc>
To: friedman at gnu.ai.mit.edu
Subject: Re: Cybercrud Mail Headers
Cc: info-ietf at uunet.uu.net
This topic doesn't even need discussion, please.....
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00780;
26 May 93 3:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00776;
26 May 93 3:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02111;
26 May 93 3:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00761;
26 May 93 3:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00736;
26 May 93 3:58 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa02101;
26 May 93 3:58 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.23477-0 at bells.cs.ucl.ac.uk>; Wed, 26 May 1993 08:58:42 +0100
To: ietf at nri.reston.va.us
Subject: Re: Recieved header lines (was: Re Cybercrud Mail Headers (was ...))
In-reply-to: Your message of "Tue, 25 May 93 21:45:42 EDT." <23262613 at um.cc.umich.edu>
Date: Wed, 26 May 93 08:58:40 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Message-ID: <9305260358.aa02101 at CNRI.Reston.VA.US>
any decent e-mail UA allows the showproc to be configured to remove
these lines - you are arguning about a user itnerface problem on a
list for discussin protocols - not good form.
what gets me are some companies who use inter-office memo structures
(specially ones with multi line cc: fields)
_inside_ a single body part replicating funcitonilty pointlessley
and defeating the smartest of showproc filters...
jon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02092;
26 May 93 8:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02088;
26 May 93 8:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05907;
26 May 93 8:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02054;
26 May 93 8:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01972;
26 May 93 7:58 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa05809; 26 May 93 7:58 EDT
Received: by ftp.com
id AA06355; Wed, 26 May 93 07:58:39 -0400
Date: Wed, 26 May 93 07:58:39 -0400
Message-Id: <9305261158.AA06355 at ftp.com>
To: ietf at nri.reston.va.us
Subject: Re: Recieved header lines (was: Re Cybercrud Mail Headers (was ...))
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
Could you all pleeeeeeeeeese take this to some more appropriate list.
Thank you
--
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 aa02372;
26 May 93 8:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02368;
26 May 93 8:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06239;
26 May 93 8:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02352;
26 May 93 8:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02292;
26 May 93 8:09 EDT
Received: from world.std.com by CNRI.Reston.VA.US id aa06136; 26 May 93 8:09 EDT
Received: by world.std.com (5.65c/Spike-2.0)
id AA14729; Wed, 26 May 1993 08:09:59 -0400
Date: Wed, 26 May 1993 08:08:03 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Nicolas J Keller <srcdc at world.std.com>
Subject: Re: TIS/PEM will probably have exprimental support for EDE
To: Bob Stewart <rlstewart at eng.xyplex.com>
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9305242339.AA17680 at xap.xyplex.com>
Message-Id: <Pine.3.07.9305260859.A14287-8100000 at world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Bob,
I do agree, the whatthehellisthatTIS/PEMandEDEandwhatever should be
discussed somewhere else.
That would allow to seriously diminish the amount of mail to read...
Nicolas
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02485;
26 May 93 8:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02481;
26 May 93 8:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06423;
26 May 93 8:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02467;
26 May 93 8:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02409;
26 May 93 8:17 EDT
Received: from world.std.com by CNRI.Reston.VA.US id aa06383; 26 May 93 8:17 EDT
Received: by world.std.com (5.65c/Spike-2.0)
id AA15733; Wed, 26 May 1993 08:18:06 -0400
Date: Wed, 26 May 1993 08:13:18 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Nicolas J Keller <srcdc at world.std.com>
Subject: Help... TCP/IP ES-IS
To: ietf at CNRI.Reston.VA.US
Message-Id: <Pine.3.07.9305260818.A14287-9100000 at world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
I am new in the TCP/IP world and would like to know if there is any TCP/IP
equivalent of the OSI ES-IS Routing Exchange Protocols (ISO 9542).
Nicolas Keller
System Resources Corporation
600 Maryland Avenue SW #740
Wahington, DC 20024
Tel: (202) 488-9740
Fax: (202) 488-4729
srcdc at world.std.com
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03237;
26 May 93 8:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07697;
26 May 93 8:57 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03196;
26 May 93 8:57 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03059;
26 May 93 8:53 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-houttuin-rfc1327-tutor-02.txt, .ps
Date: Wed, 26 May 93 08:53:15 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9305260853.aa03059 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : A tutorial on gatewaying between X.400 and Internet
mail
Author(s) : J. Houttuin
Filename : draft-houttuin-rfc1327-tutor-02.txt, .ps
Pages : 37
There are many ways in which X.400 and Internet (RFC 822) mail systems
can be interconnected. Addresses and service elements can be mapped
onto each other in different ways. From the early available gateway
implementations, one was not necessarily better than any other, but
the sole fact that each handled the mappings in a different way led to
major interworking problems, especially when a message (or address)
crossed more than one gateway. The need for one global standard on how
to implement X.400 - Internet mail gatewaying was satisfied by the
Internet Request For Comments 1327, "Mapping between X.400(1988)/ISO
10021 and RFC 822."
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-houttuin-rfc1327-tutor-02.txt".
Or
"get draft-houttuin-rfc1327-tutor-02.ps".
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-houttuin-rfc1327-tutor-02.txt".
Or
"SEND draft-houttuin-rfc1327-tutor-02.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-houttuin-rfc1327-tutor-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-houttuin-rfc1327-tutor-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 aa06053;
26 May 93 10:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06043;
26 May 93 10:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10947;
26 May 93 10:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05991;
26 May 93 10:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05708;
26 May 93 10:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10882;
26 May 93 10:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05703;
26 May 93 10:27 EDT
To: internauts: ;, ietf at CNRI.Reston.VA.US
Subject: US Cryptographic Policy - comments by Steve Walker
Date: Wed, 26 May 93 10:27:52 -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: <9305261027.aa05703 at IETF.CNRI.Reston.VA.US>
On the Internet Society gopher (ietf.cnri.reston.va.us) is
a paper by Steve Walker outlining some of the critical
policy issues relating to cryptographic technology use
and export. Steve is president of Trusted Information Systems.
See the gopher page labelled "NREN, NII..."
Vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07016;
26 May 93 11:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07012;
26 May 93 11:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12347;
26 May 93 11:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06988;
26 May 93 11:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06957;
26 May 93 11:08 EDT
Received: from OPAL.ACC.COM by CNRI.Reston.VA.US id aa12293; 26 May 93 11:08 EDT
Received: by opal.acc.com (4.1/SMI-4.0)
id AA06449; Wed, 26 May 93 08:09:07 PDT
Date: Wed, 26 May 93 08:09:07 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: <9305261509.AA06449 at opal.acc.com>
To: ietf at CNRI.Reston.VA.US, srcdc at world.std.com
Subject: Re: Help... TCP/IP ES-IS
>
>Hi,
>
>I am new in the TCP/IP world and would like to know if there is any TCP/IP
>equivalent of the OSI ES-IS Routing Exchange Protocols (ISO 9542).
There is not a one-to-one equivalent in the TCP/IP world. Elements of
what ES-IS performs may be found in the ICMP, ARP and Router Discovery
protocols.
Art
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08256;
26 May 93 12:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08252;
26 May 93 12:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14841;
26 May 93 12:39 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08236;
26 May 93 12:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08232;
26 May 93 12:39 EDT
Received: from worldlink.com by CNRI.Reston.VA.US id aa14790;
26 May 93 12:39 EDT
Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink)
id AA29792; Wed, 26 May 93 12:39:09 -0400
Date: Wed, 26 May 93 12:39:09 -0400
Message-Id: <9305261639.AA29792 at worldlink.worldlink.com>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "David M. Piscitello" <dave at mail.bellcore.com>
To: ietf at CNRI.Reston.VA.US, iesg at CNRI.Reston.VA.US
Subject: conflict of interest--jeez!
We are not attorneys. At least I'm not. The harder we try to play attorney,
the likelier we'll shoot ourselves in the foot. IMHO, the less
like a legal document RFC1310 is, the greater the potential
is for plausible deniability:-)
I'd like to echo the first part of Marshall's reply. We
can't take the constuency of the IESG potentially best suited
to make a decision out of the process simply because they are
"involved" in developing on of the alternative technologies.
Disqualification in this context is impractical.
Marshall's notion of disclosure is important, but I think if
we are going to incorporate this into 1310bis, then we need
to examine exactly what should constitute a conflict of interest.
But since not all conflicts of interest are as obvious as the case
of "the iesg member who owns a company that will make $ if IPfoo
becomes IPng", I think the process must rely on the IESG selection
process to offer up candidates who are technically competent and
who also have integrity. IESG members ought to disclose conflicts
or potential conflicts.
Let's do a reality check here. While a number of folks provide
community service to the IETF, all of us in one way or another
have a financial stake in internet technology. It's our livelihood.
And few if none of us are in the luxurious position of having both
sufficient influence in the IETF/IESG/IAB etc. to sway a decision
while simultaneously positioning a product in such a fashion that
we would profit wildly or introduce a major shift in market share
among major players as a result of a single decision. (My definition
of wild profits exceeds by an order of magnitude what someone like
the esteemed Dr. Case has earned--and note, I say earned--as a result
of a CMOT/SNMP decision. In other words, quite a bit.)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09557;
26 May 93 13:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09551;
26 May 93 13:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16187;
26 May 93 13:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09501;
26 May 93 13:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09496;
26 May 93 13:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16150;
26 May 93 13:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09491;
26 May 93 13:23 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: iplpdn 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: Last Call: Multiprotocol Interconnect over Frame Relay to
Draft Standard
Date: Wed, 26 May 93 13:23:48 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305261323.aa09491 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the IP over Large Public Data
Networks Working Group to consider <draft-ietf-iplpdn-framerelay-03.txt>
"Multiprotocol Interconnect over Frame Relay" for the status of Draft
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
June 10th.
Greg Vaudreuil
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11829;
26 May 93 14:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19386;
26 May 93 14:47 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11806;
26 May 93 14:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11729;
26 May 93 14:44 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa19305;
26 May 93 14:44 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA26489>; Wed, 26 May 1993 11:44:57 -0700
Message-Id: <199305261844.AA26489 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1466 on Guidelines for Management of IP Address Space
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 11:44:55 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 1466:
Title: Guidelines for Management of IP Address Space
Author: E. Gerich
Mailbox: epg at MERIT.EDU
Pages: 10
Characters: 22,262
Obsoletes: RFC 1366
This document has been reviewed by the Federal Engineering Planning
Group (FEPG) on behalf of the Federal Networking Council (FNC), the
co-chairs of the Intercontinental Engineering Planning Group (IEPG),
and the Reseaux IP Europeens (RIPE). There was general consensus by
those groups to support the recommendations proposed in this document
for management of the IP address space.
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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1466.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1466.txt";
site="nic.ddn.mil";
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 aa12165;
26 May 93 14:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19606;
26 May 93 14:54 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12146;
26 May 93 14:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12055;
26 May 93 14:52 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa19529;
26 May 93 14:52 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA26699>; Wed, 26 May 1993 11:53:12 -0700
Message-Id: <199305261853.AA26699 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1465 on Routing Coordination for X.400 Services
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 11:53:10 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1465:
Title: Routing Coordination for X.400 MHS Services
Within a Multi Protocol / Multi Network
Environment Table Format V3 for Static Routing
Author: D. Eppenberger
Mailbox: Eppenberger at switch.ch
Pages: 31
Characters: 66,833
Updates/Obsoletes: none
The usage of the X.400 Message Handling System (MHS) is growing
rapidly, especially in the commercial world but much interest can also
be found in the academic and research community. New networks and new
addresses come into use each and every day. The underlying technology
for different X.400 networks can vary depending on the transport
network and the X.400 MHS implementations used. As a large number of
X.400 implementations now support multiple stacks, this offers the
chance of implementing a world wide message handling service using the
same electronic mail standard and, therefore, without the need of
gateways with service reduction and without the restriction to a
single common transport network. This, however, leads to several
problems for the MHS manager, two of which are:
- Where do I route new X.400 addresses and
- How do I connect to a MHS domain that uses an underlying
technology that I do not support.
This document proposes short term solutions to these problems.
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at 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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1465.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1465.txt";
site="nic.ddn.mil";
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 aa12376;
26 May 93 14:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19783;
26 May 93 14:58 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12339;
26 May 93 14:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12262;
26 May 93 14:56 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa19682;
26 May 93 14:56 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA26792>; Wed, 26 May 1993 11:57:16 -0700
Message-Id: <199305261857.AA26792 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1464 on Storing Arbitrary Attributes in DNS
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 11:57:14 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 1464:
Title: Using the Domain Name System
To Store Arbitrary String Attributes
Author: R. Rosenbaum
Mailbox: rosenbaum at lkg.dec.com
Pages: 4
Characters: 7,953
Updates/Obsoletes: none
While the Domain Name System (DNS) is generally used to store
predefined types of information (e.g., addresses of hosts), it is
possible to use it to store information that has not been previously
classified. This paper describes a simple means to associate
arbitrary string information (ASCII text) with attributes that have
not been defined by the DNS. It uses DNS TXT resource records to
store the information. It requires no change to current DNS
implementations.
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at 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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1464.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1464.txt";
site="nic.ddn.mil";
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 aa13494;
26 May 93 15:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21280;
26 May 93 15:36 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13477;
26 May 93 15:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13394;
26 May 93 15:34 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa21193;
26 May 93 15:34 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA29082>; Wed, 26 May 1993 12:35:08 -0700
Message-Id: <199305261935.AA29082 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1459 on Internet Relay Chat Protocol
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 12:35: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 1459:
Title: Internet Relay Chat Protocol
Author: J. Oikarinen & D. Reed
Mailbox: jto at tolsun.oulu.fi, avalon at coombs.anu.edu.au
Pages: 65
Characters: 138,964
Updates/Obsoletes: none
The IRC protocol was developed over the last 4 years since it was
first implemented as a means for users on a BBS to chat amongst
themselves. Now it supports a world-wide network of servers and
clients, and is stringing to cope with growth. Over the past 2 years,
the average number of users connected to the main IRC network has
grown by a factor of 10. The IRC protocol is a text-based protocol,
with the simplest client being any socket program capable of
connecting to the server.
This memo defines an Experimental Protocol for the Internet community.
Discussion and suggestions for improvement are requested. Please
refer to the current edition of the "IAB Official Protocol Standards"
for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at 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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1459.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1459.txt";
site="nic.ddn.mil";
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 aa15125;
26 May 93 16:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15121;
26 May 93 16:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23980;
26 May 93 16:46 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15107;
26 May 93 16:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15083;
26 May 93 16:45 EDT
Received: from Valinor.Stanford.EDU by CNRI.Reston.VA.US id aa23929;
26 May 93 16:45 EDT
Received: by Valinor.Stanford.EDU (5.65/inc-1.0)
id AA03327; Wed, 26 May 93 13:45:40 -0700
Date: Wed, 26 May 93 13:45:39 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf at valinor.stanford.edu>
To: ietf at CNRI.Reston.VA.US
Office: Spruce Hall F15, (415) 723-6860
Usmail: Pine Hall 115, Stanford, CA, 94305-4122
Subject: Amsterdam hotels
Message-Id: <CMM.0.90.2.738449139.vaf at Valinor.Stanford.EDU>
Not sure if this has been discussed before, so: can someone "in the know" in
Amsterdam describe the differences between the three, four, and five star
hotels which are listed on the IETF hotel reservation form? I don't care much
for luxury, but clean is important (and a private bath is nice to have).
Thanks,
--Vince
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16214;
26 May 93 17:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16210;
26 May 93 17:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26659;
26 May 93 17:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16190;
26 May 93 17:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16113;
26 May 93 17:41 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa26562; 26 May 93 17:41 EDT
Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA01607 for ietf at cnri.reston.va.us; Wed, 26 May 93 17:41:58 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA23831; Wed, 26 May 93 14:41:13 PDT
Message-Id: <9305262141.AA23831 at aland.bbn.com>
To: Vince Fuller <vaf at valinor.stanford.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: re: Amsterdam hotels
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 26 May 93 14:41:13 -0700
X-Orig-Sender: craig at aland.bbn.com
Vince:
I won't speak about the particular hotels, just European hotels in
general.
First, if you want a private bath, you typically have to pay a lot
extra. The shared bathrooms are quite clean, and each room will have
a sink, so unless you're a shower fiend (and even then) it is usually
worth saving one's money for other things like ristafel at a good
Amsterdam restaurant.
Second, the star rating system is based on a number of factors related
to issues of room layout, amenities, etc. In general, anything of three stars
or better is likely to be OK. While five stars sometimes means some really
wonderful hotel with concierge in a 16th century building, it more often
means the local Hyatt-equivalent. Only an on-site reporter or a Michelin red
guide can give you a better sense of whether the individual hotels are worth
the differences in price.
Craig
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16266;
26 May 93 17:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26826;
26 May 93 17:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16244;
26 May 93 17:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16220;
26 May 93 17:43 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa26705;
26 May 93 17:43 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA05701>; Wed, 26 May 1993 14:44:19 -0700
Message-Id: <199305262144.AA05701 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1458 on Requirements for Multicast Protocols
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 14:44:17 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 1458:
Title: Requirements for Multicast Protocols
Author: R. Braudes & S. Zabele
Mailbox: rebraudes at tasc.com, gszabele at tasc.com
Pages: 19
Characters: 48,106
Updates/Obsoletes: none
Multicast protocols have been developed over the past several years to
address issues of group communication. Experience has demonstrated
that current protocols do not address all of the requirements of
multicast applications. This memo discusses some of these unresolved
issues, and provides a high-level design for a new multicast transport
protocol, group address and membership authority, and modifications to
existing routing protocols.
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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1458.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1458.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 aa16418;
26 May 93 17:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27186;
26 May 93 17:51 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16403;
26 May 93 17:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16375;
26 May 93 17:50 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27131;
26 May 93 17:50 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA05964>; Wed, 26 May 1993 14:50:43 -0700
Message-Id: <199305262150.AA05964 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1457 on Security Label Framework for the Internet
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 14:50:41 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 1457:
Title: Security Label Framework for the Internet
Author: R. Housley
Mailbox: Housley.McLean_CSD at Xerox.COM
Pages: 14
Characters: 35,802
Updates/Obsoletes: none
This memo presents a security labeling framework for the Internet.
The framework is intended to help protocol designers determine what,
if any, security labeling should be supported by their protocols. The
framework should also help network architects determine whether or not
a particular collection of protocols fulfill their security labeling
requirements. The Open Systems Interconnection Reference Model
provides the structure for the presentation, therefore OSI protocol
designers may also find this memo useful.
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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1457.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1457.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 aa16495;
26 May 93 17:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27297;
26 May 93 17:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16481;
26 May 93 17:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16453;
26 May 93 17:55 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27281;
26 May 93 17:55 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA06041>; Wed, 26 May 1993 14:55:55 -0700
Message-Id: <199305262155.AA06041 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1455 on Link Security TOS
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 14:55:53 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 1455:
Title: Physical Link Security Type of Service
Author: D. Eastlake, III
Mailbox: dee at ranger.enet.dec.com
Pages: 6
Characters: 12,391
Updates/Obsoletes: none
This RFC documents an experimental protocol providing a Type of
Service (TOS) to request maximum physical link security. This is an
addition to the types of service enumerated in RFC 1349: Type of
Service in the Internet Protocol Suite. The new TOS requests the
network to provide what protection it can against surreptitious
observation by outside agents of traffic so labeled. The purpose is
protection against traffic analysis and as an additional possible
level of data confidentiality. This TOS is consistent with all other
defined types of service for IP version 4 in that it is based on link
level characteristics and will not provide any particular guaranteed
level of service.
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at 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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1455.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1455.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 aa16656;
26 May 93 18:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27562;
26 May 93 18:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16641;
26 May 93 18:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16618;
26 May 93 18:07 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27546;
26 May 93 18:07 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA06383>; Wed, 26 May 1993 15:07:51 -0700
Message-Id: <199305262207.AA06383 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI19, RFC1463 on FYI--Short Bibliography
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 15:07:49 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new For Your Information (FYI) Request for Comments is now available
in online RFC libraries.
FYI 19:
RFC 1463:
Title: FYI on Introducing the Internet-- A Short
Bibliography of Introductory Internetworking
Readings
Author: E. Hoffman & L. Jackson
Mailbox: ellen at merit.edu, jackson at nsipo.arc.nasa.gov
Pages: 4
Characters: 7,116
Updates/Obsoletes: none
This bibliography offers a short list of recent information resources
that will help the network novice become familiar with the Internet,
including its associated networks, resources, protocols, and history.
This FYI RFC includes references to free sources of information
available on-line as well as traditional publications. A short
section at the end includes information for accessing the on-line
files. This FYI is intentionally brief so it can be easily used as a
handout by user services personnel. This document is based upon the
work of the User Documents Working Group in the User Services Area of
the Internet Engineering Task Force (IETF).
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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1463.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1463.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 aa16718;
26 May 93 18:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16713;
26 May 93 18:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27618;
26 May 93 18:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16698;
26 May 93 18:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16671;
26 May 93 18:09 EDT
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa27577;
26 May 93 18:09 EDT
Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP)
id <21498-0 at survis.surfnet.nl>; Thu, 27 May 1993 00:09:51 +0200
To: Vince Fuller <vaf at valinor.stanford.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Amsterdam hotels
In-reply-to: Your message of Wed, 26 May 93 13:45:39 -0700. <CMM.0.90.2.738449139.vaf at Valinor.Stanford.EDU>
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: +31 30 310290
Telefax: +31 30 340903
Date: Thu, 27 May 93 00:09:50 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Erik Huizer <Erik.Huizer at surfnet.nl>
Message-ID: <"survis.sur.502:26.04.93.22.09.52"@surfnet.nl>
** = clean but cheap, no phone and no tv
*** = clean and less cheap, shower, phane and TV
**** = clean expensive all the goodies
***** = you don't want to stay there if you'd pay yourself
We are currently working hard to put all kind of Info on IETF and
Amsterdam and the Netherlands in our Gopher server. This should be
available by end next week. Watch this space for the announcement.
Erik
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16776;
26 May 93 18:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27658;
26 May 93 18:12 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16761;
26 May 93 18:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16714;
26 May 93 18:11 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27623;
26 May 93 18:11 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA06435>; Wed, 26 May 1993 15:11:29 -0700
Message-Id: <199305262211.AA06435 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: FYI20, RFC1462 on What is the Internet?
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 15:11:27 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A new For Your Information (FYI) Request for Comments is now available
in online RFC libraries.
FYI 20:
RFC 1462:
Title: FYI on "What is the Internet?"
Author: E. Krol & E. Hoffman
Mailbox: e-krol at uiuc.edu, ellen at merit.edu
Pages: 11
Characters: 27,811
Updates/Obsoletes: none
This FYI RFC answers the question, "What is the Internet?" and is
produced by the User Services Working Group (USWG) of the Internet
Engineering Task Force (IETF). Containing a modified chapter from Ed
Krol's 1992 book, "The Whole Internet User's Guide and Catalog," the
paper covers the Internet's definition, history, administration,
protocols, financing, and current issues such as growth,
commercialization, and privatization. We would like to thank O'Reilly
& Associates for permission to reprint the chapter for use in this FYI
RFC.
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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1462.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1462.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 aa16877;
26 May 93 18:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27870;
26 May 93 18:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16862;
26 May 93 18:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16825;
26 May 93 18:22 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa27821;
26 May 93 18:22 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-10)
id <AA06744>; Wed, 26 May 1993 15:23:11 -0700
Message-Id: <199305262223.AA06744 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1461 on Multiprotocol Interconnect on X.25 MIB
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 26 May 93 15:23: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 1461:
Title: SNMP MIB extension for Multiprotocol Interconnect
over X.25
Author: D. Throop
Mailbox: throop at dg-rtp.dg.com
Pages: 21
Characters: 47,945
Updates/Obsoletes: none
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 Multiprotocol
Interconnect (including IP) traffic carried over X.25. The objects
defined here, along with the objects in the "SNMP MIB extension for
the Packet Layer of X.25", "SNMP MIB extension for LAPB", and the
"Definitions of Managed Objects for RS-232-like Hardware Devices",
combine to allow management of the traffic over an X.25 protocol
stack. The RFC is a product of the X.25 Management Information Base
Working Group of the IETF.
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 at NIC.DDN.MIL. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC
Authors", for further information.
Joyce K. Reynolds
USC/Information Sciences Institute
...
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 rfc1461.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1461.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 aa09656;
27 May 93 13:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09652;
27 May 93 13:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18272;
27 May 93 13:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09638;
27 May 93 13:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09527;
27 May 93 13:09 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa17850; 27 May 93 13:09 EDT
Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA12076 for ietf at cnri.reston.va.us; Thu, 27 May 93 13:09:21 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA28651; Thu, 27 May 93 10:08:35 PDT
Message-Id: <9305271708.AA28651 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: ADVANCE PROGRAM FOR ACM SIGCOMM '93
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: Thu, 27 May 93 10:08:34 -0700
X-Orig-Sender: craig at aland.bbn.com
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. Wea Jing Hsu (Nanyang Technological 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 aa12210;
27 May 93 15:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12206;
27 May 93 15:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23059;
27 May 93 15:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12191;
27 May 93 15:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12184;
27 May 93 15:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23049;
27 May 93 15:57 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12178;
27 May 93 15:57 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: oim at mbunix.mitre.org
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: OSI Internet Management: Management Information
Base to Historic
Date: Thu, 27 May 93 15:57:41 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305271557.aa12178 at IETF.CNRI.Reston.VA.US>
The IESG is considering moving RFC1214 "OSI Internet Management:
Management Information Base" off the standards track and designating it
as Historic.
This protocol depends upon RFC 1189 "The Common Management Information
Services and Protocols for the Internet" which was earlier moved to
historic status.
The IESG plans to make a decision in the next few weeks, and
solicitsfinal 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 June 10th.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12437;
27 May 93 16:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12433;
27 May 93 16:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23246;
27 May 93 16:03 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12417;
27 May 93 16:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12336;
27 May 93 16:01 EDT
Received: from virtual11.harvard.edu by CNRI.Reston.VA.US id aa23160;
27 May 93 16:01 EDT
Date: Thu, 27 May 93 16:02:12 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: kee at das.harvard.edu
Message-Id: <9305272002.AA01123 at virtual11.harvard.edu>
To: ietf at CNRI.Reston.VA.US
Subject: help
help
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12588;
27 May 93 16:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23495;
27 May 93 16:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12576;
27 May 93 16:07 EDT
To: IETF-Announce: ;
cc: ietf-rsvp at CNRI.Reston.VA.US
From: ietf-rsvp at CNRI.Reston.VA.US
Reply-to: ietf-rsvp at CNRI.Reston.VA.US
Subject: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
Date: Thu, 27 May 93 16:07:37 -0400
Sender: dlegare at CNRI.Reston.VA.US
Message-ID: <9305271607.aa12576 at IETF.CNRI.Reston.VA.US>
27th IETF - Amsterdam, The Netherlands
MAKE YOUR HOTEL RESERVATIONS BY ****MAY 31ST*****
If you are planning to use the RAI Hotel Service to make hotel
reservations for the 27th IETF, you should send them your Hotel
Booking Form by May 31st. AFTER MAY 31st, HOTEL ACCOMMODATIONS
CANNOT BE GUARANTEED, though requests will still be accepted.
Many of you will not be in your offices on Monday, due to the
Memorial Day holiday, so make your reservations NOW!
Please see Megan's message, included below, for more details.
Debra
========
Dear IETF'ers:
July 12-16, 1993 is the 27th Internet Engineering Task Force which
will be held in Amsterdam at the RAI Congress Centre. The RAI has
it's own Hotel Service which was able to negotiate lower Hotel rates
than I was able to. To obtain these lower rates you MUST register
through the RAI Hotel Service. They have provided the form below,
which I have slightly modified. Please fill out the form according
to the instructions and fax or mail it to the RAI. DO NOT RETURN YOUR
FORM TO THE SECRETARIAT.
Megan
P.S. According to our local host :>> In Europe there are only two sorts
of rooms:
>> SINGLE - contains one bed of aprox. 3 feet wide
>> DOUBLE - contains either two beds of 3 feet each,
or 1 bed of min. 6 feet
>>
>> (We don't do Queens or King Size)
HOTEL BOOKING FORM (page 1 of 2) - 29th IETF, 12-16, July 1993 - (Please Print)
Return this HOTEL BOOKING FORM before May 31, 1993 to: RAI HOTEL SERVICE
Europaplein, NL 1078 GZ AMSTERDAM. Phone: +31 (0) 205491927
Fax : +31 (0) 206462840
***After May 31st***, hotel accommodation cannot be guaranteed, though
requests will still be accepted.
Surname_____________________________________________ Initials___________
Organization____________________________________________________________
Address_________________________________________________________________
_________________________________________________________________
Postal Code and City____________________________________________________
Country_________________________________________________________________
Telephone______________________________ Facsimile_______________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Date of Arrival in Amsterdam_____________ Date of Departure____________
Single Room_____________ Double Room_____________
Preferred Hotel_________________________________ (see page two)
"I prefer the following hotel which is not listed on the HOTEL BOOKING FORM."
Hotel Name:_______________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
DEPOSIT: A guarantee via credit card, a cheque* made out to the RAI HOTEL
SERVICE, or a deposit of Dfl. 250 per room is required. After
receipt of your payment/credit card details, a voucher will be
forwarded to you. Payment must be made in Dutch Guilders. All
costs to transmitter's charge (approx. Dfl. 25 per transfer)
NO ROOMS CAN BE CONFIRMED UNTIL YOUR HOTEL DEPOSIT/CREDIT CARD
GUARANTEE HAS BEEN RECEIVED!!!!!
AMEX____ Diners____ Master____ Visa____ Eurocard ____ Access____
Account No._____________________________ Expiration Date_________________
Cardholder Name__________________________________________________________
Cardholder Signature_____________________________________________________
___Remitted by enclosed cheque payable to RAI HOTEL SERVICE (* personal
cheques cannot be accepted.) The deposit paid will be deductible from
your hotel bill upon presentation of this voucher at the reception desk
of the hotel.
___Remitted to RAI HOTEL SERVICE account No. 54.96.42.528 with the ABN-AMRO
Bank at Amsterdam, the Netherlands,
IETF93, Mr./Ms.____________________________________________________
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
HOTEL BOOKING FORM (page 2 of 2) - 29th IETF, 12-16, July 1993
Hotel accommodation at reduced rates can be reserved in the following hotels:
Hotel Name Stars Single Double Bkfst Incl.
--------------------------------------------------------
Holiday Inn (1) 5 Dfl. 210 Dfl. 255 No
Novotel (1) 4 Dfl. 210 Dfl. 240 Yes
Altea (2) 3 Dfl. 220 Dfl. 220 Yes
(1) Hotel located within walking distance of the RAI.
(2) Hotel located near the RAI.
CANCELLATION: Notification of cancellation must be sent in writing, (postal
mail or facsimile) no later than 72 hours (three days) prior
to originally scheduled arrival time. Notification after this
time will automatically result in a charge of Dfl. 250.
REFUNDS : Refunds, minus administration costs of Dfl. 50, will be dealt
with after the conference.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12696;
27 May 93 16:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23571;
27 May 93 16:09 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12659;
27 May 93 16:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12540;
27 May 93 16:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23480;
27 May 93 16:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12507;
27 May 93 16:07 EDT
X-Org: Corp. for National Research Initiatives
X-Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: IETF-Announce: ;
Cc: x25mib at dg-rtp.dg.com
Subject: WG ACTION: X.25 Management Information Base WG to Conclude
Date: Thu, 27 May 93 16:07:02 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil <gvaudre at CNRI.Reston.VA.US>
Message-ID: <9305271607.aa12507 at IETF.CNRI.Reston.VA.US>
With the publication of RFC 1461 "SNMP MIB extension for Multiprotocol
Interconnect over X.25" as a Proposed Standard, the X.25 Management
Information Base Working Group has completed its charter. For more
information, please contact the Network Management Area Director,
Marshall Rose.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12810;
27 May 93 16:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12803;
27 May 93 16:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23850;
27 May 93 16:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12789;
27 May 93 16:12 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12784;
27 May 93 16:12 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel 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: Compressing TCP/IP headers for low-speed
serial links to Draft Standard
Date: Thu, 27 May 93 16:12:14 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305271612.aa12784 at IETF.CNRI.Reston.VA.US>
The IESG has approved a revision of RFC 1144 "Compressing TCP/IP headers
for low-speed serial links" RFC1144 as a Draft Standard. This
document is an independent submission to the IESG. The IESG
contact person is Alison Mankin.
Technical Summary
This protocol describes a method for compressing the headers of
TCP/IP datagrams to improve performance over low speed serial links.
Working Group Summary
There are no revisions to the protocol needed and no working group
was formed. Bugs in the sample code have been discussed and
corrections have been reviewed on the PPP Extensions mailing list.
Protocol Quality
This protocol has been implemented independently in several products
and is in operational use.
The IESG is aware of several errors in the example code in RFC 1144.
A revised version with version of this RFC will be published upon
approval as a Draft Standard. The expected "diffs" are included as
an appendix to this message.
Appendix
Line numbers of rfc1144.txt
--- 2042,2049 ----
comp->last_cs = lcs;
hlen += th->th_off;
hlen <<= 2;
+ if (hlen > m->m_len) return (TYPE_IP);
goto uncompressed;
found:
/* Found it -- move to the front on the connection list. */
if (lastcs == cs)
--- 2070,2076 ----
deltaS = hlen;
hlen += th->th_off;
hlen <<= 2;
+ if (hlen > m->m_len) return (TYPE_IP);
if (((u_short *) ip)[0] != ((u_short *) &cs->cs_ip)[0] ||
((u_short *) ip)[3] != ((u_short *) &cs->cs_ip)[3] ||
((u_short *) ip)[4] != ((u_short *) &cs->cs_ip)
--- 2527,2533 ----
*/
comp->last_recv = 255;
comp->last_xmit = 255;
+ comp->flags = SLF_TOSS;
}
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12938;
27 May 93 16:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12930;
27 May 93 16:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24044;
27 May 93 16:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12914;
27 May 93 16:16 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12910;
27 May 93 16:16 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel 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: Post Office Protocol - Version 3 to Draft Standard
Date: Thu, 27 May 93 16:16:23 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305271616.aa12910 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet Draft "Post Office Protocol -
Version 3" <draft-rose-pop3-01.txt> as a Draft Standard. This
document is a revision of RFC1225, a Draft Standard Protocol.
The IESG contact person is Erik Huizer.
Technical Summary
POP3 is currently a draft standard (RFC 1225) for remote mailbox
retrieval.
This revision of POP3 replaced the optional RPOP authentication
scheme (which uses "privileged TCP" ports) with a different optional
scheme, APOP, based on MD5, shared-secrets, and challenge-strings.
Working Group Summary
This edit to POP3 consisted primarily of typographic corrections,
along with the change in optional authentication schemes. As such, a
working group was not needed.
Protocol Quality
POP3 is extensively implemented and widely-deployed. The APOP
authentication scheme, while new, has been implemented in three
different packages for nearly a year.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13174;
27 May 93 16:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13168;
27 May 93 16:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24344;
27 May 93 16:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13151;
27 May 93 16:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13147;
27 May 93 16:24 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel 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: RPC and NFS to Informational
Date: Thu, 27 May 93 16:24:36 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305271624.aa13147 at IETF.CNRI.Reston.VA.US>
The IESG has moved the NFS and RPC Protocols off the standards
track. RFC1057 "RPC: Remote Procedure Call Protocol specification
version 2" and RFC1094 "NFS: Network File System Protocol
specification" have been reclassified as Informational Protocols.
The earlier version of RPC, RFC1050 "RPC: Remote Procedure Call
Protocol specification" has been reclassified as Historic. The IESG
contact person is Dave Crocker.
Technical Summary
The movement of the Sun NFS and RPC protocols is the last of a series
of protocol grandfathering actions. These protocols were submitted
to the IAB for standardization in 1989, before the more formal
standards process currently in use was implemented. The standards
process now requires that change control be given to the IETF for
proprietary protocols being submitted for standards track
consideration.
RFC 1057 and RFC 1094 are still relevant to the Internet
community and have therefore been reclassified as informational
documents.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13713;
27 May 93 16:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13709;
27 May 93 16:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24949;
27 May 93 16:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13689;
27 May 93 16:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13685;
27 May 93 16:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24944;
27 May 93 16:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13680;
27 May 93 16:48 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel at isi.edu>
Cc: Internet Architecture Board <iab at isi.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: Transmitting IP Traffic over ARCNET Networks
to Historic
Date: Thu, 27 May 93 16:48:56 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305271648.aa13680 at IETF.CNRI.Reston.VA.US>
The IESG has moved RFC1201 "Transmitting IP Traffic over ARCNET
Networks" off the standards track and has reclassified the protocol
as a Historic protocol. The IESG contact person is Stev Knowles.
Summary
RFC 1201 was intended to eventually replace the full standard RFC
1051 "Standard for the transmission of IP datagrams and ARPpackets
over ARCNET networks. RFC 1201 was published in February 1991 and
has expired in grade as a proposed standard. The IESG is unaware of
the existance of multiple interoperable implementations based on this
specification. RFC 1051 remains a Standard.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16484;
27 May 93 20:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16480;
27 May 93 20:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00194;
27 May 93 20:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16466;
27 May 93 20:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16441;
27 May 93 20:03 EDT
Received: from att-out.att.com by CNRI.Reston.VA.US id aa00173;
27 May 93 20:03 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: sri at qsun.att.com
Date: Thu, 27 May 93 19:01 EDT
Original-From: qsun!sri (Srinivas R Sataluri +1 908 949 7782)
To: ietf at CNRI.Reston.VA.US
Subject: WHOIS
Message-ID: <9305272003.aa00173 at CNRI.Reston.VA.US>
Folks:
For some reason, sometime back, the name of our local mail exploder got
dropped from the ietf mailing list. Therefore, the InterNIC Directory
and Database Services Team missed the lively discussion on the topic
"Suggestion for RFC Authors to be in WHOIS database" initiated by Al
Costanzo (Al at kean.edu) on 27 April 93. I am sure you will now
understand why we did not speak a word during that discussion. We
retrieved the archives and read through the mail messages and
understand the concerns of the community.
After several discussions internally and with our InterNIC partners
(special thanks to Mark Kosters of NSI), we have come up with the
following plan for providing the non-milnet, non-POC WHOIS listings to
the NSFNET community.
Comments and suggestions are most welcome.
Thanks.
-sri (Srinivas R. Sataluri, sri at internic.net, 908-949-7782)
--------------------------------------------------------------------
InterNIC Directory and Database Services
DEFINITIONS & BACKGROUND
DISA: The DISA NIC or the NIC.DDN.MIL
RS: The InterNIC Registration Services Provider - NSI
DS: The InterNIC Directory and Database Services Provider - AT&T
Until March 13, 1993 DISA maintained a WHOIS database that had
information about various components such as, IP numbers, Domain Names,
ASNs, and about persons. When RS came online, most of the non-milnet
WHOIS data has been moved to RS. Now DISA is responsible for milnet
WHOIS data and RS is responsible for the rest of the Internet WHOIS
data. Except for a small part of the Persons information, the rest of
the WHOIS data is related to the registration function and hence will
be maintained by DISA and RS.
The persons data can be divided into three subsets. (a) milnet persons
(b) non-milnet persons who are POCs (Points of Contact) and (c)
non-milnet persons who are non-POCs. The RS WHOIS database acquired
subset (b) and will verify and add to this data and DISA is in the
process of dropping this data from their WHOIS database. Subset (a)
will be maintained and added to by DISA. Subset (c) is an orphan and
this plan addresses this problem.
PLAN OF ACTION:
(1) The non-milnet, non-POC WHOIS listings - subset (c),
are now available via WAIS on "ds.internic.net". For remote WAIS
users the "people.src" file is attached to this mail message.
You may access this database by telnet to "ds.internic.net"
and login as "wais". First type the command "db people" and
then start searching. For access via a gopher client, connect
to host "internic.net" port 70, select the
"InterNIC Directory and Database Services (AT&T)"
menu item and then the
"The DS WHOIS Database <?>"
menu item.
(2) Send the handles of these listings to DISA for removal from
their WHOIS database by 6/11/93
(3) Install a new WHOIS server on the DS machines by 6/11/93
A prerequisite for commissioning this server is the purging
of the non-milnet, non-POC data from the DISA WHOIS database,
so that users won't see duplicates.
PROPOSAL:
* The non-milnet, non-POC WHOIS listings - subset (c), will be made
available on our server through WAIS.
* No new entries or updates to this data will be accepted. However,
deletion of entries will be permitted.
* DS will send a list of the "NIC handles" to DISA so that the
corresponding entries will be purged from the DISA WHOIS database.
* DS will design and implement a special "Persons WHOIS server" that
does the following:
- listens on port 43 of the DS servers
- parses the incoming WHOIS query and,
if the query is for non-person data
-- e.g. IP number, Domain Name, ASN, then
it will send a message back stating that such information is
available with the DISA and RS servers.
else
-- a possible person query, a NIC handle, or can't tell
the server will send the query to both the DISA WHOIS server and
the RS WHOIS server and also search the local DS WHOIS database,
combine the results of the three queries and send them back.
Since the DS WHOIS database is implemented using WAIS, we may
have fewer or different options than those available on the RS and
DISA servers (for example, we won't be able to do initial substring
matches).
* We will contact (through e-mail) and encourage organizations whose
members are in the DS WHOIS database to start their own Directory and
list the appropriate individuals or complete our template and use our
facility. As a general rule, the InterNIC will maintain no more than
50 entries that pertain to a particular organization in the X.500
Directory Service Agents (DSAs) that will be maintained on its
servers. We will work to help organizations implement their own
X.500 DSAs. However, if an organization is unwilling to run their
own Directory, to salvage the information in the DS WHOIS database
and to quickly retire it, we will load all the entries in the DS
WHOIS database belonging to an organization into X.500. If this
results in more than 50 entries for that organization, no new entries
will be accepted from that organization.
As new organizational directories are created, the corresponding
organizational and personnel listings in the DS WHOIS database will
be retired. If a person does not respond to repeated contact attempts
or does not return the forms after three reminders, their entry will
be purged from the DS WHOIS database. If for any reason, the listed
individual does not want a listing in the new Directory, the
corresponding entry will be purged from the DS WHOIS database.
Once entries have been moved into the X.500 Directory, of course
we will accept updates to the entries.
* Users should access different WHOIS servers using the "-h <hostname>"
option of the "whois" command. Examples:
For Internet IP Networks, ASN's, Domains, and POC's access RS,
whois -h rs.internic.net "uiowa.edu"
For MILNET users, hosts, networks, TACs, and PSNs access DISA,
whois -h nic.ddn.mil "ddn.mil"
For Orphaned non-POC, non-milnet entries, access DS (after 6/11/93),
whois -h ds.internic.net "Smith, John"
ADVANTAGES
* There is no duplication of information and hence no synchronization
issue.
* DISA and RS will continue to be authoritative Registration Information
servers.
* DS will become an Internet white-pages Information server because
we run,
- a netfind Client
- a X.500 Client
- mailserver access to the X.500 Directory
- and now a WHOIS server that will search for person entries in
three WHOIS databases
MORE INFORMATION
Related information is available via anonymous FTP on the InterNIC
Directory and Database Services server "ds.internic.net" in the
"/pub/internic-info" directory. "white-pages-position-paper.txt"
contains further details and rationale, "x500desc.txt" contains a
description of our X.500 services, and "organization-x500.template"
contains the template that organizations need to complete for a listing
in our directory.
----------------- people.src ---------------------------
(:source
:version 3
:ip-address "198.49.45.10"
:ip-name "ds.internic.net"
:tcp-port 210
:database-name "people"
:cost 0.00
:cost-unit :free
:maintainer "admin at ds.internic.net"
:description "Non-point-of-contact, non-military entries from the old DDN NIC WHOIS
database.
"
)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16874;
27 May 93 20:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16870;
27 May 93 20:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01102;
27 May 93 20:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16854;
27 May 93 20:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16815;
27 May 93 20:53 EDT
Received: from INFOODS.MIT.EDU by CNRI.Reston.VA.US id aa01063;
27 May 93 20:53 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GYOKQ66VUO000ERM at INFOODS.UNU.EDU>; Thu, 27 May 1993 20:53:51 EDT
Date: Thu, 27 May 1993 20:53:51 -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.unu.edu>
Subject: Re: WHOIS
In-reply-to: <9305272003.aa00173 at CNRI.Reston.VA.US>
To: sri at qsun.att.com
Cc: ietf at CNRI.Reston.VA.US
Message-id: <738550431.213103.KLENSIN at INFOODS.UNU.EDU>
X-Envelope-to: ietf at CNRI.RESTON.VA.US
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>
>After several discussions internally and with our InterNIC partners
>(special thanks to Mark Kosters of NSI), we have come up with the
>following plan for providing the non-milnet, non-POC WHOIS listings to
>the NSFNET community.
I can't resist the urge to point out three things about this
announcement:
-- organizations that have more than 50 people who should be available
through network directories are now required, by InterNIC decision,
to run X.500 servers. Whois-based servers, finger-based servers,
etc., don't count.
-- if the syntax given for "whois", and a few other clues, are
indicative, InterNIC has concluded that all Internet sites are
running UNIX. That is, of course, consistent with the X.500 rule
above, since X.500 servers are not widely available, especially at
reasonable cost, for non-UNIX hosts. Presumably, there is no
conflict of interest here, since AT&T sold off their UNIX business
:-).
-- InterNIC has not provided a warning or transition period during
which organizations can get WHOIS records updated while they work on
X.500 servers. They have also not volunteered to absorb any of the
costs of switching over, including, even for UNIX sites, ISODE
licenses or the equivalent.
I suppose this is an excellent way to build a larger user base for full
X.500 (and the organizations that sell or support X.500 products) at a
time when the community seems to looking, for technical and performance
reasons, at other alternatives. However, in the past, we have usually
let those decisions get made on technical merit or in the marketplace,
not by monopoly control from the unique centralized NIC provider(s).
--john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17199;
27 May 93 21:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17195;
27 May 93 21:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02215;
27 May 93 21:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17180;
27 May 93 21:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17136;
27 May 93 21:46 EDT
Received: from BIG-SCREW.MIT.EDU by CNRI.Reston.VA.US id aa02195;
27 May 93 21:46 EDT
Received: by big-screw
id AA13023; Thu, 27 May 93 21:46:13 -0400
Date: Thu, 27 May 93 21:46:13 -0400
Message-Id: <9305280146.AA13023 at big-screw>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Jeffrey I. Schiller" <jis at mit.edu>
X-Orig-Sender: jis at mit.edu
To: KLENSIN at infoods.mit.edu
Cc: sri at qsun.att.com, ietf at CNRI.Reston.VA.US
In-Reply-To: John C Klensin's message of Thu, 27 May 1993 20:53:51 -0400 (EDT) <738550431.213103.KLENSIN at INFOODS.UNU.EDU>
Subject: Warning: Brokeness (accountability problem) alert! (was: WHOIS)
I have some real concerns about using X.500 for the replacement
WHOIS service. Specifically I have problems with the notion that the
X.500 white pages pilot has just magically turned into a production
service without any accountability for the operation of the X.500 root
and the C=US portion of the DIT.
The C=US portion of the DIT has been unavailable now for over 24
hours. One result of this is that people using ds.internic.net's Person
Query facility cannot lookup anyone at MIT (or at any other organization
that isn't directly registered under C=US[1]). This is because MIT is
registered under st=Massachusetts and there are currently no X.500
services operating that provide this information.
I spoke with Sri this evening at the InterNIC. Sri explained to
me that:
1) MIT was unsearchable because the C=US servers run by PSI are not
operating.
2) They were the responsibility of PSI.
3) He had no idea why they were down, nor when they would come back.
4) His contact at PSI had not returned his inquiries.
I don't mean to throw mud in Sri's nor PSI's direction. The
problem here is that a production service (the InterNIC) is dependent on
a white pages *experiment* which depends for a critical piece of its
operation upon the altruism of PSI. PSI is to my knowledge is *not*
being financed to run the White Pages project and shouldn't be held
accountable to providing reliable service unless they are being paid to
do so (or have otherwise made a commitment to the Internet Community
[2]).
This is a *problem*.... How do we get it fixed?
Sri informed me that AT&T is looking into running a replicated
copy (i.e., slave DSA) for C=US. If this came up tomorrow (or maybe
yesterday :-) ) our immediate problem would be solved. However
changes/additions still depend on the reliability of the MASTER DSA run
by PSI. Perhaps AT&T should contract with PSI to operate the MASTER DSA
(i.e., throw some money at PSI if they will agree to run the MASTER DSA
as a production service).
-Jeff
[1] Organizations registered directly under C=US are cached by many
DSAs, including AT&T's and are therefore searchable provided their own
DSA's are operational.
[2] I don't mean to imply that only organizations/people who accept
money are reliable. However I never heard PSI volunteer to run the C=US
portion of *the* X.500 DIT. I see that they *have been volunteered*. Of
course there *may* be an agreement between PSI and AT&T or between PSI
and the NSF, which I am not privy to.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20628;
27 May 93 23:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20624;
27 May 93 23:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04496;
27 May 93 23:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20608;
27 May 93 23:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20586;
27 May 93 23:23 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa04436; 27 May 93 23:23 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA28260; Thu, 27 May 93 20:23:38 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA19999; Thu, 27 May 93 20:26:03 pdt
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eva Kuiper <eva at hpindda.cup.hp.com>
Message-Id: <9305280326.AA19999 at hpindda.cup.hp.com>
Subject: Re: Warning: Brokeness (accountability problem) alert! (was: WHOIS)
To: "Jeffrey I. Schiller" <jis at mit.edu>
Date: Thu, 27 May 93 20:26:00 PDT
Cc: KLENSIN at infoods.mit.edu, sri at qsun.att.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <9305280146.AA13023 at big-screw>; from "Jeffrey I. Schiller" at May 27, 93 9:46 pm
Mailer: Elm [revision: 64.9]
Jeffrey,
I echo your concerns. If we are dependent upon a service being available
there needs to be some kind of contract in existence for the provision
of that service. Service providers do not operate on a volunteer basis
and volunteer services cannot be depended on to provide as important a
service as the root service for an X.500 directory. This is an extremely
critical service and it needs a fully committed service provider. There is
no issue about whether or not we should have a production service. We are
ready for such a service and it is technically possible today. The issue
is getting the commitments in place for going into production mode now that
we need it.
Eva
>
> I have some real concerns about using X.500 for the replacement
> WHOIS service. Specifically I have problems with the notion that the
> X.500 white pages pilot has just magically turned into a production
> service without any accountability for the operation of the X.500 root
> and the C=US portion of the DIT.
>
> The C=US portion of the DIT has been unavailable now for over 24
> hours. One result of this is that people using ds.internic.net's Person
> Query facility cannot lookup anyone at MIT (or at any other organization
> that isn't directly registered under C=US[1]). This is because MIT is
> registered under st=Massachusetts and there are currently no X.500
> services operating that provide this information.
>
> I spoke with Sri this evening at the InterNIC. Sri explained to
> me that:
>
> 1) MIT was unsearchable because the C=US servers run by PSI are not
> operating.
>
> 2) They were the responsibility of PSI.
>
> 3) He had no idea why they were down, nor when they would come back.
>
> 4) His contact at PSI had not returned his inquiries.
>
> I don't mean to throw mud in Sri's nor PSI's direction. The
> problem here is that a production service (the InterNIC) is dependent on
> a white pages *experiment* which depends for a critical piece of its
> operation upon the altruism of PSI. PSI is to my knowledge is *not*
> being financed to run the White Pages project and shouldn't be held
> accountable to providing reliable service unless they are being paid to
> do so (or have otherwise made a commitment to the Internet Community
> [2]).
>
> This is a *problem*.... How do we get it fixed?
>
> Sri informed me that AT&T is looking into running a replicated
> copy (i.e., slave DSA) for C=US. If this came up tomorrow (or maybe
> yesterday :-) ) our immediate problem would be solved. However
> changes/additions still depend on the reliability of the MASTER DSA run
> by PSI. Perhaps AT&T should contract with PSI to operate the MASTER DSA
> (i.e., throw some money at PSI if they will agree to run the MASTER DSA
> as a production service).
>
> -Jeff
>
> [1] Organizations registered directly under C=US are cached by many
> DSAs, including AT&T's and are therefore searchable provided their own
> DSA's are operational.
>
> [2] I don't mean to imply that only organizations/people who accept
> money are reliable. However I never heard PSI volunteer to run the C=US
> portion of *the* X.500 DIT. I see that they *have been volunteered*. Of
> course there *may* be an agreement between PSI and AT&T or between PSI
> and the NSF, which I am not privy to.
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00682;
28 May 93 3:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00678;
28 May 93 3:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01245;
28 May 93 3:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00654;
28 May 93 3:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00604;
28 May 93 2:53 EDT
Received: from [192.83.231.1] by CNRI.Reston.VA.US id aa01008;
28 May 93 2:53 EDT
Received: from simon.Brain-Space.internode.com.au by wraith.internode.com.au with DMSP (5.64+1.3.1+0.50/UA-5.23)
id AA09244; Fri, 28 May 1993 16:22:06 +0930
Date: Fri, 28 May 1993 16:22:06 +0930
Message-Id: <9305280652.AA09244 at wraith.internode.com.au>
To: dkatz at cisco.com
Subject: Re: OSI Multicast? (esp. DECnet/OSI) -available?
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon Hackett <simon at internode.com.au>
Reply-To: simon at internode.com.au
Cc: ietf at CNRI.Reston.VA.US
X-Orig-Sender: simon at internode.com.au
Repository: internode.com.au
Originating-Client: Brain-Space.internode.com.au
Dave Katz writes:
>
> OSI multicast is in the process of being defined, so I would be surprised if
> there was any product available.
...and the many other private replies I have received seem to echo
this sentiment. There appears to be no standard OSI way to do this at
all, let alone being any commercial fielded implementations. I have
got mail from some people mentioning experimental implementations
(none under VMS :-) ), but you can't buy it right now, whatever "it"
may ultimately be.
Thanks to all who replied. I'll settle on IP multicast for this
project, which is what I expected I'd do (and it suits me fine). As
many people reiterated in their mail to me, IP multicast is stable,
fielded, and getting easier and easier to buy in commercial protocol stacks.
Cheers,
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04388;
28 May 93 9:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04384;
28 May 93 9:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09397;
28 May 93 9:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04370;
28 May 93 9:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04258;
28 May 93 9:42 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa09329; 28 May 93 9:42 EDT
Received: by ftp.com
id AA06671; Fri, 28 May 93 09:42:38 -0400
Date: Fri, 28 May 93 09:42:38 -0400
Message-Id: <9305281342.AA06671 at ftp.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Warning: Brokeness (accountability problem) alert! (was: WHOIS)
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
> I echo your concerns. If we are dependent upon a service being available
> there needs to be some kind of contract in existence for the provision
> of that service. Service providers do not operate on a volunteer basis
> and volunteer services cannot be depended on to provide as important a
> service as the root service for an X.500 directory. This is an extremely
> critical service and it needs a fully committed service provider. There is
> no issue about whether or not we should have a production service. We are
> ready for such a service and it is technically possible today. The issue
> is getting the commitments in place for going into production mode now that
> we need it.
Fine, either the people providing the service are broken, or the
people who wrote the RFP/contract for the service are broken. If it
is the first, then we beat up on the providers until they do the
right thing (or live with the problem or find someone else willing to
do it somehow). If it is the second then what do we do? The current
Internic contract is multi-year if I remember right (5 years seems to
stick in my mind here). What do we do for the next 4.5 years?
This second issue is more insidious. What happens in 4 years, when
the Internic contract comes up again? The RFP will have the same
holes (or different holes) in it. The current Internic people,
having learned (I hope) what it takes to run a net, will respond to
the RFP and include in their proposal something to cover the holes,
and their price will include covering the holes. Someone else will
respond to the letter of the RFP and, presumably, have a lower price
since they do not have to pay to cover the holes. Which one wins the
bid?
--
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 aa04463;
28 May 93 9:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04459;
28 May 93 9:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09473;
28 May 93 9:46 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04434;
28 May 93 9:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04396;
28 May 93 9:45 EDT
Received: from att-out.att.com by CNRI.Reston.VA.US id aa09437;
28 May 93 9:45 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: sri at qsun.att.com
Date: Fri, 28 May 93 09:38 EDT
Original-From: qsun!sri (Srinivas R Sataluri +1 908 949 7782)
To: KLENSIN at infoods.mit.edu,
"Jeffrey I. Schiller" <att!att!mit.edu!jis at qsun.att.com>
Cc: ietf at CNRI.Reston.VA.US, wpp-manager at psi.com
Subject: Re: Warning: Brokeness (accountability problem) alert! (was: WHOIS)
Message-ID: <9305280945.aa09437 at CNRI.Reston.VA.US>
Jeff:
> I have some real concerns about using X.500 for the replacement
> WHOIS service. Specifically I have problems with the notion that the
> X.500 white pages pilot has just magically turned into a production
> service without any accountability for the operation of the X.500 root
> and the C=US portion of the DIT.
>
I will summarize the reasons which are in the position paper.
- a distributed directory service is a good thing because it permits the
data to be moved closer to the "owner" and hence increases the accuracy
and also addresses privacy concerns.
- the current WHOIS system is centralized
- at present, X.500 is the only technology with extensive distribution
and replication features
We are not planning to provide a new white pages service for the
Internet. We want to complement existing efforts. I did not say that
the X.500 white pages pilot has turned into a production service.
However, we will work on becoming an "official" slave for the c=US data
to improve the situation.
> The C=US portion of the DIT has been unavailable now for over 24
> hours. One result of this is that people using ds.internic.net's Person
> Query facility cannot lookup anyone at MIT (or at any other organization
> that isn't directly registered under C=US[1]). This is because MIT is
> registered under st=Massachusetts and there are currently no X.500
> services operating that provide this information.
>
> I spoke with Sri this evening at the InterNIC. Sri explained to
> me that:
>
> 1) MIT was unsearchable because the C=US servers run by PSI are not
> operating.
>
> 2) They were the responsibility of PSI.
>
> 3) He had no idea why they were down, nor when they would come back.
>
> 4) His contact at PSI had not returned his inquiries.
>
> I don't mean to throw mud in Sri's nor PSI's direction. The
> problem here is that a production service (the InterNIC) is dependent on
> a white pages *experiment* which depends for a critical piece of its
> operation upon the altruism of PSI. PSI is to my knowledge is *not*
> being financed to run the White Pages project and shouldn't be held
> accountable to providing reliable service unless they are being paid to
> do so (or have otherwise made a commitment to the Internet Community
> [2]).
>
PSI is doing an excellent job with the resources they committed to this
project. We have a good working relationship and we came up with this
idea of an other "official" slave only last week. System outages do
happen. Moreover, our present efforts are based upon public-domain,
unsupported, experimental software. It is not possible to provide
service guarantees in such an environment. I agree that InterNIC is a
production service, and therefore we will make every effort to keep our
DSAs and DUAs running. As I said earlier, we will become an official
slave for c=US. But we can not guarantee that the world-wide
distributed X.500 Directory will always be accessible and operational.
> This is a *problem*.... How do we get it fixed?
>
> Sri informed me that AT&T is looking into running a replicated
> copy (i.e., slave DSA) for C=US. If this came up tomorrow (or maybe
> yesterday :-) ) our immediate problem would be solved. However
> changes/additions still depend on the reliability of the MASTER DSA run
> by PSI. Perhaps AT&T should contract with PSI to operate the MASTER DSA
> (i.e., throw some money at PSI if they will agree to run the MASTER DSA
> as a production service).
>
> -Jeff
We have a working agreement with PSI (no contract or money involved).
They only have to do additions and deletions which they do with a
good turn-around time. Typically, access rights are set such that
the owner of the entry, typically the DSA manager of the organization
can make changes.
>
> [1] Organizations registered directly under C=US are cached by many
> DSAs, including AT&T's and are therefore searchable provided their own
> DSA's are operational.
>
> [2] I don't mean to imply that only organizations/people who accept
> money are reliable. However I never heard PSI volunteer to run the C=US
> portion of *the* X.500 DIT. I see that they *have been volunteered*. Of
> course there *may* be an agreement between PSI and AT&T or between PSI
> and the NSF, which I am not privy to.
>
-sri
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04992;
28 May 93 10:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04988;
28 May 93 10:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10249;
28 May 93 10:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04964;
28 May 93 10:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04935;
28 May 93 10:13 EDT
Received: from att-out.att.com by CNRI.Reston.VA.US id aa10201;
28 May 93 10:13 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: sri at qsun.att.com
Date: Fri, 28 May 93 10:09 EDT
Original-From: qsun!sri (Srinivas R Sataluri +1 908 949 7782)
To: John C Klensin <att!att!INFOODS.UNU.EDU!KLENSIN at qsun.att.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: WHOIS
Message-ID: <9305281013.aa10201 at CNRI.Reston.VA.US>
John:
> >After several discussions internally and with our InterNIC partners
> >(special thanks to Mark Kosters of NSI), we have come up with the
> >following plan for providing the non-milnet, non-POC WHOIS listings to
> >the NSFNET community.
>
> I can't resist the urge to point out three things about this
> announcement:
>
> -- organizations that have more than 50 people who should be available
> through network directories are now required, by InterNIC decision,
> to run X.500 servers. Whois-based servers, finger-based servers,
> etc., don't count.
For reasons of reliability, accuracy and privacy, it is a good thing
to move data closer to its "owner". We do not mandate any technology.
Due to the gateways and Gopher, today any system is accessible.
>
> -- if the syntax given for "whois", and a few other clues, are
> indicative, InterNIC has concluded that all Internet sites are
> running UNIX. That is, of course, consistent with the X.500 rule
> above, since X.500 servers are not widely available, especially at
> reasonable cost, for non-UNIX hosts. Presumably, there is no
> conflict of interest here, since AT&T sold off their UNIX business
> :-).
Thanks. I take it as a compliment. We use several leading edge
technologies in running the service, namely, archie, netfind, gopher,
WAIS, X.500, e-mail, etc., and the machines are made by SUN. There is
no conflict of interest. Yes, to run an X.500 QUIPU server you need
UNIX. I remember reading about a server on an IBM mainframe, I could be
wrong. However, thanks to LDAP, X.500 DUAs that run on PCs and Macs are
starting to appear (examples: macX500 from University of Michigan and
DE-PC from the PARADISE project).
>
> -- InterNIC has not provided a warning or transition period during
> which organizations can get WHOIS records updated while they work on
> X.500 servers. They have also not volunteered to absorb any of the
> costs of switching over, including, even for UNIX sites, ISODE
> licenses or the equivalent.
>
We clearly mentioned that "No new entries or updates to this data will
be accepted. However, deletion of entries will be permitted." Hence,
transition out of the WHOIS database ASAP is necessary, otherwise the
data will become obsolete. I feel that if an organization wants its
people to be visible on the Internet, they should run a directory.
> I suppose this is an excellent way to build a larger user base for full
> X.500 (and the organizations that sell or support X.500 products) at a
> time when the community seems to looking, for technical and performance
> reasons, at other alternatives. However, in the past, we have usually
> let those decisions get made on technical merit or in the marketplace,
> not by monopoly control from the unique centralized NIC provider(s).
>
> --john
>
I am sorry you came to this sort of a conclusion. You know that we have
no conflict of interest. We are trying to pick from the available
technologies. You do the same and thanks to gateways and other methods
everything will hang together. Actually, we are running as fast as we
can from the monopoly controlled unique centralized WHOIS database.
Thanks.
-sri
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06955;
28 May 93 11:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06951;
28 May 93 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12517;
28 May 93 11:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06934;
28 May 93 11:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06856;
28 May 93 11:12 EDT
Received: from INFOODS.MIT.EDU by CNRI.Reston.VA.US id aa12461;
28 May 93 11:12 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GYPC01BG0W000E26 at INFOODS.UNU.EDU>; Fri, 28 May 1993 11:12:30 EDT
Date: Fri, 28 May 1993 11:12:30 -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.unu.edu>
Subject: Re: WHOIS
In-reply-to: <01GYPEBQY2JM000G29 at INFOODS.UNU.EDU>
To: sri at qsun.att.com
Cc: ietf at CNRI.Reston.VA.US
Message-id: <738601950.263103.KLENSIN at INFOODS.UNU.EDU>
X-Envelope-to: ietf at CNRI.RESTON.VA.US
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>
Sri,
Thanks for your note. One observation and an aside...
-- I hope it isn't the majority, but there are at least some organizations
that have active Internet involvement that also have one-, and sometimes
two-year or longer, budget cycles.
Assume for the moment that we take "it wants to be visible..., they
should run a directory" and "ASAP" are taken as given. If this means
new platforms, new software, reorganization of local databases, training
staff, etc., "ASAP" is a serious block of time.
Take a variation on my situation as an example. I've got a couple of
different budget cycles, most of which couldn't be used to underwrite
this work. Of the ones that conceivably could, one has a year starting
1 October, but the budget for FY94 is already complete and frozen, so I
couldn't start serious work (if at all) in this area until October 94 at
the earliest. The other plausible option is a two-year cycle that next
opens in January 95.
So, independent of the other issues involved here, I'm having a
problem with the "we've decided to do it this way, we have done it, here
is the announcement, and you better convert ASAP because we have trashed
your entries in the WHOIS database" (old version) or "because, while we
have agreed to keep them, we won't accept new entries or update
anything" (new version) nature of this beast.
Taking the DNS transition as a partial precedent, the orderly thing
to do would be to announce a plan, ask for comments, install and test
the technology and be sure that it can really stand production stresses,
and then announce a schedule that is consistent with resource
requirements outside your organization as well as those inside. I
suppose it is too late for that.
Aside: Your email gateway needs fixing. The "To:" field in the message
that arrived here read:
To: John C Klensin <att!INFOODS.UNU.EDU!KLENSIN at att>
In addition to being unattractive, this violates a firm requirement
about the use of fully-qualified domain names to the right of "@" and a
number of important principles about header-munging.
I would hope that InterNIC member organizations could manage to set
better examples, lest what they do be taken as precedents and
justification by misbehaving sites we keep trying to straighten out.
john
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07929;
28 May 93 11:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13639;
28 May 93 11:45 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07898;
28 May 93 11:44 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07831;
28 May 93 11:41 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bridge-mib at pa.dec.com
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-bridge-sr-objects-01.txt
Date: Fri, 28 May 93 11:41:57 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9305281141.aa07831 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 Bridge MIB Working Group
of the IETF.
Title : Definitions of Managed Objects for Source Routing
Bridges
Author(s) : E. Decker, K. McCloghrie, P. Langille, A. Rijsinghani
Filename : draft-ietf-bridge-sr-objects-01.txt
Pages : 25
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP based internets. In particular it defines objects for managing
source routing bridges.
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-bridge-sr-objects-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-bridge-sr-objects-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-bridge-sr-objects-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bridge-sr-objects-01.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 aa08007;
28 May 93 11:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08003;
28 May 93 11:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13672;
28 May 93 11:46 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07988;
28 May 93 11:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07903;
28 May 93 11:44 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa13617;
28 May 93 11:44 EDT
Received: by atlas.xylogics.com id AA16763 (5.65c/UK-2.1-930202);
Fri, 28 May 1993 11:48:18 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Gary Scott Malkin <gmalkin at xylogics.com>
Date: Fri, 28 May 1993 11:48:18 -0400
Message-Id: <16763.199305281548 at atlas.xylogics.com>
To: kasten at ftp.com
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: Frank Kastenholz's message of Fri, 28 May 93 09:42:38 -0400 <9305281342.AA06671 at ftp.com>
Subject: Warning: Brokeness (accountability problem) alert! (was: WHOIS)
> This second issue is more insidious. What happens in 4 years, when
> the Internic contract comes up again? The RFP will have the same
> holes (or different holes) in it. The current Internic people,
> having learned (I hope) what it takes to run a net, will respond to
> the RFP and include in their proposal something to cover the holes,
> and their price will include covering the holes. Someone else will
> respond to the letter of the RFP and, presumably, have a lower price
> since they do not have to pay to cover the holes. Which one wins the
> bid?
I do not mean to offend those who have handled the NIC function these
past couple of years, but I don't think the job should ever have left
SRI in the first place. We had a system which worked because the
people running it had many years of experience. The work they did
often exceeded what was expected of them because they were committed
to what they were doing, not just because they were getting paid for
it. Every time the NIC changes hands, we loose the accumulated
experience.
This particular change is even worse than the first because now the
job is split up into three different places. We have lost vital
services and made those which still exist harder to use. In the
old days we had but one place to go for information and any way we
could think to ask worked (granted there were fewer mechanisms then).
Now we have three different places to go and they have arbitrarily
restricted the available access mechaninisms.
It sort of reminds me of the phone company break up. In the old days
we had one company with good reates and great service. Now ...
I know that some of you are thinking, "We'll he's just against
progress." Nothing could be further from the truth. However, just
because we can do a thing doesn't mean we must do a thing. There's
something to be said for, "If it ain't broke don't fix it." OK,
I guess that's enough cliches for one message.
----------------------------------------------------------------------
Gary Malkin Remember- take care of your feet,
(617) 272-8140 and always have respect for cows.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08451;
28 May 93 12:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14229;
28 May 93 12:03 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08409;
28 May 93 12:03 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07316;
28 May 93 11:31 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-egevang-addrtrans-01.txt
Date: Fri, 28 May 93 11:31:10 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9305281131.aa07316 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
NOTE: The previous version of this Internet Draft was named
"draft-tsuchiya-addrtrans-00.txt".
Title : The IP Network Address Translator (Nat)
Author(s) : Paul Francis, Kjeld Egevang
Filename : draft-egevang-addrtrans-01.txt
Pages : 11
The two most compelling problems facing the IP Internet are IP address
depletion and scaling in routing. Long-term and short-term solutions
to these problems are being developed. The short-term solution is
CIDR (Classless InterDomain Routing). The long-term solutions consist
of various proposals for new internet protocols with larger addresses.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-egevang-addrtrans-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-egevang-addrtrans-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-egevang-addrtrans-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-egevang-addrtrans-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 aa08464;
28 May 93 12:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14239;
28 May 93 12:03 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id ab08409;
28 May 93 12:03 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07378;
28 May 93 11:33 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-hitchcock-eid-00.txt
Date: Fri, 28 May 93 11:33:05 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9305281133.aa07378 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Endpoint Identifiers: What do they do and why are
they a good thing?
Author(s) : D. Hitchcock
Filename : draft-hitchcock-eid-00.txt
Pages : 5
There has been an ongoing debate on the Big Internet list over the
past year over whether abstracting the concept of Endpoint Identifier
(EID) from the concept of address which has significance in the
topology of the network. This draft attempts to summarize the
arguments pro and con as well as some discussion of whether the EID
should be in the network layer or elsewhere. This draft also contains
a specific proposal for EID format with a discussion of the pros and
cons of this choice.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-hitchcock-eid-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-hitchcock-eid-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-hitchcock-eid-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-hitchcock-eid-00.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 aa08489;
28 May 93 12:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14255;
28 May 93 12:04 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08429;
28 May 93 12:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08341;
28 May 93 12:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14174;
28 May 93 12:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08335;
28 May 93 12:01 EDT
X-Org: Corp. for National Research Initiatives
X-Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: IETF-Announce: ;
Cc: tpix at world.std.com
Subject: WG ACTION: TP/IX (tpix)
Date: Fri, 28 May 93 12:01:48 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil <gvaudre at CNRI.Reston.VA.US>
Message-ID: <9305281201.aa08335 at IETF.CNRI.Reston.VA.US>
A new working group has been formed in the Internet Area of the IETF.
Please contact the working group chair or the Internet area directors
for more information.
Greg Vaudreuil
IESG Secretary
TP/IX (tpix)
------------
Charter
Chair(s):
Vladimir Sukonnik <sukonnik at process.com>
Internet Area Director(s)
Stev Knowles <stev at ftp.com>
David Piscitello <dave at mail.bellcore.com>
Mailing lists:
General Discussion:tpix at world.std.com
To Subscribe: tpix-request at world.std.com
Archive: world.std.com:~/pub/tpix/*
Description of Working Group:
TP/IX is a new version of the IP and TCP/UDP protocols, to
advance the Internet technology to the scale and performance of
the next generation of internetwork technology. TP/IX has been
assigned the IP Protocol Identifier 7.
The Working Group is chartered to review the TP/IX and RAP
protocols, evaluate issues arising during product development
and deployment planning, and to document problems and
explanations for any parts of the coexistance with IPv4 not
covered directly in the TP/IX-IPv4 interoperation design.
The WG will also be the initial forum for development of the RAP
protocol while it is experimental; this work will need to be moved
to the Routing Area when it is to be advanced.
Goals and Milestones:
Done Present the TP/IX and the RAP protocols to the IETF Plenary.
May 93 Post the TP/IX Protocol and the RAP protocol as Experimental RFCs.
Jul 93 Hold Working Group meeting to discuss additional definitions.
Prepare criteria to be met prior to standardization.
Nov 93 Hold Working Group meeting to evaluate the TP/IX and RAP protocols
for Proposed Standard.
Dec 93 Submit the TP/IX and RAP Protocols to the IESG for consideration as a
Proposed Standard.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09042;
28 May 93 12:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09038;
28 May 93 12:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14790;
28 May 93 12:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09024;
28 May 93 12:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08978;
28 May 93 12:21 EDT
Received: from att-out.att.com by CNRI.Reston.VA.US id aa14724;
28 May 93 12:21 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: sri at qsun.att.com
Date: 28 May 93 16:21:00 GMT
Content-Length: 3130
Content-Type: text
Original-From: qsun!sri (Srinivas R Sataluri +1 908 949 7782)
To: John C Klensin <KLENSIN at infoods.unu.edu>
Cc: ietf at CNRI.Reston.VA.US
Received: from qsun by att.att.com; Fri, 28 May 93 12:21 EDT
Subject: Re: WHOIS
Message-ID: <9305281221.aa14724 at CNRI.Reston.VA.US>
John:
> Thanks for your note. One observation and an aside...
>
Thanks for both. I passed on the "aside" to our system administrator
and we will see what can be done. Until it is resolved, I will
manually edit the To: field.
> -- I hope it isn't the majority, but there are at least some organizations
> that have active Internet involvement that also have one-, and sometimes
> two-year or longer, budget cycles.
> Assume for the moment that we take "it wants to be visible..., they
> should run a directory" and "ASAP" are taken as given. If this means
> new platforms, new software, reorganization of local databases, training
> staff, etc., "ASAP" is a serious block of time.
> Take a variation on my situation as an example. I've got a couple of
> different budget cycles, most of which couldn't be used to underwrite
> this work. Of the ones that conceivably could, one has a year starting
> 1 October, but the budget for FY94 is already complete and frozen, so I
> couldn't start serious work (if at all) in this area until October 94 at
> the earliest. The other plausible option is a two-year cycle that next
> opens in January 95.
> So, independent of the other issues involved here, I'm having a
> problem with the "we've decided to do it this way, we have done it, here
> is the announcement, and you better convert ASAP because we have trashed
> your entries in the WHOIS database" (old version) or "because, while we
> have agreed to keep them, we won't accept new entries or update
> anything" (new version) nature of this beast.
> Taking the DNS transition as a partial precedent, the orderly thing
> to do would be to announce a plan, ask for comments, install and test
> the technology and be sure that it can really stand production stresses,
> and then announce a schedule that is consistent with resource
> requirements outside your organization as well as those inside. I
> suppose it is too late for that.
We are talking about the approximately 9,000 orphaned non-POC,
non-milnet WHOIS listings. Comparing these with DNS which is vital for
almost all the application programs may be inappropriate. Sometime
back, the NIC stopped taking new WHOIS listings as per NSF's advice.
This is a given. We are trying to salvage the data. Just to address
the concerns you raised above, our proposal states that we will
maintain any number of entries for organizations transitioning out of
the DS WHOIS database (non-POC, non-milnet). These transitioned
entries can be updated.
The number of Internet users is very large for a central WHOIS
database. Further, beyond technology, there are several privacy issues
that need to be addressed. The IETF IDS group has just started to work
on a document aimed at directory service providers. Erik Huizer
recently posted a paper titled "Directory Services and Privacy
Issues". Unless all these issues are clearly understood it may not be
wise, for any one, to establish an international directory service.
I got your message: "hasten slowly with the transition!" We will do our
best.
Thanks for your comments.
-sri
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09561;
28 May 93 12:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09557;
28 May 93 12:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15388;
28 May 93 12:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09542;
28 May 93 12:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09511;
28 May 93 12:46 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa15363;
28 May 93 12:46 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11675>; Fri, 28 May 1993 09:46:38 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 28 May 1993 09:46:27 -0700
To: ietf at CNRI.Reston.VA.US
Cc: deering at parc.xerox.com
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
In-reply-to: Your message of "Thu, 27 May 93 13:07:37 PDT."
<9305271607.aa12576 at IETF.CNRI.Reston.VA.US>
Date: Fri, 28 May 1993 09:46:22 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <93May28.094627pdt.12171 at skylark.parc.xerox.com>
Has anyone received confirmation of their hotel reservation from RAI?
I faxed them a reservation form about 3 weeks ago, and haven't received
a letter or fax in response, confirming that they actually reserved a
room for me.
Another, no doubt frequently asked, question: What are the issues
with taking a PowerBook to Europe? I assume I need a plug adaptor --
any suggested sources? Will my modem work? Are RJ-11 phone sockets
used in the hotel rooms? Are there likely to be any customs hassles,
any required paperwork?
Steve Deering
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10045;
28 May 93 13:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10041;
28 May 93 13:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16402;
28 May 93 13:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10003;
28 May 93 13:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09920;
28 May 93 13:22 EDT
Received: from INFOODS.MIT.EDU by CNRI.Reston.VA.US id aa16344;
28 May 93 13:22 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GYPC01BG0W000E26 at INFOODS.UNU.EDU>; Fri, 28 May 1993 13:22:28 EDT
Date: Fri, 28 May 1993 13:22: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: John C Klensin <KLENSIN at infoods.unu.edu>
Subject: Re: WHOIS
In-reply-to: <01GYPISG9CK2000DX7 at INFOODS.UNU.EDU>
To: sri at qsun.att.com
Cc: ietf at CNRI.Reston.VA.US
Message-id: <738609748.303103.KLENSIN at INFOODS.UNU.EDU>
X-Envelope-to: ietf at CNRI.RESTON.VA.US
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>
Sri,
>Just to address
>the concerns you raised above, our proposal states that we will
>maintain any number of entries for organizations transitioning out of
>the DS WHOIS database (non-POC, non-milnet). These transitioned
>entries can be updated.
This is exactly the sort of statement I was looking for, and which I
don't recall seeing earlier. My concern is that, to the degree
possible, we not make things worse, even temporarily, as part of the
plan for making them better. The timeframe for making things better is
independent. E.g., if there is a WHOIS entry now, and the organization
moves, I'm unhappy about choosing between "old, wrong record" and "no
record" as the only options. If you need some flavor of "only
grandfathered records go there, other things have to be part of a
directory structure", I'm concerned, but a lot less concerned.
john
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11072;
28 May 93 14:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17640;
28 May 93 14:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11056;
28 May 93 14:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10880;
28 May 93 13:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17470;
28 May 93 13:58 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10862;
28 May 93 13:58 EDT
X-Org: Corp. for National Research Initiatives
X-Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: IETF-Announce: ;
Cc: ietf-rip at xylogics.com
Subject: WG ACTION: RIP Version II (ripv2)
Date: Fri, 28 May 93 13:58:41 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil <gvaudre at CNRI.Reston.VA.US>
Message-ID: <9305281358.aa10862 at IETF.CNRI.Reston.VA.US>
The RIP Version 2 Working Group has been reactivated to review the
protocol for possible advancement in the standards track. For more
information, please contact the working group chairman or the Routing
area director.
Greg Vaudreuil
IESG Secretary
RIP Version II (ripv2)
----------------------
Charter
Chair(s):
Gary Malkin <gmalkin at xylogics.com>
Routing Area Director(s)
Robert Hinden <hinden at eng.sun.com>
Mailing lists:
General Discussion:ietf-rip at xylogics.com
To Subscribe: ietf-rip-request at xylogics.com
Archive: xylogics.com:gmalkin/rip/rip-arc
Description of Working Group:
RIP Version 2 and the Version 2 MIB was approved as a Proposed
Standard in January 1993. They were published as RFC1388 and RFC
1389. Since the mimimum required period has elapsed for a protocol
to remain as a Proposed Standard, RIP V2 can now be considered for
advancement to Draft Standard.
The RIP Version 2 Working Group will prepare a recommendation to the
IESG evalating the standards track status of RIP Version 2 and the
RIP Version 2 MIB. The recommendation will document implementation,
interoperability and deployment experience as required by RFC 1264
"Routing Protocol Criteria".
This group is chartered to prepare revisions of RFC 1388, RIP
Version 2, RFC 1389, the RIP Version 2 MIB, and RFC 1387, analysis
of the protocol if necessary.
Goals and Milestones:
Jul 93 Hold working group meeting to review RIP Version 2 implementations
and make any changes needed to the specifications.
Nov 93 Post as an Internet Draft a report describing the implementation and
operational experience of the RIP v2 protocol in accordance with the
RFC 1264 "Routing Protocol Criteria".
Mar 94 Submit the RIP Version 2 protocol to the IESG for consideration as a
Draft Standard.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11599;
28 May 93 14:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11595;
28 May 93 14:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18083;
28 May 93 14:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11581;
28 May 93 14:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11499;
28 May 93 14:11 EDT
Received: from cise.cise.nsf.gov by CNRI.Reston.VA.US id aa17997;
28 May 93 14:11 EDT
Received: by cise.cise.nsf.gov id <AA05901 at cise.cise.nsf.gov>; Fri, 28 May 93 14:11:31 -0400
Message-Id: <9305281811.AA05901 at cise.cise.nsf.gov>
To: ietf at CNRI.Reston.VA.US, complaints at internic.net
Subject: Re: Warning: Brokeness (accountability problem) alert! (was: WHOIS)
Cc: steve at cise.cise.nsf.gov, dmitchel at cise.cise.nsf.gov, phuston at nsf.gov
Date: Fri, 28 May 93 14:11:29 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 cise.cise.nsf.gov>
Gentlefolk -
Please cc: complaints at internic.net
in this exchange. That way you KNOW the responsible program officers at the
NSF - as well as the InterNIC managers and staff - will see what you say, be
able to gauge from the intensity and frequency of messages the level of your
discontent, and be impelled to move quickly to try to alleviate the problem.
The InterNIC multi-award had a 3 month "ramp-up" Jan-Mar, and is now just
under 2 months into the 60-month "period of performance". Teething pains
are more than we had expected, but will be overcome. We rely on the
Internet community's continued advice, suggestions, and complaints to improve
and hasten the process.
-s
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12244;
28 May 93 14:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12240;
28 May 93 14:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18625;
28 May 93 14:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12230;
28 May 93 14:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12226;
28 May 93 14:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18620;
28 May 93 14:32 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12218;
28 May 93 14:32 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 Bridges to
Draft Standard
Date: Fri, 28 May 93 14:32:09 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305281432.aa12218 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Bridge MIB Working Group to
consider <draft-ietf-bridge-objects-02.txt> "Definitions of Managed
Objects for Bridges" for the status of Draft 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
June 10th.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12596;
28 May 93 14:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12592;
28 May 93 14:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19070;
28 May 93 14:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12578;
28 May 93 14:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12515;
28 May 93 14:44 EDT
Received: from SAFFRON.ACC.COM by CNRI.Reston.VA.US id aa19019;
28 May 93 14:43 EDT
Received: by saffron.acc.com (4.1/SMI-4.1)
id AA04176; Fri, 28 May 93 11:44:17 PDT
Date: Fri, 28 May 93 11:44:17 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker at acc.com>
Message-Id: <9305281844.AA04176 at saffron.acc.com>
To: deering at parc.xerox.com
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
Cc: ietf at CNRI.Reston.VA.US
>> Has anyone received confirmation of their hotel reservation from RAI?
>> I faxed them a reservation form about 3 weeks ago, and haven't received
>> a letter or fax in response, confirming that they actually reserved a
>> room for me.
I FAXed them a hotel request last February, and they were very
helpful. They *didn't* FAX back the response, however, they mailed it
(cheaper, I suppose). It took a couple of weeks to arrive. You might
give them a call Monday morning (9 hour time difference from PDT makes
your morning their late afternoon). I don't think they are a 24 hour
service; When I called them in the middle of the night their time there
wasn't even an answering machine.
They answer the phone in some foreign language :^)
Fred
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13113;
28 May 93 15:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13109;
28 May 93 15:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19703;
28 May 93 15:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13091;
28 May 93 15:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13087;
28 May 93 15:11 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel 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: Point to Point Protocol MIBs to Proposed Standard
Date: Fri, 28 May 93 15:11:32 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9305281511.aa13087 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet Drafts
o "The Definitions of Managed Objects for the Bridge Network Control
Protocol of the Point-to-Point Protocol"
<draft-ietf-pppext-bridgemib-03.txt>
o "The Definitions of Managed Objects for the IP Network Control
Protocol of the Point-to-Point Protocol"
<draft-ietf-pppext-ipcpmib-03.txt>
o "The Definitions of Managed Objects for the Link Control Protocol of
the Point-to-Point Protocol" <draft-ietf-pppext-lcpmib-03.txt>
o "The Definitions of Managed Objects for the Security Protocols of
the Point-to-Point Protocol" <draft-ietf-pppext-secmib-03.txt>
as a Proposed Standard. These documents are the product of the
Point-to-Point Protocol Extensions Working Group. The IESG contact
person is Marshall Rose.
Technical Summary
These allow a network management station to monitor, configure, and
control the operation of a PPP interface in a host or a router.
Working Group Summary
The working group, over the course of two years, evaluated several
different approaches to MIB design. At first, an attempt was made to
have a single MIB module be all inclusive: counting, monitoring,
configuring or controlling every possible facet of the PPP. After
evaluating this early version of the MIB, it was realized that the
MIB was too big and cumbersome to be useful. The MIB was re-designed
to include only those variables which are absolutely essential to
managing PPP. Variables which "might be useful" or which were useful
only in debugging implementations or which were used to configure PPP
where there are defaults defined in the PPP specications were
discarded. The end result is a compact, well-designed collection of
four modules which the working group believes covers the essential
elements of the PPP in regards to debugging network problems.
Protocol Quality
The Network Management Area Director has reviewed the MIB modules and
suggested numerous small corrections. The Working Group incorporated
these changes. At present, there are no implementations.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15177;
28 May 93 16:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15173;
28 May 93 16:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21822;
28 May 93 16:33 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15161;
28 May 93 16:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15118;
28 May 93 16:31 EDT
Received: from INFOODS.MIT.EDU by CNRI.Reston.VA.US id aa21787;
28 May 93 16:31 EDT
Received: from INFOODS.UNU.EDU by INFOODS.UNU.EDU (PMDF V4.2-11 #042B2) id
<01GYPC01BG0W000E26 at INFOODS.UNU.EDU>; Fri, 28 May 1993 16:31:43 EDT
Date: Fri, 28 May 1993 16:31:43 -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.unu.edu>
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
In-reply-to: <93May28.094627pdt.12171 at skylark.parc.xerox.com>
To: deering at parc.xerox.com
Cc: ietf at CNRI.Reston.VA.US
Message-id: <738621103.335103.KLENSIN at INFOODS.UNU.EDU>
X-Envelope-to: ietf at CNRI.RESTON.VA.US
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>
>Has anyone received confirmation of their hotel reservation from RAI?
Yes. But they are sending them by post, so be patient. Took mine
about three weeks or so to come back after I faxed it to them.
>What are the issues
>with taking a PowerBook to Europe?
I've been waiting until Erik's gopher reference goes live, then
planning on scanning it and adding whatever else I can think of in this
area (I spend a lot of my life travelling to strange places with a
laptop, and Amsterdam is *not* strange). However, since you asked...
>I assume I need a plug adaptor -- any suggested sources?
If you don't care about grounding, Radio Shack and most department
stores. You are looking for a doo-dad with two round pins, but make
sure you get the "standard European" one, since there are some with
different pin sizes and/or spacing. If you don't find one before you go
over, these adaptors tend to be readily available, at only slightly
ridiculous prices, at airport electronics shops (and you haven't seen
airport shops until you see Schiphol). Most European hotels also keep
some adaptors (and voltage converters) on hand for silly tourists, but
the number of us probably exceeds expectations of supply.
If you do care about grounding, you don't want a plug adaptor but a
cord that has a "European" plug at one end (look for a round-ish shell,
with round metal pins in the middle and strips of metal running parallel
to the pins at the top and bottom of the shell) and the EIA
three-parallel-flat-pin thing that fits most computers and voltage-
adjusting charger/ adaptors at the other. They are hard to find in the
US, but some computer accessory stores do carry them, although at
premium prices.
> Will my modem work?
Yes, as long as you stay at or above 2400 baud or switch it to
"CCITT" (as distinct from "Bell") at the lower speeds. But you better
figure out who you are calling. Note, e.g., that international calls
from hotels in Europe tend to involve costly surprises and that the
"dial the US using our operators" services offered by AT&T, MCI, Sprint,
et al involve people who sometimes can't seem to stay off the line long
enough to transmit a fax, much less carry on an interactive session,
etc.
If it works, the odds that it is legal are low, but you need to check
with the local arrangements folks on that and then decide how much you
care.
>Are RJ-11 phone sockets used in the hotel rooms?
In general, European phones are either hard-wired (still) or use
sockets that differ from country to country and sometimes by regions
within countries. RJ11 adaptors to those sockets are widely available,
but, in theory, for use only with locally-type-accepted phones that have
"international" (i.e., RJ11) connectors on them.
Two other things to watch out for:
-- a lot of better European hotels (much higher percentage than in the
US) have digital phone systems. Unless the hotel makes special
provisions, that is the end of any hope of modem use, etc., and the
special provisions are not, in my experience, common (but I haven't been
in an Amsterdam hotel in four years or so).
-- where analog phones are in use, the systems in many European
countries are set up for "telephone meters" (very much like water or
electric meters) in which the phone company can transmit a
meter-advancing click back on one of the other wires each time you use
up a phone "unit". Since these things were designed in the days of
mechanical stepping relays, clicks can be pretty impressive: circa 70
volts and the better part of an amp in some parts of the world. Rather
than contemplate what that might do to your modem, make sure you bring
a two-wire-only cord or some equivalent isolation to which to connect
your RJ11 gear.
>Are there likely to be any customs hassles,
>any required paperwork?
No. Not unless someone suspects that you are bringing the machine in
for resale. I've occasionally had customs folks wonder when something
has come in that looks a little too new, or in factory packaging, but
I've never had a problem with a machine that has obviously been used and
kicked around a bit, especially after I explain what I do for a living.
For folks who are paranoid and who have machines that are not of US
manufacture, bringing either a purchase receipt for the machine that
shows the serial number with you or completing a "certificate of
registration for personal effects taken abroad" with the customs folks
in your departure airport will save hassles if some over-zealous US
official tries to charge you duty on it when you return. But I haven't
had that stunt pulled on me for at least five or six years, so wouldn't
spend energy worrying about it.
In general, you will find that dealing with customs and immigration
in Europe makes you wonder why it is so unpleasant here: I've spent more
time at "agricultural pest control" stops between states here than
getting into and out of most European countries.
The other caveat which probably hasn't been mentioned enough is that you
will need a passport. Anyone who is going to Amsterdam who doesn't have
one yet needs to get on it immediately, as the State Department can be a
little slow on first-time ones and it is now their busy season. If you
do it by mail, be sure to tell them where you are going and when you
have to leave. If you have your airline ticket already, enclose a copy
to reinforce your travel plans.
john
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15547;
28 May 93 17:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15543;
28 May 93 17:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22872;
28 May 93 17:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15531;
28 May 93 17:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15502;
28 May 93 17:10 EDT
Received: from POLARIS.INTEROP.COM by CNRI.Reston.VA.US id aa22820;
28 May 93 17:10 EDT
Received: from interop.com (mailer.interop.com) by polaris.interop.com (4.1/SMI-4.1)
id AA28660; Fri, 28 May 93 14:13:12 PDT
Message-Id: <9305282113.AA28660 at polaris.interop.com>
Date: 28 May 1993 14:12:04 -0800
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Richard James <Richard_James at interop.com>
Subject: Re: 27th IETF - HOTEL RESER
To: Steve Deering <deering at parc.xerox.com>, ietf at CNRI.Reston.VA.US,
deering at parc.xerox.com
Reply to: RE>>27th IETF - HOTEL RESERV
Given all the international travel that is being organized on this list, I
thought this would be useful info to many.
In Vol. 7, Num. 6(Jan 6, 1993), pgs. 40-41 of The Seybold Report on Desktop
Publishing is an article on traveling with a computer. It speaks of the
"Impactron International Travel Kit" for use with Mac and PC laptops with
modems. The kit supposedly contains all the connectors needed to connect to
nearly all the phone systems you will encounter in world travel.
Product: Impactron International Travel Kit
Company: Impactron Limited
72-76 Brighton Road
Surrey KT6 5PP, UK
phone: {44} 81 390 8522
fax: {44} 81 390 8534
Price: ~#163#101 ($160)
I have not used this product nor am I affiliated with Impactron Limited company
in any way.
Richard James
Interop Company
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16265;
28 May 93 18:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16261;
28 May 93 18:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24377;
28 May 93 18:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16247;
28 May 93 18:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16207;
28 May 93 18:17 EDT
Received: from apple.com by CNRI.Reston.VA.US id aa24356; 28 May 93 18:16 EDT
Received: from [17.130.21.118] by apple.com with SMTP (5.61/7-Aug-1992-eef)
id AA04357; Fri, 28 May 93 15:17:08 -0700
for ietf at CNRI.Reston.VA.US
Date: Fri, 28 May 93 15:17:08 -0700
Message-Id: <9305282217.AA04357 at apple.com>
To: Steve Deering <deering at parc.xerox.com>, ietf at CNRI.Reston.VA.US,
deering at parc.xerox.com, Richard James <Richard_James at interop.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Veizades <veizades at apple.com>
X-Sender: veizades at 130.43.2.2
Subject: Re: 27th IETF - HOTEL RESER
The nice thing about PowerBooks is that their power supply will adjust to
all common voltages. So all you need to plug a powerbook into a European
wall socket is the plug adapter.
John Veizades...
Apple Computer, Inc.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16471;
28 May 93 19:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab16467;
28 May 93 19:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25207;
28 May 93 19:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16455;
28 May 93 19:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16431;
28 May 93 19:04 EDT
Received: from [130.144.65.1] by CNRI.Reston.VA.US id aa25165;
28 May 93 19:04 EDT
Return-Path: <geertj at ica.philips.nl>
Received: from philica.ica.philips.nl ([130.144.131.1]) by relay.philips.nl with SMTP (5.65c/smail2.5/05-10-87);
id AA06706; Sat, 29 May 1993 01:05:58 +0200
Received: by philica.ica.philips.nl;
id AA01138; Sat, 29 May 93 01:05:06 +0200
Message-Id: <9305282305.AA01138 at philica.ica.philips.nl>
To: John C Klensin <KLENSIN at infoods.mit.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
In-Reply-To: Your message of "Fri, 28 May 1993 16:31:43 EDT."
<738621103.335103.KLENSIN at INFOODS.UNU.EDU>
Date: Sat, 29 May 1993 01:04:59 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Geert Jan de Groot <geertj at ica.philips.nl>
On Fri, 28 May 1993 16:31:43 -0400 (EDT) John C Klensin wrote:
> >I assume I need a plug adaptor -- any suggested sources?
> If you do care about grounding, you don't want a plug adaptor but a
> cord that has a "European" plug at one end (look for a round-ish shell,
> with round metal pins in the middle and strips of metal running parallel
> to the pins at the top and bottom of the shell) and the EIA
> three-parallel-flat-pin thing that fits most computers and voltage-
> adjusting charger/ adaptors at the other. They are hard to find in the
> US, but some computer accessory stores do carry them, although at
> premium prices.
And - most people already know, but finding out is *expensive*, we have
220 volts, 50 Hz in the Netherlands. If your power supply cannot be switched
to that (sometimes a switch, sometimes automatic), you will blow 110V things
up, guaranteed.
> > Will my modem work?
> Yes, as long as you stay at or above 2400 baud or switch it to
> "CCITT" (as distinct from "Bell") at the lower speeds. But you better
> figure out who you are calling. Note, e.g., that international calls
> from hotels in Europe tend to involve costly surprises and that the
> "dial the US using our operators" services offered by AT&T, MCI, Sprint,
> et al involve people who sometimes can't seem to stay off the line long
> enough to transmit a fax, much less carry on an interactive session,
> etc.
> If it works, the odds that it is legal are low, but you need to check
> with the local arrangements folks on that and then decide how much you
> care.
Indeed, calling from Europe is more expensive than the other way around.
Hotels add to that even more, so watch out!
Officially, all phone stuff should be approved. That is the official story;
I know a lot of places where genuine USA modems work. You might want to
check if your modem can dial blind (our dial tone is different), and
if it supports pulse dialling (the phone company usualy has DTMF these
days, but a hotel switch may not). I think you get away with connecting
your modem. You might expect less performance because of the mismatching
between modem and phone line impedance.
> >Are RJ-11 phone sockets used in the hotel rooms?
> In general, European phones are either hard-wired (still) or use
> sockets that differ from country to country and sometimes by regions
> within countries. RJ11 adaptors to those sockets are widely available,
> but, in theory, for use only with locally-type-accepted phones that have
> "international" (i.e., RJ11) connectors on them.
> -- where analog phones are in use, the systems in many European
> countries are set up for "telephone meters" (very much like water or
> electric meters) in which the phone company can transmit a
> meter-advancing click back on one of the other wires each time you use
> up a phone "unit". Since these things were designed in the days of
> mechanical stepping relays, clicks can be pretty impressive: circa 70
> volts and the better part of an amp in some parts of the world. Rather
> than contemplate what that might do to your modem, make sure you bring
> a two-wire-only cord or some equivalent isolation to which to connect
> your RJ11 gear.
If the phone in your hotel room has a plug, it's unlikely to be RJ11.
Fortunately, the Dutch phone plug is weird but standard, 4mm banana jacks
(the ones used on laboratory power supplies) fit in. The pinout is like:
O O <----- these
O O
Of these 4 pins (on a phone plug), you would likely only need the above
two (which compare to USA tip and ring). You might want to make a converter,
or buy one; the 'primafoon' (phone company shop) have converters to RJ11.
Please keep in mind that you do NOT want to connect to the middle 2 wires
of an RJ11 connector (wire 2 and 5) because these are usually wired in those
conversion plugs and give problems. Only connect the middle two (3 and 4).
But then again, I'm not familiar with the phone systems in these hotels.
Hope this helps a bit,
Geert Jan
--8<--nip-nip---------------------------------------------------------------
Geert Jan de Groot, 'Typos hapen'
Philips Consumer Electronics,
Building SFJ2-218, P.O. box 80002, 5600 JB Eindhoven, The Netherlands.
Internet:geertj at ica.philips.nl Phone:+31 40 797408 FAX:+31 40 732340
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16727;
28 May 93 20:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16723;
28 May 93 20:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26435;
28 May 93 20:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16711;
28 May 93 20:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16681;
28 May 93 20:04 EDT
Received: from dirt.cisco.com by CNRI.Reston.VA.US id aa26399;
28 May 93 20:04 EDT
Received: from lager.cisco.com by dirt.cisco.com with TCP; Fri, 28 May 1993 17:03:55 -0700
Message-Id: <199305290003.AA23142 at dirt.cisco.com>
To: Geert Jan de Groot <geertj at ica.philips.nl>
Cc: John C Klensin <KLENSIN at infoods.mit.edu>, ietf at CNRI.Reston.VA.US
Subject: phoning home from hotels
In-Reply-To: Your message of "Sat, 29 May 93 01:04:59 +0100."
<9305282305.AA01138 at philica.ica.philips.nl>
Date: Fri, 28 May 93 17:03:55 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jim Forster <forster at cisco.com>
I've found that AT&T's USA direct is much cheaper than hotel international
rates, and have been able to use it directly from my modem.
Last time I was in Europe, I managed to get my Mac Duo to call home using
this, all in one dial string. It was ATDT <access number>,,,<dialup
number>,,,,<AT&T credit card #>. (The commas are for delays). Note that
since you can mix pulse & tone in the same dial string, you can dial out of
the hotel pbx with pulse, then get through AT&T USA Direct with tone. I
didn't realize this until after spending excessive amounts, tho.
-- Jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17150;
28 May 93 21:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17146;
28 May 93 21:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27761;
28 May 93 21:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17134;
28 May 93 21:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17109;
28 May 93 21:47 EDT
Received: from iha.compuserve.com by CNRI.Reston.VA.US id aa27751;
28 May 93 21:47 EDT
Received: by iha.compuserve.com (5.65/5.930129sam)
id AA07282; Fri, 28 May 93 21:47:25 -0400
Date: 28 May 93 21:43:26 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark McCanna <71333.2311 at compuserve.com>
To: Internet Eng Task Force <ietf at CNRI.Reston.VA.US>
Subject: Copy of: 27th IETF Meeting - Amsterdam, The Netherlands
Message-Id: <930529014326_71333.2311_DHQ18-1 at CompuServe.COM>
---------- Forwarded Message ----------
From: Mark McCanna, 71333,2311
TO: Internet Eng Task Force, INTERNET:ietf-rsvp at cnri.reston.va.us
DATE: 5/28/93 11:55 AM
RE: Copy of: 27th IETF Meeting - Amsterdam, The Netherlands
Greetings, have received the document ISO/IEC 93/641518 N534 and
would be interested in any further information that you might be able to
provide regarding this subject. Previous minutes to meetings sent to my
CIS ID would be appreciated as well as any other information on the
subject.
I am working on an Airport and Obstacle Database (AODB) at IATA
Montreal. This is a database of airport obstacle information maintained
on a BBS here at IATA. I have investigated a number of VANs for
communications service to the BBS as well as attending the last ATA T-mail
meeting in Washington. I cannot emphasize enough how important reliable,
inexpensive, electronic communication is to the success of this project.
If you would like further information on the IATA/AODB project I
would be most happy to send it along via the internet.
Regards, Mark McCanna, Technical Manager, AODB
71333.2311 at Compuserve.com (Internet)
71333,2311 (Compuserve)
514-844-6311 ext 3467 (Voice) 514-844-6727 (Fax) 514-844-2149 or 9285
(BBS)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18469;
28 May 93 22:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18460;
28 May 93 22:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28632;
28 May 93 22:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18448;
28 May 93 22:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18426;
28 May 93 22:29 EDT
Received: from is.rice.edu by CNRI.Reston.VA.US id aa28627; 28 May 93 22:29 EDT
Received: by is.rice.edu (AA03854); Fri, 28 May 93 21:29:25 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Manning <bmanning at is.rice.edu>
Message-Id: <9305290229.AA03854 at is.rice.edu>
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
To: Steve Deering <deering at parc.xerox.com>
Date: Fri, 28 May 93 21:29:24 CDT
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
In-Reply-To: <93May28.094627pdt.12171 at skylark.parc.xerox.com>; from "Steve Deering" at May 28, 93 9:46 am
X-Mailer: ELM [version 2.3 PL11]
Can't say re powerbook, would like to know the answers.
I have the hotel confirmation.
--
Regards,
Bill Manning bmanning at rice.edu PO Box 1892
713-285-5415 713-527-6099 Houston, Texas
R.U. (o-kome) 77251-1892
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00501;
29 May 93 2:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00497;
29 May 93 2:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00877;
29 May 93 2:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00321;
29 May 93 2:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24410;
29 May 93 2:01 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa01895;
29 May 93 2:01 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA03510; Sat, 29 May 93 02:01:52 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA00778; Sat, 29 May 93 02:03:42 EDT
Message-Id: <9305290603.AA00778 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: Steve Deering <deering at parc.xerox.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
In-Reply-To: Your message of "Fri, 28 May 93 09:46:22 PDT."
<93May28.094627pdt.12171 at skylark.parc.xerox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 29 May 93 02:03:42 -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>
Powerbooks are fine with 240 volts - all you need is one of those us to
anywhere adaptors you can find in any electrical shop or airport.
AS for phone connections- you may be lucky and be able to find an RJ-11
being used by the phone itself; this is not too likely. Otherwise,
a spare phone cable, some croc-clips, and a screwdriver will see you through
just about anything.
As for customs hassles- there shouldn't be any problem if the device is for
re-export. I've taken mine into and out of England many times, and never
had any problem.
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02305;
29 May 93 10:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02301;
29 May 93 10:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07429;
29 May 93 10:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02289;
29 May 93 10:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02259;
29 May 93 10:48 EDT
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa07378;
29 May 93 10:48 EDT
Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP)
id <23578-0 at survis.surfnet.nl>; Sat, 29 May 1993 16:47:36 +0200
Received: from localhost.surfnet.nl
by survival.surfnet.nl (4.1/SMI-4.1(TV920629)) id AA06562;
Sat, 29 May 93 16:41:15 +0200
Message-Id: <9305291441.AA06562 at survival.surfnet.nl>
To: Steve Deering <deering at parc.xerox.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
In-Reply-To: Your message of Fri, 28 May 93 09:46:22 -0700. <93May28.094627pdt.12171 at skylark.parc.xerox.com>
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: +31 30 310290
Telefax: +31 30 340903
Date: Sat, 29 May 93 16:41:11 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Erik Huizer <Erik.Huizer at surfnet.nl>
Steve,
Most of your questiions have been answered by now by other people. Let me
add to this:
RJ11 is getting more and mor common in NL. Next week we'll be checking out
the hotel and the plugs they have. If the phones are not hard wired we will
provide adapters for rj-11 in the Novotel and Holiday inn. I will also try
to provide lot's of american-plug to Europlug power adapters. Tjose will
however NOT transform from 110 to 220 V.
I have never been held up by Dutch customs with my Apple DUO, however USA
customs........
Can I ask everyone to hold of questions for 10 more days, by then I hope we
have lot's of input thru ftp/gopher, and then if something is missing, feel
free to approach me. At the moment these type of questions just prevent me
from spending my time in getting things up and running.
Thanks,
Erik
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03251;
29 May 93 15:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03247;
29 May 93 15:42 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12226;
29 May 93 15:42 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03235;
29 May 93 15:42 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03199;
29 May 93 15:40 EDT
Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa12204;
29 May 93 15:40 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id
<01GYQQMXJ1BK8Y53GW at INNOSOFT.COM>; Sat, 29 May 1993 12:40:14 PST
Date: Sat, 29 May 1993 12:31:35 -0800 (PST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ned Freed <NED at innosoft.com>
Subject: RE: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
In-reply-to: Your message dated "Sat, 29 May 1993 02:03:42 -0400"
<9305290603.AA00778 at tipper>
To: Simon E Spero <ses at tipper.oit.unc.edu>
Cc: Steve Deering <deering at parc.xerox.com>, ietf at CNRI.Reston.VA.US
Message-id: <01GYQXOY9NXE8Y53GW at INNOSOFT.COM>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
> As for customs hassles- there shouldn't be any problem if the device is for
> re-export. I've taken mine into and out of England many times, and never
> had any problem.
Simon is correct as far as he goes here. The worst hassle I've had is not from
customs, but from the inspection teams. In some airports they have lists of
machines and they really want to find your model # on that list. If it isn't
there you can be delayed while they check it out with someone higher up. (No, I
don't know why they have lists or what information the lists contain. The fact
that these are dead-serious security types, plus the fact that our only shared
linguistic territory wasn't very large, kinda dissuaded me from asking any
pointed questions about what was going on.)
I happened to have a DEC PC laptop of fairly recent vintage with me on a recent
trip through Europe and I got delayed a couple of times for 15-30 minutes. It
is the first time I recall being penalized for keeping my hardware up to date;
usually it is the other way around ;-)
Ned
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04004;
29 May 93 19:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04000;
29 May 93 19:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15487;
29 May 93 19:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03985;
29 May 93 19:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03949;
29 May 93 19:08 EDT
Received: from [132.160.3.23] by CNRI.Reston.VA.US id aa15425;
29 May 93 19:08 EDT
Received: from foralie.net.hawaii.edu ([132.160.3.1]) by galaxy.net.Hawaii.Edu with SMTP id <119664>; Sat, 29 May 1993 13:06:08 -1000
Date: Sat, 29 May 1993 12:54:27 -1000
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Torben Noerup Nielsen <torben at hawaii.edu>
X-Orig-Sender: Torben Noerup Nielsen <torben at hawaii.edu>
Subject: RE: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
To: Ned Freed <NED at innosoft.com>
cc: Simon E Spero <ses at tipper.oit.unc.edu>,
Steve Deering <deering at parc.xerox.com>, ietf at CNRI.Reston.VA.US
In-Reply-To: <01GYQXOY9NXE8Y53GW at INNOSOFT.COM>
Message-ID: <MailManager.738716067.2197.torben at foralie.net.hawaii.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
>>As for customs hassles- there shouldn't be any problem if the device is for
>>re-export. I've taken mine into and out of England many times, and never
>>had any problem.
>
>Simon is correct as far as he goes here. The worst hassle I've had is not
>from customs, but from the inspection teams. In some airports they have lists
>of machines and they really want to find your model # on that list. If it
>isn't there you can be delayed while they check it out with someone higher
>up. (No, I don't know why they have lists or what information the lists
>contain. The fact that these are dead-serious security types, plus the fact
>that our only shared linguistic territory wasn't very large, kinda dissuade
>me from asking any pointed questions about what was going on.)
I have run into this in Frankfurt. Having a greater linguistic overlap with
them, I asked why they had lists and what they contain. The lists contain
accurate weights and chemical composition information for the components. What
they sometimes do is to weigh the unit to check for possible explosives
inside. The reason is that even working portables could have explosives
stuffed in empty spaces inside (no, there aren't many, but then again, not
much explosive is required to do serious damage either). For items not on the
list, they can run a high power vacuuming unit over it and feed the particles
thus collected into a mass spectrometer. This is tied to a computer that gives
an indication of whether or not such a molecular distribution could have
arisen from known explosives. I have had this done to me because of a video
camera that was not yet commonly available and thus not on the list. If the
result of any of these tests is positive, you may expect major delays while
they check you out. Most people cooperate fully and quietly; loaded submachine
guns pointed directly at them causes most people to be quite cooperative....
Cheers, Torben
P.S. This type of procedure is not in all airports although I wish it were.
After all, I as a passenger have a very strong vested interest in not having
other people bring explosive devices in board a plane.....
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25388;
31 May 93 10:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25384;
31 May 93 10:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22626;
31 May 93 10:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25372;
31 May 93 10:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25337;
31 May 93 10:26 EDT
Received: from iha.compuserve.com by CNRI.Reston.VA.US id aa22565;
31 May 93 10:26 EDT
Received: by iha.compuserve.com (5.65/5.930129sam)
id AA10775; Mon, 31 May 93 10:27:12 -0400
Date: 31 May 93 10:20:21 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark McCanna <71333.2311 at compuserve.com>
To: Internet Eng Task Force <ietf at CNRI.Reston.VA.US>
Subject: Internet Meeting
Message-Id: <930531142021_71333.2311_DHQ49-1 at CompuServe.COM>
Greetings, have received the document ISO/IEC 93/641518 N534 and
would be interested in any further information that you might be able to
provide regarding this subject. Previous minutes to meetings sent to my
CIS ID would be appreciated as well as any other information on the
subject.
I am working on an Airport and Obstacle Database (AODB) at IATA
Montreal. This is a database of airport obstacle information maintained
on a BBS here at IATA. I have investigated a number of VANs for
communications service to the BBS as well as attending the last ATA T-mail
meeting in Washington. I cannot emphasize enough how important reliable,
inexpensive, electronic communication is to the success of this project.
If you would like further information on the IATA/AODB project I
would be most happy to send it along via the internet.
Regards, Mark McCanna, Technical Manager, AODB
71333.2311 at Compuserve.com (Internet)
71333,2311 (Compuserve)
514-844-6311 ext 3467 (Voice) 514-844-6727 (Fax) 514-844-2149 or 9285
(BBS)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28933;
31 May 93 21:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28929;
31 May 93 21:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06401;
31 May 93 21:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28916;
31 May 93 21:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28875;
31 May 93 21:35 EDT
Received: from UTKVX3.UTK.EDU by CNRI.Reston.VA.US id aa06385;
31 May 93 21:35 EDT
Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.2-11 #4157) id
<01GYU8YHWK8G8WW3AB at utkvx.utk.edu>; Mon, 31 May 1993 21:35:30 EDT
Date: Mon, 31 May 1993 21:35:29 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: CASE at utkvx.utk.edu
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
To: torben at hawaii.edu
Cc: ietf at CNRI.Reston.VA.US
Message-id: <01GYU8YI1DUA8WW3AB at utkvx.utk.edu>
X-VMS-To: IN%"torben at hawaii.edu"
X-VMS-Cc: IN%"ietf at CNRI.Reston.VA.US",CASE
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
ddFrom: IN%"torben at hawaii.edu" "Torben Noerup Nielsen" 29-MAY-1993 19:28:25.24
To: IN%"NED at innosoft.com" "Ned Freed"
CC: IN%"ses at tipper.oit.unc.edu" "Simon E Spero", IN%"deering at parc.xerox.com" "Steve Deering", IN%"ietf at CNRI.Reston.VA.US"
Subj: RE: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
Return-path: <ietf-request at ietf.cnri.reston.va.us>
Received: from CS.UTK.EDU by utkvx.utk.edu (PMDF V4.2-11 #4157) id
<01GYRBTZJ8LC8Y66K3 at utkvx.utk.edu>; Sat, 29 May 1993 19:25:12 EDT
Received: from ietf.cnri.reston.va.us by CS.UTK.EDU with SMTP
(5.61+IDA+UTK-930125/2.8s-UTK) id AA09675; Sat, 29 May 93 19:25:01 -0400
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03970; 29
May 93 19:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03949; 29 May
93 19:08 EDT
Received: from [132.160.3.23] by CNRI.Reston.VA.US id aa15425; 29 May 93 19:08
EDT
Received: from foralie.net.hawaii.edu ([132.160.3.1]) by galaxy.net.Hawaii.Edu
with SMTP id <119664>; Sat, 29 May 1993 13:06:08 -1000
Date: Sat, 29 May 1993 12:54:27 -1000
From: Torben Noerup Nielsen <torben at hawaii.edu>
bject: RE: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
In-reply-to: <01GYQXOY9NXE8Y53GW at INNOSOFT.COM>
Sender: ietf-request at IETF.CNRI.Reston.VA.US
To: Ned Freed <NED at innosoft.com>
Cc: Simon E Spero <ses at tipper.oit.unc.edu>,
Steve Deering <deering at parc.xerox.com>, ietf at CNRI.Reston.VA.US
Message-id: <MailManager.738716067.2197.torben at foralie.net.hawaii.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
X-Orig-Sender: Torben Noerup Nielsen <torben at hawaii.edu>
>>As for customs hassles- there shouldn't be any problem if the device is for
>>re-export. I've taken mine into and out of England many times, and never
>>had any problem.
>
>Simon is correct as far as he goes here. The worst hassle I've had is not
>from customs, but from the inspection teams. In some airports they have lists
>of machines and they really want to find your model # on that list. If it
>isn't there you can be delayed while they check it out with someone higher
>up. (No, I don't know why they have lists or what information the lists
>contain. The fact that these are dead-serious security types, plus the fact
>that our only shared linguistic territory wasn't very large, kinda dissuade
>me from asking any pointed questions about what was going on.)
I have run into this in Frankfurt. Having a greater linguistic overlap with
them, I asked why they had lists and what they contain. The lists contain
accurate weights and chemical composition information for the components. What
they sometimes do is to weigh the unit to check for possible explosives
inside. The reason is that even working portables could have explosives
stuffed in empty spaces inside (no, there aren't many, but then again, not
much explosive is required to do serious damage either). For items not on the
list, they can run a high power vacuuming unit over it and feed the particles
thus collected into a mass spectrometer. This is tied to a computer that gives
an indication of whether or not such a molecular distribution could have
arisen from known explosives. I have had this done to me because of a video
camera that was not yet commonly available and thus not on the list. If the
result of any of these tests is positive, you may expect major delays while
they check you out. Most people cooperate fully and quietly; loaded submachine
guns pointed directly at them causes most people to be quite cooperative....
Cheers, Torben
P.S. This type of procedure is not in all airports although I wish it were.
After all, I as a passenger have a very strong vested interest in not having
other people bring explosive devices in board a plane.....
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29070;
31 May 93 21:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29066;
31 May 93 21:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06608;
31 May 93 21:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29054;
31 May 93 21:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29032;
31 May 93 21:52 EDT
Received: from UTKVX3.UTK.EDU by CNRI.Reston.VA.US id aa06593;
31 May 93 21:52 EDT
Received: from utkvx.utk.edu by utkvx.utk.edu (PMDF V4.2-11 #4157) id
<01GYU94TN7NK8WW3AB at utkvx.utk.edu>; Mon, 31 May 1993 21:52:38 EDT
Date: Mon, 31 May 1993 21:52:38 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: CASE at utkvx.utk.edu
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
To: torben at hawaii.edu
Cc: ietf at CNRI.Reston.VA.US
Message-id: <01GYU94TRRMA8WW3AB at utkvx.utk.edu>
X-VMS-To: IN%"torben at hawaii.edu"
X-VMS-Cc: IN%"ietf at CNRI.Reston.VA.US",CASE,CASE
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
1. apologies for the message fragement in busted reply which just leaked out
a "helpful" system administrator changed the default editor behaviour
within mail :-(
2. i have traveled into and out of schipol recently
my laptop/luggable has never been checked against any list but has gotten
the vacuum and gas chromatograph treatment
there were no machine guns visible
everybody was very nice
these discussions are helpful for people to plan, and there is no
substitute for planning ... i also encourage reducing levels of anxiety
in that the rudest customs and security officials i have encountered
anywhere in multiple international trips have always been the ones in
the u.s. [sigh]
one further tip, it is possible to rapidly raise the local police stress
level by appearing to leave a bag unattended/abandoned in an airport
lobby (dont do this)
looking forward to this trip and more details when erik can set up the servers
regards,
jdc
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00702;
1 Jun 93 3:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00698;
1 Jun 93 3:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01606;
1 Jun 93 3:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00675;
1 Jun 93 3:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00593;
1 Jun 93 3:13 EDT
Received: from SYNW03.elettra.trieste.it by CNRI.Reston.VA.US id aa01453;
1 Jun 93 3:13 EDT
Date: Tue, 1 Jun 1993 9:12:56 +0200 (WET-DST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Claudio Allocchio - +39 40 3758523 <ALLOCCHIO at elettra.trieste.it>
Message-Id: <930601091256.34400088 at elettra.trieste.it>
Subject: Customs tip
To: ietf at CNRI.Reston.VA.US
X-Vmsmail-To: SMTP%"ietf at cnri.reston.va.us"
Hallo,
mmmh listening to the on-going discussion about travelling tips I'm realizing
that many things which really look so normal for an European traveller, used
to change language, currency and sometimes side of the road on which to drive
(but are British Islands in Europe?) every "few" kilometers can create doubts
in other travellers. Luckily the European Customs, as already described by
many of you, are a different style compared with the US ones: often security
in the airports in more strict, even if you notice it less than in the US,
but at least the do think "a priori" that you're trying to immigrate illegally
in Europe to apply for some job without a work permit, "risking deportation".
Thus don'w worry too much. Moreover all Dutch Custom officers I met share
a very large English language knowledge, thus they can understand you explai-
ning why you brougth with you your own Bud Light beer because in The Netherland
there is no good beer (but at least they'll be quite surprised! Heineken was
born there... and many many more brands, taste them.).
Just to add to my chats a useful tip: since Jan 1st 1993 within all the EEC
countries there is no more Custom control for EEC citizens. Thus the registered
baggage or travellers within EEC is labelled in a different way (two green
stripes on the edged of the label) to enable Customs to distiguish it from
the others. Thus don't be surprised if a custom office, looking carefully
at the baggage labes pick up just your suitcase inthe middle of many others
with greenish tags just to ask you kindly "anything to declare?".
OK, than have a nice trip to Amsterdam, The Netherlands, Europe!
Claudio
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01178;
1 Jun 93 4:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01174;
1 Jun 93 4:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02967;
1 Jun 93 4:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01162;
1 Jun 93 4:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01139;
1 Jun 93 4:55 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa02951;
1 Jun 93 4:55 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.08507-0 at bells.cs.ucl.ac.uk>; Tue, 1 Jun 1993 09:55:31 +0100
To: ietf at CNRI.Reston.VA.US
Subject: Re: 27th IETF - HOTEL RESERVATIONS - laptops...
In-reply-to: Your message of "Fri, 28 May 93 21:29:24 CDT." <9305290229.AA03854 at is.rice.edu>
Date: Tue, 01 Jun 93 09:55:23 +0100
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Message-ID: <9306010455.aa02951 at CNRI.Reston.VA.US>
>Can't say re powerbook, would like to know the answers.
well, ISDN of course is widely available in europe - just what do you
call back home, though?:-)
jon
joke alert, joke alert, joke alert - do not take seriously.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01234;
1 Jun 93 5:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01230;
1 Jun 93 5:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03026;
1 Jun 93 5:00 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01218;
1 Jun 93 5:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01185;
1 Jun 93 4:58 EDT
Received: from ncc.ripe.net by CNRI.Reston.VA.US id aa02980; 1 Jun 93 4:58 EDT
Received: from reif.ripe.net by ncc.ripe.net with SMTP
id AA05306 (5.65a/NCC-1.3); Tue, 1 Jun 1993 10:59:11 +0200
Message-Id: <9306010859.AA05306 at ncc.ripe.net>
To: ietf at CNRI.Reston.VA.US
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
In-Reply-To: Your message of Mon, 31 May 1993 21:52:38 EDT.
<01GYU94TRRMA8WW3AB at utkvx.utk.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Daniel Karrenberg <Daniel.Karrenberg at ripe.net>
X-Organization: RIPE Network Coordination Centre
X-Phone: +31 20 592 5065
Date: Tue, 01 Jun 1993 10:59:10 +0200
X-Orig-Sender: Daniel.Karrenberg at ripe.net
Just to add some more real life experiences about Amsterdam customs.
Don't worry, be happy!
I have been living here (there) for more than 6 years now. I have gone
through customs at Schipol (Amsterdam airport) roughly twice a month
-say 150 times. I have never *ever* had any baggage inspected. I have
once been asked politely where I was travelling from and been waved thru
afterwards. And no I do not look very repectable sometimes after a long
flight and I don't wear no suits on airplanes either. Actually I have
the outer appearance of the average IETFer. And yes I carry notebooks
sometimes.
Don't worry, be happy!
Note-1: On the other hand I am told that Dutch customs *are* zealous and
*effective* if it comes to drugs and protected species. Don't read the
above to mean you can bring *anything*. You have been warned!
Note-2: Airport security checks are quite similar to those on any airline
flights within the US. No surprises likely there. At Schipol they are
done at the gate rather than at the lobby entrance like most US airports.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03690;
1 Jun 93 9:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08141;
1 Jun 93 9:14 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03662;
1 Jun 93 9:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03550;
1 Jun 93 9:08 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: chassismib at cs.utk.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-chassis-mib-01.txt
Date: Tue, 01 Jun 93 09:08:35 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9306010908.aa03550 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 Chassis MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for a Chassis
Containing Multiple Logical Network Devices
Author(s) : K McCloghrie, D Arneson, M Kaycee, B Stewart, D McMaster
Filename : draft-ietf-chassis-mib-01.txt
Pages : 41
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP based internets. In particular it defines objects for managing
a chassis containing multiple (logical) networking devices, such as
repeaters, bridges, routers, terminal servers, etc.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-chassis-mib-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-chassis-mib-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-chassis-mib-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-chassis-mib-01.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 aa04457;
1 Jun 93 9:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04453;
1 Jun 93 9:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09430;
1 Jun 93 9:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04440;
1 Jun 93 9:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04406;
1 Jun 93 9:54 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa09380; 1 Jun 93 9:54 EDT
Received: by ftp.com
id AA23469; Tue, 1 Jun 93 09:54:33 -0400
Date: Tue, 1 Jun 93 09:54:33 -0400
Message-Id: <9306011354.AA23469 at ftp.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: phoning home from hotels
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
Now, maybe it's just me, but has anyone else noticed the dichotomy
in this thread?
I mean, we've built what can be argued as the "greatest" network in
the world, certainly one of the most sophisticated and powerful.
And here we are, trying to figure out how to connect our computers up
to the phone network so that we can phone home.
--
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 aa08193;
1 Jun 93 12:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08189;
1 Jun 93 12:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14833;
1 Jun 93 12:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08164;
1 Jun 93 12:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08080;
1 Jun 93 12:27 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa14805;
1 Jun 93 12:27 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab02425;
1 Jun 93 16:21 GMT
Date: Tue, 1 Jun 93 16:13 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 CNRI.Reston.VA.US>
Subject: Re: phoning home from hotels
Message-Id: <51930601161315/0003858921NA2EM at mcimail.com>
Frank Kastenholz said:
>Now, maybe it's just me, but has anyone else noticed the dichotomy
>in this thread?
>I mean, we've built what can be argued as the "greatest" network in
>the world, certainly one of the most sophisticated and powerful.
>And here we are, trying to figure out how to connect our computers up
>to the phone network so that we can phone home.
Interesting yes.
But I found that the terminal room at IETF 26 did not meet my needs. So I was
calling my NetBlazer back at corporate and connecting with PPP and doing
whatever I needed to do. Now much of this was 'behind the corporate firewall'
so no INTERNET connection would have helped that. But other things it would
have.
It would be interesting to find out how many people could take advantage of a
PPP service at IETF so a local call from the hotel would yield INTERNET
connectivity. Of course, a direct connection with a Null Modem in the terminal
room would be nice too. Then with the new crop of notebooks with built in LAN
cards or PCMCIA LAN cards, how about a hub and a group off addresses to use for
drop-ins?
But really, I wasn't ready to use the terminal room until around 11:30pm or else
6:00am so I found it of no value.
I am not even asking my management for permission to go to IETF 27, but I am
going to try for 28 in Huston. Maybe something like this can be done there?
Bob Moskowitz
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10669;
1 Jun 93 14:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10665;
1 Jun 93 14:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19094;
1 Jun 93 14:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10653;
1 Jun 93 14:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10598;
1 Jun 93 14:20 EDT
Received: from ns.oar.net by CNRI.Reston.VA.US id aa19045; 1 Jun 93 14:20 EDT
Received: from valhalla.oar.net for kannan at oar.net
by ns.oar.net (5.65c+KVa/920824.1144) id AA21733; Tue, 1 Jun 1993 14:20:51 -0400
Message-Id: <199306011820.AA21733 at ns.oar.net>
X-Mail-Agent: mh-6.7.2-MIME
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Return-Receipt-To:
Reply-To: kannan at oar.net
Subject: Re: phoning home from hotels
In-Reply-To: Your message of Tue, 01 Jun 1993 16:13:00 +0000.<51930601161315/0003858921NA2EM at mcimail.com>
Date: Tue, 01 Jun 1993 14:20:41 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Kannan Varadhan <kannan at oar.net>
>>> From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
>>> Date: Tue, 01 Jun 1993 16:13:00 GMT
> But I found that the terminal room at IETF 26 did not meet my needs. So I wa
> calling my NetBlazer back at corporate and connecting with PPP and doing
> whatever I needed to do. Now much of this was 'behind the corporate firewall'
> so no INTERNET connection would have helped that. But other things it would
> have.
>
> It would be interesting to find out how many people could take advantage of a
> PPP service at IETF so a local call from the hotel would yield INTERNET
> connectivity. Of course, a direct connection with a Null Modem in the terminal
> room would be nice too.
I am sorry that the terminal room at IETF 26 did not meet your
requirements. Did you try out our PPP set up? We logged about 45 hours
of PPP activity on our netblazers. Apart from this, we also had a few
direct connections to dumb terminals available.
> But really, I wasn't ready to use the terminal room until around 11:30pm or else
> 6:00am so I found it of no value.
The room was open 24 hours a day, starting from late saturday evening,
till noon on friday.
I wish you had approached Henry or myself while you were here at IETF to
mention some of this.
Cheers,
Kannan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11155;
1 Jun 93 14:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11146;
1 Jun 93 14:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19735;
1 Jun 93 14:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11126;
1 Jun 93 14:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11030;
1 Jun 93 14:36 EDT
Received: from tadpole.Tadpole.COM by CNRI.Reston.VA.US id aa19623;
1 Jun 93 14:36 EDT
Received: by tadpole.tadpole.com (4.1/SMI-4.1)
id AA07972; Tue, 1 Jun 93 13:36:28 CDT
Date: Tue, 1 Jun 93 13:36:28 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jim Thompson <jim at tadpole.com>
Message-Id: <9306011836.AA07972 at tadpole.tadpole.com>
To: ietf at CNRI.Reston.VA.US, 0003858921 at mcimail.com
Subject: Re: phoning home from hotels
> It would be interesting to find out how many people could take advantage of a
> PPP service at IETF so a local call from the hotel would yield INTERNET
> connectivity. Of course, a direct connection with a Null Modem in the terminal
> room would be nice too. Then with the new crop of notebooks with built in LAN
> cards or PCMCIA LAN cards, how about a hub and a group off addresses to use for
> drop-ins?
The folks running the terminal room at Wash D.C., (last time I got approval
to attend), had no problem with me plugging in to the local ethernet.
Jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15105;
1 Jun 93 16:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15101;
1 Jun 93 16:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22849;
1 Jun 93 16:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15089;
1 Jun 93 16:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15043;
1 Jun 93 16:03 EDT
Received: from sparky.cert.org by CNRI.Reston.VA.US id aa22733;
1 Jun 93 16:03 EDT
Received: from localhost.cert.org by sparky.cert.org (4.1/2.3)
id AA01520; Tue, 1 Jun 93 16:04:14 EDT
Message-Id: <9306012004.AA01520 at sparky.cert.org>
To: ietf at CNRI.Reston.VA.US
Subject: Fifth Computer Security Incident Handling Workshop
Date: Tue, 01 Jun 93 16:04:14 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Barbara Fraser <byf at cert.org>
Fifth Computer Security Incident Handling Workshop
St. Louis Missouri
August 10 - 13, 1993
Hosted by FIRST - Forum of Incident Response and Security Teams
Since November of 1988 a number of government and private organizations in
North America, Europe and Australia have worked together to deal with a
continuous stream of comupter system and network security events which have
affected thousands of sites and hosts, and compromised thousands of accounts.
Known as the Forum of Incident Response and Security Teams, or FIRST, the
coalition brings together a variety of computer security incident response
teams from the public and private sectors as well as from universities. FIRST
aims to foster cooperation and coordination in incident prevention, to prompt
rapid reaction to incidents, and to promote information sharing among members
and the community at large. This workshop is part of that activity. All who
have an interest in computer security incident handling are invited to
attend.
The workshop is being conducted as a series of invited tutorials and
presentations on preselected topics. The presentations will focus on the
complex issues surrounding incident response activities as well as lessons
learned to date. In addition, participants will have the opportunity to
debate and expand upon ideas advanced during the presentations while attending
the fully catered reception on Wednesday evening and the birds-of-a feather
and poster sessions on Thursday evening.
The agenda is:
Tuesday, August 10, 1993, 8:30 AM - 5:00 PM
Three full-day tutorials Creating a Security Policy - Charles Cresson Wood
Responding to Computer Viruses - Padgett Peterson
Unix Security - Matt Bishop
Wednesday, August 11, 1993, 8:30 AM - 9:00 PM
Presentation Sessions Keynote Address
International Issues
Professional Certification and Qualification
Incident Aftermath and Press Relations
Reception
Thursday, August 12, 1993 8:30 AM - 9:00 PM
Presentation Sessions Preserving Rights During an Investigation
Coordinating an Investigation
Liabilities and Insurance
Incident Role Play
BOFs and Poster Sessions
Friday, August 13, 1993 8:30 AM - 1:00 PM
Presentation Sessions Virus Incidents
Databases
Threats
Concluding Remarks
Please address questions regarding the Workshop to:
FIRST Workshop Program Committee
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
+1-412-268-6933
st at cert.org
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
INQUIRES:
Direct questions concerning registration and payment to: Events at 412-268-6531
Direct general questions concerning the workshop to: Mary Alice "Sam" Toocheck
at 412-268-6933
Return to: Helen E. Joyce
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
Facsimile: 412-268-7401
TERMS:
Please make checks or purchase orders payable to SEI/CMU. Credit cards are not
accepted. No refunds will be issued, substitutions are encouraged.
The registrations fee includes materials, continental breakfast, lunches (not
included on August 13), morning and afternoon breaks and an evening reception
on August 11. Completed registration materials must be received by the SEI no
later than July 10, 1993.
Registrations for tutorials will NOT be accepted after the cut-off date. A
minimum of 7 attendees are needed for each tutorial and there will be limit of
50 attendees. You MUST indicate which tutorial you would like to attend and an
alternate if your first choice is full.
GOVERNMENT TERMS:
If your organization has not made prior arrangements for reimbursement of
workshop expenses, please provide authorization (1556) from your agency at the
time of registration.
GENERAL REGISTRATION INFORMATION:
Workshop................................. ..............$300.00
All registrations received after July 10, 1993..........$350.00
Tutorials (Must be registered by July, 10, 1993)........$190.00
NAME:
TITLE:
COMPANY:
DIVISION:
ADDRESS:
CITY:
STATE:
ZIP:
BUSINESS PHONE:
EMERGENCY PHONE:
FACSIMILE NUMBER:
E-MAIL ADDRESS:
DIETARY/ACCESS REQUIREMENTS:
CITIZENSHIP: Are you a U.S. Citizen? YES/NO
Identify country where citizenship is held if not the U.S.:
GENERAL HOTEL INFORMATION:
RATES: A block of rooms has been reserved at the Hyatt Regency at Union
Station, One St. Louis Union Station, St. Louis, Missouri 63103. The hotel
will hold these rooms until July 10, 1993. Hotel arrangements should be made
directly with the Hyatt, 314-231-1234. To receive the special rate of $65.00
per night, please mention the Fifth Computer Security Incident Handling
Workshop when making your hotel arrangements.
ACCOMMODATIONS: Six-story hotel featuring 540 guest rooms, including 20
suites. All rooms have individual climate control, direct-dial telephone with
message alert, color TV with cable and optional pay movies. Suites available
with wet bar. Hotel offers three floors of Regency accomodations, along with
a Hyatt Gold Passport floor, and a special floor for women travelers.
LOCATION/TRANSPORTATION FACTS: Downtown hotel located in historic Union
Station one mile from Cervantes Convention Center and St. Louis Convention
Center and St. Louis Arch. Fifteen miles (30 minutes) from St. Louis Zoo.
DINING/ENTERTAINMENT: Italian Cuisine is featured at Aldo's, the hotel's
full-service restaurant. Enjoy afternoon cocktails in the Grand Hall, an
open-air, six-story area featuring filigree work, fresco and stained glass
windows. The station Grille offers a chop house and seafood menu.
RECREATIONAL/AMUSEMENT FACILITIES: Seasonal outdoor swimming pool. Full
health club; suana in both men's and women's locker rooms. Jogging maps are
available at the hotel front desk.
SERVICES/FACILITIES/SHOPS: Over 100 specialty shops throughout the hotel,
including men's and women's boutiques, children's toy shops and train stores.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15345;
1 Jun 93 16:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15340;
1 Jun 93 16:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23168;
1 Jun 93 16:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15320;
1 Jun 93 16:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15283;
1 Jun 93 16:15 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa23136;
1 Jun 93 16:15 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id cq10179;
1 Jun 93 20:03 GMT
Date: Tue, 1 Jun 93 19:59 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Greenfield <0004020699 at mcimail.com>
To: Daniel Karrenberg <Daniel.Karrenberg at ripe.net>
To: "David E. McDysan" <0002806303 at mcimail.com>
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: Kelly Jackson <0004073507 at mcimail.com>
To: Johna Johnson <0004143837 at mcimail.com>
To: "RND Inc." <0004393582 at mcimail.com>
To: Mary Jander <0004734998 at mcimail.com>
To: Salvatore Salamone <0005379565 at mcimail.com>
To: Blair Sanders <SN=Blair_Sanders%SU=Sanders%GI=Blair%TI at mcimail.com>
To: Bob Stine <0004219666 at mcimail.com>
To: Mustafa Soysal <0003310988 at mcimail.com>
To: owen <owen%WRQ at mcimail.com>
To: Scott Brigham <0002442341 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
Message-Id: <20930601195902/0004020699PK3EM at mcimail.com>
please remove me from this list
thanks
dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18495;
1 Jun 93 19:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18489;
1 Jun 93 19:17 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa29952; 1 Jun 93 19:17 EDT
Received: by bitsy.MIT.EDU
id AA15494; Tue, 1 Jun 93 19:02:09 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA15488; Tue, 1 Jun 93 19:02:07 EDT
Received: from ctt.ctt.bellcore.com by MIT.EDU with SMTP
id AA04800; Tue, 1 Jun 93 19:02:03 EDT
Received: from shadow.secure.bellcore.com by ctt.ctt.bellcore.com (4.1/1.34)
id AA18670; Tue, 1 Jun 93 19:01:59 EDT
Received: by shadow.secure.bellcore.com (4.1/SMI-4.1)
id AA20297; Tue, 1 Jun 93 19:00:46 EDT
Date: Tue, 1 Jun 93 19:00:46 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Lunt <lunt at ctt.bellcore.com>
Message-Id: <9306012300.AA20297 at shadow.secure.bellcore.com>
To: kerberos at athena.mit.edu, yuan at syl.dl.nec.com
Subject: Re: Kerberized ftp with encryption option available.
Cc: cat-ietf at mit.edu
Ruixi,
I have been working on an Internet standard
which defines extensions to the FTP protocol which
provide integrity and confidentiality on both the
control and data channels. I have also implemented
this using BSD ftp/ftpd and Kerberos Version 4.
The intent is to introduce Kerberos Version 5 by means
of the GSSAPI.
See the file draft-ietf-cat-ftpsec-01.txt
on nnsc.nsf.net in the internet-drafts directory.
Also, the code and documentation is available via
anonymous FTP from thumper.bellcore.com in /pub/lunt.
The working group mailing list is cat-ietf at mit.edu.
Comments are appreciated.
-- Steve
Steven J. Lunt lunt at bellcore.com
Information Technology Security RRC 1L-213
Bellcore 444 Hoes Lane
(908) 699-4244 Piscataway, NJ 08854
> From: yuan at syl.dl.nec.com (Ruixi Yuan)
> Date: Fri, 7 May 93 14:38:47 CDT
> To: kerberos at athena.mit.edu
> Subject: Re: Kerberized ftp with encryption option available.
>
> Thanks to the kind offering of resource from Lawrence Livermore
> National Lab. The kerberized ftp with encryption options is now
> available for "Anonymous ftp" from:
>
> lorien.ocf.llnl.gov 134.9.50.3 /pub/mit/kftp-1.0.tar.Z
>
> This package works with MIT Kerberos V5 to provide
> authentication and encrypted file transfer capability
> for FTP across the network.
>
> I would like to hear comments and questions from anyone
> who has worked (is working) on kerberized ftp.
>
> --- Ruixi
>
> ==========================================================
> Ruixi Yuan yuan at syl.dl.nec.com
> NEC Systems Lab. Inc. (214)518-3585(voice)
> 1901 Gateway Drive (214)518-3552(fax)
> Irving, TX 75038
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26195;
2 Jun 93 1:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26191;
2 Jun 93 1:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09604;
2 Jun 93 1:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26179;
2 Jun 93 1:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26152;
2 Jun 93 1:45 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa09549;
2 Jun 93 1:45 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12435>; Tue, 1 Jun 1993 22:45:59 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 1 Jun 1993 22:45:51 -0700
To: ietf at CNRI.Reston.VA.US
To: deering at parc.xerox.com
Subject: Re: 27th IETF - HOTEL RESERVATIONS - MAY 31st DEADLINE
Date: Tue, 1 Jun 1993 22:45:49 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <93Jun1.224551pdt.12171 at skylark.parc.xerox.com>
Many thanks for the messages reporting that RAI does confirm hotel
reservation by postal mail, and for all of the excellent tips on travelling
to and from Europe with a laptop computer. I have gathered together the
messages on the latter topic in a file called powerbook-travel-tips in the
pub/net-research directory on the anonymous-FTP host parcftp.xerox.com.
Steve Deering
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05124;
2 Jun 93 10:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12881;
2 Jun 93 10:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05062;
2 Jun 93 10:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04638;
2 Jun 93 10:14 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: fddi-mib at cs.utk.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-fddimib-objects-02.txt
Date: Wed, 02 Jun 93 10:14:05 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9306021014.aa04638 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 FDDI MIB Working Group
of the IETF.
Title : FDDI Management Information Base
Author(s) : J. Case, A. Rijsinghani
Filename : draft-ietf-fddimib-objects-02.txt
Pages : 62
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it defines objects for
managing devices which implement the FDDI based on the ANSI FDDI SMT
7.3 draft standard, which has been forwarded for publication by the
X3T9.5 committee.
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-fddimib-objects-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-fddimib-objects-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-fddimib-objects-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-fddimib-objects-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 aa05126;
2 Jun 93 10:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12882;
2 Jun 93 10:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05061;
2 Jun 93 10:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04564;
2 Jun 93 10:13 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: rem-conf at es.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-avt-video-packet-01.txt
Date: Wed, 02 Jun 93 10:13:16 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9306021013.aa04564 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 Audio/Video Transport
Working Group of the IETF.
Title : Packetization of H.261 video streams
Author(s) : T. Turletti, C. Huitema
Filename : draft-ietf-avt-video-packet-01.txt
Pages : 15
This draft describes a packetization scheme of H.261 video stream.
The scheme proposed can be used to transport such a video flow over
the protocols used by RTP.
This specification is a product of the Audio-Video Transport working
group within the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing list
at rem-conf at es.net and/or the authors.
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-avt-video-packet-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-avt-video-packet-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-avt-video-packet-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-avt-video-packet-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 aa05128;
2 Jun 93 10:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12883;
2 Jun 93 10:23 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05060;
2 Jun 93 10:23 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04601;
2 Jun 93 10:13 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ids at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-ids-x500-survey-02.txt
Date: Wed, 02 Jun 93 10:13:37 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9306021013.aa04601 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 Integrated Directory
Services Working Group of the IETF.
Title : A Survey of Advanced Usages of X.500
Author(s) : Chris Weider, Russ Wright
Filename : draft-ietf-ids-x500-survey-02.txt
Pages : 20
This document is the result of a survey asking people to detail their
advanced usages of X.500. It is intended to show how various
organizations are using X.500 in ways which extend the view of X.500
as a 'White Pages' 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-ids-x500-survey-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-ids-x500-survey-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-ids-x500-survey-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ids-x500-survey-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 aa05697;
2 Jun 93 10:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05693;
2 Jun 93 10:45 EDT
Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa14097;
2 Jun 93 10:45 EDT
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id
<01GYW7G7IJ289I43R9 at INNOSOFT.COM>; Wed, 2 Jun 1993 07:13:33 PST
Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by INNOSOFT.COM
(PMDF V4.2-13 #1336) id <01GYW7G29GJK9I43WT at INNOSOFT.COM>; Wed,
2 Jun 1993 07:13:23 PST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04513; 2 Jun 93 10:12
EDT
Date: Wed, 02 Jun 1993 10:12:17 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-madman-networkmib-00.txt
X-Orig-Sender: cclark at CNRI.Reston.VA.US
To: IETF-Announce: ;
Cc: madman at innosoft.com
Errors-to: ned+madman-errors at INNOSOFT.COM
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Resent-message-id: <01GYW7G7L7IQ9I43R9 at INNOSOFT.COM>
Message-id: <9306021012.aa04513 at IETF.CNRI.Reston.VA.US>
X-VMS-Cc: IN%"madman at INNOSOFT.COM"
MIME-version: 1.0
Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID 66pGGW7GUJK5XySjxFFJHA)"
--Boundary (ID 66pGGW7GUJK5XySjxFFJHA)
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
A New 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-00.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-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-madman-networkmib-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.
--Boundary (ID 66pGGW7GUJK5XySjxFFJHA)
Content-type: MULTIPART/ALTERNATIVE;
BOUNDARY="Boundary (ID hitEhciXbgegaOETgJIdwg)"
--Boundary (ID hitEhciXbgegaOETgJIdwg)
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-00.txt
--Boundary (ID hitEhciXbgegaOETgJIdwg)
Content-type: Message/External-body;
name="draft-ietf-madman-networkmib-00.txt"; site="ds.internic.net";
access-type="anon-ftp"; directory="internet-drafts"
Content-Type: text/plain
--Boundary (ID hitEhciXbgegaOETgJIdwg)--
--Boundary (ID 66pGGW7GUJK5XySjxFFJHA)--
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05940;
2 Jun 93 10:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14414;
2 Jun 93 10:52 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05918;
2 Jun 93 10:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05833;
2 Jun 93 10:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14362;
2 Jun 93 10:50 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05827;
2 Jun 93 10:50 EDT
To: IETF-Announce: ;
REPLY-TO: train at rare.nl
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
FROM: Erik Huizer <Erik.Huizer at surfnet.nl>
Subject: July IETF: Amsterdam IETF Social Event
Date: Wed, 02 Jun 93 10:49:59 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9306021050.aa05827 at IETF.CNRI.Reston.VA.US>
This is to announce the the Train through The Netherlands ( The Amsterdam
IETF Social Event) is fully booked. We were swamped with requests, and
managed to get an additional coach. We can therefore accomodate 225 people.
The first 225 people who registered have by now received a confirmation. 17
people were put on a waitinglist, that will hold at most 40 people. This
means that there is still space on the waiting list for 23 people to
register (send mail to : <train at rare.nl>). They will be admitted on the
train if people on the main list have not applied for their tickets before
monday 12 july noon.
Erik Huizer (SURFnet)
Anne Cozanet (RARE)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08092;
2 Jun 93 12:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08081;
2 Jun 93 12:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01319;
2 Jun 93 12:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08036;
2 Jun 93 12:36 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08032;
2 Jun 93 12:36 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ids at merit.edu
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Document Action: A Survey of Advanced Usages of X.500 to
Informational
Date: Wed, 02 Jun 93 12:36:45 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9306021236.aa08032 at IETF.CNRI.Reston.VA.US>
The IESG has reviewed the Internet Draft "A Survey of Advanced
Usages of X.500" <draft-ietf-ids-x500-survey-02.txt> and recommends
that it be published by the RFC Editor as an Informational RFC. This
document is the product of the Integrated Directory Services Working
Group. The IESG contact person is Joyce Reynolds.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09353;
2 Jun 93 13:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09349;
2 Jun 93 13:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02283;
2 Jun 93 13:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09328;
2 Jun 93 13:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09208;
2 Jun 93 12:58 EDT
Received: from osi-west.es.net by CNRI.Reston.VA.US id aa02203;
2 Jun 93 12:58 EDT
Received: from ophelia.nersc.gov by osi-west.es.net with SMTP (PP)
id <00242-0 at osi-west.es.net>; Wed, 2 Jun 1993 09:56:18 +0000
Received: by ophelia.nersc.gov (4.1/SMI-4.2-MHS-7.0) id AA24064;
Wed, 2 Jun 93 09:56:17 PDT
Date: Wed, 2 Jun 93 09:56:17 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Tony Genovese <genovese at ophelia.nersc.gov>
Message-Id: <9306021656.AA24064 at ophelia.nersc.gov>
To: ietf at CNRI.Reston.VA.US
Subject: Clinton is now really on the Internet!!!!!!!!
I think this is funny. I hear our (USA) President and
Vice President are on the network. The funny part
is I heard it from our European colleagues ;-)
Tony...
----- Begin Included Message -----
THE WHITE HOUSE
Office of Presidential Correspondence
______________________________________________________________
For Immediate Release June 1, 1993
LETTER FROM THE PRESIDENT AND VICE PRESIDENT
IN ANNOUNCEMENT OF WHITE HOUSE ELECTRONIC MAIL ACCESS
Dear Friends:
Part of our commitment to change is to keep the White House
in step with today's changing technology. As we move ahead into
the twenty-first century, we must have a government that can show
the way and lead by example. Today, we are pleased to announce
that for the first time in history, the White House will be
connected to you via electronic mail. Electronic mail will bring
the Presidency and this Administration closer and make it more
accessible to the people.
The White House will be connected to the Internet as well as
several on-line commercial vendors, thus making us more
accessible and more in touch with people across this country. We
will not be alone in this venture. Congress is also getting
involved, and an exciting announcement regarding electronic mail
is expected to come from the House of Representatives tomorrow.
Various government agencies also will be taking part in the
near future. Americans Communicating Electronically is a project
developed by several government agencies to coordinate and
improve access to the nation's educational and information assets
and resources. This will be done through interactive
communications such as electronic mail, and brought to people who
do not have ready access to a computer.
However, we must be realistic about the limitations and
expectations of the White House electronic mail system. This
experiment is the first-ever e-mail project done on such a large
scale. As we work to reinvent government and streamline our
processes, the e-mail project can help to put us on the leading
edge of progress.
Initially, your e-mail message will be read and receipt
immediately acknowledged. A careful count will be taken on the
number received as well as the subject of each message. However,
the White House is not yet capable of sending back a tailored
response via electronic mail. We are hoping this will happen by
the end of the year.
A number of response-based programs which allow technology
to help us read your message more effectively, and, eventually
respond to you electronically in a timely fashion will be tried
out as well. These programs will change periodically as we
experiment with the best way to handle electronic mail from the
public. Since this has never been tried before, it is important
to allow for some flexibility in the system in these first
stages. We welcome your suggestions.
This is an historic moment in the White House and we look
forward to your participation and enthusiasm for this milestone
event. We eagerly anticipate the day when electronic mail from
the public is an integral and normal part of the White House
communications system.
President Clinton Vice President Gore
PRESIDENT at WHITEHOUSE.GOV VICE.PRESIDENT at WHITEHOUSE.GOV
###
- ------- End of Forwarded Message
------- End of Forwarded Message
----- End Included Message -----
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11576;
2 Jun 93 14:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11568;
2 Jun 93 14:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05622;
2 Jun 93 14:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11551;
2 Jun 93 14:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11545;
2 Jun 93 14:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05602;
2 Jun 93 14:12 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11539;
2 Jun 93 14:12 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-822 at dimacs.rutgers.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: MIME to Draft Standard
Date: Wed, 02 Jun 93 14:12:51 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9306021412.aa11539 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Internet Message Extensions
Working Group to consider <draft-ietf-822ext-mime2-03.txt, .ps> "MIME
(Multipurpose Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet Message Bodies" and
<draft-ietf-822ext-mime-part2-01.txt> "MIME (Multipurpose Internet Mail
Extensions) Part Two: Message Header Extensions for Non-ASCII Text"
for the status of Draft 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
June 16th.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11751;
2 Jun 93 14:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11747;
2 Jun 93 14:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05797;
2 Jun 93 14:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11736;
2 Jun 93 14:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11730;
2 Jun 93 14:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05782;
2 Jun 93 14:16 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11718;
2 Jun 93 14:16 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: ietf-822 at dimacs.rutgers.edu
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Last Call: The MIME Content-MD5 Header to Proposed Standard
Date: Wed, 02 Jun 93 14:16:08 -0400
X-Orig-Sender: gvaudre at CNRI.Reston.VA.US
Message-ID: <9306021416.aa11718 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Internet Message Extensions
Working Group to consider <draft-ietf-822ext-md5-02.txt> "The
Content-MD5 Header" 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
June 16th.
Greg Vaudreuil
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12295;
2 Jun 93 14:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12291;
2 Jun 93 14:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06909;
2 Jun 93 14:38 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12275;
2 Jun 93 14:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12248;
2 Jun 93 14:37 EDT
Received: from reggae.concert.net by CNRI.Reston.VA.US id aa06896;
2 Jun 93 14:37 EDT
Received: from mento.oit.unc.edu by reggae.concert.net (5.59/tas-reggae/8-15-92)
id AA13410; Wed, 2 Jun 93 14:29:16 -0400
Received: by mento.oit.unc.edu (NeXT-1.0 (From Sendmail 5.52)/TAS/11-16-88)
id AA07533; Wed, 2 Jun 93 14:29:14 EDT
Date: Wed, 2 Jun 1993 14:27:45 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Jones <pjones at mento.oit.unc.edu>
Subject: Re: FYI: White House EMail (fwd)
To: ietf at CNRI.Reston.VA.US
Message-Id: <Pine.3.05.9306021445.P3728-c100000 at mento.oit.unc.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
as seen on info-nets... (the original posting of the White House E-Mail
message was to the Clinton volunteers list and a few other places
yesterday, but the following is in the spirit of the last posting--note
the server used).
==============================================
Paul Jones
Office FOR Information Technology
University of North Carolina
Chapel Hill, NC
Paul_Jones at unc.edu
Visualize Whirled Peas!
---------- Forwarded message ----------
Date: Wed, 02 Jun 1993 17:37:26 +0100
From: Alan Thew <Alan.Thew at liverpool.ac.uk>
To: info-nets at Think.COM
Subject: Re: FYI: White House EMail
On Wed, 2 Jun 93 10:47:42 -0400 Richard Lee Holbert wrote:
>
>
>Jack and others:
>
>*NONE* of those previously posted e-mail address were actually for
>the White House. They were for places that were dissemnating info
>from the White House but had no actual physical link to it. These
>are supposed to be *VALID* addresses but so were the others. So until
>I see proof that these are correct, I will take it like I did the
>others. With several grains of salt.
>
I told myself that I wouldn't do this... :-)
It seems to have some truth...
Default Server: dns0.liv.ac.uk
Address: 138.253.31.2
> set type=ANY
> whitehouse.gov
Server: dns0.liv.ac.uk
Address: 138.253.31.2
Non-authoritative answer:
whitehouse.gov inet address = 198.137.240.100
whitehouse.gov nameserver = WHITEHOUSE.GOV
whitehouse.gov nameserver = NS.UU.NET
Authoritative answers can be found from:
WHITEHOUSE.GOV inet address = 198.137.240.100
NS.UU.NET inet address = 137.39.1.3
whois "net 198.137.240.0"
Executive Office Of The President USA (NET-EOPNET-C1)
Room NEOB 4208
725 17th Street NW
Washington, DC 20503
Netname: EOPNET-C1
Netnumber: 198.137.240.0
Coordinator:
Fox, Jack S. (JSF) fox_j at EOP.GOV
(202) 395-7323
Domain System inverse mapping provided by:
WHITEHOUSE.GOV 198.137.240.100
NS.UU.NET 137.39.1.3
Record last updated on 26-May-93.
The InterNIC Registration Services Host ONLY contains Internet Information
(Networks, ASN's, Domains, and POC's).
Please use the whois server at nic.ddn.mil for MILNET Information.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14256;
2 Jun 93 15:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14252;
2 Jun 93 15:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09478;
2 Jun 93 15:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14238;
2 Jun 93 15:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14201;
2 Jun 93 15:52 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa09455; 2 Jun 93 15:52 EDT
Return-Path: <klatta at merit.edu>
Received: from fox.merit.edu by merit.edu (5.65/1123-1.0)
id AA01364; Wed, 2 Jun 93 15:52:23 -0400
Received: by fox.merit.edu (5.65/client-0.9)
id AA20845; Wed, 2 Jun 93 15:52:23 -0400
Message-Id: <9306021952.AA20845 at fox.merit.edu>
To: Tony Genovese <genovese at ophelia.nersc.gov>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Clinton is now really on the Internet!!!!!!!!
In-Reply-To: Your message of "Wed, 02 Jun 1993 09:56:17 PDT."
<9306021656.AA24064 at ophelia.nersc.gov>
Date: Wed, 02 Jun 1993 15:52:22 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ken Latta <klatta at merit.edu>
I've receive 5 different announcements about this in the last
day....only one of which was from a list centered in Europe. ;-}
The home team is always the last to know....
Ken Latta, Merit Network, Inc.
NSFNET Project, Internet Engineering Group
1071 Beal, Ann Arbor, MI 48109-2103
313.936.2115 voice, 313.747.3745 fax
klatta at merit.edu, USERLFQF at umichum.bitnet
> From: Tony Genovese <genovese at ophelia.nersc.gov>
> To: ietf at CNRI.Reston.VA.US
>
> I think this is funny. I hear our (USA) President and
> Vice President are on the network. The funny part
> is I heard it from our European colleagues ;-)
>
> Tony...
>
> ----- Begin Included Message -----
>
>
> THE WHITE HOUSE
>
> Office of Presidential Correspondence
>
> ______________________________________________________________
> For Immediate Release June 1, 1993
>
>
> LETTER FROM THE PRESIDENT AND VICE PRESIDENT
> IN ANNOUNCEMENT OF WHITE HOUSE ELECTRONIC MAIL ACCESS
>
>
>
>
> Dear Friends:
>
> Part of our commitment to change is to keep the White House
> in step with today's changing technology. As we move ahead into
> the twenty-first century, we must have a government that can show
> the way and lead by example. Today, we are pleased to announce
> that for the first time in history, the White House will be
> connected to you via electronic mail. Electronic mail will bring
> the Presidency and this Administration closer and make it more
> accessible to the people.
>
> The White House will be connected to the Internet as well as
> several on-line commercial vendors, thus making us more
> accessible and more in touch with people across this country. We
> will not be alone in this venture. Congress is also getting
> involved, and an exciting announcement regarding electronic mail
> is expected to come from the House of Representatives tomorrow.
>
> Various government agencies also will be taking part in the
> near future. Americans Communicating Electronically is a project
> developed by several government agencies to coordinate and
> improve access to the nation's educational and information assets
> and resources. This will be done through interactive
> communications such as electronic mail, and brought to people who
> do not have ready access to a computer.
>
> However, we must be realistic about the limitations and
> expectations of the White House electronic mail system. This
> experiment is the first-ever e-mail project done on such a large
> scale. As we work to reinvent government and streamline our
> processes, the e-mail project can help to put us on the leading
> edge of progress.
>
> Initially, your e-mail message will be read and receipt
> immediately acknowledged. A careful count will be taken on the
> number received as well as the subject of each message. However,
> the White House is not yet capable of sending back a tailored
> response via electronic mail. We are hoping this will happen by
> the end of the year.
>
> A number of response-based programs which allow technology
> to help us read your message more effectively, and, eventually
> respond to you electronically in a timely fashion will be tried
> out as well. These programs will change periodically as we
> experiment with the best way to handle electronic mail from the
> public. Since this has never been tried before, it is important
> to allow for some flexibility in the system in these first
> stages. We welcome your suggestions.
>
> This is an historic moment in the White House and we look
> forward to your participation and enthusiasm for this milestone
> event. We eagerly anticipate the day when electronic mail from
> the public is an integral and normal part of the White House
> communications system.
>
>
>
> President Clinton Vice President Gore
>
> PRESIDENT at WHITEHOUSE.GOV VICE.PRESIDENT at WHITEHOUSE.GOV
>
>
> ###
>
>
>
>
> - ------- End of Forwarded Message
>
>
> ------- End of Forwarded Message
>
>
>
> ----- End Included Message -----
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15399;
2 Jun 93 16:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15390;
2 Jun 93 16:50 EDT
Received: from TIS.COM by CNRI.Reston.VA.US id aa12049; 2 Jun 93 16:50 EDT
Received: by TIS.COM (4.1/SUN-5.64)
id AA09074; Wed, 2 Jun 93 16:52:14 EDT
Received: from MAGELLAN.TIS.COM by TIS.COM (4.1/SUN-5.64)
id AA09067; Wed, 2 Jun 93 16:52:12 EDT
Message-Id: <9306022052.AA09067 at TIS.COM>
Reply-To: James M Galvin <galvin at tis.com>
To: TISPEM Announcement: ;, TIS.COM at CNRI.Reston.VA.US,
ietf at CNRI.Reston.VA.US, pem-dev at tis.com, rsaref-users at rsa.com,
saag-interest at tis.com, psrg-interest at isi.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Privacy Enhanced Mail available via anonymous FTP
Date: Wed, 02 Jun 93 16:51:17 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: James M Galvin <galvin at tis.com>
X-Orig-Sender: pem-dev-relay at tis.com
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDE
kMCIGA1UEChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwh
HbGVud29vZA==,02
MIC-Info: RSA-MD5,RSA,ndrjfb54QirydT4/KLgg9HJh+5k0ON+bj9Wil5LeVTE
3E0ST0Bmv12KbChUn5MhxpH556ur0TbWTjl8/csLK52ARxGs0VJlzKfNOWL00SbB
JfuyLIM6RLF9uE2ZBNNjP
Trusted Information Systems, in cooperation with RSADSI, is pleased to
announce the availability of Version 6.0 of TIS/PEM, the Internet
reference implementation of Privacy Enhanced Mail.
This software is available to US and Canadian organizations and citizens
via anonymous ftp. All source code is included, including Version 6.7
of the Rand MH message handling system and Version 1.02 of RSAREF.
To retrieve TIS/PEM please FTP to
host: ftp.tis.com
login: anonymous
and retrieve the files
pub/PEM/README
pub/PEM/LICENSE
The README file contains further instructions. The LICENSE file
contains the restrictions and rules governing use of TIS/PEM.
Please read this file before retrieving the code.
Send questions to tispem-support at tis.com
-----END PRIVACY-ENHANCED MESSAGE-----
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16114;
2 Jun 93 17:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16108;
2 Jun 93 17:25 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa13637; 2 Jun 93 17:25 EDT
Received: by bitsy.MIT.EDU
id AA01611; Wed, 2 Jun 93 17:13:09 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA01605; Wed, 2 Jun 93 17:13:07 EDT
Received: from texas.syl.dl.nec.com by MIT.EDU with SMTP
id AA27000; Wed, 2 Jun 93 17:13:05 EDT
Received: by texas.syl.dl.nec.com (4.1/YDL1.9-920708.13)
id AA01889(texas.syl.dl.nec.com); Wed, 2 Jun 93 16:05:46 CDT
Received: by utah.syl.dl.nec.com (4.1/YDL1.9-920708.13)
id AA15462(utah.syl.dl.nec.com); Wed, 2 Jun 93 16:05:43 CDT
Date: Wed, 2 Jun 93 16:05:43 CDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ruixi Yuan <yuan at syl.dl.nec.com>
Message-Id: <9306022105.AA15462 at utah.syl.dl.nec.com>
To: lunt at ctt.bellcore.com
Subject: Re: Kerberized ftp with encryption option available.
Cc: cat-ietf at mit.edu, kerberos at athena.mit.edu
>Ruixi,
> I have been working on an Internet standard
>which defines extensions to the FTP protocol which
>provide integrity and confidentiality on both the
>control and data channels. I have also implemented
>this using BSD ftp/ftpd and Kerberos Version 4.
>The intent is to introduce Kerberos Version 5 by means
>of the GSSAPI.
>
> See the file draft-ietf-cat-ftpsec-01.txt
>on nnsc.nsf.net in the internet-drafts directory.
>Also, the code and documentation is available via
>anonymous FTP from thumper.bellcore.com in /pub/lunt.
>The working group mailing list is cat-ietf at mit.edu.
>Comments are appreciated.
>
>-- Steve
>
>Steven J. Lunt lunt at bellcore.com
>Information Technology Security RRC 1L-213
>Bellcore 444 Hoes Lane
>(908) 699-4244 Piscataway, NJ 08854
>
Steve:
I have ftped and read your internet draft on the FTP security
extensions. I think the proposed extensions address most of
of the security needs. Two minor comments are:
- Sometimes, there is no clear separation between authentication
and authorization. Thus the commands AUTH, ADAT, USER PASS
maybe organized in a different manner to address it.
- On the encryption of ascii text, is it possible to have some
buffering scheme to avoid encoding each charactor individully?
BTW, how do I subscribe the mailing list cat-ietf at mit.edu?
Regards,
--- Ruixi
==========================================================
Ruixi Yuan yuan at syl.dl.nec.com
NEC Systems Lab. (214)518-3585(voice)
1901 Gateway Drive (214)518-3552(fax)
Irving, TX 75038
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16882;
2 Jun 93 18:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16876;
2 Jun 93 18:23 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa15564; 2 Jun 93 18:23 EDT
Received: by bitsy.MIT.EDU
id AA02293; Wed, 2 Jun 93 18:02:45 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA02287; Wed, 2 Jun 93 18:02:43 EDT
Received: from ctt.ctt.bellcore.com by MIT.EDU with SMTP
id AA28313; Wed, 2 Jun 93 18:02:41 EDT
Received: from shadow.secure.bellcore.com by ctt.ctt.bellcore.com (4.1/1.34)
id AA11275; Wed, 2 Jun 93 18:02:38 EDT
Received: by shadow.secure.bellcore.com (4.1/SMI-4.1)
id AA07930; Wed, 2 Jun 93 17:52:26 EDT
Date: Wed, 2 Jun 93 17:52:26 EDT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Lunt <lunt at ctt.bellcore.com>
Message-Id: <9306022152.AA07930 at shadow.secure.bellcore.com>
To: yuan at syl.dl.nec.com
Subject: Re: Kerberized ftp with encryption option available.
Cc: cat-ietf at mit.edu, kerberos at athena.mit.edu
> Steve:
>
> I have ftped and read your internet draft on the FTP security
> extensions. I think the proposed extensions address most of
> of the security needs. Two minor comments are:
>
> - Sometimes, there is no clear separation between authentication
> and authorization. Thus the commands AUTH, ADAT, USER PASS
> maybe organized in a different manner to address it.
Does the following section clear this up? This appears under
the definition of the ADAT command:
If an authentication exchange succeeds, then the client's identity
has been authenticated but not yet authorized. The client must
next invoke the USER command to identify to the server the account
(file system) for which access is requested. If the USER command
results in a 231 reply, then the client is authorized, and no
password is required. However, the client must then send the PASS
command to actually log the user in (the actual password is
ignored and should be a dummy value). If the USER command results
in a 333 reply, then the user was not authorized without a
password, and a password must be sent with the PASS command. In
this case, it is recommended that the PASS command be ENC
protected. Additional USER or PASS commands may be sent after
success of an ADAT command.
> - On the encryption of ascii text, is it possible to have some
> buffering scheme to avoid encoding each charactor individully?
Whenever encrypted (or integrity checked) data are sent over
the control channel, the bytes are buffered, encrypted
(processed), and sent a buffer at a time, regardless of the
transfer type (ASCII or binary).
> BTW, how do I subscribe the mailing list cat-ietf at mit.edu?
Send email to cat-ietf-request at mit.edu.
> Regards,
>
> --- Ruixi
-- Steve
Steven J. Lunt lunt at bellcore.com
Information Technology Security RRC 1L-213
Bellcore 444 Hoes Lane
(908) 699-4244 Piscataway, NJ 08854
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07246;
3 Jun 93 13:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16198;
3 Jun 93 13:37 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07212;
3 Jun 93 13:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06790;
3 Jun 93 13:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15653;
3 Jun 93 13:22 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06785;
3 Jun 93 13:22 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Chris Adie <cja at castle.edinburgh.ac.uk>
Subject: July IETF: NETWORKING MULTIMEDIA APPLICATIONS BOF (multiapp)
Date: Thu, 03 Jun 93 13:21:53 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9306031322.aa06785 at IETF.CNRI.Reston.VA.US>
IETF Meeting in Amsterdam
BOF Session on
NETWORKING MULTIMEDIA APPLICATIONS
The ready availability of user-friendly multimedia authoring tools such
as Authorware Professional, Asymmetrix Multimedia Toolbook, Macromind
Director and many more, has stimulated much interest in multimedia
within the user community. Sophisticated interactive multimedia
applications are being developed in many disparate subjects and for a
wide range of purposes. Users are now beginning to ask us, as network
technologists, "how can I make my multimedia application available to
others across the network?".
In a parallel development, existing client-server network information
retrieval tools are being enhanced with multimedia handling features.
Gopher+ for instance has been designed with multimedia data firmly in
mind. The World Wide Web project is currently defining a new version of
its hypertext markup language, to be called HMML - HyperMedia Markup
Language - which includes multimedia support.
A third strand of activity is the emergence of network technologies
capable of carrying audio and video data across the network, initially
driven by multimedia conferencing applications. Network technologies
such as ATM and protocols such as RTP are potentially capable of
handling isochronous multimedia data in an effective way.
This BOF session will focus on issues which link these three strands.
Particular questions to be addressed are:
* What are user requirements in terms of responsiveness, and what demands
this places on the network and server system, and how these might
be mitigated.
* The prospects for making existing interactive multimedia applications
available over the network - eg by writing conversion tools from
proprietary formats to a suitable open format.
* To what extent can existing network information retrieval tools such as
Gopher, WWW, WAIS be used for sophisticated multimedia applications?
What about the tools emerging from the research community such as
AthenaMuse 2 (MIT), Microcosm (U of Southampton), HyperG (U of Graz)?
Do we need another tool, or can we build on what we have?
* How can such tools be enhanced to take advantage of isochronous
data streams?
* What relevance do standards such as HyTime and MHEG have?
The BOF is intended to test interest in the subject, to define issues
that need resoving, and to see whether a WG can be formed to work on
those issues.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10132;
3 Jun 93 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10128;
3 Jun 93 16:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21468;
3 Jun 93 16:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10115;
3 Jun 93 16:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10074;
3 Jun 93 16:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21382;
3 Jun 93 16:14 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10068;
3 Jun 93 16:14 EDT
X-Org: Corp. for National Research Initiatives
X-Phone: (703) 620-8990 ; Fax: (703) 620-0913
To: ietf at CNRI.Reston.VA.US
Subject: House of Representatives on-line
Date: Thu, 03 Jun 93 16:14:23 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Greg Vaudreuil <gvaudre at CNRI.Reston.VA.US>
Message-ID: <9306031614.aa10068 at IETF.CNRI.Reston.VA.US>
In the spirit of getting the (US) government on-line....
Greg V.
------- Forwarded Message
Date: 03 Jun 93 15:41:15 -0500
Subject: press release
TEXT OF PRESS RELEASE FROM COMMITTEE ON HOUSE ADMINISTRATION, U.S.
HOUSE OF REPRESENTATIVES, DATED JUNE 3,1993
FOR IMMEDIATE RELEASE
For further information please contact:
Lance Koonce (202) 225-7922
HOUSE ANNOUNCES PUBLIC ELECTRONIC MAIL SERVICE
Chairman Charlie Rose and Ranking Minority Member Bill Thomas
of the Committee on House Administration announced today the pilot
program of the Constituent Electronic Mail System. This
ground-breaking new service will allow citizens to communicate
directly with their Member of Congress by electronic mail. The House
of Representatives has established an electronic gateway to the
Internet, the vast computer network that is used currently by over
twelve million people worldwide. Participating Members of the House
have been assigned public mailboxes which may be accessed by their
constituents from their home computers. In addition, many libraries,
schools and other public institutions now provide, or soon will
provide, public access to the Internet.
The Members of the House of Representatives who have agreed to
participate in this pilot program are: Rep. Jay Dickey (AR-07), Rep.
Sam Gejdenson (CT-02), Rep. Newt Gingrich (GA-06), Rep. George Miller
(CA-07), Rep. Charlie Rose (NC-07), Rep. Fortney (Pete) Stark (CA-l3),
and Rep. Melvin Watt (NC-12). These Members will be making
announcements in their congressional districts within the next few
weeks to make their constituents aware of the new service.
The Constituent Electronic Mail System represents a
significant effort by the House of Representatives to expand
communication with constituents. With the tremendous growth of
electronic mail over the past several years, and the increasingly
inter-connected nature of computer networks, the new service is a
natural addition to the current methods of communication available to
constituents. At the present time, House Members involved in the
pilot program will largely respond to electronic mail messages from
their constituents by postal mail, to ensure confidentiality.
Constituents of House Members participating in the pilot
program who wish to communicate with those Members will be asked to
send a letter or postcard stating their interest to the Member's
office. The request will include the constituent's Internet
"address," as well as that constituent's name and postal address. This
process will allow Members to identify an electronic mail user as his
or her constituent.
The pilot e-mail program will continue until sufficient
feedback from participating offices has been collected to allow
improvements and modifications to the system. When House Information
Systems and the Committee on House Administration are satisfied that
the system is sufficiently error-free, other Members of the House will
be allowed to add this new service as technical, budgetary and
staffing concerns allow.
For more information,Internet users are encouraged to contact
the House of Representative's new on-line information service. Please
send a request for information to CONGRESS at HR.HOUSE.GOV (1)
(1) Please be advised that the commercial "at" symbol is not
recognized by some computer systems when transmitted electronically.
The "at" symbol is an important part of the electronic mail address
for the U.S. House information service, and should be inserted in
place of the question mark in the following example:
"CONGRESS?HR.HOUSE.GOV"
------- End of Forwarded Message
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11235;
3 Jun 93 17:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23195;
3 Jun 93 17:06 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11217;
3 Jun 93 17:06 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11124;
3 Jun 93 17:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: hubmib at synoptics.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-hubmib-mau-02.txt
Date: Thu, 03 Jun 93 17:03:57 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9306031704.aa11124 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 IEEE 802.3 Hub MIB
Working Group of the IETF.
Title : Definitions of Managed Objects for IEEE 802.3
Medium Attachment Units (MAUs)
Author(s) : D. McMaster, K. McCloghrie, S. Roberts
Filename : draft-ietf-hubmib-mau-02.txt
Pages : 32
This document defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it defines objects for
managing IEEE 802.3 Medium Attachment Units (MAUs).
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-hubmib-mau-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-hubmib-mau-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-hubmib-mau-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-hubmib-mau-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 aa11307;
3 Jun 93 17:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11303;
3 Jun 93 17:08 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa23329;
3 Jun 93 17:08 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA24735; Thu, 3 Jun 93 16:08:52 CDT
Received: by hemlock.cray.com
id AA02998; 4.1/CRI-5.6; Thu, 3 Jun 93 16:08:43 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
id AA02993; 4.1/CRI-5.6; Thu, 3 Jun 93 16:08:38 CDT
Received: from laidbak.i88.isc.com by cray.com (4.1/CRI-MX 2.19)
id AA24724; Thu, 3 Jun 93 16:08:22 CDT
Received: from ra.i88.isc.com by laidbak.i88.isc.com with SMTP
(5.65/isc-mail-gw/2/23/93) id AA18565; Thu, 3 Jun 93 16:07:21 -0500
Received: from jupiter.i88.isc.com by ra.i88.isc.com (4.1/SMI-4.1)
id AA11355; Thu, 3 Jun 93 16:07:19 CDT
Message-Id: <9306032107.AA11355 at ra.i88.isc.com>
To: telnet-ietf at cray.com
Subject: Telnet Transfer Control Option
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Date: Thu, 03 Jun 1993 16:06:54 -0500
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Alexander <stevea at lachman.com>
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
While cleaning out some old mail I realized that I never sent this out.
I received this a while back, with the request that the group review it.
Thanks,
-- Steve
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-Description: Transfer Control Draft
Network Working Group S. Denton
Internet-Draft Coal Services Corp.
April 1993
TELNET Transfer Control Option
Status of this Memo
This memo defines an Experimental Protocol for the Internet communi-
ty. 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.
Motivation
There has come into being on the Internet a number of loosely coupled
hypertext multi-user databases (aka MUDs). These may be character-
ized by the existence of a network-unique cursor object (aka player)
which may be passed from host to host when the user is following what
appears to be an otherwise normal database link.
Although the security requirements of these systems are no greater
than those of anonymous FTP, each system keeps track of the user's
location within the database so that each new session starts where
the previous session ended. For this reason, an arbitrary user iden-
tifier is generated the first time a connection is made, and a simple
password protocol is used to avoid accidentally using another user's
cursor. Users normally connect to these databases using a client
program that emulates a simple Network Virtual Terminal.
Currently, the hand-off of a cursor from one host to another is ac-
complished by a procedure the details of which vary from system to
system. For the purposes of this dissusion, the procedure used by
the UnterMUD system will be described. The current host establishes
a connection to the proposed host using a previously agreed upon port
number; the current host transfers the contents of the cursor object
to the proposed host via this connection; when and if the transfer
has been successfully completed, the current host marks the cursor
object as "not-in-use" and sends a message to the user requesting a
transfer to the proposed host. The message has the fixed format
"#### Please reconnect to MyMUD at 123.45.67.89 (MUDHOST.YOYODYNE.COM)
port 12345 ####". The user is then expected to manually break the
Telnet connection and establish a new connection to the specified
port. Many of the more specialized client programs recognize this
S. Denton Expires October 1993 [Page 1]
Internet-Draft TELNET Transfer Control Option April 1993
message and attempt to perform the transfer transparently.
The author conjectures that a formalized version of this protocol
would not only be convenient for the users of these databases, but
could be useful in its own right. Several services utilize the Tel-
net protcol for communications to a client. Using this protcol, a
Telnet connection to a service could be dynamically switched to
another host for purposes of load sharing or to facilitate a simpler
data path for information retrieval. E.g., after connecting to an
FTP server, a client may issue a CWD to a directory that is remotely
mounted via NFS from another host that also provides FTP services.
In this case, the client could be advised that an alternative connec-
tion is preferred. Also, the method currently in use is subject to
"spoof"-ing. A message that resembles the transfer request may ac-
cidentally be placed into a MUD (in help text, for instance) where
the client NVT will mistake the message for a genuine transfer re-
quest. Utilization of a Telnet option subnegotiation would make a
transfer request unambiguous.
1. Command names and codes
XFER_CTRL to be assigned
LOGON 0
MUST_XFER 1
2. Command meanings
IAC WILL XFER_CTRL
The sender of this command REQUESTS permission to, or confirms that
it will, suggest transfer to/from another server.
IAC WONT XFER_CTRL
The sender of this command REFUSES to suggest transfer to/from anoth-
er server.
IAC DO XFER_CTRL
The sender of this command REQUESTS that the receiver, or grants the
receiver permission to, suggest transfers between servers.
IAC DONT XFER_CTRL
The sender of this command DEMANDS that the receiver not suggest
transfers between servers.
IAC SB XFER_CTRL ( WILL/WONT/DO/DONT <command> ) ... IAC SE
S. Denton Expires October 1993 [Page 2]
Internet-Draft TELNET Transfer Control Option April 1993
To allow for future expansion of the protocol, each command must be
separately negotiated using the standard WILL/WONT/DO/DONT technique.
Multiple commands may, but need not, be negotiated within a single
subnegotiation.
IAC SB XFER_CTRL MUST_XFER <alternate port> IAC SE
The sender specifies a remote host to which the connection must be
transferred immediately. The sender has already sent all necessary
state information to the remote host via a private channel. The
sender can break the connection immediately.
The parameter specifies the address of the suggested host. If known,
this should be the Internet address expressed as four decimal numbers
separated by periods; optionally a DNS-style host name should be
specified. Space characters are NOT allowed to appear within the
name. If the TCP port number will be the same at the alternate host,
nothing more needs to be said. Otherwise a space character will be
issued, followed by the port number expressed as a 1-5 digit decimal
number. The information will be encoded using NVT ASCII.
IAC SB XFER_CTRL LOGON <handshake> IAC SE
The sender requests that the host utilize a private logon protocol to
effect a transparent transfer of control. This is sent by the client
to a server at the beginning of a session. The meaning of the
handshake data is arbitrary and is not covered by this standard. One
use would be to exchange normal logon prompts and replies in an unam-
biguous fashion. The handshake is a string of NVT ASCII data.
3. Defaults
WONT XFER_CTRL
DONT XFER_CTRL
i.e., this protocol will not be used.
SB XFER_CTRL WONT/DONT LOGON
Transparent reconnect using this protocol will not be allowed.
SB XFER_CTRL WONT/DONT MUST_XFER
Mandatory session tranfer using this protocol will not be allowed.
4. Description and Implementation Notes
WILL and DO are used only at the beginning of the connection to ob-
tain and grant permission for future negotiations. Either side is
S. Denton Expires October 1993 [Page 3]
Internet-Draft TELNET Transfer Control Option April 1993
free to begin negotiations. Because of the possible effect the se-
mantics of the LOGON subnegotiation can have on subsequent Telnet op-
tion negotiations, XFER_CTRL negotiations should be performed as ear-
ly as possible in the session. The protocol is symmetric: a person
could use this option to move a connection from a workstation to a
personal digital assistant. Only the sender of WILL XFER_CTRL may
send XFER_CTRL WILL MUST_XFER and subsequently only that sender may
sent XFER_CTRL MUST_XFER <alternate port>; if both sides might wish
to do this, they should both send WILL XFER_CTRL.
Note that it is common to use the word "server" to refer to the side
of the connection that did the passive TCP open (TCP LISTEN state),
and the word "client" to refer to the side of the connection that did
the active open. In a hand-off from one client to another, the pro-
posed recipient must have already performed a passive TCP open and be
expecting the connection from the server. At this point the notions
of server and client become confused, especially in the context of
the Telnet Authentication Option. To clear this up, the following
rule is suggested: No more than one side of a connection may be in
the XFER_CTRL DO LOGON state and no more than one side may be in the
XFER_CTRL WILL LOGON state; once confirmed, the side in the XFER_CTRL
DO LOGON state shall henceforth be treated as having performed a pas-
sive TCP open, while the side in the XFER_CTRL WILL LOGON state shall
henceforth be treated as having performed an active TCP open. To en-
force this rule, if a side sees XFER_CTRL WILL LOGON after having
first sent XFER_CTRL WILL LOGON, it must send XFER_CTRL DONT LOGON;
if a side sees XFER_CTRL DO LOGON after having first sent XFER_CTRL
DO LOGON, it must send XFER_CTRL WONT LOGON. (This is not expected
to be a problem in practice; failure of this subnegotiation would be
sufficient cause to terminate a session.) Also, because either side
of the new connection could be the former client, a side is allowed
to send the XFER_CTRL WILL LOGON command when it is in either of the
WILL XFER_CTRL or DO XFER_CTRL states.
The sole reason for the existance of the logon handshake procedure to
establish identity rather than using the Telnet authentication op-
tions is that the existing options are too secure. Even a nominally
anonymous user may still have session state information that should
survive a single connection, and any collection of hosts supporting
transfer of control should utilize some method of confirming that an
incoming connection is synonymous to a previous connection. Some may
argue that only MUDs require this capability, but many services could
benefit from this added feature, and often provide a way to use it.
For example, many, if not most, FTP connections on the Internet are
anonymous. In this case, common usage provides for the use of an In-
ternet mailing address as a password to allow administrators to track
usage. This can provide a way to contact users if, for example,
downloaded files are later discovered to contain a security hazard.
RFC 959 gives a state diagram for automating a logon procedure using
S. Denton Expires October 1993 [Page 4]
Internet-Draft TELNET Transfer Control Option April 1993
the client-issued commands USER, PASS, and ACCT. The second imple-
mentation example in this document uses this same state diagram for
automating reconnection. Note that passwords are passed in clear
text through the network. If the connections go through untrusted
networks, there is the possibility that passwords will be compromised
by someone watching the packets as they go by. RFC 1416, along with
1411 and 1412 detail authentication options that should be used in
preference to this procedure whenever such security is warrented.
The final implementation example uses a non-approved but apparently
legal variation of the Telnet authentication option to accomplish the
same end. Again, passwords are passed in clear text through the net-
work.
Finally, RFC 1408 details a Telnet environment option that could be
used to transmit detailed state information during a transfer of con-
trol.
5. Examples
In the following examples, all quoted strings are NVT ASCII.
1. Server demands transfer to an alternate server.
Client Server
[ The client connects to the service at castor.gemini.org. ]
IAC WILL XFER_CTRL
IAC DO XFER_CTRL
IAC SB XFER_CTRL WILL MUST_XFER
IAC SE
IAC SB XFER_CTRL DO MUST_XFER
IAC SE
[ Time passes. Server decides to require transferring the
connection to an alternate server. ]
IAC SB XFER_CTRL MUST_XFER
"pollux.gemini.org 6565" IAC SE
[ The server is requiring the user to reconnect to an alternate
host. The server will break the connection at this point. The
client should immediately connect to port 6565 at
pollux.gemini.org. ]
2. Client connects to an alternate server supporting dynamic control
transfer and reconnection.
Client Server
[ Client connects to server at pollux.gemini.org. ]
IAC WILL XFER_CTRL
IAC DO XFER_CTRL
IAC SB XFER_CTRL WILL LOGON IAC
SE
IAC SB XFER_CTRL DO LOGON IAC SE
IAC SB XFER_CTRL LOGON "USER
123 at MyMUD" IAC SE
IAC SB XFER_CTRL LOGON "330
S. Denton Expires October 1993 [Page 5]
Internet-Draft TELNET Transfer Control Option April 1993
Enter password as 'PASS
<password>'" IAC SE
IAC SB XFER_CTRL LOGON "PASS
potrzebie" IAC SE
IAC SB XFER_CTRL LOGON "231
Connected." IAC SE
[ Client and server are connected. ]
3. Transfer of server connection from one client to another.
Host 1 Host A
[ Server (Host A) connects to client(Host 1). ]
IAC WILL XFER_CTRL
IAC DO XFER_CTRL
IAC SB XFER_CTRL WILL MUST_XFER
IAC SE
IAC SB XFER_CTRL DO MUST_XFER
IAC SE
[ Time passes. Host 1 decides to transfer the connection to an
alternate host. Host 2 performs a passive TCP open on port
1234. ]
IAC SB XFER_CTRL MUST_XFER
"123.45.67.89 1234" IAC SE
[ Host 1 breaks connection. Host A performs an active TCP open
to the suggested host and port. ]
Host 2 Host A
IAC WILL XFER_CTRL
IAC DO XFER_CTRL
[ Both hosts have now agreed to some form of the XFER_CTRL
protocol. ]
IAC SB XFER_CTRL WILL LOGON IAC
SE
IAC SB XFER_CTRL DO LOGON IAC SE
[ From this point on for the purposes of this or any other Telnet
option, Host A will be treated as though it had originally
performed a passive TCP open (Host A is the Server) and Host 2
will be treated as though it had originally performed an active
TCP open (Host 2 is the Client). ]
IAC WILL AUTHENTICATION IAC SE
IAC DO AUTHENTICATION IAC SE
[ Both hosts agree to use the Telnet authentication option. Even
though RFC 1416 specifies that only the side of the session
that performed an active open may send WILL AUTHENTICATION, the
successful negotiation of XFER_CTRL WILL LOGON has reversed
logical direction of the connection. (Note: AUTH and ACCEPT
are not defined for the NULL authentication type, but for this
example they are assumed to have the same values as defined for
Kerberos and SPX.) ]
IAC SB AUTHENTICATION SEND NULL
CLIENT|ONE_WAY IAC SE
IAC SB AUTHENTICATION NAME
S. Denton Expires October 1993 [Page 6]
Internet-Draft TELNET Transfer Control Option April 1993
"anonymous" IAC SE
IAC SB AUTHENTICATION IS NULL
CLIENT|ONE_WAY AUTH
"john at yoyodyne.com" IAC SE
IAC SB AUTHENTICATION REPLY NULL
CLIENT|ONE_WAY ACCEPT IAC SE
Future directions
The original concept featured a MAY_XFER command to handle non-
mandatory transfers. This idea ran aground during the initial
implementation because of various uncertainties in the semantics of
the command.
It might be useful if the stable end of the connection could be used
as the repository of connection state information during the transfer
from the old host to the new.
Acknowledgements
Thanks to the inventor of Cyberportals, which inspired me to invent a
standardized protocol to accomplish the same result.
References
[1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[2] Borman, D., "Telnet Authentication Option", RFC 1416, Cray
Research, Inc., February 1993.
[4] Alagappan, K., "Telnet Authentication: SPX", RFC 1412, Digital
Equipment Corporation, January 1985.
[3] Borman, D., "Telnet Authentication: Kerberos", RFC 1411, Cray
Research, Inc., January 1993.
[5] Borman, D., "Telnet Environment Option", RFC 1408, Cray Research,
Inc., February 1993.
[6] Reynolds, J., and J. Postel, "File Transfer Protocol", RFC 959,
USC/Information Sciences Institute, October 1985.
Security Considerations
Security issues are discussed in section 4.
Author's Address
Sam Denton
S. Denton Expires October 1993 [Page 7]
Internet-Draft TELNET Transfer Control Option April 1993
Coal Services Corp.
301 North Memorial Drive
St. Louis, MO 63102
Phone: (314) 342-7853
Fax: (314) 342-3424
Email: sunarch.central.sun.com!peabody!sam.denton
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
S. Denton Expires October 1993 [Page 8]
------- =_aaaaaaaaaa0--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11584;
3 Jun 93 17:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11580;
3 Jun 93 17:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24061;
3 Jun 93 17:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11568;
3 Jun 93 17:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11523;
3 Jun 93 17:23 EDT
Received: from reggae.concert.net by CNRI.Reston.VA.US id aa23995;
3 
