Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00454;
1 Mar 95 3:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00450;
1 Mar 95 3:57 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00915;
1 Mar 95 3:57 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00442;
1 Mar 95 3:57 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00438;
1 Mar 95 3:57 EST
Received: from survis.surfnet.nl by CNRI.Reston.VA.US id aa00910;
1 Mar 95 3:57 EST
Received: from survival.surfnet.nl by survis.surfnet.nl with SMTP (PP);
Wed, 1 Mar 1995 09:50:12 +0100
To: IESG
Subject: What about: Formal IAB appeal: IESG paralysis and inactivity
Organisation: SURFnet bv
Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL
Phone: +31 30 310290
Telefax: +31 30 340903
Date: Wed, 01 Mar 1995 09:50:05 +0100
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Erik Huizer (SURFnet BV)"
Message-ID: <9503010357.aa00910@CNRI.Reston.VA.US>
I suggest that the iesg come out with a statement asap, otherwise we prove
Marshall's point by inaction.
As I realise we cannot get unanimity on the subject, I suggest we send out
at least something like Joel's line of reasoning. I know Marshal disagrees
with tyhat, and has good reasons to. It at least shows that it is not just
the iesg to blame.
We have to take part of the blame in this, regardless of the fact that the
same person who is now slinging mud was part of the iesg when the mess was
created.
My position is that we send out a statement shortly saying:
1- We took too long, and have erred (In American: we f..ked up)
2- The process as described in RFC 1602 is to restrictive for this issue
to be resolved formally. This is the IESG's axcuse
3- We cannot wait for the RFC1602 to resolve itself (although this should
happen)
4- We will ask the community what it thinks about the issues:
- not whole RPC
- patent issue
- quality of RPC (do we need it)
during the iesg plenary
5- We will act on a clear concensus of the IETF community, regardless of RFC
1602.
Your comments please.
Erik
(Who couldn't care less about SUNs RPC personally, but as an IESG member
thinks this needs to be resolved quickly).
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01125;
1 Mar 95 6:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01121;
1 Mar 95 6:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02702;
1 Mar 95 6:25 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01114;
1 Mar 95 6:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01110;
1 Mar 95 6:25 EST
Received: from rodan.UU.NET by CNRI.Reston.VA.US id aa02688; 1 Mar 95 6:25 EST
Received: by rodan.UU.NET
id QQyfeb08185; Wed, 1 Mar 1995 06:25:18 -0500
Message-Id:
To: IETF NM-AD
cc: Mike O'Dell , iesg@CNRI.Reston.VA.US
Subject: Re: help me with this.....
In-reply-to: Your message of "Tue, 28 Feb 1995 20:08:52 PST."
<9709.794030932@dbc.mtview.ca.us>
Date: Wed, 01 Mar 1995 06:25:18 -0500
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mike O'Dell
Marshall,
The note I sent was a summary of my thinking on the RPC matter and
I thought rather clear in its conclusions (those are the things
at the ends of the reasoning chains of "given this, you get that").
Either you agree with my analysis of the "givens" and therefore reach
the same conclusions as I do, or you do not for reasons that I assume
you can explain. If you agree with the reasoning, then I don't
understand your current crusade. If you do not agree with the
reasoning, because you think it directly erroneous, or that there is
information not considered which materially effects the resulting
conclusion, then I wish you would explain the where the mistake is or
what the unconsidered "given" might be and how it changes the outcome.
You have made very loud assertions of your conclusions over this
matter without sharing how you reached those conclusions. Either
reason led to those conclusions, or something else did, and it is
certainly fair that the accused gets to know which and take issue with
it.
Or is vigorous but reasoned argument not something the IETF does
anymore? If that is the case, we have a much more serious problem than
transfer of intellectual property.
-Mike O'Dell
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02469;
1 Mar 95 8:59 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02465;
1 Mar 95 8:59 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04742;
1 Mar 95 8:59 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02458;
1 Mar 95 8:59 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02452;
1 Mar 95 8:59 EST
Received: from brownstein-mac.cnri.reston.va.us by CNRI.Reston.VA.US id aa04737;
1 Mar 95 8:59 EST
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Mar 1995 09:03:53 -0500
To: Dan Lynch
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Charles Brownstein
Subject: Re: Newsweek 2/27 - Cliff Stoll - Curmudegeon of Cyberspace
Cc: "Vinton G. Cerf" <0001050002@mcimail.com>, iab ,
iesg ,
isoc-advisory-officers ,
isoc trustees
Dan - it may have been Stoll or the Newsweek editors (who reversed the very
meaning of the words from the CNRI person who was interviewed in that
issue) or both, but I agree with your reading.
At 1:06 AM 3/1/95, Dan Lynch wrote:
>At 12:50 AM 3/1/95 -0500, Vinton G. Cerf wrote:
>>Stoll pans the Internet in the 2/27 issue of Newsweek on p. 41
>>in an article titled "The Internet? Bah!"
>>
>>He has a book coming in April, Doubleday, called Silicon Snake Oil.
>>
>>All in all, a thoroughly curmudgeonly performance - he could be
>>a good substitute for one of MCI's Grammercy Press actors...
>>
>>Vint
>
>
>I could say somethin gnice about Cliff, but it escapes me. I hope his
>experience in chasing bad guys has not colored his view of the rapidly
>evolving universe. Maybe we should look for a job for him back in
>astronomy!
>
>Dan
>
>PS. I read the article and was not impressed by its balance. Or by its
>conciseness or clarity.
Charles N. Brownstein
Executive Director
Cross-Industry Working Team
Corporation for National Research Initiatives
1895 Preston White Drive
Suite 100
Reston, VA 22091
Tel: (703) 620-8990
Fax: (703) 620-0913
Internet: cbrownst@cnri.reston.va.us
On the Web: http://www.cnri.reston.va.us:3000/XIWT/public.html
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03843;
1 Mar 95 10:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03835;
1 Mar 95 10:08 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06441;
1 Mar 95 10:08 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03822;
1 Mar 95 10:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03818;
1 Mar 95 10:08 EST
Received: from ftp.com by CNRI.Reston.VA.US id aa06434; 1 Mar 95 10:08 EST
Received: from ftp.com by ftp.com ; Wed, 1 Mar 1995 10:09:15 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Wed, 1 Mar 1995 10:09:15 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA05697; Wed, 1 Mar 95 10:07:35 EST
Date: Wed, 1 Mar 95 10:07:35 EST
Message-Id: <9503011507.AA05697@mailserv-D.ftp.com>
To: pvm@isi.edu
Subject: Re: A draft RFC relating to the address space
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev@ftp.com
Cc: iesg@CNRI.Reston.VA.US
X-Orig-Sender: stev@mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Wed Mar 1 10:07:25 1995]
Originating-Client: d-cell.ftp.com
Content-Length: 372
The IANA will delegate to regional (and other) registries the task of
making specific address allocations to network service providers and
other subregional registries.
i thought at least one of the current numbering plans allowed for indiviual's
to get addresses (like they do now, with version 4).
is there a reason you dont have this in the text?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03854;
1 Mar 95 10:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03850;
1 Mar 95 10:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06449;
1 Mar 95 10:08 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03834;
1 Mar 95 10:08 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03830;
1 Mar 95 10:08 EST
Received: from ftp.com by CNRI.Reston.VA.US id aa06440; 1 Mar 95 10:08 EST
Received: from ftp.com by ftp.com ; Wed, 1 Mar 1995 10:09:19 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Wed, 1 Mar 1995 10:09:19 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA05702; Wed, 1 Mar 95 10:07:37 EST
Date: Wed, 1 Mar 95 10:07:37 EST
Message-Id: <9503011507.AA05702@mailserv-D.ftp.com>
To: iesg@CNRI.Reston.VA.US
Subject: Re: Formal IAB appeal: IESG paralysis and inactivity
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev@ftp.com
X-Orig-Sender: stev@mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Wed Mar 1 10:07:26 1995]
Originating-Client: d-cell.ftp.com
Content-Length: 325
Motorola sent a letter to the IETF. The IETF Secretariate has refused
to disclose the contents of that letter, despite repeated verbal and
written requests.
i was under the impression that we were sharing all correspondance
with the WG chair, is this true? is there a reason we dont share it
with the WG?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04988;
1 Mar 95 10:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04982;
1 Mar 95 10:56 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07528;
1 Mar 95 10:56 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04950;
1 Mar 95 10:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04889;
1 Mar 95 10:53 EST
Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa07460;
1 Mar 95 10:53 EST
Received: from dbc.mtview.ca.us by dbc.mtview.ca.us (5.65/3.1.090690)
id AA25277; Wed, 1 Mar 95 07:52:45 -0800
X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: IETF NM-AD
To: IETF NM-AD
Subject: NM "State of the Area" Report
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-Id: <25275.794073159.1@dbc.mtview.ca.us>
Content-Description: apologies for the cross-posting
Date: Wed, 01 Mar 1995 07:52:40 -0800
Message-Id: <25276.794073160@dbc.mtview.ca.us>
X-Orig-Sender: mrose@dbc.mtview.ca.us
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25275.794073159.2@dbc.mtview.ca.us>
Content-Description: The NM Area Directorate
The NM Area Directorate
-----------------------
The NM area has a Directorate. The role of the NM-Directorate is three-fold:
- to consider strategic evolution of the SNMP framework;
- to provide architectural and engineering guidance to working groups
which develop MIB modules, at the earliest possible stages; and,
- to help the NM AD in reviewing submitted I-Ds.
The current NM-Directorate membership is:
Fred Baker
Tracy Brown
Ted Brunner
Jeff Case
Deirdre Kostick
Keith McCloghrie
Dave Perkins
Bob Stewart
Kaj Tesink
Steve Waldbusser
The NM-Directorate is an advisory entity and has no standards-setting
powers. The meetings of the NM-Directorate are closed. The members of the
NM-Directorate are appointed by the NM AD.
For the first role, strategic evolution, the NM-Directorate considers "what
needs to be done next". Of course, strategic issues may also be pursued in
BOF's at IETF meetings, independently of the NM-Directorate. Alternately,
you can send a message to me and I will forward it to the NM-Directorate.
For the second role, whenever a WG will be developing a MIB module as a part
of their chartered activities, a member of the NM-Directorate will be asked
to participate in that WG, to provide expert consultation with respect to
SNMP, MIB module design, and standards development. This assignment will be
a matter of record in the charter.
Finally, for the third role, once a MIB module is completed by a WG, the IESG
asks the NM-Directorate to review the document. My hope is that this will be
a pro-forma review--after all, a member of the NM-Directorate should have
been assigned to help the WG during their development effort.
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25275.794073159.3@dbc.mtview.ca.us>
Content-Description: Policy on SNMPv2 and MIB modules
Policy on SNMPv2 and MIB modules
--------------------------------
There are two network management frameworks for the Internet community.
The Internet-standard Network Management Framework is based on SNMPv1:
1155 Structure of Management Information
1212 Concise MIB Definitions
1157 Simple Network Management Protocol
1215 A Convention for Defining Traps
All of these documents are full Internet standards, with the exception
of 1215 which is an informational document.
SNMPv2 provides the basis for the successor framework:
1441 Introduction to SNMPv2
1442 SMI for SNMPv2
1443 Textual Conventions for SNMPv2
1444 Conformance Statements for SNMPv2
1445 Administrative Model for SNMPv2
1446 Security Protocols for SNMPv2
1447 Party MIB for SNMPv2
1448 Protocol Operations for SNMPv2
1449 Transport Mappings for SNMPv2
1450 MIB for SNMPv2
1451 Manager-to-Manager MIB
1452 Coexistence between SNMPv1 and SNMPv2
All of these documents are proposed Internet standards.
Prior to the entry of SNMPv2 onto the standards-track, MIB modules were
written using the SNMPv1 SMI. There is a transition policy for writing MIB
modules.
Until the SNMPv2 SMI is a draft Internet-standard:
All MIB modules submitted by a WG for standardization must use the
SNMPv2 SMI. However, the following SNMPv2 syntaxes may not be
used: BIT STRING, NsapAddress, Counter64, or UInteger32 (either directly
or through a textual convention). Further, any existing MIB modules
updated by a WG must be evaluated and possibly changed to minimize
the transformation necessary to use the SNMPv2 SMI. Finally, this
policy does not apply if the MIB module is being submitted for
consideration as a full standard.
Once the SNMPv2 SMI is a draft Internet-standard:
All MIB modules submitted by a WG for standardization must use the
SNMPv2 SMI, and are allowed to use any SNMPv2 syntax. Further, any
MIB existing modules on the standards-track which use the SNMPv1
SMI will be modified to use the SNMPv2 SMI, making the smallest
possible set of changes. In most cases, this means that only the
IMPORTS statement of the MIB module will change.
Note well:
Whenever a WG works on a MIB module (either developing it or
advancing it along the standards-track), that WG will be
responsible for producing a conformance statement for that MIB.
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25275.794073159.4@dbc.mtview.ca.us>
Content-Description: Automated checking of MIB modules
Automated Checking of MIB modules
---------------------------------
A MIB module syntax checking facility is available. Send the MIB
module in the body of a mail message to:
mib-checker@epilogue.com
or
mosy@dbc.mtview.ca.us
An automated reply will be returned. Be sure to IMPORT the OBJECT-TYPE
macro from SNMPv2-SMI, e.g.,
IMPORTS
...
OBJECT-TYPE ...
FROM SNMPv2-SMI;
Once a MIB module compiles successfully, a check can be made to see if
it can be converted to V1-format. Send the MIB module in the body
of a mail message to:
mib-v2tov1@dbc.mtview.ca.us
An automated reply will be returned containing a V1-format of the MIB
module.
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25275.794073159.5@dbc.mtview.ca.us>
Content-Description: Policy on Standards for SNMP Agent Extensibility
Policy on Standards for SNMP Agent Extensibility
------------------------------------------------
Although there is considerable interest in IETF standardization of
either an agent extensibility protocol or API or both, this is outside
the scope of IETF standardization.
There are two reasons for this:
1. A key motivation for developing a standard in this area is the
perception that a standard will allow sub-agent implementors to develop
according to a single sub-agent API. In the best case, such an API
would be highly inefficient on many platforms as it must work with a
reasonably chosen lowest common denominator technology. In the worst
case, such an API would be impossible to standardize because of the wide
differences in platform capabilities for interprocess communications.
2. An SNMP MIB view is an self-consistent data set, in which only the
external aspects are standardized (i.e., the behavior of operations upon
the variables within a MIB view). A standard for extensible SNMP agents
must, by definition, specify internal aspects of a MIB view. This is
known to have serious architectural impacts as manifested, e.g., by the
"sysUpTime problem". It is unclear as to what other problems are
introduced when the internal properties of MIB views are specified.
It is unrealistic to expect that these architectural impacts are
solvable using a platform-independent standard.
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25275.794073159.6@dbc.mtview.ca.us>
Content-Description: Status of Working Groups
Status of Working Groups
------------------------
A working group is either active or inactive. Active working groups have
charters to develop documents. Inactive working groups have no charter --
typically because they have completed their previous charter. These inactive
working groups (and their mailing lists) serve as a forum for implementors.
When a standards-track document produced by a working group is ready for
further evaluation or new documents are appropriate, the working group is
re-chartered accordingly.
AToM MIB (atommib)
Chair: Kaj Tesink
Consultant: Keith McCloghrie
WG mail: atommib@thumper.bellcore.com
To join: atommib-request@thumper.bellcore.com
Inactive: awaiting the next stage for RFC 1695 (proposed standard)
The WG is eligible to re-activate in February, 1995.
Bridge MIB (bridge)
Chair: Fred Baker
WG mail: bridge-mib@decwrl.dec.com
To join: bridge-mib-request@decwrl.dec.com
Inactive: awaiting the next stage for RFC 1493 (draft standard)
and RFC 1525 (proposed standard)
The WG is eligible to re-activate now.
Character MIB (charmib)
Chair: Bob Stewart
WG mail: char-mib@decwrl.dec.com
To join: char-mib-request@decwrl.dec.com
Inactive: waiting for the next state for RFC 1658 (draft standard)
RFC 1659 (draft standard)
RFC 1660 (draft standard)
The WG is eligible to re-activate now.
Data Link Switching MIB (dlswmib)
Chair: Shannon Nix
Consultant: Deirde Kostick
WG mail: aiw-dlsw-mib@networking.raleigh.ibm.com
To join: aiw-dlsw-mib-request@networking.raleigh.ibm.com
Active: in progress
The WG has just started.
DECnet Phase IV MIB (decnetiv)
Chair: Jon Saperia
WG mail: phiv-mib@jove.pa.dec.com
To join: phiv-mib-request@jove.pa.dec.com
Inactive: waiting for the next stage for RFC 1559 (draft standard)
The WG is eligible to re-activate now.
FDDI MIB (fddimib)
Chair: Jeffrey Case
WG mail: fddi-mib@cs.utk.edu
To join: fddi-mib-request@cs.utk.edu
Inactive: awaiting the next stage for RFC 1285 (proposed standard)
and RFC 1512 (proposed standard)
The WG is eligible to re-activate now.
Frame Relay Service MIB (frnetmib)
Chair: James Watt
Consultant: Fred Baker
WG mail: frftc@nsco.network.com
To join: frftc-request@nsco.network.com
Inactive: awaiting the next stage for RFC 1604 (proposed standard)
The WG is eligible to re-activate now.
Host Resources MIB (hostmib)
Chair: Steven Waldbusser
WG mail: hostmib@andrew.cmu.edu
To join: hostmib-request@andrew.cmu.edu
Inactive: awaiting the next state for RFC 1514 (proposed standard)
The WG is eligible to re-activate now.
IEEE 802.3 Hub MIB (hubmib)
Chair: Keith McCloghrie
Donna McMaster
WG mail: hubmib@synoptics.com
To join: hubmib-request@synoptics.com
Inactive: awaiting the next stage for RFC 1515 (proposed standard)
and RFC 1516 (draft standard)
The WG is eligible to re-activate now.
Interfaces MIB (ifmib)
Chair: Ted Brunner
WG mail: if-mib@thumper.bellcore.com
To join: if-mib-request@thumper.bellcore.com
Inactive: awaiting the next stage for RFC 1573 (proposed standard)
and RFCs 1748-9 (proposed standard)
The WG is eligible to re-activate now to consider RFC 1573.
Mail and Directory Management (madman)
Chair: Steve Kille
Consultant: Marshall Rose
WG mail: ietf-madman@innosoft.com
To join: mailserv@innosoft.com (body: "subscribe ietf-madman")
Inactive: awaiting the ntext stage for RFCs 1565-1567 (proposed standard)
The WG is eligible to re-activate now.
Modem Management (modemmgt)
Chair: Mark S. Lewis
Consultant: Steven Waldbusser
WG mail: modemmgt@Telebit.com
To join: majordomo@Telebit.com
Inactive: awaiting the next stage for RFC 1696 (proposed standard)
The WG is eligible to re-activate in February, 1995.
Printer MIB (printmib)
Chair: Joel Gyllenskog
Consultant: Steven Waldbusser
WG mail: pmi@hpbs907.boi.hp.com
To join: pmi-request@hpbs907.boi.hp.com
Active: awaiting RFC publication of draft-ietf-printmib-printer-mib-03.txt
The chair is working on harmonizing the MIB's character sets with the
IANA registry.
RDBMS MIB (rdbmsmib)
Chair: Robert Purvy
Consultant: Marshall Rose
WG mail: rdbmsmib@us.oracle.com
To join: rdbmsmib-request@us.oracle.com
Inactive: awaiting the next state for RFC 1697 (proposed standard)
The WG is eligible to re-activate in February, 1995.
Remote Monitoring (rmonmib)
Chair: Andy Bierman
WG mail: rmonmib@jarthur.claremont.edu
To join: rmonmib-request@jarthur.claremont.edu
Active: in progress
The WG is working on RMONv2. The WG is eligible to evaluate RFC 1513
(proposed standard) with respect to the standards track now (although
such an evaluation requires an update to the charter). The WG is
eligible to evaluate RFC 1757 (draft standard) with respect to the
standards track in July, 1995.
SNA DLC Services MIB (snadlc)
Chair: Shannon Nix
Consultant: Deirde Kostick
WG mail: snadlcmib@cisco.com
To join: snadlcmib-request@cisco.com
Active: editing draft-ietf-snadlc-llc-mib-01.txt
The WG is completing an LLC-2 MIB.
SNA NAU Services MIB (snanau)
Chair: Zbigniew Kielczewski
Deirde Kostick
Consultant: David Perkins
WG mail: snanaumib@thumper.bellcore.com
To join: snanaumib-request@thumper.bellcore.com
Active: editing draft-ietf-snanau-appcmib-00.txt
The WG is completing an APPC MIB.
SNMP version 2 (snmpv2)
Chair: Bob Stewart
WG mail: snmp2@tis.com
To join: snmp2-request@tis.com
Active: the games have begun
The WG is evaluating the SNMPv2 documents with respect to the standards track.
Trunk MIB (trunkmib)
Chair: Fred Baker
Tracy Brown
WG mail: trunk-mib@saffron.acc.com
To join: trunk-mib-request@saffron.acc.com
Inactive: awaiting the next stage for RFCs 1406, 1407 (proposed standard)
The WG is eligible to re-activate now.
Uninterruptible Power Supply (upsmib)
Chair: Jeffrey Case
WG mail: ups-mib@cs.utk.edu
To join: ups-mib-request@cs.utk.edu
Inactive: Awaiting the next stage for RFC 1628 (Proposed standard)
The WG is eligible to reactiviate now.
X.25 Management Information Base (x25mib)
Chair: Dean Throop
WG mail: x25mib@dg-rtp.dg.com
To join: x25mib-request@dg-rtp.dg.com
Inactive: awaiting the next stage for RFCs 1381-1382 (proposed standard)
The WG is eligible to re-activate now.
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25275.794073159.7@dbc.mtview.ca.us>
Content-Description: Policy on Formation of Working Groups
Policy on Formation of Working Groups
-------------------------------------
It is the goal of the IETF to produce standards which:
- have high technical quality;
- solve real and immediate problems in the Internet using modest
community and computing resources;
- are accessible to a broad community;
- are developed in an open and fair manner; and,
- are developed in a timely manner.
To assist in achieving this goal, each standardization activity
(WG) must have the participation of one or more senior technical
resources within an area. Without this senior guidance, WGs tend
to produce documents which are inconsistent with one or more of the
characteristics above. (Of course, the presence of senior guidance
does not guarantee success--senior guidance is a necessary, but not
sufficient ingredient.)
A senior technical resource has substantial content-relevant
experience and extensive experience with the IETF process of
developing and adopting Internet standards. As examples, technical
simplicity and operational scaling are two characteristics of
Internet architecture with which senior contributors will have had
considerable experience.
As membership in the IETF grows, the percentage of senior
technical resources has been decreasing. There are two reasons
for this: first, many new members, while skilled, do not have
senior levels of expertise with respect to Internet architecture
and specifications. Second, appreciation of the IETF philosophy
takes time. Thus, by definition, any new IETF member, regardless
of their background, initially lacks the shared philosophy necessary
to be considered a senior technical resource. Of course, it is
hoped that, over time, new IETF members will become steeped in the
culture.
As the success of the Internet standards process has become more
visible, the IETF is being asked to consider standardization of an
increasingly broad range of technologies. Unfortunately, there
are insufficient senior technical resources to meet this demand.
This means that each request for a standardization activity must
be carefully scrutinized, both to see if it is likely to be
successful, and for its impact on other standardization
activities.
As such, the policy for the formation of new WGs in the Network
Management area of the IETF is:
1. Parties interested in starting a new standardization activity
must first check whether an existing WG is working with that
technology. If one is not, the AD will provide the party with a
list of area consultants. This list is created, approved, and
maintained by the AD.
In the NM area of the IETF, the list of area consultants for *new*
working groups consists precisely of the membership of the NM area
Directorate.
2. The party must then find an area consultant who expresses an
interest in guiding the activity. At this stage however, the area
consultant is not expressing a commitment, merely an interest. If
the party is unable to find an interested area consultant, then no
new WG is formed.
3. The area consultant will discuss the matter with the AD to
determine the parameters for a mailing list, a BOF and a charter.
If after this discussion, the area consultant decides that a
commitment would be inappropriate, the party is informed, and the
process goes back to step 2.
4. The party, under the guidance of the area consultant, determines
the level of community interest in producing and using the
technology. This is first accomplished via e-mail, either through
an existing list or by creating a new list. The purpose of this
activity is to establish an initial vocabulary and set of views,
and to draft a preliminary, non-binding charter.
5. The party, under the guidance of the area consultant, requests a
BOF to be held at the next meeting of the IETF. The purpose of
this BOF is to gauge two criteria:
- community interest in producing the resulting technology
(multiple organizations are interested in participating in the
WG and in implementing the resulting technology); and,
- community interest in using the resulting technology (the
technology is of broad interest to the Internet community as a
whole).
and also to refine the preliminary, non-binding charter.
Further, if the technology to be developed is a MIB module, then
the the purpose of the BOF is to gauge a third criterion:
- existing vendor-specific MIB modules and user experience with
those modules.
If the AD, who will attend the BOF, isn't satisfied as to the
demonstration of any of these criteria, the party is informed and
the process goes back to step 2.
6. The party, under the guidance of the area consultant, prepares a
draft charter and begins the charter negotiation process with the
AD. When the party, the area consultant, and the AD agree on a
draft charter, the AD begins the charter negotiation process with
the IESG.
Note that this policy does not apply to WGs which are currently inactive,
i.e., those which are awaiting re-activation due to standards-track
activity.
------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25275.794073159.8@dbc.mtview.ca.us>
Content-Description: NM Area Director's Statement of Disclosure
NM Area Director's Statement of Disclosure
------------------------------------------
This information is disclosed so that any party may evaluate the
performance of the NM AD, without having to speculate as to any
possible conflicts of interest. As always, questions about
specific actions by IETF members, WG chairs, or ADs should be
communicated to that person and/or whoever oversees their work.
You are encouraged to bring your concerns directly to the AD or to
the IESG, should any actions cause you any question.
I am Principal of a consultancy corporation: 50% of my time is devoted to
clients, 50% to community service. The clients neither fund nor direct any
community service. The corporation supports my participation on the IESG
solely as a matter of community service. Here is my current client list:
Client Market Area
------------------------------ ---------------------------
Interop Company US Program Committee
First Virtual Holdings Internet Commerce products and services
(equity participant)
In each market area, I am "exclusive" to that client. In addition, with the
exception of a small number of shares in PSI, I have no financial interest in
any computer-communications company. I am the author of several books on
internetworking technologies published by Prentice Hall, for which I receive
royalties.
Finally, I am a member of the board for the Internet Multicasting Service, a
non-profit organization, for which I receive no compensation.
Dr. Marshall T. Rose
Principal
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US
Tel: +1 415 968 1052
Fax: +1 415 968 2510
Email: mrose.iesg@dbc.mtview.ca.us (official IESG business)
mrose@dbc.mtview.ca.us (otherwise)
------- =_aaaaaaaaaa0--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05153;
1 Mar 95 11:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05147;
1 Mar 95 11:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07785;
1 Mar 95 11:10 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05140;
1 Mar 95 11:10 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05135;
1 Mar 95 11:10 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07780;
1 Mar 95 11:10 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05128;
1 Mar 95 11:10 EST
To: stev@ftp.com
cc: iesg@CNRI.Reston.VA.US
Subject: Re: Formal IAB appeal: IESG paralysis and inactivity
In-reply-to: Your message of "Wed, 01 Mar 95 10:07:37 EST."
<9503011507.AA05702@mailserv-D.ftp.com>
Date: Wed, 01 Mar 95 11:10:32 -0500
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Coya
Message-ID: <9503011110.aa05128@IETF.CNRI.Reston.VA.US>
>> Motorola sent a letter to the IETF. The IETF Secretariate has
>> refused to disclose the contents of that letter, despite repeated
>> verbal and written requests.
>> i was under the impression that we were sharing all correspondance
>> with the WG chair, is this true? is there a reason we dont share it
>> with the WG?
Some time last year, Fred and I agreed to limit the participation to
the WG Chair, the I-D author, and the ADs. I'd have to go digging for
the actual message, but I believe you and Claudio were copied).
BTW, Bill's claim is inaccurate and disingenuous. He IS aware of the
contents of the letter; I personally read it to him over the phone and
gave him the patent numbers. What I did NOT do was send him a copy of
the letter, nor did I provide him with the name and address of
Motorola's IPR counsel.
What's irritating is that the IESG is not involved with the Motorola
patent issue (though I do provide status updates when they occur). The
Secretariat is (why is another story altogether), the Internet ADs are,
but this is not on the IESG plate. If Bill wants to complain about the
Secretariat, that's fine; but there's no reason to expand his net to
include the IESG.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05270;
1 Mar 95 11:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05266;
1 Mar 95 11:14 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07838;
1 Mar 95 11:14 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05257;
1 Mar 95 11:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05247;
1 Mar 95 11:14 EST
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa07833;
1 Mar 95 11:14 EST
Received: from [198.120.32.47] (arc-tac2-slip3.nsi.nasa.gov [198.120.32.47]) by Mordor.Stanford.EDU (8.6.10/8.6.6) with SMTP id IAA05116; Wed, 1 Mar 1995 08:14:14 -0800
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Mar 1995 08:14:19 -0800
To: "Vinton G. Cerf" <0001050002@mcimail.com>
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dave Crocker
Subject: Re: SUN/ISOC
Cc: Andrea Ireland <0006773625@mcimail.com>, tony rutkowski ,
iesg
At 9:53 PM 2/28/95, Vinton G. Cerf wrote:
>We seem to be very close to an agreement; Steve Nahm at SUN is
Wonderful news, Vint. Many thanks for the efforts and the update.
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 dcrocker@mordor.stanford.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07806;
1 Mar 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07802;
1 Mar 95 13:40 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10804;
1 Mar 95 13:40 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07781;
1 Mar 95 13:40 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa07777;
1 Mar 95 13:40 EST
Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa10793;
1 Mar 95 13:40 EST
Received: from dbc.mtview.ca.us by dbc.mtview.ca.us (5.65/3.1.090690)
id AA29450; Wed, 1 Mar 95 10:39:56 -0800
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: IETF NM-AD
To: Mike O'Dell
Cc: iesg@CNRI.Reston.VA.US
Subject: Re: RPC working group
In-Reply-To: Your message of "Tue, 28 Feb 1995 18:33:30 EST."
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Id: <29389.794083093.1@dbc.mtview.ca.us>
Date: Wed, 01 Mar 1995 10:38:15 -0800
Message-Id: <29404.794083095@dbc.mtview.ca.us>
X-Orig-Sender: mrose@dbc.mtview.ca.us
> I've been ruminating on your call to arms and am stuck on a point, so
> maybe you can help me out here.
here we go...
> I claim the only way the working group could have been validly
> chartered is that it's work output must be subject to the RFC1602
> process definition, which was in place at the time. That is, RFC 1602
> contains the terms and conditions of the contract and the RPC working
> group was no different in this respect. Therefore, any work output
> progressing was *known* to be contingent upon successful satisfaction
> of the requirements in RFC1602 when the WG was chartered.
i think that you are putting procedures before process. 1602 is a set
of rules that was supposed to reflect the IETF's goals of progress,
openness, fairness, concensus. 1602 is now proven to be a poor
reflection of that.
when confronted with such a dilemna, the IESG can either blindly follow
broken rules, or it can get work done.
thus, the correct path for the IESG is to proceed in a fashion which
fosters progress and honors openness, fairness, and concensus.
> Given this, I have a little trouble with the claim that because the
> requirements were not met there is a violation of "honor" with respect
> to letting the WG proceed in spite of failing to meet RFC1602.
not really honor, but rather competence (that's why the word was in
quotation marks).
> It was known by all concerned going into it that this WG was the first
> time the 1602 transfer process was going to be executed, and for
> experienced protocol designers to express surprise and aggrevation
> when a bug was found in the first execution of a complex protocol
> is just a tad curious.
the rule *follows* procedure, it does not dictate it. that is the key
issue the majority of the IESG is unable to grasp.
> I do understand the feelings about this having taken a long time. I had
> initially agreed to chair the ONC WG, so I think it's clear that I'm not
> exactly disinterested in the outcome.
>
> However, unless someone wishes to claim *directly* that some party was
> acting in bad faith, and wishes to back up that statement, the only
> conclusion I can reach is that
with respect to bad faith, the smoking gun is quite clear: the IESG
allowed this to drag on, and on, and on. the community doesn't care
about excuses, it cares about results. the IESG isn't doing its job.
its job is to get results, not to make like the energizer bunny.
> (1) people worked hard, in good faith, trying to reach
> a satisfactory conclusion, but....
>
> (2) the 1602 process is hoplessly screwed and will not ever
> produce the desired result, so it must be changed.
>
> If someone wishes to argue
>
> "You shoulda given up sooner"
>
> then I claim that's an easy thing to say in hindsight, albeit
> possibly true in retrospect.
fix the problem, not the blame. it's the IESG's job to make things
work. cowering behind the skirts of 1602, or the legendary incompetence
of the ISOc, isn't exactly what i would view as a good defense.
>
> But the culture is one where people continue to work on hard
> problems attempting to resolve them, and they don't give up easily.
with the exception, of course, of the IESG.
> I think that this time the culture worked against us.
> But that's no reason to jettison the culture.
the thrashing that the IESG is taking is entirely consistent with the
way things are done in the community...
/mtr
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08340;
1 Mar 95 14:13 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08336;
1 Mar 95 14:13 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11456;
1 Mar 95 14:13 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08329;
1 Mar 95 14:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08323;
1 Mar 95 14:12 EST
Received: from ftp.com by CNRI.Reston.VA.US id aa11446; 1 Mar 95 14:12 EST
Received: from ftp.com by ftp.com ; Wed, 1 Mar 1995 14:13:21 -0500
Received: from mailserv-D.ftp.com by ftp.com ; Wed, 1 Mar 1995 14:13:21 -0500
Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA09973; Wed, 1 Mar 95 14:11:41 EST
Date: Wed, 1 Mar 95 14:11:41 EST
Message-Id: <9503011911.AA09973@mailserv-D.ftp.com>
To: scoya@CNRI.Reston.VA.US
Subject: Re: Formal IAB appeal: IESG paralysis and inactivity
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: stev@ftp.com
Cc: iesg@CNRI.Reston.VA.US
X-Orig-Sender: stev@mailserv-d.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Wed Mar 1 14:11:38 1995]
Originating-Client: d-cell.ftp.com
Content-Length: 192
the note from fred limiting the group would be useful.
at this point, i woudl prefer to embarass bill with the
accuracy of his note at the IAB meeting, rather than
doing it over EMAIL.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08397;
1 Mar 95 14:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08390;
1 Mar 95 14:14 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11499;
1 Mar 95 14:14 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08383;
1 Mar 95 14:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08379;
1 Mar 95 14:14 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11494;
1 Mar 95 14:14 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08371;
1 Mar 95 14:14 EST
To: stev@ftp.com
cc: iesg@CNRI.Reston.VA.US
Subject: Re: Formal IAB appeal: IESG paralysis and inactivity
In-reply-to: Your message of "Wed, 01 Mar 95 14:11:41 EST."
<9503011911.AA09973@mailserv-D.ftp.com>
Date: Wed, 01 Mar 95 14:14:28 -0500
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Coya
Message-ID: <9503011414.aa08371@IETF.CNRI.Reston.VA.US>
>> the note from fred limiting the group would be useful.
I'll go looking for it, but it will be a (short) while.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09789;
1 Mar 95 15:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09785;
1 Mar 95 15:33 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13039;
1 Mar 95 15:33 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09774;
1 Mar 95 15:33 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09768;
1 Mar 95 15:33 EST
Received: from BIG-SCREW.MIT.EDU by CNRI.Reston.VA.US id aa13032;
1 Mar 95 15:33 EST
Received: by big-screw
id AA21908; Wed, 1 Mar 95 15:33:41 -0500
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Mar 1995 15:31:55 -0500
To: Megan Davies Walnut
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Jeffrey I. Schiller"
Subject: Re: Danvers (Sunday dinner after Registration)
Cc: iesg@CNRI.Reston.VA.US, mwalnut@CNRI.Reston.VA.US
At 6:19 PM 2/28/95, Megan Davies Walnut wrote:
>One and all,
>
>Any thoughts as to whether you'll continue the tradition of dinner
>on Sunday evening immediately following the IETF Registration/Reception?
>If so, there may be a bit more work involved (whether or not you do
>this on your own or I help). The Sheraton is fairly isolated and
>folks will have to have transportation to get to any off-site
>restaurant.
I can carry 7 people (including myself) in my Caravan. I also know of a
very good Indian restaurant in the neighborhood of the hotel.
-Jeff
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11976;
1 Mar 95 17:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11972;
1 Mar 95 17:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15917;
1 Mar 95 17:48 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11965;
1 Mar 95 17:48 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11959;
1 Mar 95 17:48 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15912;
1 Mar 95 17:48 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11954;
1 Mar 95 17:48 EST
To: "Jeffrey I. Schiller"
cc: Megan Davies Walnut , iesg@CNRI.Reston.VA.US
Subject: Re: Danvers (Sunday dinner after Registration)
In-reply-to: Your message of "Wed, 01 Mar 95 15:31:55 EST."
Date: Wed, 01 Mar 95 17:48:09 -0500
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut
Message-ID: <9503011748.aa11954@IETF.CNRI.Reston.VA.US>
If I'm still considered an honorary IESG member for this event :*)
I can make my rental car available.
Megan
>> >One and all,
>> >
>> >Any thoughts as to whether you'll continue the tradition of dinner
>> >on Sunday evening immediately following the IETF Registration/Reception?
>> >If so, there may be a bit more work involved (whether or not you do
>> >this on your own or I help). The Sheraton is fairly isolated and
>> >folks will have to have transportation to get to any off-site
>> >restaurant.
>>
>> I can carry 7 people (including myself) in my Caravan. I also know of a
>> very good Indian restaurant in the neighborhood of the hotel.
>>
>> -Jeff
>>
>>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12744;
1 Mar 95 18:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12740;
1 Mar 95 18:28 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16645;
1 Mar 95 18:28 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12724;
1 Mar 95 18:28 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12718;
1 Mar 95 18:28 EST
Received: from nic.cerf.net by CNRI.Reston.VA.US id aa16635; 1 Mar 95 18:28 EST
Received: from aldea.com ([192.215.50.20]) by nic.cerf.net (8.6.10/8.6.9) with SMTP id PAA03341; Wed, 1 Mar 1995 15:28:55 -0800
Received: from [192.215.50.22] by aldea.com (4.1/SMI-4.1)
id AA01155; Wed, 1 Mar 95 15:23:47 PST
X-Sender: sestrada@192.215.50.20
Message-Id:
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 1 Mar 1995 15:33:29 -0800
To: "Vinton G. Cerf" <0001050002@mcimail.com>, iab ,
iesg ,
isoc-advisory-officers ,
isoc trustees
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Susan Estrada
Subject: Re: Newsweek 2/27 - Cliff Stoll - Curmudegeon of Cyberspace
From Publishers Weekly, January 16
Collision on the Superhighway
Astronomer Cliff Stoll takes more than a skeptical look at the information
superhighway in "Silicon Snake Oil" (Doubleday, Apr.). Striking out
against the Internet, which he calls an alluring "distraction from reality"
that works against literacy, isolates people from one another and cheapens
the meaning of actual experience, he tells us that, though "the Internet
beckons brightly, seductively flashing an icon of knowledge-as-power, this
nonplace lures us to surrender our time on earth" -- strong words from the
man who wrote "The Cuckoo's Egg", about the awesome power of computer
networking. Hoping to keep the lid on the book until the April pub date,
Doubleday has dispensed with advanced galleys and is launching the title
with Stoll's appearance on Prime Time Live and Good Morning America.
*************************************************
Aldea Communications, Inc. | info@aldea.com | 1-619-929-1100
Home of NetPages(tm) - real yellow pages for the Internet.
Download NetPages from the following sites:
Santa Cruz Operation - Number 1 Unix Servers
ftp to ftp.sco.com
in the NetPages directory (case sensitive)
AT&T Jens - Japanese Internet Service Provider
ftp to ftp.spin.ad.jp (165.76.8.4)
pub/doc/NetPages
CompuServe's Internet Forum
"Doing business without advertising is like winking at a girl in the dark:
You know what you are doing but nobody else does." Ed Howe
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12784;
1 Mar 95 18:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12779;
1 Mar 95 18:29 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16660;
1 Mar 95 18:29 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12771;
1 Mar 95 18:29 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12765;
1 Mar 95 18:29 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16655;
1 Mar 95 18:29 EST
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12760;
1 Mar 95 18:29 EST
To: iesg@CNRI.Reston.VA.US
cc: mwalnut@CNRI.Reston.VA.US
Subject: Danvers Registration
Date: Wed, 01 Mar 95 18:29:11 -0500
X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut
Message-ID: <9503011829.aa12760@IETF.CNRI.Reston.VA.US>
The following IESG Members have registered for the Danvers IETF.
Anyone not on this list should send their rsvp in immediately.
Thanks,
Megan
Erik Huizer/SURFnet and
John Klensin/MCI
Stev Knowles/FTP Software and
Claudio Topolcic/BBN
Scott Bradner/Harvard and
Marshall T. Rose/DBC
Joel Halpern/Newbridge Networks
Jeff Schiller/MIT
Joyce K. Reynolds/ISI