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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 7 Sep 2006 22:26:15 +0200

I also see another few NITs now that I am reviewing the 2nd 
MIB module in the same document.

- t11FLockRejectReasonCode OBJECT-TYPE
    SYNTAX        T11NsGs4RejectReasonCode
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
           "When the value of the corresponding instance of
           t11FLockStatus is 'rejected', this object contains
           the rejection's reason code."

  Based on the ENUMerated values for t11FlockStatus, I 
  think we should change 'rejected' into 'rejectFailure'.

- same for t11FLockRejectReasonCodeExp
  and t11FLockRejectReasonVendorCode

- Now that I see t11ZsServerReasonCode, I wonder if the 2nd
  para in the DESCRIPTION clause would also make sense for
  the t11FLockRejectReasonCode object

- do the SIZE for t11ZsServerReasonCodeExp
  and t11ZsServerReasonVendorCode possibly also make sense for 
  t11FLockRejectReasonCodeExp, t11FLockRejectReasonVendorCode
  that is allowing for a SIZE of zero?

Bert

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Thursday, September 07, 2006 17:51
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB in
> draft-ietf-imss-f c-zs-mib-00.txt
> 
> 
> 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 ent" 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.
> 

Above is for the WG to discuss and decide I think.

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

I was bringing up the question. 
It may help figure out who tried to lock.
And in case multiple operators are at the same NMS, maybe if "bert"
creates a lock, maybe he does not want "perkins" to release it????
Just thinking aloud here.

For me, such does not need to be a secret. Just normal access
control.

Bert
> > - 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 assignmof 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
> 

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

ent, 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 7 Sep 2006 22:26:15 +0200

Bert