Subject: [MIB-DOCTORS] 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

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

---

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

Thanks for your follow up/reaction Dave.

See my response inline

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

Aha... it was a guess. I was not sure. 
What I wanted to trigegr is that it gets documented.

Your writeup of scenarios below helps the WG (I hope) to
figure out what it wants and then to document that.

more below

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

I certainly agree with the "try to NOT REQUIRE createAndWait" support.
But this WG (and the main author(s)) of the WG MIB documents seem to
think it is fine cause they never make that optional via an OBJECT
clause in the MODULE-COMPLIANCE. So I would prefer they would do so,
but I dont; think that we (as MIB doctors or MIB reviewers can 
tell them taht they MUST follow our (subjective) opreferences.

But maybe this discussion between you and me helps some revisit
this topic. Anyway, at WG Last Call, this is probably not the 
best moment to bring this up or at least not to DEMAND change.

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

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