Results of APPN MIB Review
Bill Kwan <billk@jup-nova1.jti.com> Thu, 25 July 1996 21:47 UTC
Received: from ietf.org by ietf.org id aa16339; 25 Jul 96 17:47 EDT
Received: from cnri by ietf.org id aa16335; 25 Jul 96 17:47 EDT
Received: from trix.cisco.com by CNRI.Reston.VA.US id aa22133; 25 Jul 96 17:47 EDT
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by trix.cisco.com (8.6.12/8.6.5) with ESMTP id OAA20635 for <snanaumib@aliashost.cisco.com>; Thu, 25 Jul 1996 14:39:09 -0700
Received: from jti.com (bart.jti.com [198.22.30.1]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id OAA28775 for <snanaumib@cisco.com>; Thu, 25 Jul 1996 14:42:26 -0700
Received: from charon.jti.com by jti.com with SMTP id AA15459 (5.65c/IDA-1.5 for <snanaumib@cisco.com>); Thu, 25 Jul 1996 17:38:36 -0400
Received: From JUP-NOVA1/WORKQUEUE by charon.jti.com via Charon-4.0-VROOM with IPX id 100.960725173801.288; 25 Jul 96 17:38:38 +500
Message-Id: <MAILQUEUE-101.960725173800.480@jup-nova1.jti.com>
Sender: ietf-archive-request@ietf.org
From: Bill Kwan <billk@jup-nova1.jti.com>
Organization: Jupiter Technology, Inc
To: snanaumib@cisco.com, aiw-appn-mibs@www.raleigh.ibm.com
Date: Thu, 25 Jul 1996 17:38:00 -0000
Subject: Results of APPN MIB Review
Priority: normal
X-Mailer: Pegasus Mail for Windows (v2.30)
Date sent: Thu, 25 Jul 1996 13:59:45 -0700 From: Randy Presuhn <rpresuhn@peer.com> To: billk@jti.com Subject: APPN MIB Review Copies to: clouston@cisco.com, kostick@qsun.ho.att.com, remoore@ralvm6.vnet.ibm.com Hi Bill - Attached are my initial comments on <draft-ietf-snanau-appnmib-01.txt> The only problem detected by the mib compilers I tried was in the use of potentially negative numbers of indexes. The remaining problems are more subtle - semantic / stylistic issues or requirements imposed by RFC 1902 that cannot be evaluated by a compiler. Feel free to give me a call if you have any questions. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA ----------------------------------------------------------------------------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ These are my initial comments developed in reviewing the Definitions of Managed Objects for APPN in <draft-ietf-snanau- appnmib-01.txt>. Most comments fall into these categories: 1 cases where Integer32 was used when Unsigned32 was probably intended 2 identification of discontinuity indicators for counters 3 clarification of description texts 4 conventions for strings, especially hex statuses and names In most cases, I would expect the resolution of an item to be handled consistently for all relevant definitions identified in that item. Some of these issues, such as the use of textual conventions, are a matter of stylistic preferences, though argu- ments can be made in terms of maintainability and ease of use. Item: 1 Page: - Clause: - Qualifier: general Rationale: The definitions of the tables appnPortTable, appnL- sTable, appnLsStatusTable, appnVrnTable, appnNnTopolo- gyFRTable, appnNnTgTopologyFRTable, appnLocalTgTable, appnLocalEnTgTable, appnDirTable, appnCosModeTable, appnCosNameTable, appnCosNodeRowTable, appnCosT- gRowTable, appnIsInTable, and appnIsRtpTable do not describe the conditions under which entries are added or deleted. The MIB definitions do not provide a low- overhead mechanism for detecting changes to tables. Proposal: Make the decision to do this a conscious one. APPN MIB review [Page 1] Item: 2 Page: - Clause: - Qualifier: general Rationale: The way the definitions are currently written make it impossible for a future version of this MIB to allow management operations to create/delete table rows, modify configuration parameters, and so on. Proposal: Make the decision to do this a conscious one. If there is a realistic possibility that management con- trol will be needed, it would make sense to modify the relevant MAX-ACCESS clauses from "read-only" to "read- write" or "read-create", and to use the MIN-ACCESS in the MODULE-COMPLIANCE section to set the "read-only" expectation. Item: 3 Page: 2 Clause: 4 Qualifier: editorial Rationale: This document is presumably more than a proposal. Proposal: Replace "the proposed" with "a" in the first sentence of the first paragraph. Item: 4 Page: 2 Clause: 4 Qualifier: editorial Rationale: Consistency of reference style. Proposal: Replace "(RFC1666 [8])" with "[8]" in the first para- graph. APPN MIB review [Page 2] Item: 5 Page: 2 Clause: 4 Qualifier: editorial Rationale: English usage. Proposal: Replace "is comprised of" with "comprises" in the first sentence of the second paragraph. Item: 6 Page: 3 Clause: 4 Qualifier: editorial Rationale: Typo. Proposal: Replace "LLCMIB" with "LLC MIB" in the first paragraph on page 3. Item: 7 Page: 3 Clause: 4 Qualifier: minor Rationale: It is not entirely clear in the MIB module exactly which variables are subject to the constraints described in fifth paragraph on SNA name representa- tion. Proposal: Include this text as part of a textual convention, and use that textual convention for the SYNTAX of the variables to which these constraints apply. This would appear to affect appnPortName, appnLsName, appnLsPortName, appnLocalTgDest, appnLocalTgPortName, appnLocalEnTgOrigin, appnLocalEnTgDest, appnDirLuName, appnDirNnServerName, appnDirLuOwnerName, appnCosTgRow- Name, appnIsInPriLuName, and appnIsInSecLuName. It would be advisable to examine all DisplayString usages to determine which ones are subject to these con- straints. APPN MIB review [Page 3] Item: 8 Page: 4 Clause: 4 Qualifier: Major Rationale: The example given of a GET-NEXT request using an index of "M " assumes that no character with a value less than 32 (space) may appear in one of these indexes. This constraint is not stated. Proposal: Either add text identifying the set of characters per- mitted, or correct the example to use the probe value of 8.77 (no additional subidentifiers) to obtain the element indexed by first 8-character string beginning with "M". Item: 9 Page: 4 Clause: 4 Qualifier: editorial Rationale: The two occurrances of "M" in the paragraph at the top of the page should be in quotes. Proposal: Add the missing quotes. Item: 10 Page: - Clause: - Qualifier: editorial Rationale: Several abbreviations are not expanded before being used, although in some cases an expansion appears later in the text. Though most of these would be fairly obvious to the SNA-aware, the lack of expan- sions is inconsistent with the expansion of other basic SNA-isms in this document. ABM, ACTPU, ANR, APPC, CS, CV22, DLUR, FMD, HPR, LLC, LU, MAC, MS, MU, NAU, NCE, NRM, PIU, RSCV, RTP, RU, SAP, SDLC, SNA, SSCP, TDU, XID. Proposal: Add the missing definitions as needed. APPN MIB review [Page 4] Item: 11 Page: 10 Clause: 5 Qualifier: minor Rationale: Is "{ experimental 1000 }" the correct registration for this MIB? Proposal: Update with the official registration. Item: 12 Page: 10 Clause: 5 Qualifier: minor Rationale: The description of SnaSenseData does not specify the set of characters permitted. In particular, if hex- adecimal numbers show up here, are a-f upper or lower case? Proposal: Identify the permitted characters in these strings and the mapping from how the information is represented in SNA-land. Item: 13 Page: 11+ Clause: 5 Qualifier: minor Rationale: In the definitions of appnNodeCpName, appnN- odeEnNnServer, appnLsAdjCpName, appnLsStatusCpName, appnNnNodeFRName, appnNnTgFROwner, appnDirNnServer- Name, appnDirLuOwnerName, appnIsInFqCpName, and app- nIsInSsAdjCpName, the notation describing the format of network names is unclear due to the unfortunate puctuation of the description clause. Proposal: Define a textual convention for use in these defini- tions, and make it clear that only the dot between NetId and CpName belongs to the format. APPN MIB review [Page 5] Item: 14 Page: 11+ Clause: 5 Qualifier: minor Rationale: In the definitions of appnNodeId, appnLsPartnerNodeId, and appnLsStatusPartnerId, the description does not make it clear what characters are used in the hexadec- imal representation, e.g., uppercase or lowercase for A-F, whether leading zeroes can be mapped to spaces, and so on. Proposal: Define a textual convention for hexadecimal strings like these, clearly defining whether zero-suppression is allowed and what characters are used for what dig- its. Item: 15 Page: 11+ Clause: 5 Qualifier: minor Rationale: In the definitions of appnNodeType, appnNodeParal- lelTg, appnNodeAdaptiveBindPacing, appnNodeHprSupport, appnNodeNnCentralDirectory, appnNodeNnTreeCache, appnNodeNnIsr, appnNodeNnPeriBorderSup, appnNodeNnIn- terchangeSup, appnNodeNnExteBorderSup, appnNodeNnIs- rDepleted, appnNodeNnQuiescing, appnNodeNnGateway, appnNodeEnModeCosMap, appnNodeEnLuSearch, appnPortOp- erState, appnPortPortType, appnPortSIMRIM, appnPortNe- gotLs, appnPortDynamicLinkSupport, appnLsOperState, appnLsAdjNodeType, appnLsLimResource, appnLsActOnDe- mand, appnLsMigration, appnLsCpCpSessionSupport, appnLsErrRecoSup, appnLsStatusRetry, appnNnNodeFRType, appnNnNodeFRCongested, appnNnNodeFRIsrDepleted, appnNnNodeFRQuiescing, appnNnNodeFRGateway, appnNnN- odeFRCentralDirectory, appnNnNodeFRIsr, appnNnNodeFR- GarbageCollect, appnNnNodeFRHprSupport, appnNnNodeFR- PeriBorderSup, appnNnNodeFRInterchangeSup, appnNnNode- FRExteBorderSup, appnNnTgFRDestVirtual, appnNnTgFROp- erational, appnNnTgFRQuiescing, appnNnTgFRCpCpSession, appnNnTgFRSecurity, appnNnTgFRGarbageCollect, appnNnT- gFRHprSup, appnNnTgFRDestHprTrans, appnNnTgFRTypeIndi- cator, appnNnTgFRIntersubnet, appnLocalTgDestVirtual, appnLocalTgQuiescing, appnLocalTgOperational, appnLo- calTgCpCpSession, appnLocalTgHprSup, appnLocalTgInter- subnet, appnLocalEnTgDestVirtual, APPN MIB review [Page 6] appnLocalEnTgOperational, appnLocalEnTgCpCpSession, appnCosTransPriority, and appnIsInTransPriority, the relationship between the labels provided in the list of possible values and the elements of the description clause is not clear. Proposal: In the description clause, explicitly identify the label corresponding to each condition. Item: 16 Page: 12 Clause: 5 Qualifier: question Rationale: Is it acceptable for appnNodeUpTime to wrap when sys- tems stay up longer than about 497 days? Proposal: Item: 17 Page: 12+ Clause: 5 Qualifier: minor Rationale: The "SYNTAX INTEGER { yes(1), no(2) }" appears numer- ous times in this MIB. A textual convention, such as TruthValue from RFC 1903, would be appropriate. The affected definitions are appnNodeParallelTg, appnN- odeAdaptiveBindPacing, appnNodeNnCentralDirectory, appnNodeNnIsr, appnNodeNnPeriBorderSup, appnNodeNnIn- terchangeSup, appnNodeNnExteBorderSup, appnNodeNnCon- gested, appnNodeNnIsrDepleted, appnNodeNnQuiescing, appnNodeNnGateway, appnNodeEnModeCosMap, appnNodeEn- LuSearch, appnPortSIMRIM, appnPortNegotLs, appnPortDy- namicLinkSupport, appnLsDynamic, appnLsLimResource, appnLsActOnDemand, appnLsMigration, appnLsCpCpSession- Support, appnLsErrRecoSup, appnLsStatusRetry, appnNnN- odeFRCongested, appnNnNodeFRIsrDepleted, appnNnNode- FRQuiescing, appnNnNodeFRGateway, appnNnNodeFR- CentralDirectory, appnNnNodeFRIsr, appnNnNodeFR- GarbageCollect, appnNnNodeFRPeriBorderSup, appnNnNode- FRInterchangeSup, appnNnNodeFRExteBorderSup, appnNnT- gFRDestVirtual, appnNnTgFROperational, appnNnTgFRQui- escing, appnNnTgFRGarbageCollect, appnNnTgFRHprSup, appnNnTgFRDestHprTrans, appnNnTgFRIntersubnet, appnLo- calTgDestVirtual, appnLocalTgQuiescing, appnLocalTgOp- erational, appnLocalTgIntersubnet, APPN MIB review [Page 7] appnLocalEnTgDestVirtual, appnLocalEnTgOperational, appnCosNodeRowMinCongestAllow, and appnCosNodeRowMax- CongestAllow. Proposal: Add TruthValue to the IMPORTS list on page 9, and update these definitions to make use of it. Item: 18 Page: 12+ Clause: 5 Qualifier: minor Rationale: The "SYNTAX INTEGER { noHprSupport(1), hprBaseOnly(2), rtpTower(3), controlFlowsOverRtpTower(4)}" appears in several locations. Introducing a textual convention might be appropriate. The definitions affected are: appnNodeHprSupport, appnLsHprSup, appnNnNodeFRHprSup- port, and appnLocalTgHprSup. Proposal: Add a textual convention and make use of it in these definitions. Item: 19 Page: 13+ Clause: 5 Qualifier: minor Rationale: The mapping between the identified bit positions and the possible enumerated values is not clear. Imple- mentation by offset and by masking would produce dif- ferent results. The mapping of the bit combinations to the enumeration values should be made explicit. The definitions affected are: appnNodeHprSupport, appnNodeNnCentralDirectory, appnNodeNnIsr, appnNodeN- nPeriBorderSup, appnNodeNnInterchangeSup, appnNodeN- nExteBorderSup, appnNodeNnCongested, appnNodeNnIsrDe- pleted, appnNodeNnQuiescing, appnNodeNnGateway, appnNnNodeFRCongested, appnNnNodeFRIsrDepleted, appnNnNodeFRQuiescing, appnNnNodeFRGateway, appnNnN- odeFRCentralDirectory, appnNnNodeFRIsr, appnNnNodeFR- GarbageCollect, appnNnNodeFRHprSupport, appnNnNodeFR- PeriBorderSup, appnNnNodeFRInterchangeSup, appnNnNode- FRExteBorderSup, appnNnTgFROperational, appnNnTgFRQui- escing, appnNnTgFRCpCpSession, appnNnTgFRGarbageCol- lect, appnNnTgFRHprSup, appnNnTgFRDestHprTrans, appnNnTgFRTypeIndicator, and appnNnTgFRIntersubnet. APPN MIB review [Page 8] Proposal: Identify the mapping between the various bit combina- tions and the enumeration values. Item: 20 Page: 13 Clause: 5 Qualifier: editorial Rationale: In the definition of appnNodeMaxSessPerRtpConn, the sense of "would" is unclear. Proposal: Replace "would" with "is able to" (if that is what is meant). Item: 21 Page: 13+ Clause: 5 Qualifier: minor Rationale: According to RFC 1902 clause 7.1.6, counters have no defined initial value. The definitions affected are appnNodeHprIntRteSetups, appnNodeHprIntRteRejects, appnNodeHprOrgRteSetups, appnNodeHprOrgRteRejects, appnNodeHprEndRteSetups, appnNodeHprEndRteRejects, appnNnTopoNodePurges, appnNnTopoTgPurges, appnDirInLo- cates, appnDirInBcastLocates, appnDirOutLocates, app- nDirOutBcastLocates, appnDirNotFoundLocates, and app- nDirNotFoundBcastLocates. Proposal: Consider whether the "initial value" specification is needed. Identify the TimeStamp discontinuity indica- tor for these counters as required by RFC 1902 clause 7.1.6. Item: 22 Page: 16 Clause: 5 Qualifier: major Rationale: Is the range of flow-reduction sequence numbers really -2147483648 to 2147483647? This affects the defini- tions of appnNodeNnFrsn, appnNnNodeFRFrsn, and appnNnTgFRFrsn. Proposal: Since this are used as indexes in the case of appnNnTopologyFRTable, and appnNnTgTopologyFRTable, APPN MIB review [Page 9] and negative indexes are not permitted, a syntax of Unsigned32 would probably be appropriate. Item: 23 Page: 17 Clause: 5 Qualifier: editorial Rationale: In the definition of appnNodeNnSafeStoreFreq, the phrase "even multiple" is ambiguous. It can be read to mean "(updates modulo appnNodeNnSafeStoreFreq) == 0" or "(updates modulo (appnNodeNnSafeStoreFreq * 2)) == 0". Proposal: Clarify whatever is meant. Item: 24 Page: 17+ Clause: 5 Qualifier: minor Rationale: The range of values permitted by the syntax for appnN- odeNnSafeStoreFreq, appnPortMaxIframeWindow, appnLsCurrentDelay, appnLsMaxDelay, appnLsMinDelay, and appnNnTopoMaxNodes is inconsistent with its description. Proposal: Modify the SYNTAX to exclude negative values. Gauge32 may be appropriate. Item: 25 Page: 17,56 Clause: 5 Qualifier: minor Rationale: Are negative resource sequence numbers permitted? This affects the definition of appnNodeNnRsn, and appnNnTgFRRsn. Proposal: Use an appropriate syntax, such as Unsigned32. APPN MIB review [Page 10] Item: 26 Page: 17+ Clause: 5 Qualifier: minor Rationale: The mapping between multiple byte quantities in machine registers and integer syntaxes needs to be clear to avoid byte-ordering confusion. This affects the definition of appnNodeNnRsn, appnPortMaxRcvBtu- Size, appnLsStatusXidByteInError, appnNnNodeFRRsn, appnNnTgFRRsn, and appnNnTgFRSubareaNum. Proposal: Identify the byte order of the bytes being mapped to this value. Item: 27 Page: 19 Clause: 5 Qualifier: minor Rationale: The last two sentences of the description of appnPort- Table are confusing. They appear to be making appn- PortSpecific optional. However, this is inconsistent with the reference to "the value of IfIndex", which would be of the wrong type to use in this manner. Proposal: Clarify what is meant, ensuring that the syntaxes are consistent and that the relevant objects are identi- fied. Item: 28 Page: 20-21 Clause: 5 Qualifier: minor Rationale: The last sentence of the first paragraph of descrip- tion text for appnPortAdminState, appnLsAdminState, and appnIsInGlobeCtrAdminStatus. is incomprehensible. If taken literally, the text would suggest that the initial value for an instance of this object is "ready", and that this value must be maintained until a set operation is received. It would also suggest that a port cannot be used (be active) until manage- ment action changes the state from "ready" to "active". If this is true, then a system is required to come up in a state inaccessible to management, and is not permitted to allow communication until APPN MIB review [Page 11] management magically succeeds in setting this variable to "active." The text in the description of appnLsAc- tOnDemand conflicts with this reading. Proposal: Clarify whatever is really intended for this variable. Item: 29 Page: 23 Clause: 5 Qualifier: major Rationale: RFC 1902 clause 7.1.6 requires that counters which can experience discontinuities at times other than manage- ment system re-initialization must identify an object of type TimeStamp which can be monitored to detect such discontinuities. This affects the definition of appnPortDefLsGoodXids, appnPortDefLsBadXids, appnPort- DynLsGoodXids, and appnPortDynLsBadXids. Proposal: Add an appnPortStartedTimeStamp object to satisfy this requirement. Item: 30 Page: 24 Clause: 5 Qualifier: editorial Rationale: Is the concept of "unsuccessful XID exchanges" well- defined? Does it include failure to respond, protocol errors, and so on? This affects appnPortDefLsBadXids, appnPortDynLsBadXids, and appnLsBadXids Proposal: Identify exactly what is being counted. Item: 31 Page: 24 Clause: 5 Qualifier: minor Rationale: Is this item intended to be a pointer? This affects the definition of appnPortSpecific, and appnLsSpe- cific. Proposal: Use the RowPointer textual convention from RFC 1903. Identify the value to be used when no object exists to supply additional information. APPN MIB review [Page 12] Item: 32 Page: 24+ Clause: 5 Qualifier: minor Rationale: The mapping from addresses to DisplayString represen- tation needs to be defined. Proposal: Modify the definition of appnPortDlcLocalAddr, appnL- sLocalAddr, appnLsRemoteAddr, appnLsStatusLocalAddr, and appnLsStatusRemoteAddr to describe the mapping of addresses into DisplayString form. If these mappings follow a pattern, a textual convention may be appro- priate. Item: 33 Page: 31 Clause: 5 Qualifier: editorial Rationale: Missing word. Proposal: Add "maximum" between "desired" and "number" in the first sentence of the description of appnLsMaxSendBtu- Size. Item: 34 Page: 31 Clause: 5 Qualifier: minor/editorial Rationale: Missing reference in the second paragraph of the defi- nition of appnLsMaxSendBtuSize. Proposal: The variable which defines "activating" should be identified. There is currently no variable in the MIB with this as a possible value. APPN MIB review [Page 13] Item: 35 Page: 31+ Clause: 5 Qualifier: minor Rationale: RFC 1902 clause 7.1.6 suggests that it would be appro- priate to identify how discontinuities in counters may be detected. For the objects appnLsInXidBytes, appnLsInMsgBytes, appnLsInXidFrames, appnLsInMs- gFrames, appnLsOutXidBytes, appnLsOutMsgBytes, appnL- sOutXidFrames appnLsOutMsgFrames appnLsEchoRsps, appnLsGoodXids, and appnLsBadXids no such objects are identified. Proposal: Decide whether these counts are maintained over the lifetime of the system or have some other lifetime, and update the definitions accordingly. Item: 36 Page: 31+ Clause: 5 Qualifier: minor Rationale: Are the ways in which XID bytes, and I-frame bytes, are counted well-agreed? The definitions of appnLsInXidBytes, appnLsInMsgBytes, appnLsOutXidBytes, and appnLsOutMsgBytes leave much to the imagination. Proposal: Define exactly which bytes are counted or provide a reference to the document which defines which bytes are included in these counts. Item: 37 Page: 33 Clause: 5 Qualifier: editorial Rationale: Missing word. Proposal: Insert "echo" before "responses" in the first sentence of the description of appnLsEchoRsps. APPN MIB review [Page 14] Item: 38 Page: 33,34 Clause: 5 Qualifier: minor Rationale: The semantics of gauges recording maximum of minimum observed values logically require definition of ini- tial values to handle the case when the gauge is observed before the measured condition has occurred. Proposal: Add appropriate initial values to the description text for appnLsMaxDelay, appnLsMinDelay, appnLsMaxDelay- Time. Item: 39 Page: 35 Clause: 5 Qualifier: minor Rationale: The description of appnLsActiveTime is inconsistent with the semantics of TimeTicks in clause 7.1.8 of RFC 1902. Also, it is unclear whether "node activation" is the same thing as "node re-initialization". Proposal: Use Unsigned32 syntax for this information. Clarify what is meant by "node activation". Item: 40 Page: 38 Clause: 5 Qualifier: editorial Rationale: The comment makes a broader statement than was proba- bly intended. Proposal: Delete both occurrances of the word "all." Item: 41 Page: 38 Clause: 5 Qualifier: question Rationale: Is there agreement on when entries are added to appnLsStatusTable? Proposal: Identify when entries are added. APPN MIB review [Page 15] Item: 42 Page: 38 Clause: 5 Qualifier: minor Rationale: The description of appnLsStatusEntry is not satisfied by the behavior of appnLsStatusIndex. After a wrap has occurred, GET-NEXT will not be limited to retriev- ing only updates to the table. Proposal: Clarify the algorithm for retrieving updates to make use of appnLsStatusTime as a termination condition. Note that this will not be of use with GET-BULK retrieval. Item: 43 Page: 39 Clause: 5 Qualifier: question Rationale: Are all the columns identified in AppnLsStatusEntry present for all rows? Meaningful values appear to be defined for all columns. Proposal: Identify explicitly any columns which are not always present in all rows. Item: 44 Page: 39 Clause: 5 Qualifier: minor Rationale: The description of appnLsStatusTime gives an example that is not supported by the rest of the MIB. The "last the the APPN node was re-initialized" is not available as DateAndTime. Proposal: Either change the example or add the missing object. APPN MIB review [Page 16] Item: 45 Page: 44 Clause: 5 Qualifier: question Rationale: For appnVrnName, is the intent for the definitions to make use of the same format as is defined for, e.g, appnNodeEnNnServer? Proposal: If so, make use of a common textual convention. Item: 46 Page: 46 Clause: 5 Qualifier: question Rationale: Is the implementation choice allowed in the descrip- tion of appnNnTopoMaxNodes and appnNnTopoCurNumNodes in the best interest of interoperability? Can statis- tics collected using the two algorithms be combined in any meaningful way? Proposal: Pick one of the algorithms. There is a clear require- ment (though not explicit in the MIB definition) that the same choice be made for both objects. Item: 47 Page: 49 Clause: 5 Qualifier: editorial Rationale: The description of appnNnNodeFREntryTimeLeft allows more implementation freedom than was probably intended. Proposal: Replace "this or the next" with something clearer. Item: 48 Page: 50 Clause: 5 Qualifier: question Rationale: Is the range of permitted values for appnNnNodeFRRsn really -2147483648 to 2147483647? Proposal: Use Unsigned32. APPN MIB review [Page 17] Item: 49 Page: 56,70 Clause: 5 Qualifier: editorial Rationale: The current description of appnNnTgFREntryTimeLeft, appnLocalEnTgEntryTimeLeft, and does not make it clear what a value of zero means. Proposal: Add clarifying text. Item: 50 Page: 56,64,71 Clause: 5 Qualifier: minor Rationale: The description of appnNnTgFRDlcData, appnLocalTgDlc- Data, and appnLocalEnTgDlcData does not make it clear how the various address types are mapped into an octet string. For example, are X.25 dial digits represented as a character string, binary digits, packed BCD, or something else? Proposal: Describe the mapping used for each of the examples, and provide guidelines for determining the mapping to be used for other types. It may be appropriate to define a textual convention for these objects. Item: 51 Page: 57,65,71 Clause: editorial Qualifier: Rationale: The syntax of appnNnTgFRCpCpSession, appnLocalT- gCpCpSession, and appnLocalEnTgCpCpSession is identi- cal, and may be appropriate for definition as a tex- tual convention. Proposal: Consider whether the use of a textual convention would enhance readability. APPN MIB review [Page 18] Item: 52 Page: 58,65,72,86 Clause: editorial Qualifier: Rationale: The definitions of appnNnTgFREffCap, appnLocalTgEff- Cap, appnLocalEnTgEffCap, appnCosTgRowEffCapMin, and appnCosTgRowEffCapMax all refer to the encoding of byte 7 of cv47. Proposal: Consider whether the use of a textual convention would enhance readability. Item: 53 Page: 59,67,73,89 Clause: editorial Qualifier: Rationale: The definitions of appnNnTgFRDelay, appnLocalTgDelay, appnLocalEnTgDelay, appnCosTgRowDelayMin, and appn- CosTgRowDelayMax all refer to the encoding of byte 17 of cv47. Proposal: Consider whether the use of a textual convention would enhance readability. Item: 54 Page: 59+ Clause: 5 Qualifier: minor Rationale: In the description of appnNnTgFRSecurity, appnLocalT- gSecurity, appnLocalEnTgSecurity, appnCosTgRowSecuri- tyMin, and appnCosTgRowSecurityMax, it is unclear which of the specified values should be used when the user-defined characteristics are used. (The phrase "other than the ones defined here" makes it sound like some value other than the ones permitted by the enu- meration might be used, contrary to the syntax speci- fication.) Proposal: Identify the value(s) to be used in the "other" case. A textual convention may be appropriate. APPN MIB review [Page 19] Item: 55 Page: 60+ Clause: 5 Qualifier: editorial Rationale: The descriptions of appnNnTgFRUsr1, appnNnTgFRUsr2, appnNnTgFRUsr3, appnLocalTgUsr1, appnLocalTgUsr2, appnLocalTgUsr3, appnLocalEnTgUsr1, appnLocalEnTgUsr2, appnLocalEnTgUsr3, appnCosTgRowUsr1Min, appnCosT- gRowUsr1Max, appnCosTgRowUsr2Min, appnCosTgRowUsr2Max, appnCosTgRowUsr3Min, and appnCosTgRowUsr3Max are rather vacuous. Proposal: If possible, pin down just what these variables mean. Item: 56 Page: 61 Clause: 5 Qualifier: question Rationale: The syntax of appnNnTgFRSubareaNum would imply that negative subarea numbers are permitted. Is this intentional? Proposal: Choose an appropriate syntax, such as Unsigned32. Item: 57 Page: 69 Clause: 5 Qualifier: editorial Rationale: The second sentence of the description of appnLoca- lEnTgTable is odd. This sentence tells us what is not in the table, but doesn't tell us what is in the table. Proposal: Clarify. APPN MIB review [Page 20] Item: 58 Page: 74 Clause: 5 Qualifier: Major Rationale: The syntax of appnDirMaxCaches is in conflict with the object's semantics and the syntaxes of related objects. Negative cache sizes are not meaningful. Proposal: Change the syntax to Unsigned32. Item: 59 Page: 78 Clause: 5 Qualifier: editorial Rationale: There is a missing "'" at the end of the description of appnDirLuOwnerName. Also, the format "ccc*" is unclear as to whether "ccc" represents exactly three characters or one to sixteen characters. Proposal: Change /'*"/ to /'*'"/, and clarify what is meant by "ccc". Item: 60 Page: 84 Clause: 5 Qualifier: editorial Rationale: The description text for appnCosNodeRowMinCongestAllow and appnCosNodeRowMaxCongestAllow is incomprehensible. Proposal: Clarify what is meant. Item: 61 Page: 92 Clause: 5 Qualifier: editorial Rationale: The second paragraph of description text for appnIsIn- GlobeCtrAdminStatus is confusing, especially in light of the following paragraph. For example, none of the objects referred to are counters. Proposal: Identify the objects, and refer to the collected data as "counts" rather than "counters". Make similar adjustments to the description text of APPN MIB review [Page 21] appnIsInGlobeCtrOperStatus. Item: 62 Page: 96 Clause: 5 Qualifier: Major Rationale: The labels and values of the enumeration for the syn- tax of appnIsInSessState do not match the description text. Proposal: Align the syntax and the description. Item: 63 Page: 99 Clause: 5 Qualifier: minor Rationale: The UNITS clauses on appnIsInSessUpTime and appnIsInC- trUpTime are superfluous; the units are inherent in the definition of TimeTicks. Item: 64 Page: 99+ Clause: 5 Qualifier: minor Rationale: The syntax for appnIsInP2SFmdPius, appnIsInS2PFmdPius, appnIsInP2SNonFmdPius, appnIsInS2PNonFmdPius, appnIs- InP2SFmdBytes, appnIsInS2PFmdBytes, appnIsInP2SNonFmd- Bytes, and appnIsInS2PNonFmdBytes does not match the object semantics. In particular, a range of -2147483648 to 2147483647 is not meaningful for what are really counts. Proposal: Unsigned32 would be more appropriate. It would also be helpful to explicitly reference appnIsInGlobeCtrAd- minStatus in the descriptions, and to refer to them as counts rather than counters. APPN MIB review [Page 22] Item: 65 Page: 102 Clause: 5 Qualifier: minor Rationale: It would be helpful to provide UNITS clauses for app- nIsInPsSendRpc, appnIsInPsSendNxWndwSize, appnIs- InPsRecvRpc, appnIsInPsRecvNxWndwSize, app- nIsInSsSendRpc, appnIsInSsSendNxWndwSize, appnIsInSs- RecvRpc, appnIsInSsRecvNxWndwSize, and appnIsRtpSes- sions. Proposal: Add UNITS clauses. Item: 66 Page: 105 Clause: 5 Qualifier: minor Rationale: The description text for appnIsInRouteInfo does not make it clear whether "not present" means that the object does not exist or that it should have a spe- cific value, such as a zero length string. Proposal: Clarify what is meant by "not present." Item: 67 Page: 108 Clause: 5 Qualifier: questions Rationale: For alertIdNumber and affectedObject, was the inten- tion for these objects to be "read-only" or "accessi- ble-for-notify"? Proposal: Specify the value taken by affectedObject when no object is associated with the alert in question. Depending on the alerts, it may be appropriate for it to have a RowPointer syntax. APPN MIB review [Page 23] Item: 68 Page: 119 Clause: 5 Qualifier: minor Rationale: For appnTrapConfGroup, it might by more appropriate to describe it as a NOTIFICATION-GROUP than an OBJECT group. Proposal: Re-cast appnTrapConfGroup as a NOTIFICATION-GROUP Item: 69 Page: 120 Clause: 7 Qualifier: editorial Rationale: References [9] and [13] are incomplete. Proposal: Complete the references. APPN MIB review [Page 24]
- Results of APPN MIB Review Bill Kwan
- Results of APPN MIB Review Bill Kwan