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: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 7 Sep 2006 22:35:32 +0200

I thought (But Dan can correct me if he wants) that we did
not want to cc: mib-doctors on all discussions because

- most normal wg members are not subscribers to mib-doctors,
  and so cannot post (with me approving the posting).
  We want to keep it that way, you do not want to see all the
  spam that I now delete.

- We do not want to start flooding the mib-doctors list with
  postings.

We would bcc: the mib doctors, so we can all see the initial
review comments. I would think that for most things we
could then join discussion on the specific WG list.
If we get responses that we also want the mib-doctors to see,
we can forward, or we can again bcc: on our own responses.

So that is my current understanding of how we operate.

Bert
p.s. I had not bcc:-ed my first 2 reviews of other IMSS MIB modules,
I had siad I would post them if any otehr MIB doctor wants to see
them. They were posted to imss list.

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Thursday, September 07, 2006 21:59
> To: [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 (fwd)
> 
> 
> 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
> 

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