Subject: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB in draft-ietf-imss-f c-zs-mib-00.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 7 Sep 2006 17:50:44 +0200

T11-FC-FABRIC-LOCK-MIB review

--------- questions/comments

- DESSCIPTION clause of t11FLockApplicationID says:
           The value assigned to identify the 'application' for a
           lock established via Acquire Change Authorization (ACA)
           request is: 'D0'h (208 decimal).  This value will be
           documented in a future revision of the FC-SW-nn
           specification."

   Do we have any idea as to "when such future FC-SW-nn will show
   up ?? If not, is this acceptable?

- For t11FLockInitiator, in the case the SNMP, would it not be 
  wise/usefull to add the snmpSecuityName?

- Reading:

   t11FLockRowStatus OBJECT-TYPE
      SYNTAX        RowStatus
      MAX-ACCESS    read-create
      STATUS        current
      DESCRIPTION
           "The status of this conceptual row.

           A row for which the value of t11FLockInitiatorType is
           not 'snmp' cannot be deleted via this object."

  I wonder:
  - can a row be set to notReady or notInservice for rows that
    were not created by 'snmp'? I guess not, but one could get
    the impression that such is possible based on this one 
    sentence
  - What is the persistence behaviour of a row created via snmp?
    Probably nonVolatile? But would be good to say something
    about it.

- SO I see:

    t11FLockStatus OBJECT-TYPE
        SYNTAX        INTEGER {
                      active(1),
                      settingUp(2),
                      rejectFailure(3),
                      otherFailure(4)
                  }

  and wonder what will happen if the lock gets released?
  not sure I understand how such happens, but I would assume a lock does
  not stay forever once it has become active, does it?
  Does the entry disappear in that case? 

--------- NITS

- in t11FLockEntry DESCRIPTION clause I read 4th para:

          Recently, a distinct value of Application_ID has also been
          assigned/reserved as a means of distinguishing locks
          established via Acquire Change Authorization (ACA)
          requests.  With this recent assignment, an Application_ID

  I think I would remove "Recently" and "recent".
  This document is intended for a reasonably long lifespan in the
  future, no?

- REFERENCE clauses of course need to be updated.

- for t11FLockActiveGroup, the deascription clause does not say that
  (if write/create-mode is supported) that a lock can also be
  established.

Bert

_______________________________________________
imss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss

---

From: "David T. Perkins" <[email-masked]>
Date: Thu, 7 Sep 2006 12:00:13 -0700 (PDT)

HI,

For your generic question "can a row be set to notReady or notInservice
for rows that were not created by 'snmp'?"
I disagree with your response of "I guess not".

The generic answer is always "it depends". 

Note that I'm biased againest supporting "notReady" and "notInService"
because they add much complexity to the implementation of agent
access routines, and believe that well designed MIB modules can
live without them (and createAndWait).

But back to your question...
Consider the following scenario:
1) rows created via SNMP in table A
2) configuration saved
3) system rebooted
4) on startup the system reads saved configuration
   and "applies" it, which result in rows created in table A
5) an SNMP set creates additional rows in table A
6) CLI commands are executed that creates additional rows in table A
7) operation of the managed subsystem creates rows in table A

Are the rows created by system startup "different" than rows
create by other means? 
First, I believe that there are two classes of rows:
 1) those created during operation of the managed subsystem
 2) those created by management action
And for both, there may be semantics that control the deletion
of the rows and the persistence of the rows. Note that I'm
also biased againest use of the StorageType TC, since many
systems don't support saving individual instances of configuration.
Configuration persistance is all or nothing, and config
can be saved to specific targets (which is not directly supported
by the StorageType TC (note: I hear the "but contexts can be
used to specify different targets" song in the background
(which is a dream))).

So the "depends" to me means that the MIB module designer
must specify the semantics to say exactly what should be
supported.

On other questions, see inline...

>   wise/usefull to add the snmpSecuityName?
Don't know that complete context of this. Please note that
there is a broken design pattern used in several of the DISMAN
MIB modules that save the snmpSecuityName in a "secret" location.
This presents problems, so don't do that. If you are to
save an Initiator name, make sure it is accessible, and
that the process works if the initiation is done via other
management interfaces, sich as the CLI, WEB interface, or
a specific protocol. 

>   (if write/create-mode is supported) that a lock can also be
Regards,
/david t. perkins