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

["David T. Perkins" <[e-mail]>]

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...

On Thu, 7 Sep 2006, Wijnen, Bert (Bert) wrote:
> 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?
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. 

> - 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
Regards,
/david t. perkins


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