First response to Randy Presuhn's APPN MIB comments
"R.E. (Robert) Moore (254-4436)" <REMOORE@ralvm6.vnet.ibm.com> Tue, 20 August 1996 18:54 UTC
Received: from ietf.org by ietf.org id aa21745; 20 Aug 96 14:54 EDT
Received: from cnri by ietf.org id aa21740; 20 Aug 96 14:54 EDT
Received: from [171.69.3.10] by CNRI.Reston.VA.US id aa11945; 20 Aug 96 14:54 EDT
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by fontina.cisco.com (8.6.12/8.6.5) with ESMTP id LAA17673 for <snanaumib@aliashost.cisco.com>; Tue, 20 Aug 1996 11:49:10 -0700
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id LAA16480 for <snanaumib@cisco.com>; Tue, 20 Aug 1996 11:52:40 -0700
Message-Id: <199608201852.LAA16480@hubbub.cisco.com>
Received: from RALVM6 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5951; Tue, 20 Aug 96 14:48:36 EDT
Date: Tue, 20 Aug 1996 14:41:59 -0400
Sender: ietf-archive-request@ietf.org
From: "R.E. (Robert) Moore (254-4436)" <REMOORE@ralvm6.vnet.ibm.com>
To: aiw-appn-mibs@www.raleigh.ibm.com, snanaumib@cisco.com
Subject: First response to Randy Presuhn's APPN MIB comments
I've made a pass through Randy's comments on the APPN MIB, and inserted a "BobM>" response to each. These are not necessarily how we'll word our responses to Randy--they're just for the WG / SIG for now. I'll start editing the APPN MIB, to make the changes that are (or at least should be!) non-controversial. Meanwhile, if anyone has something to add on any of these 69 points, please speak up. Thanks, Bob Moore, IBM Network Management Architecture +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Date: Thu, 25 Jul 1996 13:59:45 -0700 From: Randy Presuhn <rpresuhn@peer.com> To: billk@jti.com Subject: APPN MIB Review Cc: clouston@cisco.com, kostick@qsun.ho.att.com, remoore@ralvm6.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit 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. BobM> We'll need to respond to Randy, saying that the decision was a BobM> conscious one, and that while it's unusual, we *do* have a low- BobM> overhead way of detecting changes to the FR tables. 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. BobM> We'll need to respond to Randy, saying that the decision was a BobM> conscious one. 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. BobM> OK; BobC to fix. Item: 4 Page: 2 Clause: 4 Qualifier: editorial Rationale: Consistency of reference style. Proposal: Replace "(RFC1666 [8])" with "[8]" in the first para- graph. BobM> OK; BobC to fix. 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. BobM> OK; BobC to fix. Item: 6 Page: 3 Clause: 4 Qualifier: editorial Rationale: Typo. Proposal: Replace "LLCMIB" with "LLC MIB" in the first paragraph on page 3. BobM> OK; BobC to fix. 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. BobM> OK in principle. I'll update the MIB module with several TCs, BobM> for the different varieties of names present in the MIB. After BobM> I've done this, BobC can determine whether the front matter needs BobM> to be changed as well. 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". BobM> I'll add character set descriptions to the textual conventions. BobM> BobC will re-work this example. 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. BobM> OK; BobC to fix. 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. BobM> I agree with the comment, but I'm not sure how/where to put the BobM> expansions for these acronyms. Any suggestions? Item: 11 Page: 10 Clause: 5 Qualifier: minor Rationale: Is "{ experimental 1000 }" the correct registration for this MIB? Proposal: Update with the official registration. BobM> Bill Kwan is working on this. He should have a fix to propose in BobM> a few days. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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, 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. BobM> OK; BobM to fix. 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? BobM> This sounds like a pretty esoteric problem to be worrying about. BobM> How is this handled in other MIBs? 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, 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. Proposal: Identify the mapping between the various bit combina- tions and the enumeration values. BobM> This seems unnecessary to me. Most of these are just mapping a bit BobM> in a CV to a TruthValue. Where they aren't, an implementer who BobM> reads SNA Formats shouldn't have any trouble deciding what to do. 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). BobM> OK; BobM to fix, but I'll double check first to make this is what BobM> it really means. 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. BobM> I'll add pointers to the "discontinuity indicators" for these BobM> counters. I'm not quite sure what point Randy is making about BobM> initial values, though. 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, and negative indexes are not permitted, a syntax of Unsigned32 would probably be appropriate. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> I don't know what Randy is asking for here. Any proposals? 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. BobM> This may take a little work to clarify. This is where we were BobM> *trying* to have an object that could either point to an ifEntry BobM> (if there was one), or if not, point to something else, or to BobM> nothing. 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 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. BobM> I'll clarify the text, since Randy has missed the admin versus BobM> oper distinction (in this case). 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. BobM> This comment seems correct to me. Do we want to add another BobM> time stamp for these counters (presumably in our usual BobM> DateAndTime format)? 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. BobM> OK; BobM to fix. 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. BobM> See item 27 above. I don't think RowPointer does all that we're BobM> trying to do with this object. Comments? 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. BobM> We decided to leave this unspecified in the MIB. For "old" DLCs BobM> we're assuming that the format is obvious. For "new" ones, we'll BobM> specify it explicitly in an architecture document, as we did in BobM> Gary Dudley's for HPR over ATM. 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. BobM> I'll look into this. I'm not sure Randy's hypothesis is correct BobM> here. 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. BobM> I'll look into this. 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. BobM> This is basically the same comment as item 23 above, but we must BobM> be wearing Randy down: 23 was major, but this one's only minor;-). BobM> Do we want yet another DateAndTime here? 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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". BobM> OK; BobM to fix. 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." BobM> OK; BobM to fix. 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. BobM> What can we say here? I'm not sure whether Randy is asking in BobM> what situations/scenarios entries are added, or at exactly what BobM> point in time they're added in these scenarios. 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. BobM> Clearly this index will never wrap in practice, so what should we BobM> say here? 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. BobM> We need to think about this one. Thoughts? 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. BobM> I guess Randy's right about this. A Management Station can BobM> retrieve appnUpTime and get an approximate DateAndTime when the BobM> node was last re-initialized. Is this good enough? 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. BobM> OK; BobM to fix as part of overall textual conventions. 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. BobM> We'll need to look at the APPN architecture for TRS here. At the BobM> very least, Randy's correct that a single node should use the same BobM> algorithm for both of these 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. BobM> I'll check the architecture on this point. Item: 48 Page: 50 Clause: 5 Qualifier: question Rationale: Is the range of permitted values for appnNnNodeFRRsn really -2147483648 to 2147483647? Proposal: Use Unsigned32. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> See item 32 above. 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. BobM> I think that a textual convention here enhances maintainability BobM> at the cost of *decreased* readability, but I'll go ahead and BobM> add the textual convention unless somebody thinks I shouldn't. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> Randy's misreading this, so I'll see if I can clarify it. 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. BobM> I'll check, but I suspect that the descriptions capture every BobM> shred of information that's there in the architecture itself. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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". BobM> OK; BobM to fix. Item: 60 Page: 84 Clause: 5 Qualifier: editorial Rationale: The description text for appnCosNodeRowMinCongestAllow and appnCosNodeRowMaxCongestAllow is incomprehensible. Proposal: Clarify what is meant. BobM> OK; BobM to fix. 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 appnIsInGlobeCtrOperStatus. BobM> I'm not sure I agree with Randy's premise that SMI has reserved the BobM> word "counter" for its Counternn syntaxes, but I'll clarify this BobM> text. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. 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." BobM> OK; BobM to fix. 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. BobM> OK; BobM to fix. I think the intent here was for these objects BobM> to be accessible-for-notify. 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 BobM> OK; BobM to fix, but I think we need *both* an OBJECT-GROUP and a BobM> NOTIFICATION-GROUP. Item: 69 Page: 120 Clause: 7 Qualifier: editorial Rationale: References [9] and [13] are incomplete. Proposal: Complete the references. BobM> OK; BobC to fix.
- First response to Randy Presuhn's APPN MIB commen… R.E. (Robert) Moore (254-4436)
- Re: First response to Randy Presuhn's APPN MIB co… Randy Presuhn