Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06623; 4 Jan 93 0:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06619; 4 Jan 93 0:29 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27472; 4 Jan 93 0:30 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 4 Jan 93 00:29:55 EST Received: from uu2.psi.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 4 Jan 93 00:29:53 EST Received: from port6.li.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA26963; Mon, 4 Jan 93 00:26:17 -0500 Date: Mon, 4 Jan 93 00:26:17 -0500 Message-Id: <9301040526.AA26963@uu2.psi.com> To: snmp2@thumper.bellcore.com Subject: Going out on a limb Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Lance Sprung Reply-To: sprung@sys.smc.com Hi Everyone! I've been sitting back watching the massive amount of SNMP2 activity. Just want to let you all know that you're doing a great job! Now, I'm probably going out on a limb asking this very basic question, but who better to ask than the SNMP experts (right?). While discussing the topic of network management simplicity, from the "users" perspective, we were curious about something. Here it goes: It seems that management applications which implement "help" functionality (defined here as a function which enables the user to obtain some textual description about a MIB object), do so primarily by displaying the text contained in the "DESCRIPTION" clause associated with that object. However, while most developers and engineers understand the definitions contained in the "DESCRIPTION" clause, I am under the impression that many end-users sometimes find the wording contained in RFC's confusing (I don't think examples are necessary here). Has anyone considered the possibility of adding an additional Description clause so that AGENT vendors can add additional information to the "Standard" descriptions of agents? This way, when a user asks a management application for "HELP", they would find themselves presented with both the standard description as well as the Vendor-extended description. So, what do you think? worded,   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17508; 4 Jan 93 15:35 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17504; 4 Jan 93 15:35 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22356; 4 Jan 93 15:35 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 4 Jan 93 15:35:41 EST Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 4 Jan 93 15:35:36 EST Received: by xap.xyplex.com id ; Mon, 4 Jan 93 18:35:27 -0500 Date: Mon, 4 Jan 93 18:35:27 -0500 Message-Id: <9301042335.AA15566@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com In-Reply-To: Marshall Rose's message of Thu, 31 Dec 1992 19:50:22 -0800 <7728.725860222@dbc.mtview.ca.us> Subject: Re: A couple of typos in the TC document I'd say that those particular typos constitute bugs to be fixed. The additional note is more questionable. It's an optimization, and I'm not sure I understand it. If the NMS does as suggested, and the row has been deleted or not, what happens? Is it talking about while I was creating the row and it was notInService, or later, after the row was activated? I'm not convinced that there was a problem here that has now been fixed. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17632; 4 Jan 93 15:39 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17628; 4 Jan 93 15:39 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22574; 4 Jan 93 15:39 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 4 Jan 93 15:39:27 EST Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 4 Jan 93 15:39:18 EST Received: by xap.xyplex.com id ; Mon, 4 Jan 93 18:38:21 -0500 Date: Mon, 4 Jan 93 18:38:21 -0500 Message-Id: <9301042338.AA15602@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com In-Reply-To: Marshall Rose's message of Sat, 02 Jan 1993 17:31:20 -0800 <19901.726024680@dbc.mtview.ca.us> Subject: Re: V2->V1 proxy of inform requests Not specifying necessary operation is a bug. Your suggested resolution sounds appropriate to me. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17927; 4 Jan 93 15:49 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17920; 4 Jan 93 15:49 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23402; 4 Jan 93 15:49 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 4 Jan 93 15:49:34 EST Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 4 Jan 93 15:49:26 EST Received: by xap.xyplex.com id ; Mon, 4 Jan 93 18:49:18 -0500 Date: Mon, 4 Jan 93 18:49:18 -0500 Message-Id: <9301042349.AA15683@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com In-Reply-To: (Lance Sprung's message of Mon, 4 Jan 93 00:26:17 -0500 <9301040526.AA26963@uu2.psi.com> Subject: Re: Going out on a limb Sawing the limb off... :-)} The polite answer: You're right, the DESCRIPTION clause is not suitable for user help. We discussed various ideas along the line you suggest, and decided there is lot of work we can do in the future to improve network management systems by providing information in a standardized form, but that's not appropriate to what we need to finish now. The less polite answer (still smiling): We're at a point where such suggestions are not appropriate, since all we're supposed to be doing now is fixing bugs. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19309; 4 Jan 93 16:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19303; 4 Jan 93 16:28 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa25316; 4 Jan 93 16:28 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 4 Jan 93 16:28:21 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 4 Jan 93 16:28:17 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA04116; Mon, 4 Jan 93 13:26:43 -0800 To: Bob Stewart Reply-To: snmp2@thumper.bellcore.com Cc: snmp2@thumper.bellcore.com Subject: Re: A couple of typos in the TC document In-Reply-To: Your message of "Mon, 04 Jan 1993 18:35:27 EST." <9301042335.AA15566@xap.xyplex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Jan 1993 13:26:42 -0800 Message-Id: <4114.726182802@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose > The additional note is more questionable. It's an optimization, and I'm not > sure I understand it. If the NMS does as suggested, and the row has been > deleted or not, what happens? Is it talking about while I was creating the > row and it was notInService, or later, after the row was activated? I'm not > convinced that there was a problem here that has now been fixed. The additional note doesn't fix a problem, 'cause a problem doesn't exist. Rather it gives a hint to someone writing a management application how, if they worry about a certain kind of interaction, they can have the status column detect it for them. This note is along the lines of additional information... /mtr ps: makes no difference to me whether it goes in, but it does no harm as far as I can see...   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20335; 4 Jan 93 17:05 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20331; 4 Jan 93 17:05 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa26837; 4 Jan 93 17:05 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 4 Jan 93 17:05:22 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 4 Jan 93 17:05:18 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA04720; Mon, 4 Jan 93 14:03:58 -0800 To: snmp2@thumper.bellcore.com Subject: Typo in definition of Display string Reply-To: snmp2@thumper.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Jan 1993 14:03:57 -0800 Message-Id: <4717.726185037@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose The definition of DisplayString is DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. Any object defined using this syntax may not exceed 255 characters in length." SYNTAX OCTET STRING the last line really should be SYNTAX OCTET STRING (SIZE (0..255)) instead. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21807; 4 Jan 93 18:17 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21803; 4 Jan 93 18:17 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa29447; 4 Jan 93 18:18 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 4 Jan 93 18:17:42 EST Received: from TGV.COM (HQ.TGV.COM) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 4 Jan 93 18:17:40 EST Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ; Mon, 4 Jan 93 15:17:33 PST Received: from karl.mongo-jr.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1) id AA00550; Mon, 4 Jan 93 15:19:30 PST Date: Mon, 4 Jan 93 15:19:30 PST Message-Id: <9301042319.AA00550@mel-brooks.empirical.com> To: snmp2@thumper.bellcore.com Subject: Re: Typo in definition of Display string Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Karl Auerbach, Empirical Tools and Technologies, 408/427-5280" Reply-To: karl@empirical.com Cc: snmp2@thumper.bellcore.com X-Orig-Sender: karl@mel-brooks.empirical.com Repository: empirical.com Originating-Client: mongo-jr.empirical.com Given the number of agents which mis-do display strings (e.g. they send an individual newline rather than cr+lf as required by NVT, or they tack on a null byte at the end) it might be worth a footnote emphasising that those sorts of things are *not* legal NVT. Yes, that would be non-essential, redundant text. But it might save some problems in the future. --karl-- > The definition of DisplayString is > > DisplayString ::= TEXTUAL-CONVENTION > DISPLAY-HINT "255a" > STATUS current > DESCRIPTION > "Represents textual information taken from the NVT > ASCII character set, as defined in pages 4, 10-11 > of RFC 854. Any object defined using this syntax > may not exceed 255 characters in length." > SYNTAX OCTET STRING > > the last line really should be > > SYNTAX OCTET STRING (SIZE (0..255)) > > instead.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23214; 4 Jan 93 22:28 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23210; 4 Jan 93 22:28 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05562; 4 Jan 93 22:29 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Mon, 4 Jan 93 22:29:00 EST Received: from asavax.asa.org by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Mon, 4 Jan 93 22:28:59 EST Date: Tue, 5 Jan 1993 3:27:05 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Faulhaber Message-Id: <930105032705.419@asa.org> Subject: Unsubscribe To: snmp2@thumper.bellcore.com X-Vmsmail-To: SMTP%"snmp2@thumper.bellcore.com" UNSUBSCRIBE SNMP2 Robert J. Faulhaber   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03305; 5 Jan 93 11:06 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03295; 5 Jan 93 11:06 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa06406; 5 Jan 93 11:07 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 5 Jan 93 11:05:43 EST Received: from colossus.apple.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 5 Jan 93 11:05:41 EST Received: from [17.130.8.47] by colossus.apple.com with SMTP (5.65/7-Aug-1992-eef) id AA07797; Tue, 5 Jan 93 08:00:17 -0800 for Received: by alink-gw.apple.com (5.65/27-Sep-1991-eef) id AA27847; Tue, 5 Jan 93 07:45:20 -0800 for Date: 05 Jan 93 15:43 GMT Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "ER&D - ODA, G Holzhauer" Subject: help To: SNMP2@thumper.bellcore.com Message-Id: <726248733.2600034@AppleLink.Apple.COM> Hi, could you please add me to the SNMP version2 mailing list? Thanks a lot, Gerd Holzhauer, Apple Computer, ER&D, E-Mail adress: Holzhauer1@applelink.apple.com Tel: (+33 1) 4901 4704   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09972; 5 Jan 93 16:51 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09967; 5 Jan 93 16:51 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18362; 5 Jan 93 16:51 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 5 Jan 93 16:51:33 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 5 Jan 93 16:51:29 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA17938; Tue, 5 Jan 93 13:50:08 -0800 To: snmp2@thumper.bellcore.com Subject: Another typo in RowStatus Reply-To: snmp2@thumper.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Jan 1993 13:50:07 -0800 Message-Id: <17937.726270607@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose In the state table, in the cell for ACTION = set status column to notInService STATE = status column is not ready the current result is inconsistentValue. This is wrong it should be inconsistentValue or see 4 ->C where 4 is if other variable bindings, included in the same PDU, provide values for all columns which are missing but required, then noError is returned and state C is entered. This makes it analogous with the behavior of the ACTION = set status column to active STATE = status column is not ready cell. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10198; 5 Jan 93 17:08 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10190; 5 Jan 93 17:08 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa18879; 5 Jan 93 17:09 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 5 Jan 93 17:09:14 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 5 Jan 93 17:09:08 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA18099; Tue, 5 Jan 93 14:07:49 -0800 To: snmp2@thumper.bellcore.com Subject: Something unexpected... Reply-To: snmp2@thumper.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Jan 1993 14:07:47 -0800 Message-Id: <18098.726271667@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose Over the last few weeks, a few of us have been busy implementing the current drafts, especially the new security stuff. (This experience has been the source of most of the "typo" messages I've been sending.) Anyway, we found something that isn't a typo. We need--gasp--another error code for the set operation. Here's the scenario, a packet has come in, eventually we get past the access policy check and we decide to perform the set operation. Now suppose that: - one of the variables refers to an instance that doesn't exist; but, - the agent does allow instances of that type to be created; but, - the agent refuses to create the specific instance requested. For example, if you try to create an entry in the access control table, the instance-identifier is derived from the identities of a couple of parties. If those parties do not exist, the agent may decline creating that instance. Or, an even simpler example, suppose the request tries to set "ipForwarding.1" an instance which can never exist. There is no error code that covers this scenario. The three closest are: noAccess: the variable is outside the MIB view for the SNMP operation noCreation: the variable doesn't exist, and the agent isn't able to create instances of the corresponding object type notWritable: the variable does exist, but the agent isn't able to modify instances of the corresponding object type But none of them really apply, so, I think we need a new error code. I propose inconsistentName: the variable doesn't exist, and the agent is able to create instances of the corresponding object type, but the name provided is presently inconsistent . Comments? /mtr ps: Bob, am I out of scope?   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16490; 5 Jan 93 22:19 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16486; 5 Jan 93 22:18 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa27826; 5 Jan 93 22:19 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 5 Jan 93 22:19:28 EST Received: from synoptics.com (mvis1.synoptics.com) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 5 Jan 93 22:19:26 EST Received: from immer (immer.synoptics.com) by synoptics.com (4.1/SMI-4.1) id AA00289; Tue, 5 Jan 93 19:17:31 PST Received: by immer (4.1/2.0N) id AA03140; Tue, 5 Jan 93 19:18:14 PST Message-Id: <9301060318.AA03140@immer> Date: Tue, 5 Jan 93 19:18:14 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: David Perkins To: snmp2@thumper.bellcore.com Subject: Re: Typo in definition of Display string Marshall, Doing the change below would break my MIB compiler, but since I will be rewriting it anyway, it is not a problem as long as there is an answer to the following question. SMIC checks where a TC is used to see if a SIZE/RANGE clause is given. If so, it checks to see how the TC was defined. If the TC is defined with a SIZE/RANGE clause, then it flags it as an error. (Also, since TCs can be defined on TCs, for example MyDisplayString is defined as DisplayString, it also follows the chain of TCs back until the base syntax, or a TC on the chain with a SIZE/RANGE.) So the question is, what should be the correct behavior when a SIZE/RANGE is specified when the TC is used, but the TC has a SIZE/RANGE specified in it's definition? Does it make a difference if the SIZE/RANGE clause is the same, "smaller", "larger", etc? > The definition of DisplayString is > > DisplayString ::= TEXTUAL-CONVENTION > DISPLAY-HINT "255a" > STATUS current > DESCRIPTION > "Represents textual information taken from the NVT > ASCII character set, as defined in pages 4, 10-11 > of RFC 854. Any object defined using this syntax > may not exceed 255 characters in length." > SYNTAX OCTET STRING > > the last line really should be > > SYNTAX OCTET STRING (SIZE (0..255)) > > instead. > /dave perkins, synoptics, 408-764-1516   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16527; 5 Jan 93 22:29 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16523; 5 Jan 93 22:29 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa28189; 5 Jan 93 22:30 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 5 Jan 93 22:30:18 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 5 Jan 93 22:30:15 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA20817; Tue, 5 Jan 93 19:28:46 -0800 To: David Perkins Reply-To: snmp2@thumper.bellcore.com Cc: snmp2@thumper.bellcore.com Subject: Re: Typo in definition of Display string In-Reply-To: Your message of "Tue, 05 Jan 1993 19:18:14 PST." <9301060318.AA03140@immer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Jan 1993 19:28:44 -0800 Message-Id: <20814.726290924@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose I think the text on syntax refinement is pretty clear on what the rules are for subtyping. In the case of a string-valued syntax, you should expect the bounds of the size to be reduced. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08048; 6 Jan 93 14:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08044; 6 Jan 93 14:43 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20387; 6 Jan 93 14:43 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 6 Jan 93 14:43:40 EST Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 6 Jan 93 14:43:37 EST Received: by xap.xyplex.com id ; Wed, 6 Jan 93 14:42:13 -0500 Date: Wed, 6 Jan 93 14:42:13 -0500 Message-Id: <9301061942.AA01388@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com In-Reply-To: Marshall Rose's message of Tue, 05 Jan 1993 14:07:47 -0800 <18098.726271667@dbc.mtview.ca.us> Subject: Re: Something unexpected... Yesterday Marshall said that we have a problem that requires a new error code. Nobody said a word. Unless somebody objects soon, I'll assume that means we agree with his suggested fix. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09108; 6 Jan 93 15:40 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09104; 6 Jan 93 15:40 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22832; 6 Jan 93 15:40 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 6 Jan 93 15:40:34 EST Received: from eco.twg.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 6 Jan 93 15:40:22 EST Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $) id AA05208; Wed, 6 Jan 93 15:37:36 -0500 Message-Id: <9301062037.AA05208@eco.twg.com> Date: Wed, 6 Jan 1993 12:37:41 -0800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ed Alcoff - Prod Mtg Subject: Re: Something unexpected... To: snmp2@thumper.bellcore.com Why can't we expand the meaning of "notWritable" to cover this occurence? It seems to be the closest acceptable one w/o having to create a new one. Just one suit's thoughts, Ed Alcoff   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09298; 6 Jan 93 15:58 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09294; 6 Jan 93 15:58 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23508; 6 Jan 93 15:59 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 6 Jan 93 15:59:09 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 6 Jan 93 15:59:05 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA29034; Wed, 6 Jan 93 12:57:08 -0800 To: Ed Alcoff - Prod Mtg Reply-To: snmp2@thumper.bellcore.com Cc: snmp2@thumper.bellcore.com Subject: Re: Something unexpected... In-Reply-To: Your message of "Wed, 06 Jan 1993 12:37:41 PST." <9301062037.AA05208@eco.twg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Jan 1993 12:57:00 -0800 Message-Id: <29028.726353820@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose In the original SNMP, there was an error code called badValue. It could mean any of the following SNMPv2 codes: wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), notWritable(17) Why did we take one code and turn it into 10? The reason was that badValue was AMBIGUOUS. When a management station got it, it didn't know if the error was a permanent thing, a transient thing, or a "what we have here is a failure to communicate" thing. As a result, interoperability sufferred. At present, if I get back a notWritable, it is saying to me that the agent can--under no circumstances--write this instance. The situation I described yesterday is along the lines of "I can write this object but I can't create the instance you specified at this time." These are distinctive conditions and mixing them in one error code won't be of help to anyone. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11311; 6 Jan 93 17:39 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11307; 6 Jan 93 17:39 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa02433; 6 Jan 93 17:40 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 6 Jan 93 17:40:08 EST Received: from gateway.gtech.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 6 Jan 93 17:40:07 EST Received: from ops.soft.gtech.com ([192.69.165.186]) by gateway.gtech.com with SMTP id <30726>; Wed, 6 Jan 1993 17:37:05 -0500 Received: by ops.soft.gtech.com (16.6/2.05-R); id AA01701 for snmp2@thumper.bellcore.com; Wed, 6 Jan 93 17:37:59 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Aleksey Y. Romanov" Message-Id: <9301062237.AA01701@ops.soft.gtech.com> Subject: Re: Something unexpected To: snmp2@thumper.bellcore.com Date: Wed, 6 Jan 1993 17:37:59 -0500 Mailer: Elm [revision: 66.25] > > Why did we take one code and turn it into 10? The reason was that It seems to me that real number is 5. But it does not matter. > badValue was AMBIGUOUS. When a management station got it, it didn't > know if the error was a permanent thing, a transient thing, or a > "what we have here is a failure to communicate" thing. As a result, > interoperability sufferred. The new ambigious error code was introduced since that time: inconsistentValue It covers three diffrent sources of errors. > These are distinctive conditions and mixing them in one error code won't > be of help to anyone. Yes we have to add the proposed error code. If we will start to discuss error code mapping why not to look into the problem once more and split inconsistentValue into three separate codes, add code for locked variable, add code for MIB specific inconsistensy ? > > /mtr > Aleksey   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24083; 16 Jan 93 0:04 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24079; 16 Jan 93 0:04 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa03358; 16 Jan 93 0:05 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Sat, 16 Jan 93 00:05:22 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Sat, 16 Jan 93 00:05:18 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA22096; Fri, 15 Jan 93 21:03:56 -0800 To: snmp2@thumper.bellcore.com Subject: New SNMP Security I-Ds Reply-To: snmp2@thumper.bellcore.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Jan 1993 21:03:55 -0800 Message-Id: <22095.727160635@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose New drafts have been posted to the I-D area reflecting work, but not necessarily concensus, in the SNMP Security working group. The three primary documents are: draft-ietf-snmpsec-adminv2-01.txt draft-ietf-snmpsec-partyv2-01.txt draft-ietf-snmpsec-secv2-01.txt There are also three documents which are modified versions of documents from the SNMPv2 working group: draft-ietf-snmpsec-protov2-00.txt text of trap generation modified to reference a context referring to a MIB view. draft-ietf-snmpsec-mibv2-00.txt unchanged from 12/15 - adds a new object for counting unknown contexts. draft-ietf-snmpsec-tmv2-00.txt unchanged from 12/15 - removes the RestartDomain and EntityDomain transport mappings as their functionality is moved to to the "context" concept defined in the admin document. When the SNMP Security working group reaches closure, we'll have to discuss the changes in these three documents. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07734; 21 Jan 93 15:57 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07730; 21 Jan 93 15:57 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa15539; 21 Jan 93 15:59 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 21 Jan 93 15:58:41 EST Received: from dexter.bellcore.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Thu, 21 Jan 93 15:58:39 EST Received: by dexter.bellcore.com (4.1/4.7) id for snmp2@thumper; Thu, 21 Jan 93 15:58:39 EST Date: Thu, 21 Jan 93 15:58:39 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Taso N. Devetzis" Message-Id: <9301212058.AA23412@dexter.bellcore.com> To: snmp2@thumper.bellcore.com Subject: Mailing List Archive My apologies for the non-technical submission, but I have a quick administrative note. The archive for this mailing list was incorrectly identified as: pub/davin/snmp2-archive@faline.bellcore.com (INCORRECT) The correct address is: pub/davin/snmp2-archive@thumper.bellcore.com (CORRECT) The incorrect address was specified in the charter (at least the version I have) sent to new subscribers. Thanks, --taso   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09674; 21 Jan 93 17:59 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09669; 21 Jan 93 17:59 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa20528; 21 Jan 93 18:01 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 21 Jan 93 18:00:57 EST Received: from sbctri.sbc.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Thu, 21 Jan 93 18:00:55 EST Received: from calvin.sbc.com by sbctri.sbc.com (4.1/SMI-4.1) id AA03681; Thu, 21 Jan 93 16:59:21 CST Received: from emily.sbc.com by calvin.sbc.com (4.1/SMI-4.1) id AA12922; Thu, 21 Jan 93 17:00:53 CST Date: Thu, 21 Jan 93 17:00:53 CST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Matt D. Nguyen" Message-Id: <9301212300.AA12922@calvin.sbc.com> To: snmp2@thumper.bellcore.com Subject: SNMP2 vs. OSI CMIP ? I am not yet in this discussion group, please email your reply to my email address directly. Would you please recommend some public domain docs providing comparison of these two? briefs of your opinion/experience on these would also be appreciated, in particular to ATM equipments. Thanks, Matt   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12847; 26 Jan 93 22:59 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12843; 26 Jan 93 22:59 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa09352; 26 Jan 93 23:01 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Tue, 26 Jan 93 23:01:19 EST Received: from emory.mathcs.emory.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Tue, 26 Jan 93 23:01:17 EST Received: from bir.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.4) via UUCP id AA15432 ; Tue, 26 Jan 93 23:01:14 -0500 Return-Path: bir!mlk@bir.com Received: by bir.bir.com (uA-1.5v4); Tue, 26 Jan 93 22:58:05 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "Michael L. Kornegay" To: snmp-sec-dev@tis.com Subject: Squashing important ideas (was Re: consensus coming? Date: Tue, 26 Jan 93 22:58:05 EST Cc: snmp2@thumper.bellcore.com, snmp@psi.com Reply-To: mlk%bir.UUCP@mathcs.emory.edu Message-Id: <0D15DDF1.omsjq8@bir.bir.com> X-Mailer: uAccess - Macintosh Release: 1.5v4 > Let me remind everyone that discussion is scheduled to close at the end > of this week. Further, Chuck Davin has posted a substantial amount of > material that has not been significantly discussed. In the absence of > discussion I'm interpreting the quiet to be a deafening approval of the > proposed revised documents that Marshall will be distributing soon. I feel it is important to make the following comments: o Quiet can be "approval" as indicated above, or just frustration with the process. o Chuck's proposals about time/space vs SMP time/space would/should have got more discussion if we were not in such a hurry. Belittling and/or ignoring his proposals have "squashed" them. o Me and others have had the same problem with the SNMPv2 working group squashing "manager issues", a VERY IMPORTANT ISSUE FOR SNMP! I tried to build interest in this with a group of people via private email (out- side the snmp2 list), but they were all too tired of being "squashed". Summarizing, I feel ok about the SNMPv2 and SNMP Security proposals and look forward to implementing and using them in the future. Its just too bad the process and time pressures allow important ideas to be pushed aside (in my view - "squashed"). Just wanted this to be "on the record" and in the archives on these issues. I felt the cross posting was important, if you want to reply lets keep it on one list. How about snmp@psi.com since this is a general snmp issue. Thanks, ---- mlk@bir.com, mlk@bir.uucp, or bir!mlk (Michael L. Kornegay)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13818; 27 Jan 93 1:27 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13814; 27 Jan 93 1:27 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13804; 27 Jan 93 1:29 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 27 Jan 93 01:29:20 EST Received: from dbc.mtview.ca.us (ppp.dbc.mtview.ca.us) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 27 Jan 93 01:29:15 EST Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA18504; Tue, 26 Jan 93 22:27:34 -0800 To: mlk%bir.UUCP@mathcs.emory.edu Cc: snmp-sec-dev@tis.com, snmp2@thumper.bellcore.com, snmp@psi.com Reply-To: snmp-sec@dbc.mtview.ca.us Subject: Re: Squashing important ideas (was Re: consensus coming? In-Reply-To: Your message of "Tue, 26 Jan 1993 22:58:05 EST." <0D15DDF1.omsjq8@bir.bir.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Jan 1993 22:26:54 -0800 Message-Id: <18502.728116014@dbc.mtview.ca.us> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose For a moment, consider an alternate perspective. At some point you just have to ask yourself "how much discussion is enough". Certainly we could have an open-ended process that continually refined SNMPv2 until it was all things for all people. However, experience shows that this does not produce useful technology. The original call for proposals went out in March of last year. For a six month period, people had a chance to put something together. There have been repeated opportunities for people to formulate proposals, modifications, etc. Some of this input has been productive. Some has not. The moral of the story is that talk is cheap, but workable technology is not. With respect to the current situation, the process and time pressures have not squashed Chuck's proposals. They have been on the table for over a month. The problem is that most people can not even understand his proposals (and I wonder how many could even begin to implement them). I do understand them and I will tell you that from my admittedly biased--yet informed--position, they have little chance of resulting in fielded, interoperable implementations. I've already explained why I think Chuck is engaging in this disruptive behavior, and you might disagree with my analysis. However, it is a plain fact that his proposal has no constituency, nor does it have the force of interoperable implementation behind them. As such, the resolution of a situation is a foregone conclusion. /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04815; 27 Jan 93 10:43 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04811; 27 Jan 93 10:43 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13160; 27 Jan 93 10:45 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 27 Jan 93 10:44:48 EST Received: from uu3.psi.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 27 Jan 93 10:44:46 EST Received: from acec.com by uu3.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA16420 for snmp2@thumper.bellcore.com; Wed, 27 Jan 93 10:11:23 -0500 Date: Wed, 27 Jan 1993 10:12:17 -0500 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Natale Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA07501; Wed, 27 Jan 1993 10:12:17 -0500 Message-Id: <9301271512.AA07501@nips.acec.com> To: snmp2@thumper.bellcore.com Subject: Subscribe me Please subscribe me to your SNMP and/or SNMPv2 mailing list(s) and any associated or related mailing lists you might manage. We are building SNMPv2 *applications* and wish to comply with all standards and consensus positions where interpretations are required. Thanks. ^------------------------^----------------------^-------------------^ | Bob Natale | American Computer | 301-258-9850 [tel]| | Director | 209 Perry Pkwy | 301-921-0434 [fax]| | Data Networking Systems| Gaithersburg MD 20877| natale@acec.com | |------------------------|----------------------|-------------------|   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05421; 27 Jan 93 10:59 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05417; 27 Jan 93 10:59 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa13901; 27 Jan 93 11:01 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 27 Jan 93 11:01:45 EST Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 27 Jan 93 11:01:42 EST Received: by xap.xyplex.com id ; Wed, 27 Jan 93 14:04:20 -0500 Date: Wed, 27 Jan 93 14:04:20 -0500 Message-Id: <9301271904.AA05280@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp2@thumper.bellcore.com Subject: Meetings Except for final alignment with Secure SNMP, I believe we are done and do not need to schedule meetings for Columbus or Amsterdam. Can anyone think of a reason why we need such meetings? Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05941; 27 Jan 93 11:18 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05937; 27 Jan 93 11:18 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa14700; 27 Jan 93 11:20 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 27 Jan 93 11:20:30 EST Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 27 Jan 93 11:20:23 EST Received: by xap.xyplex.com id ; Wed, 27 Jan 93 14:22:55 -0500 Date: Wed, 27 Jan 93 14:22:55 -0500 Message-Id: <9301271922.AA21577@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp-sec-dev@tis.com, snmp2@thumper.bellcore.com, snmp@psi.com In-Reply-To: Michael L. Kornegay's message of Tue, 26 Jan 93 22:58:05 EST <0D15DDF1.omsjq8@bir.bir.com> Subject: Re: Squashing important ideas (was Re: consensus coming? The importance of an idea is often an issue of debate in itself. This is not to say what is important, but to say that an assertion of importance, or insignificance, is not sufficient. > o Quiet can be "approval" as indicated above, or just frustration with > the process. True. But if you do not speak up, you are guaranteed that your opinion will not be considered, whether the issue is the process itself or the conclusions. > o Chuck's proposals about time/space vs SMP time/space would/should have > got more discussion if we were not in such a hurry. Belittling and/or > ignoring his proposals have "squashed" them. I don't agree. If people believe something is important, they will find time to discuss it, or at least to say something. The proposals have been ignored by the community at large, not by the vocal few who have disagreed with them. The proposals have not be squashed. They have not found supporters. > o Me and others have had the same problem with the SNMPv2 working group > squashing "manager issues", a VERY IMPORTANT ISSUE FOR SNMP! I tried > to build interest in this with a group of people via private email (out- > side the snmp2 list), but they were all too tired of being "squashed". The hardest part of engineering is knowing when one more important issue is one issue too many and will result in no product at all. Many of the people who fought off "manager issues" are actually quite interested in those issues but did not believe that their time for consideration had come. I am one of those. Try building interest in manager issues as soon as we have SNMPv2 put to bed. I believe you'll find lots of participants then. >Summarizing, I feel ok about the SNMPv2 and SNMP Security proposals and look >forward to implementing and using them in the future. Thank you very much for saying that. I know that the process was sometimes brutal, and feelings were heavily bruised. Nevertheless, I've continued to hope for a positive outcome. Bob   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08703; 27 Jan 93 13:11 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08699; 27 Jan 93 13:11 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa19648; 27 Jan 93 13:13 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 27 Jan 93 13:13:32 EST Received: from auspex-gw.Auspex.COM ([131.119.72.22]) by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 27 Jan 93 13:13:30 EST Received: from auspex.com (auspex.auspex.com) by auspex-gw.Auspex.COM (4.1/SMI-4.1) id AA19082; Wed, 27 Jan 93 10:13:29 PST Received: from alpha1-e5.auspex.com by auspex.com (4.1/SMI-4.1) id AA03777; Wed, 27 Jan 93 10:13:28 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Hubbert Smith Message-Id: <9301271813.AA03777@auspex.com> Subject: unsubscribe To: snmp2@thumper.bellcore.com Date: Wed, 27 Jan 93 10:14:29 PST X-Mailer: ELM [version 2.3 PL2] Unsubscribe me. thanks -- ........................................................................... | Hubbert Smith -- Auspex Marketing -- | ( Auspex Systems -- 2952 Bunker Hill Ln -- Santa Clara CA 95054 ) | 408 492 0900 -- fax 408 492 0909 -- hsmith@auspex.com |   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10800; 27 Jan 93 14:32 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10796; 27 Jan 93 14:32 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22850; 27 Jan 93 14:34 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Wed, 27 Jan 93 14:34:16 EST Received: from phila.bellcore.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Wed, 27 Jan 93 14:34:11 EST Received: from localhost.bellcore.com by phila.bellcore.com (4.1/4.7) id for snmp@psi.com; Wed, 27 Jan 93 14:34:49 EST Message-Id: <9301271934.AA00670@phila.bellcore.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: "James R. (Chuck) Davin" To: snmp-sec@dbc.mtview.ca.us Cc: snmp-sec-dev@tis.com, snmp2@thumper.bellcore.com, snmp@psi.com Subject: Re: Squashing important ideas (was Re: consensus coming? In-Reply-To: Your message of Tue, 26 Jan 93 22:26:54 -0800. <18502.728116014@dbc.mtview.ca.us> Date: Wed, 27 Jan 93 14:34:47 -0500 X-Orig-Sender: davin@phila.bellcore.com Marshall, The issues that have been raised are not connected with any proposals that were contributed in response to the call in March 1992. It is work that was introduced in what should have been the closing moments of the evolution process, was developed very hastily, and addresses longstanding problems that were not addressed in any of the baseline proposals. The special groundrules that were instituted in the SNMP V2 working group to assure timely progess were based on the extended open period for contributions, the availability of strong, widely available, relatively stable baseline proposals, and the preference of the community for a single transition rather than many. These special groundrules did not represent some massive weather-change in the way that the work of normal IETF WGs is routinely conducted. In particular, the groundrules for the SNMP Security WG are those of normal IETF WGs -- not the special conventions introduced into the SNMPV2 WG. The charter of the SNMP Security WG characterizes the revisions to the security documents as a routine part of their maturation in the standards process. The commitment that Steve Crocker and I jointly made for timely completion of both the SNMP V2 and SNMP Security efforts was premised on the work that was represented in the original baseline documents -- which contained between 8-12 fairly contained and well-understood changes to the security specs that would increase their utility in the new framework. All this work was mostly wrapped up on schedule (for which many involved deserve due credit). We did not tailor the rules to assure quick progress of the baseline SMP proposals and then extend carte blanche for unlimited reworking of those proposals and even the addition of new areas of work. And yet this is exactly the premise on which this lastest episode is based. I will observe that once again you have eschewed discussion of substantive technical issues by calling into question my credibility and motives. While I'm willing (nay, eager?) to be shot down by sound technical argument (!= unsupported claims to authority based on idiomatic "implementation experience"), I am completely unwilling to see important technical issues dismissed based on specious procedural tactics, apathy, or exhaustion. Let me suggest that bashing me technically is your fastest route to success. Regards, Chuck > To: mlk%bir.UUCP@mathcs.emory.edu > Cc: snmp-sec-dev@tis.com, snmp2@thumper.bellcore.com, snmp@psi.com > Reply-To: snmp-sec@dbc.mtview.ca.us > Subject: Re: Squashing important ideas (was Re: consensus coming? > In-Reply-To: Your message of "Tue, 26 Jan 1993 22:58:05 EST." <0D15DDF1.omsjq8@bir.bir.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Date: Tue, 26 Jan 1993 22:26:54 -0800 > Message-Id: <18502.728116014@dbc.mtview.ca.us> > From: Marshall Rose > > For a moment, consider an alternate perspective. > > At some point you just have to ask yourself "how much discussion is > enough". Certainly we could have an open-ended process that continually > refined SNMPv2 until it was all things for all people. However, > experience shows that this does not produce useful technology. > > The original call for proposals went out in March of last year. For a > six month period, people had a chance to put something together. There > have been repeated opportunities for people to formulate proposals, > modifications, etc. Some of this input has been productive. Some has not. > The moral of the story is that talk is cheap, but workable technology is > not. > > With respect to the current situation, the process and time pressures > have not squashed Chuck's proposals. They have been on the table for > over a month. The problem is that most people can not even understand > his proposals (and I wonder how many could even begin to implement > them). I do understand them and I will tell you that from my admittedly > biased--yet informed--position, they have little chance of resulting in > fielded, interoperable implementations. I've already explained why I > think Chuck is engaging in this disruptive behavior, and you might > disagree with my analysis. However, it is a plain fact that his > proposal has no constituency, nor does it have the force of > interoperable implementation behind them. As such, the resolution of a > situation is a foregone conclusion. > > /mtr   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09650; 28 Jan 93 14:21 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09646; 28 Jan 93 14:21 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa22276; 28 Jan 93 14:24 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 28 Jan 93 14:23:59 EST Received: from burdell.cc.gatech.edu by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Thu, 28 Jan 93 14:23:58 EST Received: from terminus.cc.gatech.edu by burdell.cc.gatech.edu with SMTP id AA06353 (5.65c/IDA-1.4.4 for ); Thu, 28 Jan 1993 14:23:40 -0500 Received: by terminus.cc.gatech.edu (4.1/SMI-4.1) id AA15894; Thu, 28 Jan 93 14:23:31 EST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Cheryl Krupczak Message-Id: <9301281923.AA15894@terminus.cc.gatech.edu> Subject: Re: Squashing important ideas (was Re: consensus coming? To: snmp-sec@dbc.mtview.ca.us Date: Thu, 28 Jan 93 14:23:29 EST Cc: mlk%bir.UUCP@mathcs.emory.edu, snmp-sec-dev@tis.com, snmp2@thumper.bellcore.com, snmp@psi.com In-Reply-To: <18502.728116014@dbc.mtview.ca.us>; from "Marshall Rose" at Jan 26, 93 10:26 pm X-Mailer: ELM [version 2.3 PL11] Well, I've been quiet while I've been putting out the fire Marshall flamed me with before Christmas in regards to the Create/Delete issues in snmpv2. Mainly, I have kept silent because I am TOTALLY disgusted with the behavior I have seen on the mailing lists. Does my silence mean I implicitly agree with the current proposal? NO, it means I don't want my personal character attacked by Marshall as he has done in the past and as he has continued to do to Chuck. THIS HAS GONE TOO FAR!! We, as a group, have a community responsibility to keep the discussion on track, and on a constructive, professional course. Let's get back to work and end the ego wars. Here are the responsibilites: ---------------------------- 1) Individual - Keep your post clear, to the point, and address the issue you are responding to (don't bring up old arguments to confuse the issue). Use self-control; do not attack the person making the proposal -- give technical reasons why you disaggree with a technical point (it shouldn't matter WHO made the proposal, judge the proposal on content, not authorship). 2) Working group chair - Tough job. No question there. This job requires an almost parent-like role. You have to be a non-biased, fair listener to all the arguments. The worst thing you can do is to be perceived as "playing favorites" to certain parties. You have to keep the discussion on track and gently scold the one who tries to throw it off track. And most importantly, if one of the "kids" is getting out of hand (not following responsibilities listed in step 1) you should send them private mail and ask them to "play well with others". 3) Community - Its tempting to avoid your responsibility by retaining silence and apathy (I know). But in the long run, its not in your best interest. Express your opinions on the issues. Be adult enough to accept criticism; be tough skinned. If the community shows its approval of good behavior and rejection of bad behavior, eventually the bad behavior will be ostracized. (Then again, there is always someone that wont play nice -- that's where the wg chair might be able to help). I'm going to try fulfill these responsibilities. When I slip, (I'm only human -- and I've been known to have quite a temper), I hope you'll fulfill your community responsibility and get me back in line. NOW..... back to work. Cheryl Krupczak cheryl@cc.gatech.edu   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10083; 28 Jan 93 14:54 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10079; 28 Jan 93 14:54 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa23659; 28 Jan 93 14:56 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Thu, 28 Jan 93 14:56:43 EST Received: from saffron.acc.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Thu, 28 Jan 93 14:56:41 EST Received: by saffron.acc.com (4.1/SMI-4.1) id AA01645; Thu, 28 Jan 93 11:56:19 PST Date: Thu, 28 Jan 93 11:56:19 PST Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Fred Baker Message-Id: <9301281956.AA01645@saffron.acc.com> To: cheryl@cc.gatech.edu Subject: Re: Squashing important ideas (was Re: consensus coming? Cc: snmp-sec-dev@tis.com, snmp2@thumper.bellcore.com, snmp@psi.com Thanks, Cheryl.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02855; 29 Jan 93 9:38 EST Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02850; 29 Jan 93 9:38 EST Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa10583; 29 Jan 93 9:41 EST Received: by thumper.bellcore.com (4.1/4.7) id for ietf-archive@nri.reston.va.us; Fri, 29 Jan 93 09:41:16 EST Received: from xap.xyplex.com by thumper.bellcore.com (4.1/4.7) id for /usr/lib/sendmail -oi -fowner-snmp2 X-snmp2; Fri, 29 Jan 93 09:41:13 EST Received: by xap.xyplex.com id ; Fri, 29 Jan 93 12:43:40 -0500 Date: Fri, 29 Jan 93 12:43:40 -0500 Message-Id: <9301291743.AA04470@xap.xyplex.com> Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Bob Stewart To: snmp-sec-dev@tis.com, snmp2@thumper.bellcore.com, snmp@psi.com In-Reply-To: Cheryl Krupczak's message of Thu, 28 Jan 93 14:23:29 EST <9301281923.AA15894@terminus.cc.gatech.edu> Subject: Re: Squashing important ideas (was Re: consensus coming? Cheryl made some very good points. In my zeal to get the work done, I haven't been as aware or active as I could have been to avoid the appearance of favoritism. I'll try to do that better. Bob