Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02111; 2 Apr 93 9:09 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02105; 2 Apr 93 9:09 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07066; 2 Apr 93 9:09 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02088; 2 Apr 93 9:08 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02084; 2 Apr 93 9:08 EST To: IETF-Announce: ; Cc: Jon Postel -- RFC Editor Cc: Internet Architecture Board Cc: snmp2@thumper.bellcore.com Cc: snmp-sec-dev@tis.com Cc: The Internet Engineering Steering Group X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: IESG Secretary Subject: Protocol Action: SNMP Version 2 and SNMP Security to Proposed Standard Date: Fri, 02 Apr 93 09:08:43 -0500 X-Orig-Sender: gvaudre@CNRI.Reston.VA.US Message-ID: <9304020908.aa02084@IETF.CNRI.Reston.VA.US> The IESG has approved the SNMP Version 2 and SNMP Security Protocols as a Proposed Standard. These protocols are the product of the SNMP Version 2 Working Group and the SNMP Security Working Group. The IESG contact person is Steve Crocker. This proposed standard is defined in the following documents: o "Introduction to version 2 of the Internet-standard Network Management Framework" . o "Coexistence between version 1 and version 2 of the Network Management Framework" o "Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)" o "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)" o "Manager to Manager Management Information Base" o "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)" o "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)" o "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)" o "Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)" o "Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2)" o "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)" o "Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2)" The SNMP Security Protocols for SNMP Version 2 replace the SNMP Security Protocols defined which have been reclassified as Historic. The following documents are now Historic: o SNMP Administrative Model o SNMP Security Protocols o Definitions of Managed Objects for Administration of SNMP Parties Introduction In March '92, the IESG issued a call for proposals on evolving the Internet-standard Network Management Framework. In response to the IESG call, the SMP proposal was issued in July '92. Later that month at the Cambridge meeting of the IETF, a BOF was held with over 200 persons in attendance. There was near-unanimous consensus that: - a near-term deadline would be set for other proposals; - in the absence of other proposals, SMP should be the basis for the evolution; - a new working group would be formed to take SMP and develop it into SNMP version 2 (SNMPv2); - the SNMP Security working group would be re-activated to align the SNMP security work with SNMPv2; and, - this work would be done on an accelerated schedule. The SNMPv2 and SNMP Security working groups have now completed their work. Technical Summary SNMPv2 consists of several thrusts: - incorporation of SNMP Security with several improvements, based on implementation experience; - incorporation of bulk-retrieval and manager to manager operations; - refinement of the set operation based on implementation experience; - definition of additional data types and formalisms based on implementation experience; - transport service independence: mappings for SNMPv2 over several transports are defined (these mappings are aligned with the output of the multi-protocol SNMPv1 working group); and, - recording the unwritten rules of SNMP -- those rules which are accepted practice but, for one reason or another, were never documented. Throughout the design process, coexistence with the existing framework was given substantive attention. Many design decisions were made by favoring coexistence over other goals. All 12 documents have the same editor, and there are six authors. The editor has ensured that the documents are consistent with one another. The three security-related documents (ADMIN, SEC, and PARTY) are largely identical to RFCs 1351-1353, which are Proposed Standards. Unfortunately, the writing clarity of some of these documents (RFCs 1351/1352 and the two corresponding SNMPv2 documents, ADMIN and SEC) prevents them from being as readable as desired. However, due to the pressing need to complete this work, a non-technical re-write of these three documents is not scheduled until after all documents re-enter the standards track, i.e., between the time the documents are published as Proposed Standards and the time they are evaluated for promotion to Draft Standards. This schedule for a non-technical re-write is identical to the one adopted at the time RFCs 1351-1353 were originally published. (A non-technical re-write would necessitate at least a two month review period by the working group, a delay which would be contrary to the overwhelming consensus of the July 1992 IETF meeting.) Working Group Summary The documents have been developed by both the SNMPv2 and SNMP Security working groups. The current version of the documents have been available since at least January 1993 and represent the broad, but not unanimous, consensus of the working groups. Protocol Quality (Who has reviewed the spec for the IESG? Are there implementations?) The documents meet all the requirements for entry into the standards track as Proposed Standards as specified in RFC 1310, i.e., - RFC 1310 requires that the specifications be generally stable: and the SNMPv2 specification has been stable since at least January, 1993. - RFC 1310 requires that the known design choices be resolved: and this was met through the working groups' deliberations, including the working groups having made choices about consideration of lengthy expositions of alternative design choices introduced in late in the process. - RFC 1310 requires that the documents be believed to be well-understood: the existence of at least one interoperable implementation by implementors who were not authors of the specifications is evidence that this requirement has been met and that the specifications are understandable and understood. - The documents are in an area of high visibility and interest and have received the requisite significant community review. There can be no doubt that there is sufficient community interest and expression of value, as evidenced by the overwhelming support expressed in the July 1992 IETF meeting. - RFC 1310 requires that there be no known technical omissions with respect to the requirements placed upon it and there are none known. The specifications are aided in this regard by their heritage. Nine of the twelve documents are descendant of RFCs 1155, 1157, 1212, 1215, 1303, and others, with which there is strong implementation and operational experience which guided the revisions. Three of the twelve documents are direct descendants from RFCs 1351-1353 and benefit from that experience base. As is sometimes required of specifications which materially affect the core Internet protocols, those documents underwent an extensive additional review before their original publication last year, resulting in a delay of six months after they were originally completed by the working group. Although the security portions of SNMPv2 are slightly different than RFCs 1351-1353, an additional delay in order to obtain further security review is inappropriate at this time because such a delay is unlikely to be fruitful. The past security review did not uncover problems which were later uncovered through implementation and deployment. Furthermore, the IAB's security expertise and the SAAG have already been repeatedly invited to review and provide comments on the changes in the security aspects which were first identified in July, 1992. No problems have been identified nor have any suggested changes have been forwarded to date as a result of these invitations. As a result, implementation and deployment of SNMPv2 as a Proposed Standard is a more productive method of security review than another delay of six months. Finally, according to RFC 1310, implementation experience is not required of Proposed Standards, although highly desirable. As of this writing, five independent, interoperable implementations are known to exist. The fifth was produced by an implementor who is not an author of any of these documents. Other implementations are underway. Two of the current implementations will be made openly-available as reference implementations.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03037; 2 Apr 93 10:49 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03033; 2 Apr 93 10:49 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10282; 2 Apr 93 10:49 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03021; 2 Apr 93 10:49 EST Received: from HQ.TGV.COM by IETF.CNRI.Reston.VA.US id aa03017; 2 Apr 93 10:49 EST Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ; Fri, 2 Apr 93 07:49:49 PST Received: from karl.mel-brooks by mel-brooks.empirical.com (4.1/SMI-4.1) id AA07045; Fri, 2 Apr 93 07:49:57 PST Date: Fri, 2 Apr 93 07:49:57 PST Message-Id: <9304021549.AA07045@mel-brooks.empirical.com> To: iesg-secretary@CNRI.Reston.VA.US cc: IETF-Announce: %IETF.CNRI.Reston.VA.US@tgv.com;, postel@isi.edu, iab@isi.edu, snmp2@thumper.bellcore.com, snmp-sec-dev@tis.com, IESG@IETF.CNRI.Reston.VA.US MMDF-Warning: Parse error in original version of preceding line at IETF.CNRI.Reston.VA.US In-Reply-To: IESG Secretary's message of Fri, 02 Apr 93 09:08:43 -0500 <9304020908.aa02084@IETF.CNRI.Reston.VA.US> Subject: Re: Protocol Action: SNMP Version 2 and SNMP Security to Proposed Standard Reply-To: karl@empirical.com X-Orig-Sender: karl@mel-brooks.empirical.com X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: karl@mel-brooks.empirical.com Repository: empirical.com Originating-Client: mel-brooks > The IESG has approved the SNMP Version 2 and SNMP Security Protocols > as a Proposed Standard. > > Protocol Quality > *> (Who has reviewed the spec for the IESG? Are there implementations?) > +> The documents meet all the requirements for entry into the standards > track as Proposed Standards as specified in RFC 1310, i.e., That line with the "*" scares me. Did these documents get the technical review that is implied by the lines with the "+"? --karl--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03585; 2 Apr 93 11:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03578; 2 Apr 93 11:51 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13416; 2 Apr 93 11:51 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03561; 2 Apr 93 11:51 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03555; 2 Apr 93 11:51 EST To: karl@empirical.com cc: iesg-secretary@CNRI.Reston.VA.US, postel@isi.edu, iab@isi.edu, snmp2@thumper.bellcore.com, snmp-sec-dev@tis.com, IESG@IETF.CNRI.Reston.VA.US Subject: Re: Protocol Action: SNMP Version 2 and SNMP Security to Proposed Standard In-reply-to: Your message of "Fri, 02 Apr 93 07:49:57 PST." <9304021549.AA07045@mel-brooks.empirical.com> Date: Fri, 02 Apr 93 11:51:28 -0500 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Greg Vaudreuil Message-ID: <9304021151.aa03555@IETF.CNRI.Reston.VA.US> Karl, >*> (Who has reviewed the spec for the IESG? Are there implementations?) Please forgive my Friday morning at IETF goof. This is a line I neglected to delete from the boilerplate recommendation. This line is intended to be be an to aid to the IESG Area Director in the preparation of a protocol action report and has no relation to the SNMPv2 or SNMP Security protocols. Greg Vaudreuil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06382; 2 Apr 93 18:52 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06378; 2 Apr 93 18:52 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02182; 2 Apr 93 18:52 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06359; 2 Apr 93 18:52 EST Received: from merit.edu by IETF.CNRI.Reston.VA.US id aa06353; 2 Apr 93 18:52 EST Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA09247; Fri, 2 Apr 93 18:52:31 -0500 Message-Id: <9304022352.AA09247@merit.edu> To: Greg Vaudreuil Cc: karl@empirical.com, iesg-secretary@CNRI.Reston.VA.US, postel@isi.edu, iab@isi.edu, snmp2@thumper.bellcore.com, snmp-sec-dev@tis.com, IESG@IETF.CNRI.Reston.VA.US Subject: Re: Protocol Action: SNMP Version 2 and SNMP Security to Proposed Standard In-Reply-To: Your message of "Fri, 02 Apr 93 11:51:28 EST." <9304021151.aa03555@IETF.CNRI.Reston.VA.US> Date: Fri, 02 Apr 93 18:52:31 -0500 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bill Norton Actually, I'd be curious to hear the answer to these questions. Besides the four implementations from the authors, are there any others that have proven interoperability? Were these "complete" implementations ( all security stuff, bulk retrievals, etc.? ) Who in the IESG reviewed the specs? Bill >Subject: Re: Protocol Action: SNMP Version 2 and SNMP Security > to Proposed Standard >In-Reply-To: Your message of "Fri, 02 Apr 93 07:49:57 PST." > <9304021549.AA07045@mel-brooks.empirical.com> >Date: Fri, 02 Apr 93 11:51:28 -0500 >From: Greg Vaudreuil > > > > >Karl, > >>*> (Who has reviewed the spec for the IESG? Are there implementations?) > >Please forgive my Friday morning at IETF goof. This is a line I neglected >to delete from the boilerplate recommendation. This line is intended >to be be an to aid to the IESG Area Director in the preparation of a >protocol action report and has no relation to the SNMPv2 or SNMP Security >protocols. > >Greg Vaudreuil   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10704; 4 Apr 93 21:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10700; 4 Apr 93 21:40 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20514; 4 Apr 93 21:40 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10687; 4 Apr 93 21:40 EDT Received: from TIS.COM by IETF.CNRI.Reston.VA.US id aa10683; 4 Apr 93 21:40 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA15803; Sun, 4 Apr 93 21:41:27 EDT Message-Id: <9304050141.AA15803@TIS.COM> To: Bill Norton , karl@empirical.com Cc: iab@isi.edu, snmp2@thumper.bellcore.com, snmp-sec-dev@tis.com, IESG@IETF.CNRI.Reston.VA.US Subject: Re: Protocol Action: SNMP Version 2 and SNMP Security to Proposed Standard In-Reply-To: Your message of Fri, 02 Apr 93 18:52:31 -0500. <9304022352.AA09247@merit.edu> Date: Sun, 04 Apr 93 21:41:26 -0400 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Stephen D Crocker Bill and Karl, The name of a fifth interoperable implementation was supplied to the IESG, but with the proviso that they would have to contact the vendor to get permission to identify them. I don't have a lot of additional details, but I found it helpful to know there had been an independent effort. I was more concerned with the readability of the documents than the actual success of the implementation since multiple interoperable implementations are not required for Proposed Standard status. I expect additional work on the documents and additional reviews during the next few months. If either of you want to sign up to do a serious review, let me know. Steve > From: wbn@merit.edu (Bill Norton) > Subject: Re: Protocol Action: SNMP Version 2 and SNMP Security to Proposed Standard > Date: Fri, 02 Apr 93 18:52:31 -0500 > To: Greg Vaudreuil > Cc: karl@empirical.com, iesg-secretary@CNRI.Reston.VA.US, postel@isi.edu, > iab@isi.edu, snmp2@thumper.bellcore.com, snmp-sec-dev@tis.com, > IESG@IETF.CNRI.Reston.VA.US > > Actually, I'd be curious to hear the answer to these questions. > Besides the four implementations from the authors, are there any others > that have proven interoperability? > > Were these "complete" implementations ( all security stuff, bulk > retrievals, etc.? ) > > Who in the IESG reviewed the specs? > > > Bill   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11493; 4 Apr 93 22:32 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11489; 4 Apr 93 22:32 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21472; 4 Apr 93 22:32 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11477; 4 Apr 93 22:32 EDT Received: from HQ.TGV.COM by IETF.CNRI.Reston.VA.US id aa11473; 4 Apr 93 22:32 EDT Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ; Sun, 4 Apr 93 19:32:28 PDT Received: from karl.mel-brooks by mel-brooks.empirical.com (4.1/SMI-4.1) id AA08497; Sun, 4 Apr 93 19:32:37 PDT Date: Sun, 4 Apr 93 19:32:37 PDT Message-Id: <9304050232.AA08497@mel-brooks.empirical.com> To: wbn@merit.edu cc: gvaudre@CNRI.Reston.VA.US, iesg-secretary@CNRI.Reston.VA.US, postel@isi.edu, iab@isi.edu, snmp2@thumper.bellcore.com, snmp-sec-dev@tis.com, IESG@IETF.CNRI.Reston.VA.US In-Reply-To: Bill Norton's message of Fri, 02 Apr 93 18:52:31 -0500 <9304022352.AA09247@merit.edu> Subject: Re: Protocol Action: SNMP Version 2 and SNMP Security to Proposed Standard Reply-To: karl@empirical.com X-Orig-Sender: karl@mel-brooks.empirical.com X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: karl@mel-brooks.empirical.com Repository: empirical.com Originating-Client: mel-brooks > Actually, I'd be curious to hear the answer to these questions. > Besides the four implementations from the authors, are there any others > that have proven interoperability? > > Were these "complete" implementations ( all security stuff, bulk > retrievals, etc.? ) Aside from the SNMPv2 issue, which apparently has been reviewed and has jumped through all the correct hoops... The words "interoperating implementations" is a bit vague. In the case of established protocols such as Telnet we are still finding that a significant portion of the implementations still do things wrong. (Just try logging into a VMS system from a Sun via a command window with scrolling enabled.) I've seen too many folks bounce a couple of very simple structured packets back and forth and declare the implementation to be "interoperable." Further, mere interoperation doesn't reflect more than that the basic premises of the protocol may be implemented. It does not prove that the protocol design itself is either error-free, that it is an efficient design, or that it is sufficiently well worked out that it deserves to be called an Internet Standard (whether Draft, Proposed, or Full.) Yet waiting for full industry acceptance and commercial grade implementations before promoting a standard is unworkable. So I invite discussion on the issue of what level of implementation and experience constitutes "implementation experience" adequate to give us real confidence that we are promoting quality protocols? That said, we ought to focus the discussion to a more limited forum. --karl--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09776; 9 Apr 93 15:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09771; 9 Apr 93 15:08 EDT Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa16195; 9 Apr 93 15:08 EDT Received: from sleepy.tis.com by sleepy.TIS.COM id aa18903; 9 Apr 93 18:51 GMT Received: from tis.com by sleepy.TIS.COM id aa18898; 9 Apr 93 14:42 EDT Received: from motgate.mot.com by TIS.COM (4.1/SUN-5.64) id AA27332; Fri, 9 Apr 93 14:43:09 EDT Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.13 for ) id AA09880; Fri, 9 Apr 1993 13:42:11 -0500 Received: from isunix.cdx.mot.com by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.12 for ) id AA28815; Fri, 9 Apr 1993 13:42:10 -0500 Received: by isunix.cdx.mot.com (5.57/Ultrix3.0-C) id AA12592; Fri, 9 Apr 93 14:42:08 -0400 Received: by cae.prds.cdx.mot.com ( 5.52 (84)/Spike-2.0) id AA06432; Fri, 9 Apr 93 14:41:03 EDT Date: Fri, 9 Apr 93 14:41:03 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Peter Walter Message-Id: <9304091841.AA06432@cae.prds.cdx.mot.com> To: snmp-sec-dev@tis.com Subject: Add me to the SNMP sec mail list   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20123; 13 Apr 93 9:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20116; 13 Apr 93 9:49 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id bo04796; 13 Apr 93 9:49 EDT Received: from SLEEPY.TIS.COM by IETF.CNRI.Reston.VA.US id aa07750; 13 Apr 93 6:44 EDT Received: from sleepy.tis.com by sleepy.TIS.COM id aa20781; 13 Apr 93 9:20 GMT Received: from tis.com by sleepy.TIS.COM id aa20779; 13 Apr 93 5:14 EDT Received: from utrhcs.cs.utwente.nl ([130.89.10.247]) by TIS.COM (4.1/SUN-5.64) id AA14557; Tue, 13 Apr 93 05:14:06 EDT Received: from utis83.cs.utwente.nl by utrhcs.cs.utwente.nl (4.1/RBCS-2.4mx) id AA01759; Tue, 13 Apr 93 11:12:57 +0200 Received: by utis83.cs.utwente.nl (4.1/RBCS-1.0.1) id AA08556; Tue, 13 Apr 93 11:12:56 +0200 Message-Id: <9304130912.AA08556@utis83.cs.utwente.nl> To: snmp2@thumper.bellcore.com Cc: snmp-sec-dev@tis.com Subject: Errors in the standards Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Eric Schekkerman Organisation: Univ. of Twente, Dept. of CS, Tele-Informatics & Open Systems Address: P.O. Box 217, 7500 AE Enschede, The Netherlands Telephone: +31 53 894287 Telefax: +31 53 333815 Date: Tue, 13 Apr 93 11:12:55 +0200 X-Orig-Sender: schekker@cs.utwente.nl After carefully re-studying the documents I discovered some errors. First of all there is a minor typo: * adminv2-03, page 18: snmpStatsPacket should be snmpStatsPackets In addition I encountered the following inconsistencies in the proposed standards: * The snmpStatsSilentDrops counter is never used. I.e. the protocol does not specify when this counter should be incremented. * Section 3.2 of the adminv2-03 standard covers the processing of a received communication. Steps 15 and 16 cover all classes except class 64 (Inform). If I understand it correclty, class 64 should be included in step 16. Furthermore, I believe the description of the snmpStatsBadOperations counter should indicate that the referred operation was not allowed because it didn't match the requested role of the entity (i.e. the agent role). (And because of that it is not allowed by the entry in the aclTable.) Any comments? --- Eric Schekkerman ---   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26747; 14 Apr 93 11:52 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26742; 14 Apr 93 11:52 EDT Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa13810; 14 Apr 93 11:52 EDT Received: from sleepy.tis.com by sleepy.TIS.COM id aa22091; 14 Apr 93 15:35 GMT Received: from tis.com by sleepy.TIS.COM id aa22089; 14 Apr 93 11:31 EDT Received: from xap.xyplex.com by TIS.COM (4.1/SUN-5.64) id AA28260; Wed, 14 Apr 93 11:31:47 EDT Received: by xap.xyplex.com id ; Wed, 14 Apr 93 10:31:23 -0500 Date: Wed, 14 Apr 93 10:31:23 -0500 Message-Id: <9304141531.AA24553@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp-sec-dev@tis.com Subject: Further SNMPv2 Discussion We should hold all future discussions of SNMPv2 on the SNMPv2 mailing list. If you are a member of the snmp-sec-dev list and not SNMPv2, please join by sending a request to: snmp2-request@thumper.bellcore.com Thanks. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08828; 26 Apr 93 2:46 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08824; 26 Apr 93 2:46 EDT Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa20834; 26 Apr 93 2:46 EDT Received: from sleepy.tis.com by sleepy.TIS.COM id aa29565; 26 Apr 93 6:38 GMT Received: from tis.com by sleepy.TIS.COM id aa29563; 26 Apr 93 2:32 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA02089; Mon, 26 Apr 93 02:33:35 EDT Message-Id: <9304260633.AA02089@TIS.COM> Reply-To: James M Galvin To: snmp-sec-dev@tis.com Subject: [Burt Kaliski: Pseudocollisions in MD5] Date: Mon, 26 Apr 93 02:33:34 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin Here is some more information about the suggestion that MD5 is vulnerable. Jim ------- Forwarded Message Message-ID: <9304240015.AA04170@RSA.COM> Sender: pem-dev-relay@TIS.COM From: burt@RSA.COM (Burt Kaliski) To: pem-dev@TIS.COM Date: Fri, 23 Apr 93 17:15:02 PDT Subject: Pseudocollisions in MD5 Following is a short note commenting on den Boer and Bosselaers' recent work on the MD5 message-digest algorithm. Feel free to email questions or further comments. - -- Burt Kaliski RSA Laboratories - ---------------------------------------------------------------------- \documentstyle[12pt]{article} \begin{document} \title{On ``Pseudocollisions'' in the MD5 Message-Digest Algorithm} \author{Burton S. Kaliski Jr. \\ {\tt burt@rsa.com} \and Matthew J.B. Robshaw \\ {\tt matt@rsa.com} \and RSA Laboratories \\ 100 Marine Parkway \\ Redwood City, CA 94065} \date{April 23, 1993} \maketitle A message-digest algorithm maps a message of arbitrary length to a ``digest'' of fixed length, and has three properties: Computing the digest is easy, finding a message with a given digest---``inversion''---is hard, and finding two messages with the same digest---``collision''---is also hard. Message-digest algorithms have many applications, including digital signatures and message authentication. RSA Data Security's MD5 message-digest algorithm, developed by Ron Rivest \cite{rfc-md5}, maps a message to a 128-bit message digest. Computing the digest of a one-megabyte message takes as little as a second. While no message-digest algorithm can yet be {\em proved} secure, MD5 is believed to be at least as good as any other that maps to a 128-bit digest. Inversion should take about $2^{128}$ operations, and collision should take about $2^{64}$ operations. No one has found a faster approach to inversion or collision. Recent work by den Boer and Bosselaers \cite{den-boer-md5} presents a special kind of ``pseudocollision'' in MD5's internal compression function, which maps a 512-bit message block $x$ and a 128-bit input state $s$ to a 128-bit output state. They show how to find a message block $x$ and two related input states $s_1$ and $s_2$ that yield the same output state: $f(x,s_1)$ = $f(x,s_2)$. Their well-thought approach exploits structural properties of the collision function to find a pseudocollision in about $2^{16}$ operations, much less than one would expect. Practical implications of this pseudocollision work to the security of MD5 are not evident. While a real collision in MD5 implies a pseudocollision (or a ``pseudo-inversion''), a pseudocollision need not imply a real collision. Indeed, a real collision, since it involves two different messages, would almost always involve {\em different} message blocks $x_1$ and $x_2$ such that $f(x_1,s_1) = f(x_2,s_2)$, but the pseudocollisions have the same message blocks. Moreover, the input states $s_1$ and $s_2$ would generally be unrelated, but the pseudocollisions' input states are the same except for four bits. There does not seem to be any way to extend den Boer and Bosselaers' approach to anything beyond the special pseudocollisions, a limitation they readily admit. It is reasonable, therefore, to believe that MD5 remains secure. While den Boer and Bosselaers have found interesting structural properties in MD5, the properties seem only to lead to special pseudocollisions and not anything approaching real collisions. Further research, of course, will give a better understanding of the strengths of MD5 and other message-digest algorithms, with the eventual hope that such algorithms can, in some sense, be proved secure. \bibliographystyle{plain} \begin{thebibliography}{1} \bibitem{den-boer-md5} Bert den~Boer and Antoon Bosselaers. \newblock Collisions for the compression function of {MD5}. \newblock In {\it Advances in Cryptology --- Eurocrypt '93}, 1993. \newblock Preprint. \bibitem{rfc-md5} R.L. Rivest. \newblock {\it {RFC} 1321: The {MD5 Message-Digest Algorithm}}. \newblock Internet Activities Board, April 1992. \end{thebibliography} \end{document} ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02424; 27 Apr 93 9:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02419; 27 Apr 93 9:11 EDT Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa19066; 27 Apr 93 9:11 EDT Received: from sleepy.tis.com by sleepy.TIS.COM id aa00662; 27 Apr 93 12:58 GMT Received: from tis.com by sleepy.TIS.COM id aa00648; 27 Apr 93 8:47 EDT Received: from iha.compuserve.com by TIS.COM (4.1/SUN-5.64) id AA15480; Tue, 27 Apr 93 08:48:35 EDT Received: by iha.compuserve.com (5.65/5.930129sam) id AA18706; Tue, 27 Apr 93 08:47:23 -0400 Date: 27 Apr 93 08:41:35 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: WilliamStallings <72500.3562@compuserve.com> To: snmp-sec-dev@tis.com MMDF-Warning: Parse error in original version of preceding line at sleepy.TIS.COM Subject: Re: Pseudocollisions in MD5 Message-Id: <930427124134_72500.3562_FHG39-1@CompuServe.COM> To: >INTERNET: snmp-sec-dev@tis.com Burt, Is the den Boer and Bosselaers' paper available via ftp?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07950; 28 Apr 93 17:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07946; 28 Apr 93 17:11 EDT Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa27017; 28 Apr 93 17:11 EDT Received: from sleepy.tis.com by sleepy.TIS.COM id aa02152; 28 Apr 93 21:02 GMT Received: from tis.com by sleepy.TIS.COM id aa02140; 28 Apr 93 16:52 EDT Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA19201; Wed, 28 Apr 93 16:52:55 EDT Message-Id: <9304282052.AA19201@TIS.COM> Reply-To: James M Galvin To: WilliamStallings <72500.3562@compuserve.com> Cc: snmp-sec-dev@tis.com Subject: Re: Pseudocollisions in MD5 In-Reply-To: WilliamStallings's message of 27 Apr 93 08:41:35 EDT. <930427124134_72500.3562_FHG39-1@CompuServe.COM> Date: Wed, 28 Apr 93 16:52:53 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: James M Galvin Burt, Is the den Boer and Bosselaers' paper available via ftp? Burt does not read this list; I forwarded the message. As far as I know, the answer is no. It will only appear in the EuroCrypt proceedings, which are typically delayed by almost a year after the conference. Extended abstracts are available to those who attend the conference. Jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06729; 30 Apr 93 12:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06723; 30 Apr 93 12:11 EDT Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa15240; 30 Apr 93 12:11 EDT Received: from sleepy.tis.com by sleepy.TIS.COM id aa03679; 30 Apr 93 16:04 GMT Received: from tis.com by sleepy.TIS.COM id aa03671; 30 Apr 93 11:53 EDT Received: from chesapeake.ads.com by TIS.COM (4.1/SUN-5.64) id AA22003; Fri, 30 Apr 93 11:54:27 EDT Received: from smtpj (smtpj.ads.com) by chesapeake.ads.com (4.1/1.34v1.3) id AA14529; Fri, 30 Apr 93 11:55:31 EDT Received: by smtpj with Microsoft Mail id <2B2D6018@smtpj>; Mon, 14 Dec 92 20:33:28 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Sharpe Alex To: SNMP Security Date: Fri, 30 Apr 93 07:00:00 PST Message-Id: <2B2D6018@smtpj> Encoding: 1 TEXT X-Mailer: Microsoft Mail V3.0 Please include me on your distribution list. Thanks, Alex   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00551; 2 Mar 93 6:05 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00547; 2 Mar 93 6:05 EST Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa02087; 2 Mar 93 6:05 EST Received: from sleepy.tis.com by sleepy.TIS.COM id aa00796; 2 Mar 93 10:54 GMT Received: from tis.com by sleepy.TIS.COM id aa00794; 2 Mar 93 5:51 EST Received: from survis.surfnet.nl by TIS.COM (4.1/SUN-5.64) id AA01798; Tue, 2 Mar 93 05:51:36 EST Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <00646-0@survis.surfnet.nl>; Tue, 2 Mar 1993 11:25:36 +0100 Received: from localhost.surfnet.nl by survival.surfnet.nl (4.1/SMI-4.1(TV920629)) id AA04874; Tue, 2 Mar 93 11:25:34 +0100 Message-Id: <9303021025.AA04874@survival.surfnet.nl> Date: Tue, 02 Mar 93 11:25:33 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Erik Huizer Subject: Process inquiry Apparently-To: ------- Blind-Carbon-Copy Subject: Process inquiry Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Tue, 02 Mar 93 11:25:33 +0100 From: Erik Huizer Bcc: Blind Distribution List: ; L.s., The SNMPv2 process is drawing near to a conclusion with the submission of 12 documents to the IESG. The IESG is working to process these documents as soon as possible. Recently, from a variety of channels and to more than one member, complaints have reached the IESG which call into question the process by which SNMPv2 has advanced. The entire IETF is accountable for the standards it produces, and the IESG is obliged to investigate these complaints to determine whether the process has remained fair and open throughout. The IESG realizes the importance of a broad acceptance of SNMPv2 and finds it necessary to establish that the complaints are unfounded. The IESG has charged me, a non-partisan in the NM area, to approach the community most directly involved with SNMPv2 for input. Therefore I send you this message, and ask each and everyone of you who has comments on the process that led to the creation of SNMPv2 to send me a PERSONAL note. It should present your candid and confidential assessment of the chronology of events leading to the request to advance SNMPv2 to proposed standard, from the original call for contributions through the most recent postings to the mailing list. Since it is equally important to the IESG to hear from those who view the process as having succeeded as not, I urge you to respond. Please rest assured that your correspondence will remain entirely confidential; I will report back to the IESG in a summary fashion. The IESG does not wish this "process checkpoint" to further delay the advancement of these standards. You thus have until monday 8 march 9 am EST to react. This will give me enough time to summarise before the IESG meeting later that day. So if you want to send me a personal note on this subject, do it now, and make sure that it has the same subject line as above, preceded by "re:". I apologise to everyone who feels offended by this note, or by the query. The IESG recognizes that requests of this nature are highly unusual, and deeply regrets having to proceed in this fashion. Indeed, if you find this action to be contrary to the best interests of the community, the IESG is interested in this feedback as well. We are trying to do what is best from the community, and taking the question to the community seems to be our best alternative in this matter. Thanks for reading this, Erik Huizer (Don't shoot me I'm only the messenger :-) ------- End of Blind-Carbon-Copy   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00768; 17 Mar 93 5:36 EST Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa03353; 17 Mar 93 5:36 EST Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23847; Wed, 17 Mar 1993 11:34:06 +0100 Date: Wed, 17 Mar 1993 11:34:02 +0100 Message-Id: <9303171034.AA23847@dxmint.cern.ch> From: Francois Fluckiger X-Vms-To: MINT::ietf-rsvp@cnri.reston.va.us X-Vms-Cc: FLUCKIGER Subject: Registration to IETF X-Mail11-Ostype: VAX/VMS Apparently-To: Dear Sirs, Please find enclosed my registration form for the IETF meeting, Columbus. Best regards. Francois Fluckiger, CERN-Geneva --------------------------------------------------------------------------- REGISTRATION FORM 26th Internet Engineering Task Force - Page 1 of 2 March 29 - April 2, 1993 Columbus, Ohio Please print or type: Name (Mr/Dr/Ms) Mr Francois Fluckiger____________________________________ Title Deputy Leader, Communications Group________________________________ Organization CERN________________________________________________________ Address__________________________________________________________________ _________________________________________________________________________ City Geneva 23_____________________________State ____Postal Code CH-1211_ Country Switzerland______________________________________________________ Telephone +41 22 767 4991_____________Fax +41 22 767 7155________________ Email fluckiger@vxcern.cern.ch___________________________________________ Do you plan to attend the Sunday, March 28th NEWCOMER'S ORIENTATION at 4:30 p.m. ET? YES_X_ NO___ Do you plan to attend the Sunday, March 28th reception at 6:00 p.m. ET? YES_X_ NO___ $130.00 Registration postmarked no later than Monday, March 1, 1993 (emailed and faxed forms must reflect a date no later than March 1, 1993). $150.00 ($130.00 + $20.00 late fee) Registration postmarked after Monday, March 1, 1993. Method of payment: ___AMEX ___VISA _X_MC ___Diners ___Check (U.S. dollars, drawn on a U.S. Bank), payable to: Corporation for National Research Initiatives Account No.5413 2511 5573 3776_________ Expiration Date may 1993________ Cardholder Name Francois Fluckiger _____________________________________ Cardholder Signature Francois Fluckiger_________________________________ Registration Forms can be sent via electronic mail, facsimile, or postal mail: Electronic: ietf-rsvp@cnri.reston.va.us Facsimile: +1-703-620-0913 Postal: Corporation for National Research Initiatives Accounting Department - 26th IETF Meeting 1895 Preston White Drive, Suite 100 Reston, VA 22091-5434 USA REGISTRATION FORM 26th Internet Engineering Task Force - Page 2 of 2 March 29 - April 2, 1993 Columbus, Ohio 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. Registration Forms will be accepted via electronic mail and facsimile until 1:00 p.m. ET on Friday, March 26, 1993. 7. Requests for refunds must be received by March 26, 1993. 8. Refund policy: Refunds are subject to a $20.00 service charge. Late fees will not be refunded. 9. 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@cnri.reston.va.us. Direct all inquiries to: 26th IETF Meeting - Columbus, Ohio.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04634; 17 Mar 93 11:34 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04628; 17 Mar 93 11:34 EST Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa12273; 17 Mar 93 11:34 EST Received: from mailserv-daemon by INNOSOFT.COM (PMDF V4.2-10 #1336) id <01GVWPTI02BK8Y5GEL@INNOSOFT.COM>; Wed, 17 Mar 1993 08:34:03 PST Date: Wed, 17 Mar 1993 08:34:03 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "PMDF Mailserv V4.2" Subject: Re: subscribe ietf-madman "IETF-ARCHIVE" To: Greg Vaudreuil , IETF-ARCHIVE@CNRI.Reston.VA.US Message-id: <01GVWPTJ25UQ8Y5GEL@INNOSOFT.COM> MIME-version: 1.0 Content-transfer-encoding: 7BIT The address: IETF-ARCHIVE@CNRI.RESTON.VA.US has been added to the IETF-MADMAN mailing list by Greg Vaudreuil .   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08203; 18 Mar 93 11:55 EST Received: from vm.usc.edu by CNRI.Reston.VA.US id aa15051; 18 Mar 93 11:55 EST Received: from UNMVMA.UNM.EDU by VM.USC.EDU (IBM VM SMTP V2R2) with BSMTP id 4927; Thu, 18 Mar 93 08:54:15 PST Received: from UNMVMA.BITNET (NJE origin LISTSERV@UNMVMA) by UNMVMA.UNM.EDU (LMail V1.1d/1.7f) with BSMTP id 3575; Thu, 18 Mar 1993 09:53:19 -0700 Date: Thu, 18 Mar 1993 09:53:19 -0700 From: Revised List Processor (1.7e) Subject: Output of your job "ietfadm" To: ietfadm@CNRI.Reston.VA.US Message-ID: <9303181155.aa15051@CNRI.Reston.VA.US> > subscribe isn-wg ietf-archive You must specify your FULL name, for example: SUBSCRIBE ISN-WG John A. Doe. Summary of resource utilization ------------------------------- CPU time: 0.032 sec Device I/O: 8 Overhead CPU: 0.005 sec Paging I/O: 0 CPU model: 9121 DASD model: 3390   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17339; 18 Mar 93 17:48 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17332; 18 Mar 93 17:48 EST Received: from TIS.COM by CNRI.Reston.VA.US id aa29415; 18 Mar 93 17:48 EST Received: by TIS.COM (4.1/SUN-5.64) id AA18888; Thu, 18 Mar 93 17:48:52 EST Received: from blackbird.afit.af.mil by TIS.COM (4.1/SUN-5.64) id AA18880; Thu, 18 Mar 93 17:48:49 EST Received: from scgraph.afit.af.mil by blackbird.afit.af.mil with SMTP id AA19454 (5.65c/IDA-1.4.4 for ); Thu, 18 Mar 1993 17:48:07 -0500 Received: from lion.zoo_serv (lion.afit.af.mil) by scgraph.afit.af.mil (4.1/SMI-4.1) id AA09725; Thu, 18 Mar 93 17:48:04 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gwishon@afit.af.mil Message-Id: <9303182248.AA09725@scgraph.afit.af.mil> Subject: Re: was RE: RIPEM, now who knows? To: Markowitz@dockmaster.ncsc.mil Date: Thu, 18 Mar 93 17:46:33 EST In-Reply-To: <930318201858.302694@DOCKMASTER.NCSC.MIL>; from "Markowitz@DOCKMASTER.NCSC.MIL" at Mar 18, 93 3:18 pm X-Mailer: ELM [version 2.3 PL11] X-Orig-Sender: pem-dev-relay@tis.com > > As long as there is no NIST standardization on the symmetric > cryptosystem used in PMSP, FIPS 41-1 & 86 specify what the federal > government must use--so we're stuck with DES. FIPS XX and YY specify > DSA/SHA. ElGamal, being the basis of the DSA, is a good near-to-middle > term solution to the key management problem. The Universities can use > whatever the hell they like; DLA trading partners and electronic tax > filers will have to use the DSS, no? This means the > registration/certification of ElGamal public keys. TIS, at least, is > working in the right direction. As is NASA/Ames, AT&T, and others. > The sad thing here is, of course, there are many of us who must work and interact with colleagues in _both_ worlds, and who are anxiously awaiting the eventual reconciliation and convergence of standards, certification heirarchies, and products. We'll see that day come soon, won't we.... Gordon Gordon D. Wishon, Air Force Institute of Technology 2950 P Street, Wright-Patterson AFB, OH 45433-7765 USA gwishon@afit.af.mil * tel (513) 255-8000 * fax (513) 476-7080   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19021; 19 Mar 93 17:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19017; 19 Mar 93 17:38 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20945; 19 Mar 93 17:38 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19009; 19 Mar 93 17:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19005; 19 Mar 93 17:38 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20928; 19 Mar 93 17:38 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18983; 19 Mar 93 17:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18979; 19 Mar 93 17:37 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20886; 19 Mar 93 17:37 EST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18969; 19 Mar 93 17:37 EST To: wgchairs@CNRI.Reston.VA.US, bofchairs@CNRI.Reston.VA.US cc: minutes@CNRI.Reston.VA.US X-Orig-Sender:bofchairs-request@IETF.CNRI.Reston.VA.US X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minutes@CNRI.Reston.VA.US Subject: Minutes and Slides for the Proceedings Date: Fri, 19 Mar 93 17:37:36 -0500 X-Orig-Sender: dlegare@CNRI.Reston.VA.US Message-ID: <9303191737.aa18969@IETF.CNRI.Reston.VA.US> Hello. This is just a reminder to those of you who will either be taking notes during your sessions or who will be delegating that responsibility. Minutes should provide a thorough "SUMMARY" of the issues discussed during the working group/bof sessions. They should NOT follow a "Mortimer said", then "Agnes said", then "Duane said", format, nor should they contain a detailed list of changes to a document. While these forms may be helpful to the folks who actually attend the sessions, they are less helpful to those who have a more general interest in the groups' activities. Please be sure that the Minutes contain complete sentences, NOT phrases. If you have overhead slides to present during your sessions, and feel they should be included in the Proceedings with your minutes, please follow these guidelines: a. Please do not submit handwritten slides unless it is absolutely necessary. They are often illegible after reduction. b. Please place a border around your slides. Flat dark borders are best as they maintain their appearance even when reduced. Thin borders fade after only one reduction and we usually go through several before they make it into the Proceedings. c. Please use a fairly large font, so that information isn't lost during reduction. d. The more detailed your slides the less clear they are when reduced. Chances are too much detail on the orginal gets lost even during the presentation. e. If you have the means to do this, please provide us with a reduced set of the slides you intend to present. a. Regardless of whether your original slides are landscape (horizontal) or portrait (vertical) the reductions should be arranged in portrait style. b. Landscape slides are typically arranged six to a page in the Proceedings (see back issues for exact layout). c. Portrait slides can be reduced to fit four to a page. Again refer to a back issue of the Proceedings for examples. d. Please allow for the following margins: a. top margin: 1/2" b. left/right margins: 3/4" c. bottom margin: 1/2" to 2" f. When submitting your slides to the IETF Registration Desk, be sure to specify that they are to be included in the Proceedings. We'd really appreciate your help with this as we continue to work to improve the quality of the Proceedings and the timeliness of their mailing. Thanks, Debra   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20039; 22 Mar 93 12:39 EST Received: from dxmint.cern.ch by CNRI.Reston.VA.US id aa08912; 22 Mar 93 12:39 EST Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23000; Mon, 22 Mar 1993 18:36:09 +0100 Date: Mon, 22 Mar 1993 18:36:09 +0100 Message-Id: <9303221736.AA23000@dxmint.cern.ch> From: Francois Fluckiger X-Vms-To: MINT::mdavies@CNRI.Reston.VA.US, MINT::ietf-rsvp@cnri.reston.va.us X-Vms-Cc: FLUCKIGER Subject: IETF Columbus X-Mail11-Ostype: VAX/VMS Apparently-To: Apparently-To: Dear colleagues, I sent a week ago the registration form by E-mail. Apparently I got no ack, so could you confirm I am registered? Could you also provide additional hotels, as the two given on the form are fully booked for the Saturday 27. Thanks. Best regards. Francois FLUCKIGER CERN CH-1211 geneva 23 Switzerland e-mail: fluckiger@vxcern.cern.ch   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01627; 23 Mar 93 8:24 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ai01506; 23 Mar 93 8:24 EST Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa07833; 23 Mar 93 4:58 EST Via: uk.ac.mailbase; Tue, 23 Mar 1993 09:57:53 +0000 Date: Tue, 23 Mar 1993 09:57:45 GMT To: ietf-archive@CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: mailbase-admin@mailbase.ac.uk Subject: File mailbase user-card Message-ID: <9303230458.aa07833@CNRI.Reston.VA.US> User Commands Reference Card January 1993 **************************** Copyright the UK Networked Information Services Project, 1993 The Computing Service, University of Newcastle upon Tyne. This is the on-line version of the reference card - a formatted copy may be obtained from NISP: send your e-mail request to mailbase-helpline@uk.ac.mailbase If you are not the type of person to plough through a lengthy document and just want to get started, this card may provide you with all the information you need. If you require a comprehensive introduction to Mailbase you may retrieve the User's Guide by sending the following command in an e-mail message to mailbase@uk.ac.mailbase send mailbase user-guide Welcome to Mailbase (TM) ******************* Mailbase is an electronic information service which allows UK groups to manage their own discussion topics (Mailbase lists) and associated files. The Mailbase service is run as part of the JANET Networked Information Services Project (NISP) based at Newcastle University. If you are new to Mailbase you may find it useful to read through some other Mailbase documents. Other documents For a list of on-line documentation about Mailbase, send the following command in an e-mail message to: mailbase@uk.ac.mailbase index mailbase You can then use the "send" command to retrieve those documents that interest you. Support from Mailbase "help" returns a summary of the Mailbase commands. If the "command" option is used then a more detailed description of a particular command is given. Example: help review Will return information on the command review. If you have problems with Mailbase first look at the file of "frequently asked questions". To retrieve this file send the following command to mailbase@uk.ac.mailbase send mailbase user-faq If you still have a problem contact your List Owner, the address is: listname-request@uk.ac.mailbase where listname is the name of your chosen list. For example to contact the List Owner for the list chest-dtp, the address would be: chest-dtp-request@uk.ac.mailbase If you are still need help send an e-mail message to: mailbase-helpline@uk.ac.mailbase explaining the problem - we will do our best to help. Sending Mailbase Commands ************************* This card provides a summary of the commands needed to use a Mailbase discussion list. Commands should be sent as an electronic mail message to: mailbase@uk.ac.mailbase More than one command may appear in a message to Mailbase; They may be in any order, in UPPER, lower, or MiXeD case. If you normally terminate your e-mail messages with a signature, please use stop after the final command sent to mailbase. As an example, if you wish to join an open list, then depending upon the type of mail system your mail message should look similar to the following. ---------------------------------------------------------------------------- | mail message | | | | To: mailbase@uk.ac.mailbase | | | | Subject: test (you may leave this blank) | | | | Text of message: join eng-lit Cliff Spencer | | | ---------------------------------------------------------------------------- To check if there are any files associated with a particular list send an index command. ---------------------------------------------------------------------------- | mail message | | | | To: mailbase@uk.ac.mailbase | | | | Subject: test (you may leave this blank) | | | | Text of message: index eng-lit | | | ---------------------------------------------------------------------------- To contribute to a list, for example English Literature. --------------------------------------------------------------------------- | mail message | | | | To: eng-lit@uk.ac.mailbase | | | | Subject: romantic poetry | | | | Text of message: A recent study has shown that... | | | --------------------------------------------------------------------------- Quick Reference *************** Notation Braces { and } enclose alternative items, one of which must be given. Square brackets [ and ] enclose optional items. A vertical bar | means or. Items in angle brackets <> are to be replaced appropriately. Please note that lists quoted in the examples on this card are fictitious. COMMANDS ******** find lists help [command] index [listname] join leave { | all} line limit list me lists [full] resume mail { | all } review send statistics [commands | lists | ] stop suspend mail { | all } USER COMMANDS ************* Joining and leaving a list Use the "join" command to add your name to a Mailbase list Example: join fluid-dynamics George Stevens Synonym: subscribe You will begin to receive messages from the list(s) you have joined - if you wish to make a contribution send your message(s) to the list address. You can see an example in the section Sending Mailbase Commands. "Leave" will remove your name from a specified Mailbase list, or, if the all option is used, from all those lists where your membership address corresponds to your current mail address. Example: leave read-digest Synonym: unsubscribe Use "suspend mail" to temporarily suspend mail from a specified list, or from every list if the all option is used. You will still remain a list member and may continue to receive mail by issuing a resume mail command. Example: suspend mail cti-humgrad "resume mail" will restore mail from a chosen list, or from all (joined) lists if the all option is used. Example: resume mail cti-humgrad Checking your membership "list me" shows which lists you are member of, and whether you are a List Owner or Moderator. Synonym: listme Retrieving files Use the "index" command to obtain a record of those lists which have related files. If you include a listname then the names of files specific to that list are returned. Example: index romantic-poets send retrieves files via electronic mail (see index command). Large files are automatically broken down into several messages each 1000 lines long. Example: send mac-users dtp-review Synonym: get, send me You may set your own file size, up to a maximum of 5,000 lines, by using the "line limit" command. If required it should precede a send command. The minimum line limit value is 1000. Example: line limit 2000 Synonym: line-limit Anonymous FTP Public files on Mailbase may be retrieved using the anonymous FTP service. * Use your local FTP service to connect to mailbase.ac.uk * Login as "anonymous" * Files for a list are in /pub/listname. For example the files for the nisp list are in the directory /pub/nisp * Mailbase documents are in the directory /pub/mailbase Contact your local system administrator for details of FTP at your site. List information "lists" returns a list of all the current Mailbase lists. The full option adds short descriptions provided by List Owners. Example: lists full Use find lists" to search Mailbase for lists which have descriptions matching your subject area. Example: find lists medical Use review to obtain details of the members of a Mailbase list, and a brief description of the purpose of that list. Example: review lib-cdroms Mailbase statistics Use "statistics" to obtain data on a specific Mailbase list if the listname option is given, or on all lists if the lists option is chosen. With the commands option, statistics on Mailbase commands are shown. If no options are given, statistics on both commands and lists are returned. Example: statistics eng-lit =============================================================================== (cs Jan 1993)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01635; 23 Mar 93 8:24 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aj01506; 23 Mar 93 8:24 EST Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa07842; 23 Mar 93 5:01 EST Via: uk.ac.mailbase; Tue, 23 Mar 1993 09:58:38 +0000 Date: Tue, 23 Mar 1993 09:57:47 GMT To: ietf-archive@CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: mailbase-admin@mailbase.ac.uk Subject: Subscription to Mailbase list nir Message-ID: <9303230501.aa07842@CNRI.Reston.VA.US> You have been added to the Mailbase list nir To leave this list send the command LEAVE nir to mailbase@uk.ac.mailbase List description: Discussion list for the IETF/RARE/CNI Joint Working Group on Networked Information Retrieval (NIR). (IETF - Internet Engineering Task Force; RARE - Association of European Research Networks; CNI - Coalition for Networked Information) You will also receive mail directed to this list's superlist wg-isus   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20341; 23 Mar 93 23:33 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20337; 23 Mar 93 23:33 EST Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa03755; 23 Mar 93 23:33 EST Via: uk.ac.mailbase; Wed, 24 Mar 1993 04:30:16 +0000 Date: Wed, 24 Mar 1993 04:30:10 GMT To: ietf-archive@nri.reston.va.us Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: mailbase-admin@mailbase.ac.uk Subject: File mailbase user-card Message-ID: <9303232333.aa03755@CNRI.Reston.VA.US> User Commands Reference Card January 1993 **************************** Copyright the UK Networked Information Services Project, 1993 The Computing Service, University of Newcastle upon Tyne. This is the on-line version of the reference card - a formatted copy may be obtained from NISP: send your e-mail request to mailbase-helpline@uk.ac.mailbase If you are not the type of person to plough through a lengthy document and just want to get started, this card may provide you with all the information you need. If you require a comprehensive introduction to Mailbase you may retrieve the User's Guide by sending the following command in an e-mail message to mailbase@uk.ac.mailbase send mailbase user-guide Welcome to Mailbase (TM) ******************* Mailbase is an electronic information service which allows UK groups to manage their own discussion topics (Mailbase lists) and associated files. The Mailbase service is run as part of the JANET Networked Information Services Project (NISP) based at Newcastle University. If you are new to Mailbase you may find it useful to read through some other Mailbase documents. Other documents For a list of on-line documentation about Mailbase, send the following command in an e-mail message to: mailbase@uk.ac.mailbase index mailbase You can then use the "send" command to retrieve those documents that interest you. Support from Mailbase "help" returns a summary of the Mailbase commands. If the "command" option is used then a more detailed description of a particular command is given. Example: help review Will return information on the command review. If you have problems with Mailbase first look at the file of "frequently asked questions". To retrieve this file send the following command to mailbase@uk.ac.mailbase send mailbase user-faq If you still have a problem contact your List Owner, the address is: listname-request@uk.ac.mailbase where listname is the name of your chosen list. For example to contact the List Owner for the list chest-dtp, the address would be: chest-dtp-request@uk.ac.mailbase If you are still need help send an e-mail message to: mailbase-helpline@uk.ac.mailbase explaining the problem - we will do our best to help. Sending Mailbase Commands ************************* This card provides a summary of the commands needed to use a Mailbase discussion list. Commands should be sent as an electronic mail message to: mailbase@uk.ac.mailbase More than one command may appear in a message to Mailbase; They may be in any order, in UPPER, lower, or MiXeD case. If you normally terminate your e-mail messages with a signature, please use stop after the final command sent to mailbase. As an example, if you wish to join an open list, then depending upon the type of mail system your mail message should look similar to the following. ---------------------------------------------------------------------------- | mail message | | | | To: mailbase@uk.ac.mailbase | | | | Subject: test (you may leave this blank) | | | | Text of message: join eng-lit Cliff Spencer | | | ---------------------------------------------------------------------------- To check if there are any files associated with a particular list send an index command. ---------------------------------------------------------------------------- | mail message | | | | To: mailbase@uk.ac.mailbase | | | | Subject: test (you may leave this blank) | | | | Text of message: index eng-lit | | | ---------------------------------------------------------------------------- To contribute to a list, for example English Literature. --------------------------------------------------------------------------- | mail message | | | | To: eng-lit@uk.ac.mailbase | | | | Subject: romantic poetry | | | | Text of message: A recent study has shown that... | | | --------------------------------------------------------------------------- Quick Reference *************** Notation Braces { and } enclose alternative items, one of which must be given. Square brackets [ and ] enclose optional items. A vertical bar | means or. Items in angle brackets <> are to be replaced appropriately. Please note that lists quoted in the examples on this card are fictitious. COMMANDS ******** find lists help [command] index [listname] join leave { | all} line limit list me lists [full] resume mail { | all } review send statistics [commands | lists | ] stop suspend mail { | all } USER COMMANDS ************* Joining and leaving a list Use the "join" command to add your name to a Mailbase list Example: join fluid-dynamics George Stevens Synonym: subscribe You will begin to receive messages from the list(s) you have joined - if you wish to make a contribution send your message(s) to the list address. You can see an example in the section Sending Mailbase Commands. "Leave" will remove your name from a specified Mailbase list, or, if the all option is used, from all those lists where your membership address corresponds to your current mail address. Example: leave read-digest Synonym: unsubscribe Use "suspend mail" to temporarily suspend mail from a specified list, or from every list if the all option is used. You will still remain a list member and may continue to receive mail by issuing a resume mail command. Example: suspend mail cti-humgrad "resume mail" will restore mail from a chosen list, or from all (joined) lists if the all option is used. Example: resume mail cti-humgrad Checking your membership "list me" shows which lists you are member of, and whether you are a List Owner or Moderator. Synonym: listme Retrieving files Use the "index" command to obtain a record of those lists which have related files. If you include a listname then the names of files specific to that list are returned. Example: index romantic-poets send retrieves files via electronic mail (see index command). Large files are automatically broken down into several messages each 1000 lines long. Example: send mac-users dtp-review Synonym: get, send me You may set your own file size, up to a maximum of 5,000 lines, by using the "line limit" command. If required it should precede a send command. The minimum line limit value is 1000. Example: line limit 2000 Synonym: line-limit Anonymous FTP Public files on Mailbase may be retrieved using the anonymous FTP service. * Use your local FTP service to connect to mailbase.ac.uk * Login as "anonymous" * Files for a list are in /pub/listname. For example the files for the nisp list are in the directory /pub/nisp * Mailbase documents are in the directory /pub/mailbase Contact your local system administrator for details of FTP at your site. List information "lists" returns a list of all the current Mailbase lists. The full option adds short descriptions provided by List Owners. Example: lists full Use find lists" to search Mailbase for lists which have descriptions matching your subject area. Example: find lists medical Use review to obtain details of the members of a Mailbase list, and a brief description of the purpose of that list. Example: review lib-cdroms Mailbase statistics Use "statistics" to obtain data on a specific Mailbase list if the listname option is given, or on all lists if the lists option is chosen. With the commands option, statistics on Mailbase commands are shown. If no options are given, statistics on both commands and lists are returned. Example: statistics eng-lit =============================================================================== (cs Jan 1993)   Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19797; 24 Mar 93 10:26 EST Received: from picard.cmf.nrl.navy.mil by CNRI.Reston.VA.US id aa09453; 24 Mar 93 10:26 EST Received: from gnext.cmf.nrl.navy.mil by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA24264; Wed, 24 Mar 93 10:25:59 EST From: kshah@cmf.nrl.navy.mil Received: by gnext.cmf.nrl.navy.mil (NX5.67c/client-1.3) id AA00771; Wed, 24 Mar 93 10:23:36 -0500 Date: Wed, 24 Mar 93 10:23:36 -0500 Message-Id: <9303241523.AA00771@gnext.cmf.nrl.navy.mil> Apparently-To: ietf-rsvp@cnri.reston.va.us I faxed my registration to you yesterday. I just wanted to confirm that you had received it. NAME: Kanan Shah ORGANIZATION: Locus Inc. 2560 Huntington Ave. Alexandria, VA 22303 Thank You. --Kanan   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16517; 26 Mar 93 19:31 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16513; 26 Mar 93 19:31 EST Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa12490; 26 Mar 93 19:31 EST Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Fri, 26 Mar 1993 23:51:24 +0000 Received: from kum.kaist.ac.kr by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 26 Mar 1993 23:51:03 +0000 Received: from ring.kotel.co.kr by kum.kaist.ac.kr (4.1/KUM-0.1) id AA20842; Sat, 27 Mar 93 08:52:13 KST Received: from ercc.snu.ac.kr by ring.kotel.co.kr (4.1/RING-0.1) id AA01032; Sat, 27 Mar 93 08:42:10 KST Received: from mmlab.snu.ac.kr by ercc.snu.ac.kr (4.1/SNU-0.1) id AA13815; Sat, 27 Mar 93 07:52:49 KST Received: by mmlab.snu.ac.kr (4.1/SMI-4.1) id AA02595; Sat, 27 Mar 93 08:51:27+120 Date: Sat, 27 Mar 93 08:51:27+120 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "O.S.T." Message-Id: <9303262051.AA02595@mmlab.snu.ac.kr> Apparently-To: osi-ds@cs.ucl.ac.uk Dear Chairman, I am an student at Department of Computer Sience at Seoul National University of Korea. I am interesting in ISODE and Massage Handling System. I am studying the MHS implimentation with the ability of processing Korean text and I am searching the recently-pressed proceedings and pares on ISODE and MHS. If you will mail to me with recommendation on several recently_pressed papers, I will very happy. your sincerely, Sueng_Taek Oh   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23728; 29 Mar 93 19:25 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23722; 29 Mar 93 19:25 EST Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20193; 29 Mar 93 19:25 EST Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23713; 29 Mar 93 19:24 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23707; 29 Mar 93 19:24 EST Received: from ocfmail.ocf.llnl.gov by CNRI.Reston.VA.US id aa20164; 29 Mar 93 19:24 EST Received: from framsparc.ocf.llnl.gov.ocf by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA05832; Mon, 29 Mar 93 16:24:49 PST Received: by framsparc.ocf.llnl.gov.ocf (4.1/SMI-4.1) id AA12305; Mon, 29 Mar 93 16:24:47 PST X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Boolootian Message-Id: <9303300024.AA12305@framsparc.ocf.llnl.gov.ocf> Subject: The Fortran-filter Gateway To: Mark Boolootian Date: Mon, 29 Mar 1993 16:24:46 -0800 (PST) X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2652 [Ran across this on the RISKS Forum and thought you might find it amusing - mb] Date: Fri, 26 Mar 93 23:04:46 HST From: "Joe Dellinger" Subject: The FORTRAN-hating gateway Several months ago we started noticing that (now and again) the network connection to the mainland would become very very slow; this would continue for 10-15 minutes or so, then all would suddenly be well again. A while after this started happening a coworker of mine complained to me that the connection to the mainland _never_ worked anymore. It seems that he had some FORTRAN source that he needed to copy to a machine on the mainland, but he never could because "the network wouldn't stay up long enough for the ftp to complete". Yes, it turned out that the network outages happened whenever he attempted to ftp that _particular_ FORTRAN source file to the mainland. We next tried compressing the file; it copied just fine then (but unfortunately the machine on the mainland had no uncompress program, so it was still no go). Finally we "split" his FORTRAN program up into very small pieces and sent them one at a time. Most of the pieces would copy without trouble, but a few would either not go at all or only go after many _many_ retries. Examining the troublesome pieces, we found they all had one thing in common: they contained comment blocks that began and ended with lines consisting of nothing but capital C's (his preferred FORTRAN commenting style). At this point we started sending e-mail to the network gurus on the mainland asking for help. Of course, they wanted to see an example of our un-ftp-able files, so we mailed some to them... but our mail never got there. Finally we got the bright idea of simply _describing_ what the unsendable files were like. That worked. :-) [Dare I include in this message an example of one of the offending FORTRAN comment blocks? Probably better not!] Eventually we were able to piece together the story. A new gateway had recently been installed between our part of campus and the connection to the mainland. This gateway had GREAT difficulty transmitting packets that contained repeated blocks of capital C's!!!! Just a few such packets would occupy all its energies and prevent most everything else from getting through. At this point we complained to the gateway manufacturer... and were told "Oh, yes, you've hit the repeated C's bug! We know about that already.". Eventually we solved the problem... by buying new gateways from another manufacturer. (In the manufacturer's defense I suppose an inability to propagate FORTRAN programs might be considered a feature by some!)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20696; 5 Apr 93 14:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20692; 5 Apr 93 14:05 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08981; 5 Apr 93 14:05 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20681; 5 Apr 93 14:05 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20677; 5 Apr 93 14:05 EDT Received: from SIGURD.INNOSOFT.COM by CNRI.Reston.VA.US id aa08952; 5 Apr 93 14:05 EDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992) id <01GWNENSB0W08WWEX1@SIGURD.INNOSOFT.COM>; Mon, 5 Apr 1993 11:05:27 PDT Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1992) id <01GWMVQDYTFK8WWAX7@SIGURD.INNOSOFT.COM>; Mon, 5 Apr 1993 11:05:22 PDT Date: Mon, 05 Apr 1993 10:54:53 -0700 (PDT) X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: Request from Marshall on POP3 In-reply-to: Your message dated "Mon, 05 Apr 1993 16:25:51 +0200" <"survis.sur.056:05.03.93.14.25.56"@surfnet.nl> To: Erik Huizer Cc: Application Area Directorate Message-id: <01GWNENOFNJ48WWAX7@SIGURD.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > I plan to formulate an answer to Marshall this week. My first hunch is > that I have no objection to moving POP3 with APOP addition forward as > a Draft Standard. Any comments? I agree with Marshall that the addition of APOP is a valuable one that's worth the trouble. I also agree that this addition warrants recycling the specification to draft standard again. I see no reason to reset things to proposed; in my opinion POP3/APOP is operating successfully today at draft standard status. I intend to review the entire document and get back to Marshall with any nits but I have not done so yet. I'll probably get this done today tho. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08934; 8 Apr 93 13:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08930; 8 Apr 93 13:10 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18119; 8 Apr 93 13:10 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08917; 8 Apr 93 13:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08913; 8 Apr 93 13:09 EDT Received: from survis.surfnet.nl by CNRI.Reston.VA.US id ab18100; 8 Apr 93 13:09 EDT Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <13274-0@survis.surfnet.nl>; Thu, 8 Apr 1993 19:09:29 +0200 Date: Thu, 08 Apr 93 19:09:22 +0200 X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Erik Huizer Subject: Re: new MIME WG formation BCC: Message-ID: <"survis.sur.306:08.03.93.17.09.46"@surfnet.nl> ------- Blind-Carbon-Copy To: Nathaniel Borenstein CC: Greg Vaudreuil , Marshall Rose , Dave Crocker , Applications Area Directorate Subject: Re: new MIME WG formation In-reply-to: Your message of Tue, 06 Apr 93 12:58:44 -0400. Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Thu, 08 Apr 93 19:09:22 +0200 From: Erik Huizer Nathaniel, We have discussed this in the Applications Area Directorate. John Klensin came up with the following proposal, which I feel very comfortable with. So I put this to you to see how you like it. I'd appreciate comments from others too. Erik From John Klensin: First of all, we should avoid standing working groups whose charter is to "review things as they come along". I think that is looking for trouble and is out of synch with closed-end, limited-purpose WGs. I suggest the following model: (1) If anyone proposes a change to MIME itself, we get a draft document and charter a WG. Note that nothing discussed in either Nathaniel's note or Greg's constitutes a change to MIME itself. (2) For anything that is proposed for registration, we ask that an I-D be published before an RFC and official registration. In what appear to be non-controversial cases, we issue a "heads up" to the IETF list, calling specific attention to the I-D, so that people who have comments can get them to the authors. If there appear to be potential interoperability problems, we negotiate about a WG effort. (3) If someone wants new content types (or charsets) standardized, we operate as we discussed last week--documents first, then purpose- specific WGs. Part of the reason for this is that there is no point in WG review of anything unless the WG contains the relevant expertise in relatively high density. Interestingly, Nathaniel cites three examples - -- new content-types, new charsets, and compression -- and I suspect that there are very few people in IETF who have the needed expertise to really evaluate and contribute to all three. Throwing them into one WG is therefore a pretty good mechanism for the generation of noise and possibly losing some important people to information (or noise) overload. - ------------- Nathanials original message included for people new to the cc-header: ==> From: Nathaniel Borenstein > "Brewster Kahle" > Subject: New applications working group? > CC: Greg Vaudreuil , > Ned Freed , > Marshall Rose , > Dave Crocker > > Erik, Brewster -- As you have probably heard by now, the 822 extensions > working group has essentially finished its work with the completion of > the MIME specification. Greg has announced that the Columbus meeting > was the final meeting of that working group. > > However, many of us percieve a need to charter a new working group, > essentially to manage and shepherd the continuing evolution of MIME. In > particular, there are important new standards-track content-types and > charsets to be defined, and there are still some open questions such as > the incorporation of some kind of compression mechanism into MIME. For > that reason, I'm very interested in getting such a working group > chartered. I'm willing to be the group chair, as it is my impression > that Greg is not particularly eager to do this. (Greg, please correct > me if I'm wrong.) If there's someone else who wants to do it, though, > that's fine with me too -- I just want to see it happen, that's all. > > So, what do we have to do to get a MIME extensions working group > chartered? I've never started or led a working group before, so I'm in > unfamiliar territory and woul be grateful for any guidance you can > provide. Thanks. -- Nathaniel ------- End of Blind-Carbon-Copy   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10646; 9 Apr 93 15:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10642; 9 Apr 93 15:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17712; 9 Apr 93 15:44 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10628; 9 Apr 93 15:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10624; 9 Apr 93 15:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17706; 9 Apr 93 15:44 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10595; 9 Apr 93 15:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10591; 9 Apr 93 15:44 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17696; 9 Apr 93 15:44 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10585; 9 Apr 93 15:44 EDT To: wgchairs@CNRI.Reston.VA.US, bofchairs@CNRI.Reston.VA.US cc: minutes@CNRI.Reston.VA.US X-Orig-Sender:bofchairs-request@IETF.CNRI.Reston.VA.US X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minutes@CNRI.Reston.VA.US Subject: 1st Notice: Columbus Minutes Due Date: Fri, 09 Apr 93 15:44:07 -0400 X-Orig-Sender: dlegare@CNRI.Reston.VA.US Message-ID: <9304091544.aa10585@IETF.CNRI.Reston.VA.US> As stated in the working group instruction sheet which was included in your attendee packet (assuming your packet survived the Sunday night clean up crew), Minutes from working group and bof sessions are due within the two weeks following the IETF meeting. That would be Friday, April 16th. Minutes should provide a thorough "SUMMARY" of the issues discussed during the working group/bof sessions. They should NOT follow a "Mortimer said", then "Agnes said", then "Duane said", format, nor should they contain a detailed list of changes to a document. While these forms may be helpful to the folks who actually attend the sessions, they are less helpful to those who have a more general interest in the groups' activities. Please be sure that the Minutes contain complete sentences, NOT phrases. Also: * Please indicate the name of the individual who is actually reporting the minutes. * Be sure to let us know if you expect any slides to be included with the minutes. * The attendee list will be appended upon receipt of the minutes. Many thanks to those of you who have already submitted yours! Debra   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25767; 13 Apr 93 14:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25761; 13 Apr 93 14:45 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17979; 13 Apr 93 14:45 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25748; 13 Apr 93 14:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25736; 13 Apr 93 14:45 EDT Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa17963; 13 Apr 93 14:45 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA19612; Tue, 13 Apr 93 11:45:28 -0700 To: mrose@dbc.mtview.ca.us Subject: A brief message from the new NM AD Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Apr 1993 11:45:27 -0700 Message-Id: <19611.734726727@dbc.mtview.ca.us> X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose Greetings. As a result of the IAB/IESG nomination/confirmation process established by the POISED working group, I now find myself in the role of "Area Director for Network Management" on the IESG. I am sending this note for two reasons: disclosure and dissemination. In terms of disclosure, 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 ------------------------------ --------------------------- North American Directory Forum Directory services Soft.Switch E-mail & Directory products AT&T Bell Laboratories Network Management services Intel Corporation Network Management products Interop Company Program Committee (If this list changes, then I will disclose the changes accordingly.) 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. Finally, I am the author of several books on internetworking technologies, for which I receive royalties. I am disclosing this information so that any party may evaluate my performance as 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 me or to the IESG, should my actions cause you any question. Since it isn't always clear who a consultant works for, I felt it appropriate to be forthcoming. In terms of dissemination, I will be sending out a "state of area" report for the NM area tomorrow. Because this information is specific to the NM area, I will post this information to the SNMP list, instead of the IETF list. To subscribe to the SNMP list, send a note to Thanks, /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18702; 15 Apr 93 17:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18695; 15 Apr 93 17:07 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01717; 15 Apr 93 17:07 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18684; 15 Apr 93 17:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18680; 15 Apr 93 17:07 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01712; 15 Apr 93 17:07 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18659; 15 Apr 93 17:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18655; 15 Apr 93 17:07 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01702; 15 Apr 93 17:07 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18650; 15 Apr 93 17:07 EDT To: wgchairs@CNRI.Reston.VA.US, bofchairs@CNRI.Reston.VA.US cc: minutes@CNRI.Reston.VA.US X-Orig-Sender:bofchairs-request@IETF.CNRI.Reston.VA.US X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minutes@CNRI.Reston.VA.US Subject: 2nd Notice: Columbus Minutes Due Date: Thu, 15 Apr 93 17:07:32 -0400 X-Orig-Sender: dlegare@CNRI.Reston.VA.US Message-ID: <9304151707.aa18650@IETF.CNRI.Reston.VA.US> Please remember that Friday, April 16th is the due date for minutes from the Columbus IETF. Appended to this message is a list of those which have not yet been submitted. Minutes should provide a thorough "SUMMARY" of the issues discussed during the working group/bof sessions. They should NOT follow a "Mortimer said", then "Agnes said", then "Duane said", format, nor should they contain a detailed list of changes to a document. While these forms may be helpful to the folks who actually attend the sessions, they are less helpful to those who have a more general interest in the groups' activities. Please be sure that the Minutes contain complete sentences, NOT phrases. Also: * Please indicate the name of the individual who is actually reporting the minutes. * Be sure to let us know if you expect any slides to be included with the minutes. * The attendee list will be appended upon receipt of the minutes. Thank you. Debra ======== Applications Area ----------------- mhsds mimemhs osids Internet Area ------------- bigaddr dhc ipae rtqos sip snapper Network Management Area ----------------------- chassis emailmgt fddimib hubmib madman upsmib Operational Requirements ------------------------ bgpdepl netstat njm noop opstat orad mbone Routing Area ------------ bgp idpr ipidrp mobileip mospf sdr vcrout Security Area ------------- aac cipso ipsec nasreq saag Transport and Services Area --------------------------- avt dns svrloc User Services Area ------------------ All minutes have been received   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20673; 15 Apr 93 21:09 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20669; 15 Apr 93 21:09 EDT Received: from apache.telebit.com by CNRI.Reston.VA.US id aa10561; 15 Apr 93 21:09 EDT Received: by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-930310) id AA06013 to ietf-archive@cnri.reston.va.us; Thu, 15 Apr 93 18:10:03 PDT Date: Thu, 15 Apr 93 18:10:03 PDT Message-Id: <9304160110.AA06013@apache.telebit.com> To: ietf-archive@CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Majordomo@telebit.com Subject: Welcome to modemmgt Reply-To: Majordomo@telebit.com Welcome to the modemmgt mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "Majordomo@telebit.com": unsubscribe modemmgt ietf-archive@cnri.reston.va.us Here's the general information for the list you've subscribed to, in case you don't already have it: MODEMMGT - Working Group Charter April 5, 1993 Chair: Mark S. Lewis Network Management Area Director: Marshall Rose Resources: Mailing list: modemmgt@Telebit.COM (Majordomo) MIB archive: ftp.telebit.com:/pub/modemmgt/mibs (anonymous) List archive: Description of Working Group: The modem management working group is charted to define a set of managed objects for modems and similar devices. This set of objects will be the minimum necessary to provide the ability to monitor and control the devices. The working group will consider existing specifications including the RS-232-Like, the Character, the PPP and other general MIBs. It will consider enterprise extensions made by various vendors to support modems and like devices. The working group will also consider the TSB Study Group 14s work on an OSI CMIS/CMIP object definition for V series DCEs entitled "Managed Object Template for V-Series DCE's." It will coordinate the related work of Technical Subcommittee TR-30.4 of the Telecommunications Industry Association (TIA) towards the conversion of V.im Management Information Model to an SNMP compliant MIB. The MIB object definitions produced will be for use by SNMP and will be consistent with existing SNMP standards and framework. Goals and Milestones: Apr 93 Meet with TR-30.4 Apr 93 Select author(s) and/or editor May 93 Post an internet-draft of Modem MIB Jul 93 Initial public discussion at IETF and TR-30.4 Jul 93 Post a revised internet-draft of Modem MIB Sep 93 Public discussion of modifications at IETF and TR-30.4 Oct 93 Complete at least 2 implementations Nov 93 Final public discussion at IETF and TR-30.4 Dec 93 Working group submits MIB to become RFC   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22592; 15 Apr 93 23:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22586; 15 Apr 93 23:18 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13739; 15 Apr 93 23:18 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22579; 15 Apr 93 23:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22573; 15 Apr 93 23:18 EDT Received: from ppp.dbc.mtview.ca.us by CNRI.Reston.VA.US id aa13734; 15 Apr 93 23:18 EDT Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA17884; Thu, 15 Apr 93 20:16:24 -0700 To: mrose@dbc.mtview.ca.us Subject: NM "State of the Area" Report Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Thu, 15 Apr 1993 20:16:22 -0700 Message-Id: <17882.734930182@dbc.mtview.ca.us> X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Introduction Greetings. As a result of the IAB/IESG nomination/confirmation process established by the POISED working group, I now find myself in the role of "Area Director for Network Management" on the IESG. The NM area has lacked an AD for approximately two months. Things have been piling up. I am posting the following status report for two reasons: - to inform the community as to where I think things stand; and, - to find out if I've missed something Please reply to me directly. /mtr ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Getting to know the new NM AD Getting to know the new NM AD ----------------------------- 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. For over a year now, I have been publishing a bi-monthly newsletter on SNMP (with the help of several hard-working contributors). This activity, The Simple Times, will continue. However, The Simple Times will remain independent of my role as NM AD. I will continue to use the appropriate IETF mailing lists in my role as NM AD. I will also use the SNMP mailing list for periodic updates on the NM area. There are many demands on my community service time. By taking the role of NM AD, these other activities are going to suffer, e.g., I probably won't be answering "random" questions on mailing lists. ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" 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, Ted Brunner, Jeff Case, Keith McCloghrie, Dave Perkins, Bob Stewart, and 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. The directorate is currently evaluating several I-Ds, prior to submission to the IESG for standards evaluation: draft-ietf-bridge-objects-01.txt draft-ietf-dns-mibext-05.txt draft-ietf-pppext-bridgemib-01.txt draft-ietf-pppext-ipcpmib-01.txt draft-ietf-pppext-lcpmib-01.txt draft-ietf-pppext-secmib-01.txt draft-ietf-x25mib-ipox25mib-04.txt With the exception of the DNS MIB, which is much larger than the others, I hope to have all of these before the IESG by month's end. ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: SNMPv2 and MIB modules SNMPv2 and MIB modules ---------------------- This topic is being discussed by the NM-Directorate. Until such time as a resolution is reached, here is the interim policy. From now until August 2, 1993: Any MIB module submitted by a WG must use the SNMPv1 SMI (RFCs 1155 and 1212), taking special care to minimize the transformation necessary to use the SNMPv2 SMI. From August 2, 1993 until the SNMPv2 SMI is a draft Internet-standard: All new MIB modules submitted by a WG for standardization must use the SNMPv2 SMI. However, the following SNMPv2 syntaxes may not be used: BIT STRING, 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. Once the SNMPv2 SMI is a draft Internet-standard: All new 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. In addition, from August 2, 1993 onward: 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, in a separate document, for that MIB. ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Working Groups 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(s): Kaj Tesink Consultant:Keith McCloghrie WG mail: atommib@thumper.bellcore.com To Join: atommib-request@thumper.bellcore.com Active: beginning This working group is now chartered. Bridge MIB (bridge) Chair(s): Fred Baker WG mail: bridge-mib@decwrl.dec.com To Join: bridge-mib-request@decwrl.dec.com Active: submitted draft-ietf-bridge-objects-01.txt for draft standard The working group is developing a Source Routing MIB. Character MIB (charmib) Chair(s): Bob Stewart WG mail: char-mib@decwrl.dec.com To Join: char-mib-request@decwrl.dec.com Active: Re-activated Re-activated to evaluate RFCs 1316-1318 with respect to the standards track. Chassis MIB (chassis) Chair(s): Bob Stewart Jeffrey Case WG mail: chassismib@cs.utk.edu To Join: chassismib-request@cs.utk.edu Active: editing draft-ietf-chassis-mib-00.txt The working group met in Columbus and is developing the next version of the draft. DECnet Phase IV MIB (decnetiv) Chair(s): Jon Saperia WG mail: phiv-mib@jove.pa.dec.com To Join: phiv-mib-request@jove.pa.dec.com Active: Re-activated Re-activated to evaluate RFC 1289 with respect to the standards track. FDDI MIB (fddimib) Chair(s): Jeffrey Case WG mail: fddi-mib@cs.utk.edu To Join: fddi-mib-request@cs.utk.edu Active: editing draft-ietf-fddimib-objects-01.txt The working group met in Columbus and is developing the next version of the draft. Host Resources MIB (hostmib) Chair(s): Steven Waldbusser WG mail: hostmib@andrew.cmu.edu To Join: hostmib-request@andrew.cmu.edu Done: final I-D in preparation Consensus reached in the working group, but draft not yet submitted. IEEE 802.3 Hub MIB (hubmib) Chair(s): Keith McCloghrie Donna McMaster WG mail: hubmib@synoptics.com To Join: hubmib-request@synoptics.com Active: editing draft-ietf-hubmib-mau-01.txt The working group met in Columbus and is developing the next version of the draft. In addition, RFC 1368 is now eligible for further evaluation for the standards track. Once the WG finishes the MAU MIB, I'll draft a revision to its charter so that it can work on evaluating RFC 1368 for standards track advancement. Modem Management (modemmgt) Chair(s): Mark S. Lewis Consultant:Steven Waldbusser WG mail: modemmgt@Telebit.com To Join: majordomo@Telebit.com Active: beginning This working group is now chartered. Remote Monitoring (rmonmib) Chair(s): Michael Erlinger WG mail: rmonmib@lexcel.com To Join: rmonmib-request@lexcel.com Inactive: awaiting the next stage for RFC 1271 (proposed standard) The working group is eligible to re-activate now, a charter is being prepared. SNMP Version 2 (snmpv2) Chair(s): Bob Stewart WG mail: snmp2@thumper.bellcore.com To Join: snmp2-request@thumper.bellcore.com Inactive: awaiting the next stage for SNMPv2 RFCs (proposed standard) The I-Ds produced by this WG and the SNMP Security WG were approved by the IESG as proposed standards and are in the process of RFC publication. Because of coordination problems, the SNMPv2 WG will be given responsibility for all the I-Ds, and the SNMP Security WG will be disbanded. Due to demands on my time, I will be unable to continue as editor for these documents. As such, Keith McCloghrie is designated as editor. The working group should re-activate in September. Prior to this, Keith is actioned to prepare re-writes of the ADMIN and SEC documents, to improve readability, but not change technical content. Token Ring Remote Monitoring (trmon) Chair(s): Michael Erlinger WG mail: rmonmib@lexcel.com To Join: rmonmib-request@lexcel.com Active: editing The working group met in Columbus and is developing the next version of the draft. Trunk MIB (trunkmib) Chair(s): Fred Baker Tracy Cox 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 working group should re-activate in June. Uninterruptible Power Supply (upsmib) Chair(s): Jeff Case WG mail: ups-mib@cs.utk.edu To Join: ups-mib-request@cs.utk.edu Active: editing The working group met in Columbus and is developing the next version of the draft. X.25 Management Information Base (x25mib) Chair(s): Dean Throop WG mail: x25mib@dg-rtp.dg.com To Join: x25mib-request@dg-rtp.dg.com Done: submitted draft-ietf-x25mib-ipox25mib-04.txt for proposed standard In May, RFCs 1381, 1382 will be available for further evaluation for the standards track. ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: Other things awaiting work Other things awaiting work -------------------------- Six NM-related BOFs met in Columbus. Five of the six concluded with consensus that a WG should be formed: ATM MIB (atommib) Frame Relay Service MIB (frnetmib) Mail and Directory Management (madman) Modem Management (modemmgt) SNA MIB (snamib) Two of these have already been chartered (atommib and modemmgt). I am in the process of preparing charters for the other three. I hope to have the resulting charters approved by the IESG by month's end. The sixth BOF is E-Mail Management (emailmgt) which is really an IFIP working group (WG6.5) that happens to meet when the IETF meetings, so no further action is needed. The following MIB modules are eligible for further evaluation for the standards track. However, they lack a working group. I will consult with the IESG to charter an "interfaces MIB" working group. RFC 1229 - Extensions to the generic-interface MIB RFC 1231 - IEEE 802.5 Token Ring Interface Type MIB RFC 1304 - SMDS Interface Protocol (SIP) Interface Type MIB I also expect that this WG could deal with evaluating the ether-like MIB (RFC 1398) when it is eligible in July. Here is a list of MIB modules defined by WGs outside of the NM area. This list will be provided to the appropriate AD for action. RFC MIB Module WG Eligible ---- ---------------------------------- ------- -------- 1243 AppleTalk MIB appleip now 1253 OSPF version 2 MIB ospf now 1269 BGP version 3 MIB bgp now 1315 Frame Relay DTE Interface Type MIB iplpdn now 1354 SNMP IP Forwarding Table MIB rreq now 1389 RIPv2 MIB rip2 July 1414 Identification MIB ident August Finally, the work of the multi-protocol SNMP WG will need to be advanced in September. RFC SNMPv1 Mapping WG Eligible ---- ---------------------------------- ------- -------- 1418 SNMP over OSI mpsnmp September 1419 SNMP over AppleTalk mpsnmp September 1420 SNMP over IPX mpsnmp September ------- =_aaaaaaaaaa0--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06324; 18 Apr 93 2:29 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06320; 18 Apr 93 2:29 EDT Received: from aggie.ucdavis.edu by CNRI.Reston.VA.US id aa08237; 18 Apr 93 2:28 EDT Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA00383; Sat, 17 Apr 93 23:08:21 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13432; Sat, 17 Apr 93 23:01:53 -0700 X-Orig-Sender: ietf-ppp-request@ucdavis.edu Received: from PO4.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13315; Sat, 17 Apr 93 22:59:25 -0700 Received: by po4.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Sun, 18 Apr 93 01:56:57 EDT Received: via switchmail; Sun, 18 Apr 1993 01:56:53 -0400 (EDT) Received: from zeus.andrew.cmu.edu via qmail ID ; Sun, 18 Apr 1993 01:56:26 -0400 (EDT) Received: from zeus.andrew.cmu.edu via qmail ID ; Sun, 18 Apr 1993 01:56:25 -0400 (EDT) Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.zeus.andrew.cmu.edu.sun4c.411 via MS.5.6.zeus.andrew.cmu.edu.sun4c_411; Sun, 18 Apr 1993 01:56:25 -0400 (EDT) Resent-Message-Id: Resent-Date: Sun, 18 Apr 1993 01:56:25 -0400 (EDT) Resent-From: Drew Daniel Perkins Resent-To: ietf-ppp@ucdavis.edu Message-Id: Date: Sun, 18 Apr 1993 01:55:32 -0400 (EDT) Sender:ietf-archive-request@cmu.edu From: Drew Daniel Perkins To: Keith Sklower Subject: Re: future assignments of PPP protocol id's. In-Reply-To: <199304152149.OAA25222@vangogh.CS.Berkeley.EDU> References: <199304152149.OAA25222@vangogh.CS.Berkeley.EDU> Keith Sklower writes: > [This begs the numerous PPP protocol id's > less then 600 hex for the protocols themselves > which you wouldn't want to use in ethernet packets > because they might get taken for 802.3 lengths, and > there are already common other numbers for them, > like 800 for IP packets as an ethertype]. > > I also asked Drew Perkins why it was that PPP > protocol id's had an even first byte and an odd > second byte. He said that was so they could be used > as an HDLC two-byte address, but in fact this > was something that was a hedge against a future > day where it might be useful, and wasn't currently > an absolute requirement; if there was a really good > reason to give it up, current implementations > of PPP wouldn't choke. I'm not saying there is > any good reason to give it up right now! > > (If they were used as an HDLC address, you would > need to follow them with a UI, which is currently > not being done). Keith, we somehow miscommunicated. I did NOT say that we wanted to use protocol ids as addresses. What I did try to say is the following: 1. We wanted to have two octet addresses for high-speed links where processing speed was an important criteria and alignment issues might exist. 2. We wanted to have one octet addresses for all important network-layer protocols when used with low-speed links where latency was an important criteria and alignment issues didn't exist. 3. We realized that extensible protocol numbers would solve our problem. 4. We realized that CCITT had an existing methodology for implementing extensible fields, namely using the least-significant bit, and this was already in use by the HDLC address field (which we were supporting). 5. Therefore, it made sense to use the same methodology for our protocol fields as we used for our HDLC address fields. You also mentioned that changing this now would not break any implementations. This is definitely NOT true; it cannot now be changed. Drew Perkins ----------------------------------------------------------------- email: perkins+@cmu.edu 4015 Holiday Park Drive voice: (412) 325-1785 Murrysville, PA 15668 fax: (412) 325-1344   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20261; 19 Apr 93 12:40 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20257; 19 Apr 93 12:40 EDT Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa26829; 19 Apr 93 12:40 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15266; Mon, 19 Apr 1993 23:23:28 +1000 (from owner-Big-Internet) Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15245; Mon, 19 Apr 1993 23:22:04 +1000 (from derich@netcom.com) Received: from netcom.netcom.com by ux1.cso.uiuc.edu with SMTP id AA13725 (5.67a8/IDA-1.5 for ); Mon, 19 Apr 1993 08:19:39 -0500 Received: by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA07877; Mon, 19 Apr 93 06:21:49 -0700 Newsgroups: alt.best.of.internet,alt.bbs.internet,info.big-internet,netcom.internet Path: derich Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Scotty*Tissue Subject: How to buy Internet access? How to set up a Internet site? Message-Id: Followup-To: poster Organization: NETCOM On-line Communication Services (408 241-9760 guest) Date: Mon, 19 Apr 1993 13:21:48 GMT Apparently-To: info-big-internet@ux1.cso.uiuc.edu My dad's law firm would like to obtain Internet access for its own firm, but he would like to know where and how to "buy" Internet access and have the firm's own internet address? Any helpers? Responses to derich@netcom.com or derich@digex.com -- Scott Allen Steinbrink ************************************************ * GO CLEVELAND CAVALIERS!! NBA FINALS '93!!!!!!* NetCom: Derich@netcom.com * GO CLEVELAND INDIANS!!!! WORLD SERIES '93!!!!* Digex: derich@digex.com * GO CLEVELAND BROWNS!!!!! SUPER BOWL '94!!!!!!* ************************************************   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01966; 21 Apr 93 5:44 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01962; 21 Apr 93 5:44 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa03983; 21 Apr 93 5:44 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <07083-0@mhs-relay.cs.wisc.edu>; Wed, 21 Apr 1993 04:21:47 +0000 Received: from ics.uci.edu by cs.wisc.edu; Wed, 21 Apr 93 04:21:34 -0500 Received: from nma.com by q2.ics.uci.edu id ac12712; 21 Apr 93 2:16 PDT Received: from localhost by odin.nma.com id aa28140; 21 Apr 93 0:06 PDT To: Russ Wright Cc: Allan Cargille , ietf-osi-x400ops@cs.wisc.edu Subject: Re: revised postmaster doc, support helpdesk? In-Reply-To: Your message of "Tue, 20 Apr 1993 13:14:56 -0800." <9304202018.AA28990@lbl.gov> Reply-To: Stef@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1993 00:06:35 -0700 Message-Id: <28138.735375995@odin.nma.com> X-Orig-Sender: stef@nma.com I now agree with Russ, having sat on my hands while mulling it over. The msg from ATTHELP helped to clinch it in my mind. What I see coming is a great confusion in the X.400 world as they try to use HELPDESK and ATTHELP and other variations that will degrade the quality of POSTMASTER service. Yes, we are defining a special kind of service, and its quality is of great importantce to us, else we would not bother to publish this RFC. I think we should stand asisde from the X.400 HELPDESK mess, and stick to our Postmasterly Affairs. We can do something about our part of the world, and if we set a good example, others may (or may not) follow. HELPDESK does not imply anything to do with POSTAL SERVICE, and POSTAL SERVICE is what our issue is all about. HELPDESK can mean help for anything on your mind, which may include mail problems too. Cheers...\Stef   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13056; 21 Apr 93 16:08 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13052; 21 Apr 93 16:08 EDT Received: from mhs-relay.cs.wisc.edu by CNRI.Reston.VA.US id aa28356; 21 Apr 93 16:08 EDT Received: from cs.wisc.edu by mhs-relay.cs.wisc.edu with SMTP (PP) id <11042-0@mhs-relay.cs.wisc.edu>; Wed, 21 Apr 1993 15:06:41 +0000 Received: from ics.uci.edu by cs.wisc.edu; Wed, 21 Apr 93 15:06:32 -0500 Received: from nma.com by q2.ics.uci.edu id ab19350; 21 Apr 93 13:01 PDT Received: from localhost by odin.nma.com id aa29131; 21 Apr 93 12:55 PDT To: Allan Cargille Cc: ietf-osi-x400ops@cs.wisc.edu Subject: Re: correct x400ops minutes will be in proceedings In-Reply-To: Your message of "Wed, 21 Apr 1993 11:03:19 -0000." <930421110306*/G=Allan/S=Cargille/OU=cs/O=uw-madison/PRMD=xnren/C=us/@MHS> Reply-To: Stef=x400@nma.com Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Apr 1993 12:55:08 -0700 Message-Id: <29129.735422108@odin.nma.com> X-Orig-Sender: stef@nma.com It seems clear to me tht the IETF Proceedings are really more like a collection of WG/BOF Reports, than WG/BOF Minutes of Record. So, in the EMailMgt BOF case, I simply provided a Report of the BOF, and the Minutes of Record are something else, with more detail for internal use of EMailMgt. We are not confused by calling the IETF Proceedings Report "Minutes". I suggest a similar approach for other WG/BOF "reports" to be included in the IETF Proceedings. Best...\Stef   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03511; 23 Apr 93 9:39 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03507; 23 Apr 93 9:39 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10223; 23 Apr 93 9:39 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03474; 23 Apr 93 9:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03470; 23 Apr 93 9:38 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10199; 23 Apr 93 9:38 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03439; 23 Apr 93 9:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03426; 23 Apr 93 9:37 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10112; 23 Apr 93 9:37 EDT Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa03408; 23 Apr 93 9:37 EDT To: wgchairs@CNRI.Reston.VA.US, bofchairs@CNRI.Reston.VA.US cc: minutes@CNRI.Reston.VA.US X-Orig-Sender:bofchairs-request@IETF.CNRI.Reston.VA.US X-Orig-Sender:iesg-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: minutes@CNRI.Reston.VA.US Subject: Columbus Minutes Final Cut-off - FRIDAY, APRIL 30th Date: Fri, 23 Apr 93 09:37:38 -0400 X-Orig-Sender: dlegare@CNRI.Reston.VA.US Message-ID: <9304230937.aa03408@IETF.CNRI.Reston.VA.US> There are still a number of Chairs who have not turned in Minutes for meetings that were held at the Columbus, Ohio IETF. Late submissions will be accepted until FRIDAY, APRIL 30th. Any Minutes received after that time will not be incorporated in the Proceedings, though an on-line copy will be available in the remote directories. Minutes have not been received for the following groups: Applications Area: All minutes have been received Internet Area: bigaddr (Paul Francis, Chair) rtqos (David Clark, Chair) sip (Christian Huitema and Steve Deering, co-Chairs) Network Management Area: chassis (Bob Stewart, Chair) fddimib (Jeff Case, Chair) hubmib (Keith McCloghrie and Donna McMaster, co-Chairs) upsmib (Jeff Case, Chair) Operational Requirements Area: bgpdepl (Jessica Yu, Chair) netstat (Gene Hastings, Chair) njm (Gene Hastings, Chair) mbone (Matt Mathis, Chair) Routing Area: bgp (Yakov Rekhter, Chair) ipidrp (Sue Hares, Chair) mobileip (Steve Deering, Chair) mospf (Steve Deering, Chair) vcrout (Rob Coltun and Marco Sosa, co-Chairs) Security Area: cipso (Ron Sharp, Chair) ipsec (Al Hoover and Paul Lambert, co-Chairs) Transport and Services Area: avt (Stephen Casner, Chair) User Services Area: All minutes have been received   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08462; 25 Apr 93 23:18 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08458; 25 Apr 93 23:18 EDT Received: from mx2.cac.washington.edu by CNRI.Reston.VA.US id aa07011; 25 Apr 93 23:18 EDT Received: by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26097; Sun, 25 Apr 93 20:06:18 -0700 Errors-To: owner-imap@cac.washington.edu X-Orig-Sender: owner-imap@cac.washington.edu Received: from tomobiki-cho.cac.washington.edu by mx2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA26091; Sun, 25 Apr 93 20:06:17 -0700 Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU (NX5.67c/UW-NDC Revision: 2.26 ) id AA09973; Sun, 25 Apr 93 20:06:13 -0700 Date: Sun, 25 Apr 1993 19:16:03 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Mark Crispin Subject: re: Rich, hierarchical mail object storage in IMAP To: William Chung Cc: IMAP Interest List In-Reply-To: <9304201650.AA0164@WHCHUNG1.watson.ibm.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi William - Thank you for your comments. I'm sorry to have taken so long to reply; this past week has been quite busy... To begin, note that at UW ``mailbox'' and ``folder'' are synonyms, with me (and the IMAP documents) using ``mailbox'' and everyone else using ``folder''. [My co-workers claim that a mailbox is an address that you send mail to, not an entity that you read.] I think that you mean ``folder'' as referring to the entity I call ``a collection of mailboxes'' (and my co- workers call ``a collection of folders''). Please keep this in mind when reading the rest of this message......... There is no presumption in IMAP of ``a UNIX style mail storage area''. In fact, IMAP was originally designed and implemented on a completely different operating system. Nor does IMAP presume that ``mailboxes are stored in a flat fashion with no way to accomodate something like a hierarchial folder tree.'' To my knowledge, IMAP has never been implemented on an operating system with a flat filesystem. IMAP lacks any presumption of the nature of the mail store, beyond a fundamental assumption that a character string can adequately identify a single folder object in the mail store. This is quite intentional. Any greater presumption necessarily limits IMAP to a particular mail store scheme; possibly even to a particular operating system. It was a fundamental design goal of IMAP that there be no such limitations. Recall that IMAP defines only the special name ``INBOX''. All other names are completely up to the particular server implementation. It may well be that certain implementations have chosen to use file path names, but there is no requirement that they do so. What this implies is that any mechanism for folder hierarchy must be external to IMAP. Indeed, there have been any number of individuals who have wished that IMAP solved the folder hierarchy management problem, including in our group at UW. It would make a lot of problems much simpler. However, like most simple solutions, it's *too* simplistic. Gradually, after seeing the extent of the interoperability problem, people have been won over towards the external solution viewpoint. Consider, if you would, how much less attractive IMAP would be to you if a ``UNIX style mail folder hierarchy'' were imposed upon you. Not only wouldn't your preferred model be supported, you'd have to deal with working around a different (perhaps totally hostile) model imposed upon you. It can also be claimed that ``folder structure (hierarchy) is in the mind of the beholder''. There is nothing that prevents a client from imposing its own hierarchical view (context management in the forthcoming new release of Pine is somewhat like this). Similarly, a client can flatten out heirarchy into extinction. Similarly, the management of a server may wish to impose (or eliminate) physical hierarchy of the bits on their disk to suit their operational needs. For example, one can imagine a mailer which recognizes that users Bob, Ted, Carol, and Alice all received a copy of the same message; and instead of giving them each a private copy gave them a pointer to a single shared copy. Such details may be very relevant to the management of a server, but are of no interest to a client. Some work on external hierarchy exists in IMSP (the IMAP support protocol) and in the context management code in the forthoming Pine. I would like to refer you to the IMSP work at CMU for answers to your questions about non-mailbox objects. IMSP is designed to be a layer on top of IMAP that does the tasks that IMAP does not do. The idea is to split the labor and have two smaller tools rather than one monolithic tool. Recently, our friends at CMU have posted some comments about address book implementation in IMSP. Like you, we feel that a distributed address book is very important and certainly have this as a requirement. We just don't have the requirement that IMAP satisfy *all* of the requirements by itself... The reason for this was that I (and others) have become quite wary of monolithic solutions that purport to solve all problems. Such monolithic solutions tend to be unwieldy kludge towers (X.400 comes immediately to mind) that few people understand and fewer implement to any degree. Worse, they tend to ``solve all problems'' by defining out of existance areas of the problem space. [For example, it is easy to put folder hierarchy into IMAP if you define that all file stores now and forever are BSD UNIX.] The combination of IMAP and IMSP addresses a considerable portion of the overall distributed mail problem; although it is conceivable that at some point in the future additional protocols may be necessary (we've already talked about a ``netbiff'' for PC's). I hope that this has satisfactorily answered your concerns. I am quite aware that these issues are complex and the seeming absence of such important functionality in IMAP can be difficult to fathom. Please do not hesitate to contact me if you have any further questions. Regards, -- Mark --   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00595; 28 Apr 93 12:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00578; 28 Apr 93 12:43 EDT Received: from TIS.COM by CNRI.Reston.VA.US id aa15117; 28 Apr 93 12:43 EDT Received: by TIS.COM (4.1/SUN-5.64) id AA02671; Wed, 28 Apr 93 12:44:38 EDT Received: from rodan.UU.NET by TIS.COM (4.1/SUN-5.64) id AA02658; Wed, 28 Apr 93 12:44:36 EDT Received: from relay1.UU.NET by rodan.UU.NET with SMTP (5.61/UUNET-mail-drop) id AA06005; Wed, 28 Apr 93 12:43:23 -0400 Received: from unb.ca (via hermes.csd.unb.ca) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA29424; Wed, 28 Apr 93 12:43:01 -0400 Received: from jupiter.sun.csd.unb.ca by unb.ca (4.1/SMI-4.1-930215-10:45) id AA03295; Wed, 28 Apr 93 13:42:41 ADT Received: by jupiter.sun.csd.unb.ca (4.1/SMI-4.1-930204-14:05) id AA06442; Wed, 28 Apr 93 13:42:39 ADT Newsgroups: info.pem-dev Path: mta.ca!DEDGAR Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: dedgar@mta.ca Subject: The Internet & RSA licences & PKP etc. Message-Id: <1993Apr28.164232.6389@jupiter.sun.csd.unb.ca> Reply-To: dedgar@mta.ca Organization: Mount Allison U, Sackville, N.B. Canada Date: Wed, 28 Apr 1993 16:42:32 GMT Apparently-To: uunet!info-pem-dev@uunet.uu.net X-Orig-Sender: pem-dev-relay@tis.com Hi Could someone please advise me on the legality and licensing status of the RSA Public Key algorythm to the Internet community. RFC's 1421-1424 all include a note about the intended licensing of the algorythms to an organization called Public Key Partners (PKP). Have the terms of PKP's licence been made public. How can one contact them? (Email, Phone) My attempts to call the phone number listed in RFC1170 (the one where PKP promises to make the licence available) did not get through. All help and assistance gratefully appreciated. Dale Edgar Cybernetic Control Inc. DEDGAR@MTA.CA