Subject: Fwd: review of Expression MIB

From: Randy Presuhn <[email-masked]>
Date: Tue, 5 Oct 1999 12:17:23 -0700 (PDT)

Hi -

Here are the review comments on the expression MIB.
Thanks DavidH!

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com/
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's is probably coincidental.
 ------------------------------------------------------------------------

> From [email-masked] Tue Oct  5 10:59:48 PDT 1999
> From: "Harrington, David" <[email-masked]>
> To: "Bert Wijnen (E-mail)" <[email-masked]>,
>         "Randy Presuhn (E-mail)"
> 	 <[email-masked]>
> Subject: review of Expression MIB
> Date: Tue, 5 Oct 1999 13:57:07 -0400 
> 
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_000_01BF0F5B.2FCA3F8C
> Content-Type: text/plain;
> 	charset="ISO-8859-1"
> 
> 
> 
> ------------------------------------------------------------
> #include <std.disclaimer> 
> David Harrington
> [email-masked] 
> Spectrum Smart Networking
> Cabletron Systems Inc. 
> 
> 
> ------_=_NextPart_000_01BF0F5B.2FCA3F8C
> Content-Type: text/plain;
> 	name="expressionMibreview.txt"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment;
> 	filename="expressionMibreview.txt"
> 
> To: Randy Presuhn, Bert Wijnen
> from: David Harrington
> date:  10-5-99
> re: Expression MIB review
> 
> Hi,
> Sorry this took so long. I hope to have the Notify Log MIB done by the =
> end of the week.
> I don't know who the assigned author is now that Bob has retired; Randy =
> can forward to the new author.
> Spelling mistakes are denoted sp:<incorrectly spelled word>
> 
> p4:
> 3.0 "may be used no differently" may be ambiguous as to intent.=20
> 3.0 sp: bby
> 3.3.2. paragraph 2 clarity of the run-on sentence.
> 3.3.3. "fully absolute" as compared to? partially absolute? =
> not-absolutely absolute?
> 3.3.3 "No obsolete values are kept" - I'm unclear as to what an =
> obsolete value is here.=20
> 3.3.4 I would add the word wildcarding to the end of the sentence.
> 3.6.2 "For notational clarity" - is this string usage only for the =
> example below, or part of the spec?
> 3.6.2 expExpressionRowStatus..2."me".4."hard" has two dots in a row; is =
> that a typo? if not, is it legal?
> 	(note that this has two instances in the text)
> 
> The MIB:
> general comment: identifiers longer than 32 may be problematic to some =
> NMSs, especially with snmpv1.
> Is this mib able to be converted to smiv1 and remain useful using v1 =
> managers?
> 
> expResourceDeltaMinimum - is this open to NMS contention? Could this be =
> used for denial of service?
> expResourceDeltaWildcardInstanceMaximum - description a little tough =
> going.
> expResourceDeltaWildcardInstancesHigh - "management system" is =
> ambiguous; the agent's management system, or the NMS (network =
> management system), or the combination of agent/nms? If NMS, what if =
> there are multiple NMSs?
> expExpressionEntry - "The evaluation ... takes place under the security =
> credentials ...". Can we add to the description a reference to the =
> Security Considerations section, or is that overkill?
> expExpression - "may not be recursive" - who is responsible for =
> checking this? the manager or the agent?
> 	for safety sake, I assume the agent, but this is not specified.
> expExression - there are a number of mentions of 1-based arrays; I have =
> never heard one-dimensioned arrays referred to as 1-based. Is this WG =
> consensus wording?
> expExpression - "The following rules say what operators apply with what =
> data" - "also" is unnecessary.
> 	might this be clearer in a table, or are they too different?
> expExpression - "agent system" - so, after I used the agent/manager =
> distinction above, I need to point out that agent and manager words are =
> discouraged in preference to the new application terms.
> expExpressionValueType - since this is an enum, this may be expanded in =
> the future. What if this gets out of sync with the CHOICE in =
> OBJECT-TYPE? Can this be made IANA-controlled? At a minimum, the =
> description should warn implementors that they should expect future =
> extensions to the type list.
> expExpressionDeltaInterval - "is has"
> expExpressionDeltaInterval - could this mib contain enable/disable =
> objects to prevent resource consumption when the expression is not =
> being used? Could the agent disable the object if it isn't polled by an =
> external entity within some timeout/keepalive period? Maybe this should =
> be raised during the next cycle of the document.
> expExpressionErrors - clarity; "not being accessible" - does this =
> include objects with "not-accessible" status or objects that cannot be =
> accessed due to unavailable resources or view restrictions, etc.?
> expErrorIndex - what if an empty string is passed; it's illegal, but =
> how do we indicate that error?
> 	would that simply be a badValue on the SET?
> expObjectTable - The description is complex, and it seems that this =
> could be fairly easily misconfigured and cause interoperability =
> problems. This concerns me, but I don't really have a way to reword =
> that make it clearer. Maybe we just need to wait for implementation =
> reports and interoperability testing.
> expObjectEntryStatus - "objects may be changed while <RowStatus> is in =
> any state" - isn't that a bad precedent? Why is this necessary? Is the =
> WG consensus? Can the reasoning be included in the description?
> dismanExpressionMIBCompliance - "Implementation may not allow" is =
> ambiguous - is this "MAY NOT allow" or "might disallow"
> dismanExpressionMIBCompliance - "need not" - are there RFC2119 =
> equivalents for the compliance requirements?
> 
> 5. Intellectual Property - does this imply that Cisco has some claim on =
> this expression mib technology? If so, is the WG aware of this, and is =
> it consensus to proceed even if this is dependent on Cisco intellectual =
> property?
> 
> 6. Acknowledgements - assuming we will change authors, is "colleagues" =
> a correct choice of word here?
> 
> 7. References
> [RFCEventMIB] refers to RFC ????,  and ?Month?
> 
> 8. Security Considerations
> "view-based access control [RFCEventMIB]" - is this reference =
> incorrect?
> sp: "on th"
> "RFC 2275 [RFCEventMIB]"
> "To facilitate" - run-on sentence?
> "in accordance with a security policy" seems weak.=20
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------_=_NextPart_000_01BF0F5B.2FCA3F8C--
>