Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01064; 1 Apr 93 3:37 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01060; 1 Apr 93 3:37 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01504; 1 Apr 93 3:37 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 1 Apr 93 03:37:24 EST Received: from TYO.gate.nec.co.jp by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Thu, 1 Apr 93 03:37:09 EST Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA28204; Thu, 1 Apr 1993 17:36:53 +0900 Received: from nnesv1.nnes.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4J.6) id AA08597; Thu, 1 Apr 1993 17:36:38 +0900 Received: from nnesup.dv4.nnes.nec.co.jp ([133.209.37.47]) by nnesv1.nnes.nec.co.jp (5.65c/6.4J.6-nnes2.1) id AA17039; Thu, 1 Apr 1993 17:36:16 +0900 Received: from localhost by nnesup.dv4.nnes.nec.co.jp (4.1/6.4J.6-nnes-1.1s) id AA12923; Thu, 1 Apr 93 17:33:03 JST Return-Path: Message-Id: <9304010833.AA12923@nnesup.dv4.nnes.nec.co.jp> To: snmp2@thumper.bellcore.com Cc: y-akiyam@dv4.nnes.nec.co.jp Subject: Questions Date: Thu, 01 Apr 93 17:33:02 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: y-akiyam@dv4.nnes.nec.co.jp SNMP v2 forks, I have 2 questions. Please help me. question 1: Is MIB-2(1.3.6.1.2.1) available in the SNMPv2 Protocol? Or will MIB-2 be re-defined for SNMPv2? Does SNMPv2 have compatibility in mib context? question 2: I think people who try to implement SNMPv2 outside USA (like me) must find out some other encryption algorithms other than DES because it's not available outside USA. Any nice idea? The encryption is one of the most important topics about SNMPv2, but if we cannot find out how to replace DES, it becomes less attractive outside USA. Does anyone in the US give a thought about that? How do you guys in other countries consider this? Akiyama, Yoshiyuki (Akiyama is my family name) NEC Corporation. e-mail: y-akiyam@ccs.mt.nec.co.jp y-akiyam@dv4.nnes.nec.co.jp   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03979; 2 Apr 93 12:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03975; 2 Apr 93 12:54 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15902; 2 Apr 93 12:54 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 2 Apr 93 12:54:03 EST Received: from eco.twg.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Fri, 2 Apr 93 12:53:59 EST Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA00888; Fri, 2 Apr 93 12:53:47 -0500 Message-Id: <9304021753.AA00888@eco.twg.com> Date: Fri, 2 Apr 1993 09:52:54 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ed Alcoff - Prod Mtg Subject: Re: Autotopology To: snmp@psi.com, snmp2@thumper.bellcore.com Karl et al, I do recall that there was a flurry of e-mail on this subject about 2 years ago or so, and I do believe the msgs were archived. I think that this may be a good time to revive that discussion, (although the snmp mail groups may or may not be appropriate), in that, those of us with auto-topology functionality in our managers that is based (at least in part) on GET requests, will find that it will probably not work on SNMPv2 agents due to the security aspects. I, for one, would like to see the discussions revived, but the appropriate forum needs to be determined. Regards, Ed Alcoff   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04505; 2 Apr 93 13:53 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04501; 2 Apr 93 13:53 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18414; 2 Apr 93 13:53 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 2 Apr 93 13:52:55 EST Received: from eco.twg.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Fri, 2 Apr 93 13:52:47 EST Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA02241; Fri, 2 Apr 93 13:52:45 -0500 Message-Id: <9304021852.AA02241@eco.twg.com> Date: Fri, 2 Apr 1993 10:51:02 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ed Alcoff - Prod Mtg Subject: Re: Autotopology To: snmp@psi.com, snmp2@thumper.bellcore.com >From: Marshall Midden >Message-Id: <199304021705.AA14660@m.unet.umn.edu> >Subject: Re: Autotopology > >I would encourage that all vendors ship their packages/devices >that do auto-discovery, with the feature OFF. > >Large networks may experience problems with such products and >prohibit their installation. > >Thanks for listening. I can not think of any snmp station vendor that doesn't ship their product with the auto-discovery/ topology function as a user-called option. Ed   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18141; 5 Apr 93 11:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18137; 5 Apr 93 11:34 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05318; 5 Apr 93 11:35 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 5 Apr 93 11:35:06 EDT Received: from CCV1.BBN.COM by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 5 Apr 93 11:35:04 EDT Message-Id: <9304051535.AA13591@thumper.bellcore.com> To: snmp2@thumper.bellcore.com Subject: Need to be removed from list Date: Mon, 05 Apr 93 11:34:54 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ldimaggi@bbn.com Can anyone tell me how to have my name removed from this list? Thanks...   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23100; 6 Apr 93 19:13 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23095; 6 Apr 93 19:13 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27019; 6 Apr 93 19:13 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 6 Apr 93 19:13:34 EDT Received: from kirk.bu.oz.au by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 6 Apr 93 19:13:28 EDT Received: from fiddich.its.bu.oz.au by kirk.bu.oz.au using SMTP (5.65b) id AA08834; Wed, 7 Apr 93 09:12:57 +1000 Return-Path: Received: by fiddich.ITS.BU.OZ.AU (5.65b) id AA11876; Wed, 7 Apr 93 09:12:56 +1000 Date: Wed, 7 Apr 1993 09:05:14 +1000 (EST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "David J. Hughes" Subject: Re: Autotopology To: snmp2@thumper.bellcore.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Glenn Trewitt writes: > The only difficulty with this is that arp tables time out. If you combine subnet sweeps with pings and arp table lookups you should be able to get mac info on hosts that are idle. The only factor is the size of the arp cache on the subnet's router. If a sweep stops pinging after it's received a given number of replies (eg. 10) and snarfs the arp cache of the router, the 10 noders that replied *should* still be listed. Once again this depends on the rate at which entries are timed-out, but it's a step in the right direction. ___ David J. Hughes bambi@bu.oz.au / \ / / / / __/ __ __ ____/ / / __ Senior Network Programmer / \ / \ / \ / / / / / \ / Comms Development & Operation \____/ \__// / \__/ \___/ / / / Qld. 4229 AUSTRALIA (+61 75 951450)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07446; 7 Apr 93 11:35 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07437; 7 Apr 93 11:35 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06053; 7 Apr 93 11:35 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 7 Apr 93 11:35:51 EDT Received: from eco.twg.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 7 Apr 93 11:35:43 EDT Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA15951; Wed, 7 Apr 93 11:35:09 -0400 Message-Id: <9304071535.AA15951@eco.twg.com> Date: Wed, 7 Apr 1993 08:34:39 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ed Alcoff - Prod Mtg Subject: Didn't I Start This? (Was: Autotopology) To: snmp@psi.com, snmp2@thumper.bellcore.com Greetings Once Again, While it does my heart well to see this discussion garner interest, I wonder why I haven't seen any mention or reference to my original post. (Sigh, such is the life of a suit;-() I still maintain that SNMPv2 will break one or more auto-discover/auto-topology implementations due to the security aspects. Has anybody thought of a possible solution? Does anybody care? Anxiously awaiting insight from the world's largest neural network. Ed   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10424; 7 Apr 93 13:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10420; 7 Apr 93 13:48 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10969; 7 Apr 93 13:48 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 7 Apr 93 13:48:42 EDT Received: from MCIGATEWAY.MCIMail.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 7 Apr 93 13:48:38 EDT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id at01090; 7 Apr 93 17:34 GMT Date: Wed, 7 Apr 93 17:34 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Action Motivation <0004367585@mcimail.com> To: Network Management To: Network Management To: Network Management Subject: NETWORK MANAGEMENT SHOWCASE FEATURING LIVE MULTI-VENDOR DEMOS Message-Id: <13930407173431/0004367585NA2EM@mcimail.com> ============================================================= THE THIRD INTERNATIONAL SYMPOSIUM ON INTEGRATED NETWORK MANAGEMENT ============================================================= A UNIQUE OPPORTUNITY TO VIEW FIRST HAND THE LATEST IN NETWORK MANAGEMENT TECHNOLOGY ** WHERE: April 18-23,1993, The Sheraton Palace Hotel, San Francisco, CA ** WHAT: STATE-OF-THE-ART TECHNOLOGY CENTERS demonstrating new and emerging network management technologies, EXPERT SPEAKERS, THOUGHT-PROVOKING PANEL SESSIONS,IN-DEPTH TUTORIALS,TECHNICAL PAPERS - Gary Francis,James Herman, Marshall Rose, and more....... (See Communications Week ad of April 5, p. 48 for more details) ** WHO WILL BE THERE: 40 LEADING VENDORS discussing, demonstrating, and distributing literature about their network management products and capabilities, members of the research, development and academic communities, sophisticated end users, all with the COMMON OBJECTIVE OF MOVING NETWORK MANAGEMENT TECHNOLOGY FORWARD. ** VENDOR DAY: Wednesday, April 21, a full day devoted to Vendor presentations, a unique opportunity to hear directly from the vendor community. ** SHOWCASE FLOOR OPENS TUESDAY, APRIL 20 AT 12:00 P.M. ** LIVE NETWORK -- SEE THE LATEST IN SNMPV2, RMON, OSI, OMNIPOINT, AND NETWORK MANAGEMENT APPLICATIONS. Registration Information: Call +1 415 512 1316 Fax +1 415-512-1325 EMAIL amotive@mcimail.com Network Management Week Discount still available (includes Symposium registration and four Tutorial Sessions), Symposium Registration (excludes Tutorials), SHOWCASE FLOOR PASSES AND SPECIAL VENDOR DAY PASSES ARE AVAILABLE. Sponsored by the International Federation for Information Processing (IFIP) with participation by the Institute of Electrical and Electronics Engineers (IEEE) Communications Society and support from the Institute for Educational Services (IES).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19626; 8 Apr 93 21:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19622; 8 Apr 93 21:38 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa08157; 8 Apr 93 21:38 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 8 Apr 93 21:38:10 EDT Received: from inet-gw-2.pa.dec.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Thu, 8 Apr 93 21:38:08 EDT Received: by inet-gw-2.pa.dec.com; id AA03570; Thu, 8 Apr 93 18:38:02 -0700 Received: by tcpjon.lkg.dec.com (5.57/ULTRIX-fma-071891); id AA09714; Thu, 8 Apr 93 21:41:37 -0400 Message-Id: <9304090141.AA09714@tcpjon.lkg.dec.com> To: snmp@psi.com, snmp2@thumper.bellcore.com Cc: saperia@tcpjon.lkg.dec.com Subject: Didn't I Start This? (Was: Autotopology) Date: Thu, 08 Apr 93 21:41:36 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Jon Saperia X-Mts: smtp Ed Alcoff wrote a few days ago: >> While it does my heart well to see this discussion >> garner interest, I wonder why I haven't seen any >> mention or reference to my original post. (Sigh, >> such is the life of a suit;-() >> >> I still maintain that SNMPv2 will break one or more >> auto-discover/auto-topology implementations due to >> the security aspects. I though that I would take a stab at this since I have not seen anybody else respond. I do not know if I would use the work 'break'. It is true that changes will have to be made. The crux of the question is: can you get from a compliant SNMPv2 entity the information these programs want? I believe the answer is yes. The more important question is can you get the information easily without the management station knowing ahead of time about the existence of all the objects - the reason for doing the discovery in the first place. Once again, I believe that the answer is yes. I have spent the past couple of days talking with a number of people about this issue and believe that a vendor could ship a compliant agent with the entire Internet tree included in the MIB view which is associated with the initial party id. Assuming this takes place, when the management station issues a query (we are obviously assuming noAuth/noPriv here) to the target agent, instance 1 of the party table will be used (initial party ID) which will have all the goodies the auto discovery program wants in its view. Response to the manager from the agent is taken care of since the agent knows the IP address of the manager which sent it the query. The documents offer an example which does not include all of the tree in the initial view which is problematic, there is (at least as far as I have been able to determine) no reason why a vendor could not take a broader view. So the short answer to the question is: Yes code will have to be changed, but there is nothing new or even very problematic about that. The real issue is to create a convention in our industry for SNMPv2 which has essentially the same access to objects as an SNMPv1 agent with a 'public' community string. I raised this issue several times in the past and essentially was told that the best way to deal with this would be once the standard was complete for people to adopt a reasonable default. My suggestion is above. I wrote this because obviously a bunch of us think this is an important issue. I am would be interested to know if I have missed something /jon ------------------------------------------ Jon Saperia, Digital Equipment Corporation Internet: saperia@lkg.dec.com 508-486-5959   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20382; 8 Apr 93 22:49 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20378; 8 Apr 93 22:49 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10012; 8 Apr 93 22:49 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 8 Apr 93 22:49:09 EDT Received: from TYO.gate.nec.co.jp by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Thu, 8 Apr 93 22:48:57 EDT Received: from mailsv.nec.co.jp (mailsv) by TYO.gate.nec.co.jp (5.65c/6.4J.6-TYO_gate) id AA15265; Fri, 9 Apr 1993 11:48:51 +0900 Received: from nnesv1.nnes.nec.co.jp by mailsv.nec.co.jp (5.65c/6.4JAIN) id AA08253; Fri, 9 Apr 1993 11:10:19 +0900 Received: from nnesup.dv4.nnes.nec.co.jp ([133.209.37.47]) by nnesv1.nnes.nec.co.jp (5.65c/6.4J.6-nnes2.1) id AA11344; Fri, 9 Apr 1993 11:09:45 +0900 Received: from localhost by nnesup.dv4.nnes.nec.co.jp (4.1/6.4J.6-nnes-1.1s) id AA20445; Fri, 9 Apr 93 11:10:00 JST Return-Path: Message-Id: <9304090210.AA20445@nnesup.dv4.nnes.nec.co.jp> To: snmp2@thumper.bellcore.com Subject: Re: Questions In-Reply-To: Your message of "Thu, 01 Apr 93 17:33:02 +0900." <9304010833.AA12923@nnesup.dv4.nnes.nec.co.jp> Date: Fri, 09 Apr 93 11:09:59 +0900 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: KINSAN SNMP v2 forks, Thank you all who answeres my question. It seems that I don't understand the situation which surrounds DES well. I'll do some investigation by myself about this matter for a bit, especially Japanese local problems such as exporting laws. BTW, anyone has an answer for my first question, the MIB compatibility between SNMP and SNMPv2. >> question 1: >> >> Is MIB-2(1.3.6.1.2.1) available in the SNMPv2 Protocol? >> Or will MIB-2 be re-defined for SNMPv2? >> Does SNMPv2 have compatibility in mib context? Akiyama Yoshiyuki(Akiyama is my family name.) y-akiyam@ccs.mt.nec.co.jp y-akiyam@dv4.nnes.nec.co.jp P.S It takes some time for me to decode English mails and encode my answer in English. Have pity upon this miserable non-native. :-)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04144; 9 Apr 93 10:11 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04140; 9 Apr 93 10:11 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06322; 9 Apr 93 10:11 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 9 Apr 93 10:11:56 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Fri, 9 Apr 93 10:11:52 EDT Received: by xap.xyplex.com id ; Fri, 9 Apr 93 09:12:39 -0500 Date: Fri, 9 Apr 93 09:12:39 -0500 Message-Id: <9304091412.AA17738@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com In-Reply-To: "Jon Saperia"'s message of Thu, 08 Apr 93 21:41:36 -0400 <9304090141.AA09714@tcpjon.lkg.dec.com> Subject: Re: Didn't I Start This? (Was: Autotopology) Let's not cross post the autotopology discussion to SNMPv2. This is a quiet, sleep working group mailing list, resting after a hard workout. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12920; 12 Apr 93 9:45 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12916; 12 Apr 93 9:45 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14066; 12 Apr 93 9:45 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 12 Apr 93 09:45:25 EDT Received: from nbkanata.Newbridge.COM (NEWBRIDGE.COM) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 12 Apr 93 09:45:22 EDT Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA17041; Mon, 12 Apr 93 10:46:07 EDT Received: by Newbridge.COM (4.0/SMI-4.0) id AA15966; Mon, 12 Apr 93 09:46:03 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Spencer Message-Id: <9304121446.AA15966@Newbridge.COM> Subject: SNMPv2 test tools? To: snmp2@thumper.bellcore.com Date: Mon, 12 Apr 93 9:46:02 EST X-Mailer: ELM [version 2.3 PL8] Hi everyone, I'd like to do some SNMPv2 testing. What I need to do is send SNMPv2 messages from a unix station to an agent at a given IP address. Could anyone point me to an FTP site? Thanks in advance! John Spencer Newbridge Networks jspencer@Newbridge.Com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17053; 12 Apr 93 11:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17049; 12 Apr 93 11:58 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20178; 12 Apr 93 11:58 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 12 Apr 93 11:58:14 EDT Received: from nic.near.net by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 12 Apr 93 11:58:13 EDT Received: from ctron.com by nic.near.net id aa24623; 12 Apr 93 11:58 EDT Received: from ctron (stealth.ctron.com) by ctron.com (4.1/SMI-4.1) id AA24029; Mon, 12 Apr 93 11:58:07 EDT Received: from cardinals.ctron by ctron (4.1/SMI-4.1) id AA23595; Mon, 12 Apr 93 11:58:09 EDT Received: from overload.ctron by cardinals.ctron (4.1/SMI-4.1) id AA13446; Mon, 12 Apr 93 11:58:03 EDT Date: Mon, 12 Apr 93 11:58:03 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Christopher K. Young" Message-Id: <9304121558.AA13446@cardinals.ctron> Received: by overload.ctron (4.1/SMI-4.1) id AA04076; Mon, 12 Apr 93 11:57:50 EDT To: snmp2@thumper.bellcore.com Subject: When do objects get instantiated? In-Reply-To: Mail from 'Mailer-Daemon@gatekeeper.ctron.com Mon Apr 12 11:55:38 1993' dated Mon, 12 Apr 93 11:55:35 EDT I just have to clarify something in the documents: (Don't get worried Bob, I'm not proposing a change, I only need a clarification [end of disclaimer]). The partyAuthProtocol, partyAuthLifetime and partyPrivProtocol read that once the object is instantiated it cannot be modified. Does this mean: a) After a SET request, that if default values are provided by a row in creation that those default values may not be changed by subsequent SET requests? b) That subsequent SET requests can modify those objects (which have defaults provided) but cannot modify the objects after the row is active? In other words do the objects become instantiated when you can get them back in a retrieval or when the row becomes active? If the former then this implies that defaults for these objects can only be provided by a multi-varbind SET. It seems to me that the former is stated but I do not want to be wrong on this. Chris Young   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17257; 12 Apr 93 12:10 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17253; 12 Apr 93 12:10 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20860; 12 Apr 93 12:10 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 12 Apr 93 12:10:48 EDT Received: from vnet.IBM.COM by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 12 Apr 93 12:10:47 EDT Message-Id: <9304121610.AA01450@thumper.bellcore.com> Received: from RALVM25 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 9754; Mon, 12 Apr 93 12:10:53 EDT Date: Mon, 12 Apr 93 12:10:17 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: haverlock@vnet.ibm.com To: snmp2@thumper.bellcore.com Subject: test   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 aa24891; 13 Apr 93 13:37 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24887; 13 Apr 93 13:37 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15589; 13 Apr 93 13:37 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 13 Apr 93 13:37:31 EDT Received: from motgate.mot.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 13 Apr 93 13:37:28 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 AA07992; Tue, 13 Apr 1993 12:37:28 -0500 Received: from isunix.cdx.mot.com by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.12 for ) id AA12318; Tue, 13 Apr 1993 12:37:26 -0500 Received: by isunix.cdx.mot.com (5.57/Ultrix3.0-C) id AA15027; Tue, 13 Apr 93 13:37:23 -0400 Received: by cae.prds.cdx.mot.com ( 5.52 (84)/Spike-2.0) id AA13196; Tue, 13 Apr 93 13:38:04 EDT Date: Tue, 13 Apr 93 13:38:04 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: John Leonard Message-Id: <9304131738.AA13196@cae.prds.cdx.mot.com> To: snmp2@thumper.bellcore.com Subject: SNMPv2 RFCs? I believe I saw an announcement to the effect that the SNMPv2 drafts had been accepted as Proposed Standards by the IAB. Any news on when the RFCs will be released, or am I just being impatient? -------------------------------------------------------------------------- John Leonard johnl@cae.prds.cdx.mot.com (617) 821-7215 LJL007@email.mot.com --------------------------------------------------------------------------   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26563; 13 Apr 93 15:04 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26559; 13 Apr 93 15:04 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa18861; 13 Apr 93 15:04 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-11 #1336) id <01GWYL5EE87K8Y5490@INNOSOFT.COM>; Tue, 13 Apr 1993 11:10:20 PDT Received: from MCIGATEWAY.MCIMail.com by INNOSOFT.COM (PMDF V4.2-11 #1336) id <01GWYL4RWIWG8Y5428@INNOSOFT.COM>; Tue, 13 Apr 1993 11:10:00 PDT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aj11108; 13 Apr 93 17:48 GMT Date: Tue, 13 Apr 1993 17:47 +0000 (GMT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Action Motivation <0004367585@mcimail.com> Subject: Network Management Strategies for the 90's To: NOMS To: OIW Security SIG To: Electronic Mail Management Group To: OIW NMSIG To: Regional Workshop To: ANSI To: MITRE-NADIS To: MITRE-OSI To: MITRE To: OSI Mgt Implementation To: OSI API To: IETF MADMAN To: Network Management To: Network Management To: Network Management Errors-to: ned+madman-errors@INNOSOFT.COM Resent-message-id: <01GWYL5EJOZ68Y5490@INNOSOFT.COM> Message-id: <40930413174704/0004367585NA3EM@mcimail.com> X-VMS-To: IN%"NOMS@tdd.sj.nec.com" "NOMS" Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT -------------------------------------------------------------------------- Network Management Strategies for the 90's -The ISINM '93 Showcase - RMON, SNMPv2, OSI, OMNIPoint, and Applications -------------------------------------------------------------------------- ****THE THIRD INTERNATIONAL SYMPOSIUM ON INTEGRATED NETWORK MANAGEMENT**** **APRIL 18-23, 1993, THE SHERATON PALACE HOTEL, SAN FRANCISCO, CA** Registration Information: CALL +1-415-512-1316 FAX +1-415-512-1325 or EMAIL - amotive@mcimail.com *LEARN how OMNIPoint can benefit you today while ensuring a smooth migration to the future. See the advantages of using a multi-technology, multi-standards approach.* *SEE interoperable RMON implementations by numerous vendors showcasing RMON agents and RMON management station tool sets* *TALK to the SNMPv2 authors and discover how SNMPv2, an evolutionary update to the SNMP framework, provides speed, security, systems management and manager-to-manager communications while continuing to co-exist with the huge installed base of SNMP products.* *DONT' MISS the OSI Technology Center demonstrations which will prove OSI management technology is real and supported by many vendors, service providers, and other organizations. *WATCH for the Applications Technology Center which will demonstrate the integration of independent management applications from many different vendors with each other and with the popular management platforms* ** VENDOR DAY, WEDNESDAY, APRIL 21, A FULL DAY DEVOTED TO VENDOR PRESENTATIONS** - Showcase Floor Passes and Special Vendor Day Passes Are Available Sponsored by the International Federation for Information Processing (IFIP) with participation by the Institute of Electrical and Electronics Engineers (IEEE) Communications Society and support from the Institute for Educational Services (IES).   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25973; 14 Apr 93 11:24 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25969; 14 Apr 93 11:24 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12686; 14 Apr 93 11:24 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 14 Apr 93 11:24:44 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 14 Apr 93 11:24:41 EDT Received: by xap.xyplex.com id ; Wed, 14 Apr 93 10:25:18 -0500 Date: Wed, 14 Apr 93 10:25:18 -0500 Message-Id: <9304141525.AA24459@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com In-Reply-To: "Christopher K. Young"'s message of Mon, 12 Apr 93 11:58:03 EDT <9304121558.AA13446@cardinals.ctron> Subject: Re: When do objects get instantiated? Chris asked for a clarification. He deserves one. I don't have one. If somebody doesn't raise a hand, I'll start calling on people. :-)} Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26048; 14 Apr 93 11:28 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26044; 14 Apr 93 11:28 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12763; 14 Apr 93 11:28 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 14 Apr 93 11:28:13 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 14 Apr 93 11:28:11 EDT Received: by xap.xyplex.com id ; Wed, 14 Apr 93 10:28:48 -0500 Date: Wed, 14 Apr 93 10:28:48 -0500 Message-Id: <9304141528.AA24542@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com In-Reply-To: Eric Schekkerman's message of Tue, 13 Apr 93 11:12:55 +0200 <9304130912.AA08556@utis83.cs.utwente.nl> Subject: Re: Errors in the standards Note that I removed the cross post to snmp-sec-dev. We should keep ALL SNMPv2 questions and comments on the SNMPv2 list now. I'll send a separate message to snmp-sec-dev in case anyone is on it and not here. Eric pointed out some apparent errors. If they are errors, we need to note a correction to be made when we go to Draft Standard. If they aren't we may need a clarification. In any case, Eric deserves an answer. Someone speak up. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27570; 19 Apr 93 18:42 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27566; 19 Apr 93 18:42 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12011; 19 Apr 93 18:42 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 19 Apr 93 18:42:55 EDT Received: from vnet.IBM.COM by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 19 Apr 93 18:42:53 EDT Message-Id: <9304192242.AA09611@thumper.bellcore.com> Received: from UITVM1 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 9314; Mon, 19 Apr 93 18:42:56 EDT Date: Tue, 20 Apr 93 00:42:15 CET Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Bert Wijnen (+31-2975-53316)" To: snmp2@thumper.bellcore.com Subject: SNMPv2 Protocol Operations I am looking at Dec 92 draft, so maybe it has been corrected already. Section 4.2 Page 13, 3rd pragraph states that there is no limit to the number of varBinds. However, Page 9 and 11 do define a "maxbindings". I assume that this limit DOES apply on page 13 also. Bert.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28595; 19 Apr 93 20:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28591; 19 Apr 93 20:57 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15881; 19 Apr 93 20:57 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 19 Apr 93 20:57:21 EDT Received: from TWNMOE10.EDU.TW by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 19 Apr 93 20:57:06 EDT Received: from comserv.itri.org.tw by TWNMOE10.EDU.TW (IBM VM SMTP V2R2) with TCP; Tue, 20 Apr 93 08:57:36 EST Received: by comserv.itri.org.tw (th3.8sx) from e0sun3 (e0sun3.ccl.itri.org.tw) id AA29829; Tue, 20 Apr 93 08:54:58 CST Received: from e0sun34.ccl.itri.org.tw by e0sun3 (4.1/SMI-4.1) id AA10003; Tue, 20 Apr 93 08:57:34 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hung-Fa Sun Message-Id: <9304200057.AA10003@e0sun3> Subject: Questions on adminv2-03 To: snmp2@thumper.bellcore.com Date: Tue, 20 Apr 1993 08:57:34 +0800 (WST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1563 In adminv2-03, on page 13, For each SnmpPrivMsg value that represents a SNMPv2 private management communication, the following statements are true: (delete a couple of lines) o Its privData component is called the privacy data and represents the (possibly encrypted) serialization (according to the conventions of [5]) of a SNMPv2 authenticated management communication (see Section 2.10). Question: I can understand why SnmpAuthMsg may be encrypted, but why it need serialization? On page 20, (15) The management communication class is determined from the ASN.1 tag value associated with the PDUs component of the SnmpMgmtCom value. If the management information class of the received message is either 32, 8, 2, or 1 (i.e., GetBulk, Set, GetNext or Get) and the SNMPv2 context is not realized by the local SNMPv2 entity, then the received message is discarded without further processing, after the snmpStatsUnknownContexts counter [7] is incremented. Question: What means "the SNMPv2 context is not realized by the local SNMPv2 entity"? Does it say "SNMPv2 context is absent from the local database of context information"? If it yes, then there is some mix up between the procedure (13) and (15), and the error counter should be snmpStatsBadOperations instead of snmpStatsUnknownContexts. Thanks in advance for clearify my questions. -- Frank Hung-Fa Sun Computer & Comm. Research Lab. /ITRI Internet: sunh@e0sun3.ccl.itri.org.tw Voice: (886-035)917255, FAX: 820098   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12297; 23 Apr 93 16:47 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12293; 23 Apr 93 16:47 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27422; 23 Apr 93 16:47 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 23 Apr 93 16:47:13 EDT Received: from zeus.ci.ua.pt ([192.80.21.201]) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Fri, 23 Apr 93 16:46:32 EDT Message-Id: <9304232046.AA18567@thumper.bellcore.com> Received: by zeus.ci.ua.pt (15.11/15.6) id AA00413; Fri, 23 Apr 93 15:41:52 pst Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "A.CARVALHO" Subject: submission To: snmp2@thumper.bellcore.com Date: Fri, 23 Apr 93 15:41:50 PST Cc: apc@zeus.ci.ua.pt Mailer: Elm [revision: 64.9] I want to submit to snmpv2 working group my e-mail is apc@greco.inesca.pt thanks Abilio A. P. Carvalho   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12381; 23 Apr 93 16:48 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12375; 23 Apr 93 16:48 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27463; 23 Apr 93 16:48 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 23 Apr 93 16:48:43 EDT Received: from zeus.ci.ua.pt ([192.80.21.201]) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Fri, 23 Apr 93 16:48:00 EDT Message-Id: <9304232048.AA18689@thumper.bellcore.com> Received: by zeus.ci.ua.pt (15.11/15.6) id AA00564; Fri, 23 Apr 93 16:00:25 pst Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "A.CARVALHO" Subject: submissition correction To: snmp2@thumper.bellcore.com Date: Fri, 23 Apr 93 16:00:23 PST Cc: apc@zeus.ci.ua.pt, apc@greco.inesca.pt Mailer: Elm [revision: 64.9] In the last message I have send, where is Working Group should be read mailling list sorry for the mistake. Abilio A. P. Carvalho (apc@greco.inesca.pt or apc@ua.pt )   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00897; 27 Apr 93 7:43 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00893; 27 Apr 93 7:43 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa12353; 27 Apr 93 7:43 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 27 Apr 93 07:43:11 EDT Received: from sun4.iol.unh.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 27 Apr 93 07:43:09 EDT Received: by sun4.iol.unh.edu (4.1/SMI-4.1) id AA22804; Tue, 27 Apr 93 07:38:10 EDT Date: Tue, 27 Apr 93 07:38:10 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "James B. Harville" Message-Id: <9304271138.AA22804@sun4.iol.unh.edu> To: snmp2@thumper.bellcore.com Subject: GetBulkRequest PDU Usage I would like to clarify my understanding of the GetBulkRequest-PDU as it applies to the efficient retrieval of large tables. It appears that it does not provide the functionality that was intended. For a dynamic table where the number of row entries is varying greaty, if I set max-repetitions to a small number, an entity acting in a manager role will have to make numerous requests to obtain all table information. However, if max-repetitions is set to a large number, additional information (up to max-repitions) outside of the requested table information will be delivered. The question is how do you know what to set max-repetitions to in order to obtain an efficient retrieval of dynamic tables when too small of a number means more GetBulkRequests are sent and too large of a number means extra unwanted objects are retrieved? Jim   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07531; 27 Apr 93 13:15 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07527; 27 Apr 93 13:15 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05028; 27 Apr 93 13:15 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 27 Apr 93 13:15:33 EDT Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 27 Apr 93 13:15:30 EDT Received: by xap.xyplex.com id ; Tue, 27 Apr 93 12:15:34 -0500 Date: Tue, 27 Apr 93 12:15:34 -0500 Message-Id: <9304271715.AA28092@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com In-Reply-To: Keith McCloghrie's message of Wed, 21 Apr 93 23:22:29 PDT <9304220622.AA10167@nms.hls.com> Subject: Re: Questions on adminv2-03 Keith said: >privData has the syntax OCTET STRING. SnmpAuthMsg is defined as an >ASN.1 SEQUENCE. The result of serializing (i.e., encoding according >to the Basic Encoding Rules) a SEQUENCE produces an OCTET STRING. >Thus, the serialization of an SnmpAuthMsg produces an OCTET STRING >to be used as the value of privData. Aha! I always wondered what "serialize" meant. I bet I'm not the only one who sometimes suspects portions of the SNMP specs are written in secret code. I know we're going to get an editorial rewrite of part of the security stuff. I hope this is part of that. SNMP may be simple, but it's documentation isn't. The WG chairman oughta do something. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06813; 29 Apr 93 10:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06808; 29 Apr 93 10:53 EDT Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15388; 29 Apr 93 10:53 EDT Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 29 Apr 93 10:53:56 EDT Received: from nic.near.net by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Thu, 29 Apr 93 10:53:54 EDT Received: from ctron.com by nic.near.net id aa27899; 29 Apr 93 10:53 EDT Received: from ctron (stealth.ctron.com) by ctron.com (4.1/SMI-4.1) id AA18949; Thu, 29 Apr 93 10:53:45 EDT Received: from cardinals.ctron by ctron (4.1/SMI-4.1) id AA15988; Thu, 29 Apr 93 10:53:47 EDT Received: from overload.ctron by cardinals.ctron (4.1/SMI-4.1) id AA12847; Thu, 29 Apr 93 10:53:46 EDT Date: Thu, 29 Apr 93 10:53:46 EDT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Christopher K. Young" Message-Id: <9304291453.AA12847@cardinals.ctron> Received: by overload.ctron (4.1/SMI-4.1) id AA01365; Thu, 29 Apr 93 10:51:53 EDT To: snmp2@thumper.bellcore.com Subject: Re: When do objects get instantiated? In-Reply-To: Mail from 'bcruucp@thumper.bellcore.com Mon Apr 12 12:17:29 1993' dated Mon, 12 Apr 93 11:58:03 EDT I don't won't to seem rude but I think maybe this has either gone unattended as obvious or just forgotten as busy schedules eat time. But I thought I would resend and see if I have beter luck. Chris > > The partyAuthProtocol, partyAuthLifetime and partyPrivProtocol read > that once the object is instantiated it cannot be modified. > > Does this mean: > > a) After a SET request, that if default values are provided by a > row in creation that those default values may not be changed > by subsequent SET requests? > > b) That subsequent SET requests can modify those objects (which > have defaults provided) but cannot modify the objects after > the row is active? > > In other words do the objects become instantiated when you can get > them back in a retrieval or when the row becomes active? If the > former then this implies that defaults for these objects can only > be provided by a multi-varbind SET. > > It seems to me that the former is stated but I do not want to be > wrong on this.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00514; 2 Mar 93 5:52 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00510; 2 Mar 93 5:52 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa01907; 2 Mar 93 5:52 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 2 Mar 93 05:52:43 EST Received: from survis.surfnet.nl by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 2 Mar 93 05:52:33 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