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

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

HI,

I just noticed that [email-masked] was not on the CC.

Regards,
/david t. perkins

---------- Forwarded message ----------
Date: Thu, 7 Sep 2006 12:00:13 -0700 (PDT)
From: David T. Perkins <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [MIB-DOCTORS] WG last call review: T11-FC-FABRIC-LOCK-MIB in
    draft-ietf-imss-f c-zs-mib-00.txt

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

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 7 Sep 2006 16:08:14 -0400

Hi,

I think a MIB module is an abstract interface representing the
underlying instrumentation, and if a "row" in the underlying
instrumentation is "not ready", I see no reason why that could not be
reflected in the corresponding MIB module.

(ad I am pleasantly surprised that my answer is shorter than somebody
else's for a change ;-)

dbh

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Thursday, September 07, 2006 3:59 PM
> To: [email-masked]
> Subject: Re: [MIB-DOCTORS] WG last call review: 
> T11-FC-FABRIC-LOCK-MIB indraft-ietf-imss-f c-zs-mib-00.txt (fwd)
> 
> HI,
>

---

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

HI,

The issue with the RowStatus "extra states" is that in about 99.99%
of the cases, the underlying instrumentation does not support
them, and thus, to support them the SNMP specific access
routines must provide this functionality. And when so,
this functionality does not show
up on other management interfaces that go directly to the
underlying instrumentation. 

Now, if the agent access routine writter is also the writter
of the underlying instrumentation, then this functionality
can be put in the underlying instrumentation. I've "paid off"
the writers of the underlying instrumentation to add support
for SNMP getnext and identification of managed objects to
match object definitions. However, it can be really painfull
to have to "bolt on" SNMP semantics in access routines
when the underlying instrumentation cannot be changed.

Regards,
/david t. perkins