First-pass response to Randy's DLUR MIB comments

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

Just to get us started, I've made a first pass through Randy's comments
on the DLUR MIB.  All of my responses are fair game for anyone in the
SIG / WG who thinks we should respond differently.

One item that I've presupposed in my responses is a decision by
the SIG / WG to reclassify the SNA NAU MIB as Historic.  I *think*
we (at least IBM and Cisco) agreed at AIW 12 that this is what we
wanted to do, since neither of us had an interest any longer in
completing / implementing this MIB.  But we as a SIG / WG didn't
actually make a decision to do this.

If you have comments on any of this, it would be helpful if you
could get them out onto the mailing lists prior to our meeting next
week.

Bob Moore
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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.
BobM> Thanks for giving us the credit, but I'm afraid we don't have a
BobM> "grand scheme" for fitting our MIBs together, any more than the
BobM> (old) Network Management Area in the IETF did.  The landscape will
BobM> be somewhat clearer if we demote the SNANAU MIB to Historic
BobM> status, which I'm hoping we'll agree upon next week.  Beyond this,
BobM> we can look at adding a clause that briefly positions the DLUR
BobM> MIB relative to the APPN MIB.

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

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?)
BobM> OK, BobC to fix.

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?
BobM> We can do this in part, by adding a reference to the set of
BobM> architected DLUR Alerts in SNA/MS Formats.  There won't,
BobM> however, be a linkage to any objects 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.
BobM> OK, BobC to fix.

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".
BobM> OK, BobM to fix.

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.
BobM> In most cases there will only be one APPN node per managed
BobM> system.  We're counting on MIB views / contexts to bail us out
BobM> in the rare cases where there are multiple APPN nodes in a
BobM> managed system.

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.
BobM> OK, BobM to fix.  The correct answers are:
BobM>    - The entries are ordered by preference, not arbitrarily
BobM>    - The limited range is something we came up with, but it's
BobM>      *much* bigger than what any existing DLUR product supports.
BobM>      In fact, most DLUR products support only one backup DLUS.
BobM>      We can discuss whether we want to leave this range alone
BobM>      or expand it.

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. :-)
BobM> The short answer is "Nothing."  BobM will reword this text to
BobM> make it more meaningful.


Item:         9
Severity:     editorial
Page:         10
Clause:       5
Rationale:    Missing reference (SNANAU MIB) in dlurPuName DESCRIPTION.
Proposal:     Add the reference to clause 7.
BobM> If we reclassify the SNANAU MIB as Historic, this reference will
BobM> go away.

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.
BobM> If we reclassify the SNANAU MIB as Historic, this reference will
BobM> go away.  This object is one we were *going* to add to the
BobM> SNANAU MIB, before we stopped working on it.


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.
BobM> OK, BobM to fix.

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
                   ---+----+----+---+----------------
BobM> This looks right to me.  If Randy will agree not to charge us
BobM> a royalty (:-), I may see about incorporating his matrix into
BobM> the description for this object.  And yes, this loss of information
BobM> has been thought to be acceptable for a long time.

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".
BobM> OK, BobM to fix.

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.
BobM> OK, BobM to fix.

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.
BobM> Yes, there is such a limit in the architecture.


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?
BobM> Yes and yes.

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.
BobM> We'll have to discuss this next week.