Randy's comments on the DLUR and HPR MIBs

["R.E. (Robert) Moore (254-4436)" <[e-mail]>]

As I promised, here are Randy's comments on our two MIBs.  We're going to
discuss these at AIW 13, but as I said earlier, we should try to start
any significant discussions beforehand on the mailing lists.

Bob Moore
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Date: Tue, 25 Feb 1997 11:17:11 -0800
From: Randy Presuhn <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Review of SNANAU DLUR MIB
Cc: [e-mail], [e-mail], [e-mail],
        [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=X-roman8
Content-Transfer-Encoding: 7bit

Hi Deirdre -

As requested, I have reviewed <draft-ietf-snanau-dlurmib-00.txt>
I think it needs another round, with special attention to the
indexing issues and making its relationship to the other SNA
MIBs more explicit.  My comments are attached.


Item:		0
Severity:	minor
Page:		general
Clause:		general, especially 4
Rationale:	Scattered through the MIB are references to other SNA-
		related MIBs, including SNANAU and APPN.  Clearly these
		fit together in some grand scheme.
Proposal:	Add text to clause 4 (perhaps a new clause 4.2) outlining
		the relationship of this MIB to other MIBs.  In
		particular, it would be helpful to describe any
		"referential integrity" constraints ("shared" indexes,
		"foreign keys", and relationships (dependencies?))
		between entries in these other MIBs and this MIB.

Item:		1
Severity:	editorial
Page:		2
Clause:		4
Rationale:	Missing definition of acronym.
Proposal:	In the third paragraph, define "PU"

Item:		2
Severity:	editorial
Page:		2
Clause:		4
Rationale:	Missing definition of abbreviation.
Proposal:	It would be helpful to spell out what CPSVRMGR stands
		for.  (Control Point Server Manager?)

Item:		3
Severity:	minor
Page:		3
Clause:		4
Rationale:	Completeness.
Proposal:	Identify which conditions causing APPN MIB traps affect
		DLUR resources.  In particular, how would one go from
		the varbinds in an APPN MIB trap to a specific table
		row in the DLUR MIB?

Item:		4
Severity:	editorial
Page:		3
Clause:		4.1
Rationale:	Clarity.  The word "group" appears to be used here and
		in the following clause (4.1.1) in both the English and
		the RFC 1904 senses.
Proposal:	Replace "groups" with "collections" in the first sentence.
		Delete "groups" in the last sentence.

Item:		5
Severity:	minor
Page:		6
Clause:		5
Rationale:	Some (broken) MIB compilers choke on lines of dashes.
Proposal:	Fix the line immediately following "Textual Convention".

Item:		6
Severity:	question/major
Page:		6
Clause:		5
Question:	Is it intended that there shall never be more than one
		APPN node per managed system?  Is it impossible for a
		single managed system to be multiple APPN nodes?  If not,
		then dlurNodeCpName through dlurDefaultDefPrimDlusName
		would need to be in a table.

Item:		7
Severity:	Major
Page:		8-9
Clause:		5
Rationale:	Consistency and accuracy.  The DESCRIPTION for
		dlurDefaultDefBackupDlusTable describes the entries
		as being ordered by preference.  The DESCRIPTION for
		dlurDefaultDefBackupDlusEntry says the index is arbitrary.
		The SYNTAX for dlurDefaultDefBackupDlusIndex limits the
		index range without explanation, and its DESCRIPTION does
		not give any clue that this index has preference semantics.
Proposal:	Modify the DESCRIPTIONs for dlurDefaultDefBackupDlusEntry
		and for dlurDefaultDefBackupDlusIndex to reflect the actual
		indexing semantics.  Explain the range constraints on
		dlurDefaultDefBackupDlusIndex.

Item:		8
Severity:	editorial
Page:		9
Clause:		5
Rationale:	It is not clear what is meant by the three uses of the
		phrase "DLUR-unique" on this page.
Proposal:	Clarify. :-)


Item:		9
Severity:	editorial
Page:		10
Clause:		5
Rationale:	Missing reference (SNANAU MIB) in dlurPuName DESCRIPTION.
Proposal:	Add the reference to clause 7.

Item:		10
Severity:	MAJOR
Page:		10
Clause:		5
Rationale:	Imaginary object?  I am unable to find a definition for
		snaNodeSscpSuppliedName (referenced in the
		description of dlurPuSscpSuppliedName) in RFC1666 or in
		<draft-ietf-snanau-naumib-00.txt> (which has expired,
		by the way).
Proposal:	Correct the reference, adding to the references section
		as needed.


Item:		11
Severity:	Minor
Page:		11
Clause:		5
Rationale:	The meanings of the possible values in this enumeration
		for dlurPuStatus are missing.
Proposal:	Explain the significance of each of the possible values
		in the DESCRIPTION of dlurPuStatus.

Item:		12
Severity:	Question
Page:		12
Clause:		5
Rationale:	Verification of understanding.  Is this how the states
		of the contention winner and contention loser are
		combined for dlurPuDlusSessnStatus?  Is the loss of
		information acceptable?

			   | pA | pI | A | X = !(pA | pI | A)
			---+----+----+---+----------------
			pA | 2  |  2 | 2 | 2
			---+----+----+---+----------------
			pI | 2  |  4 | 4 | 4
			---+----+----+---+----------------
			A  | 2  |  4 | 3 | 1
			---+----+----+---+----------------
			X  | 2  |  4 | 1 | 1
			---+----+----+---+----------------

Item:		13
Severity:	minor
Page:		12
Clause:		5
Rationale:	The phrase "if present" in the DESCRIPTION of
		dlurPuActiveDlusName is potentially ambiguous.
Proposal:	Replace "If present" with "If the length is
		not zero".

Item:		14
Severity:	Major
Page:		14
Clause:		5
Rationale:	See item 7 above.  The DESCRIPTIONs for the indexing
		of dlurPuDefDackupDlusTable, dlurPuDefBackupDlusEntry,
		and dlurPuDefBackupDlusIndex are inconsistent.
Proposal:	Modify these DESCRIPTIONs to describe the intended
		preference semantics and the motivation for the
		range constraints.

Item:		15
Severity:	Question
Page:		15
Clause:		5
Question:	The definition of dlurDlusName would indicate that there
		is an architectural limit of one CPSVRMGR pipe between
		any DLUS/DLUR pair.  If this is not correct, the indexing
		structure of this table would need to be changed.


Item:		16
Severity:	Question
Page:		16
Clause:		5
Question:	For the dlurDlusSessnStatus, is the state combination
		matrix like that for item 12 above, and is the information
		loss acceptible?

Item:		17
Severity:	Major
Page:		19
Clause:		8
Rationale:	Vacuous security considerations sections are no longer
		acceptible.
Proposal:	Determine the risks of exposing the information provided
		by this mib are, so that appropriate SNMP protections can
		be configured.  Note that there are no writable or creatable
		objects.

 ---------------------------------------------------------------------
 Randy Presuhn            BMC Software, Inc. (Silicon Valley Division)
 Voice: [phone]   (Formerly PEER Networks)  http://www.bmc.com
 Fax:   [phone]   1190 Saratoga Avenue, Suite 130
 Email: [e-mail]  San Jose, California 95129-3433  USA
 ---------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy memo dated December 10, 1996, page 2, item (g) (the first of
 two), I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 ---------------------------------------------------------------------


Date: Fri, 28 Feb 1997 20:09:10 -0800
From: Randy Presuhn <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: SNANAU HPR MIB review
Cc: [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=X-roman8
Content-Transfer-Encoding: 7bit

Hi Deirdre -

I've completed my initial review of <draft-ietf-snanau-hprmib-00.txt>
My comments are attached.  I think it needs another round of comment.
My biggest concerns are:

        - relationship of indexing structure to APPN MIB
        - missing security considerations
        - internal inconsistency on support for switching to a
          specified path.
        - interactions resulting from ability to turn counting
          off and on.


Item:           1
Severity:       editorial
Page:           2
Clause:         4
Proposal:       Delete "the proposed set of" in the first sentence of the
                first paragraph in this clause.

Item:           2
Severity:       question
Page:           3
Clause:         4
Question:       It the sentence at the very top of the page, is the path
                really always going to be optimal?

Item:           3
Severity:       editorial
Page:           3
Clause:         4
Rationale:      Complete references are helpful.
Proposal:       Provide a reference for the ARB algorithm.

Item:           4
Severity:       editorial
Page:           3
Clause:         4
Rationale:      Organization.
Proposal:       Move the paragraph beginning "The HPR terms and..." to the
                beginning of the section.  It would be valuable to provide
                sources for the HPR architecture beyond an FTP site.

Item:           5
Severity:       editorial
Page:           3
Clause:         4
Rationale:      Terms should be defined.
Proposal:       Define "Transport Tower". (third bullet on page)

Item:           6
Severity:       minor
Page:           3
Clause:         4
Rationale:      In the last bullet in the second group of bullets,
                there is reference to an APPN MIB trap.  It would
                be helpful to explain how one would get to this
                MIB from the information carried by that trap.
Proposal:       Add text explaining relationship between APPN MIB traps
                and this MIB.

Item:           7
Severity:       minor
Page:           3
Clause:         4
Rationale:      The relationships between this MIB and the APPN MIB
                should be explained more fully.  At the very least,
                the indexing relationships between the MIBs should
                be spelled out, particularly if there are any
                potential referential integrity issues when objects
                are used as foreign keys into tables in other MIBs.
Proposal:       Identify the objects in this MIB used as keys into
                the APPN MIB.  Identify the objects from the APPN
                MIB used as keys into this MIB.

Item:           8
Severity:       editorial
Page:           3
Clause:         4.1
Rationale:      The term "group" is used in both the RFC 1904 sense and
                the English sense.
Proposal:       Replace "groups" with "collections" in the first sentence.

Item:           9
Severity:       editorial
Page:           4
Clause:         4.1.1
Rationale:      Expand abbreviations - CP is used before being defined.
Proposal:       Add the expansion of CP to the first sentence.  (It is
                defined later at the bottom of the page.)

Item:           10
Severity:       editorial
Page:           4
Clause:         4.1.2
Rationale:      A numbered list with only one item isn't particularly helpful.
Proposal:       Replace "1) hprAnrRoutingTable ... This table" with
                "The hprAnrRoutingTable"

Item:           11
Severity:       editorial
Page:           4
Clause:         4.1.3
Rationale:      A numbered list with only one item isn't particularly helpful.
Proposal:       Replace "1) hprNceTable ... This table" with
                "The hprNceTable"

Item:           12
Severity:       editorial
Page:           5
Clause:         4.1.4
Rationale:      Expand abbreviations
Proposal:       Explain what TCID is in the third paragraph.

Item:           13
Severity:       editorial
Page:           6
Clause:         5
Rationale:      readability
Proposal:       add a blank line after the last of the IMPORTS

Item:           14
Severity:       minor
Page:           7
Clause:         5
Rationale:      Some MIB compilers choke on lines of dashes
Proposal:       Get rid of the line of dashes

Item:           15
Severity:       editorial
Page:           7
Clause:         5
Rationale:      Clarity.
Proposal:       Insert the words "correspondingly indexed" before
                "hprRtpCounterDisconTime".

Item:           16
Severity:       question
Page:           7
Clause:         5
Question:       It is not clear what is meant by "corresponds to" in the
                DESCRIPTION of hprNodeCpName.  If the value is the same,
                why is this object needed?  If it can be different, how
                are they related?  What does this object DO?

Item:           17
Severity:       minor
Page:           7
Clause:         5
Rationale:      The hprUpTime object is not used.
Proposal:       Use it or delete it.  There are several references in
                this MIB to appnNodeCounterDisconTime that should
                probably be references to this object.

Item:           18
Severity:       major
Page:           8
Clause:         5
Rationale:      The description of switchToPathSupported is in direct
                conflict with the text on page 19 for
                hprRtpPathSwitchTrigger, which in the last paragraph
                of its DESCRIPTION says this module provides no
                such feature.
Proposal:       Either delete this value or add the necessary support
                object.

Item:           19
Severity:       minor
Page:           8
Clause:         5
Rationale:      It is unclear why hprAnrsAssigned uses an object from
                the appn MIB as its discontinuity indicator.
Proposal:       Explain it or use the hprUpTime object instead.

Item:           20
Severity:       minor
Page:           8
Clause:         5
Rationale:      missing UNITS.
Proposal:       Add UNITS to hprAnrsAssigned.

Item:           21
Severity:       minor
Page:           9
Clause:         5
Rationale:      No rationale is given for counters being set to / held at
                zero when hprAnrCounterState is notActive.
Proposal:       Explain the reason for this additional constraint or
                remove it.

Item:           22
Severity:       minor
Page:           9
Clause:         5
Rationale:      The start-up value for hprAnrCounterStateTime should be
                defined.
Proposal:       Add text describing initial value for this object.

Item:           23
Severity:       editorial
Page:           9
Clause:         5
Rationale:      It is not clear what is meant by "TG information objects".
Proposal:       Identify which objects are meant by "TG information objects"

Item:           24
Severity:       minor
Page:           11
Clause:         5
Rationale:      It looks like there may be a slight ambiguity to the
                use of the value 0 with hprAnrOutTgNum, since this is
                a legitimate value for appnLocalTgNum in the APPn MIB.
Proposal:       Some explanatory text might be helpful here, particularly
                if I've been led astray.  :-)

Item:           25
Severity:       editorial
Page:           11
Clause:         5
Rationale:      In the DESCRIPTION of hprAnrPacketsReceived, the word "total"
                may be misleading, unless there is a strong assumption that
                the counter is zero-based.  Also, it should be explicit
                that the hprAnrCounterDisconTime to monitor is the one
                in the same row.
Proposal:       Replace "total" with "count"; add "in the same row" at the
                end of the description.

Item:           26
Severity:       minor
Page:           11
Clause:         5
Rationale:      need UNITS
Proposal:       add UNITS to hprAnrPacketsReceived

Item:           27
Severity:       minor
Page:           12
Clause:         5
Rationale:      The definition of hprAnrCounterState's notActive value on
                page 9 means that these counters experience discontinuity
                not only when they are turned on, but also when they are
                turned off.
Proposal:       Add "or off" to the end of the description for
                hprAnrCounterDisconTime.

Item:           28
Severity:       minor
Page:           12
Clause:         5
Rationale:      In the description of hprAnrCounterDisconTime, the word
                "later" may be problematic.  If sysUpTime is reset for
                some reason, recording its value here may result in a
                SMALLER value.  In general, one can't make assumptions
                about this variable being non-decreasing.  What sysUpTime
                reports is not really a time, but rather an interval.
Proposal:       Replace "later" with "most recent".

Item:           29
Severity:       minor
Page:           13
Clause:         5
Rationale:      The relationship of the hprNceId index to other tables
                and MIBs should be described, if there is any.
Proposal:       ?

Item:           30
Severity:       minor
Page:           13
Clause:         5
Rationale:      The enumeration for hprNceType is awkward and unenlightening.
Proposal:       Use the BITS construct instead.

Item:           31
Severity:       minor
Page:           14
Clause:         5
Rationale:      The enumeration for hprNceDefault is awkward and
                unenlightening.  The "noDefault" value looks like a hack.
Proposal:       Use the BITS construct instead.  If no bits are set, does
                this adequately represent the "noDefault" case?  If so,
                then a TEXTUAL-CONVENTION for this and the previous
                object may be appropriate.

Item:           32
Severity:       editorial
Page:           15
Clause:         5
Rationale:      The DESCRIPTION of hpr NceInstanceId is not particularly
                enlightening.
Proposal:       Is there anything more to say about this thing?  Can its
                values be used as foreign keys into other tables?

Item:           33
Severity:       minor
Page:           15-25
Clause:         5
Rationale:      The following items lack UNITS clauses:
                        hprRtpGlobeConnSetups
                        hprRtpLivenessTimeouts
                        hprRtpShortReqTimeouts
                        hprRtpMaxSendRate
                        hprRtpMinSendRate
                        hprRtpCurSendRate
                        hprRtpSendPackets
                        hprRtpRecvPackets
                        hprRtpSendBytes
                        hprRtpRecvBytes
                        hprRtpRetrPackets
                        hprRtpPacketsDiscarded
                        hprRtpDetectGaps
                        hprRtpRateReqSends
                        hprRtpOkErrPathSws
                        hprRtpBadErrPathSws
                        hprRtpOkOpPathSws
                        hprRtpBadOpPathSws
Proposal:       Add appropriate UNITS.  Also, determine whether the
                phrase "total number" should be replaced by "count of"
                to avoid assumptions on zero-based counters.

Item:           34
Severity:       minor
Page:           15
Clause:         5
Rationale:      It is not clear why the discontinuity indicator for
                hprRtpGlobeConnSetups should be in the APPN MIB.
Proposal:       replace from "appnNodeCounterDisconTime" to the end
                of the sentence with "hprUpTime"

Item:           35
Severity:       minor
Page:           16
Clause:         5
Rationale:      For hprRtpGlobeCtrState, it is not clear why notActive
                should set/hold counters to zero.
Proposal:       Explain or delete "their values are always zero"

Item:           36
Severity:       minor
Page:           16
Clause:         5
Rationale:      The description for hprRtpGlobeCtrStateTime claims that
                this objects can be used to relate the time of a state
                change to the last time of APPN node re-initialization.
                It is not clear how this is possible, given the other
                objects in this MIB and the APPN MIB.
Proposal:       Explain it. :-)

Item:           37
Severity:       Question
Page:           16
Clause:         5
Question:       The comment preceding hprRtpTable and the index structure
                of this table implies an architectural limit of one HPR
                transport tower (whatever that is) per node.  Is this
                deliberate and appropriate?

Item:           38
Severity:       editorial
Page:           17
Clause:         5
Rationale:      cosmetics.  hprRtpRecvPackets, hprRtpSendPackets,
                hprRtpRecvBytes, and hprRtpSendBytes appear in a different
                order in the SEQUENCE and the following definitions.
Proposal:       Make the orders match.

Item:           39
Severity:       minor
Page:           18
Clause:         5
Rationale:      The relationship of the hprRtpLocNceID and hprRtpLocTcId
                indexes to objects in the APPN MIB should be spelled out
                in the descriptions.  What is the relationship of these
                to the APPN appnLsTable, appnIsInTable, and appnIsRtpTable?
Proposal:       Describe the relationships.

Item:           40
Severity:       question
Page:           18
Clause:         5
Question:       For hprRtpRemCpName, is it possible for the remote node
                name to be unknown?

Item:           41
Severity:       question
Page:           18
Clause:         5
Question:       For hprRtpRemNceId, is it possible for the remote NCE
                to be unknown?

Item:           42
Severity:       question
Page:           18
Clause:         5
Question:       For hprRtpRemTcid, is it possible for the remote TCID
                to be unknown?


Item:           43
Severity:       minor
Page:           19
Clause:         5
Rationale:      The third paragraph of the DESCRIPTION of
                hprRtpPathSwitchTrigger suggested unusual behaviour.
                RFC 1905 clause 4.2.5(10) [page 20] would suggest that
                the SNMPv2 inconsistantValue (mapping to SNMPv1 badValue)
                would be a more appropriate response.
Proposal:       Align the behaviour with SNMP.  This would be as simple
                as deleting the third paragraph.

Item:           44
Severity:       major
Page:           19
Clause:         5
Rationale:      The last paragraph of the DESCRIPTION of
                hrpRtpPathSwitchTrigger directly contradicts the text on
                page 8 for switchToPathSupported.
Proposal:       Add objects to support the desired capability.

Item:           45
Severity:       minor
Page:           22
Clause:         5
Rationale:      For the rates hprRtpMaxSendRate, hprRtpMinSendRate, and
                hprRtpCurSendRate, is the period over which the rates
                are computed implementation dependent?  The dt overwhich
                rates are computed will have significant impact on both
                the high and low water marks, particularly immediately
                after connection setup.  Is any smoothing applied?
Proposal:       If there is a standard interval over which rates are
                computed, provide it.  If not, say that it's an
                implementation choice.

Item:           46
Severity:       minor
Page:           23
Clause:         5
Rationale:      Is the smoothing algorithm for hprRtpSmRdTripDelay
                implementation-dependent?
Proposal:       If so, say so.  Otherwise, outline the characteristics
                the of smoothing algorithm to be used.

Item:           47
Severity:       minor
Page:           26
Clause:         5
Rationale:      In the description of hprRtpCounterDisconTime, the word
                "later" may be problematic.  If sysUpTime is reset for
                some reason, recording its value here may result in a
                SMALLER value.  In general, one can't make assumptions
                about this variable being non-decreasing.  What sysUpTime
                reports is not really a time, but rather an interval.
Proposal:       Replace "later" with "most recent".


Item:           48
Severity:       minor
Page:           26
Clause:         5
Rationale:      Due to the description of hprRtpGlobeCtrState, the last
                sentence of hprRtpCounterDisconTime is not complete.
Proposal:       Add "or off" to the end of the DESCRIPTION.

Item:           49
Severity:       minor
Page:           27
Clause:         5
Rationale:      The relationship of the indexes for hprRtpStatusEntry
                to the other tables in this MIB and the APPN MIB should
                be described.
Proposal:       Add text describing relationship.  Does the indexing
                structure of this table align with anticipated usage
                scenarios?

Item:           50
Severity:       minor
Page:           28
Clause:         5
Rationale:      The description of hprRtpStatusIndex needs adjustment.
                The intent appears to be to order history entries for
                a given NCEID/TCID pair chronologically, or possibly to
                provide a global chronological ordering of all history
                entries (though not supported by the index structure)
Proposal:       possible replacement text might look like:
                "Each entry in this table is assigned a unique value
                for this index, starting with zero and going through
                the integers consecutively."  Wrap behaviour should
                also be covered.

Item:           51
Severity:       questions
Page:           28
Clause:         5
Question:       Will hprRtpStatusRemCpName always be known?
Question:       Will hprRtpStatusRemNceId always be known?
Question:       Will hprRtpStatusRemTcId always be known?

Item:           52
Severity:       editorial
Page:           29
Clause:         5
Rationale:      Clarity.
Proposal:       For hprRtpStatusNewRscv and hprRtpStatusOldRscv,
                explain what a 0-length octet string means.

Item:           53
Severity:       editorial
Page:           33
Clause:         5
Rationale:      consistency
Proposal:       re-order hprRtpRecvPackets, hprRtpSendPackets,
                hprRtpRecvBytes, hprRtpSendBytes to match the
                order of the definitions.


Item:           54
Severity:       editorial
Page:           35
Clause:         7
Rationale:      The url for [5] appears to go beyond the RFC margins.
                A "real" reference would be nice.
Proposal:       ?

Item:           55
Severity:       major
Page:           36
Clause:         8
Rationale:      Vacuous security considerations are a no-no.
Proposal:       Identify the security implications of the settable
                objects in this mib.  Point to generic SNMP privacy/
                authentication stuff.  Identify any information in
                this MIB which may, through exposure, be a security
                problem.

 ---------------------------------------------------------------------
 Randy Presuhn            BMC Software, Inc. (Silicon Valley Division)
 Voice: [phone]   (Formerly PEER Networks)  http://www.bmc.com
 Fax:   [phone]   1190 Saratoga Avenue, Suite 130
 Email: [e-mail]  San Jose, California 95129-3433  USA
 ---------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy memo dated December 10, 1996, page 2, item (g) (the first of
 two), I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 ---------------------------------------------------------------------