Subject: RE: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB in

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 8 Sep 2006 21:03:33 +0200

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Friday, September 08, 2006 17:42
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB in
> 
> 
> > 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?
>  
> My understanding is that FC-SW-4 is closed, and it lists 'D0'h as one
> of the reserved values.  The long-time editor of FC-SW-nn sent an email
> message dated 8Aug06 to the T11.5 mailing-list with the assignment of
> a range of values including 'D0'h for this purpose.  The assignment
> will be documented in FC-SW-5 which is approved as a new project, but
> there is no initial draft of it yet.
> 
And Claudio already seems to say it is a value of 255.
Shows that it is BEST to try and get agreement and document.

> Would you like a formal liaison message from T11 to the IETF stating
> what number has been assigned ??
> 

For me personally, I just am trying to make sure we all know/agree what
the value is (can be). And it seems we have no agreement on that yet.

It is up to your WG chair and or AD to decide if the want/need a formal 
liaison statement. 

> > - For t11FLockInitiator, in the case the SNMP, would it not be 
> >   wise/usefull to add the snmpSecuityName?
>  
> I suggest it should be possible to be a compliant implementation of this
> MIB even for an SNMPv1/SNMPv2 implementation which doesn't support SNMPv3.

Well, in IETF terms we have made CNMPv1 and SNMPv2c HISTORIC.
I understand there may be implementation that are still nto SNMPv3
compliant. But we're defining a stds track MIB here, and should (in my view)
assume that people are not using our full STD SNMP version.

> So, if we define an object to hold the value of snmpSecurityName, we
> need to define what value that object will have in an agent which does
> not implement the SNMP-COMMUNITY-MIB (in which snmpCommunitySecurityName
> is defined).  What value would you propose ??
> 

I feel that we do NOT have to spec out what people who are not coming along 
to the current IETF standards need to do in old (HISTORIC) code.

In my view they could implement just the SNMP-COMMUNITY-MIB and use
that mapping. They could alos use some imeplementation-specific or
som ad-hoc mechanism... it is not IETF standards compliant anyway, so why
would we worry.

For the security considerations, we also do not give advise on what to do if
a vendor/customers tsick to SNMPv1/v2c. We RECOMMEND to not use that, but if 
they ignore that and just do SNMPv1/v2c, they are on their own. Also for this
topic.

> > - 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
> 
> How about we change "be deleted" to "have its status changed" ??
> 

that at least makes it clear. Thanks.

> >   - What is the persistence behaviour of a row created via snmp?
> >     Probably nonVolatile? But would be good to say something
> >     about it.
>  
> No, I think it should be volatile, because an agent restart is the
> equivalent of the "various error situations" mentioned in the last
> paragraph of t11FLockEntry's DESCRIPTION.  Yes, I'll add some text.
> 

Thanks, looking forward to the text.

> > - 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?
> 
> No.  It gets released explicitly or implicitly (as mentioned above). 
> 

Might be good to also state that somewhere in a DESCRIPTION clause.

> >   Does the entry disappear in that case? 
>  
> Yes, because the table is defined as the list of all *current* locks.
>  

Also that should be documented in a DESCRIPTION clause... but 
the list is NOT a list of all *current* locks. Because the Status allows
for errors like rejectFailure/other failure. In that case it is NOT
a current lock, is it? How long will such a row exist?

> > --------- 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?
>  
> OK, how about I can change it to:
> 
>           Not long before this MIB was defined, a distinct value of
>           Application_ID was also assigned/reserved as the means to
>           distinguish locks established via Acquire Change
> 	  Authorization (ACA) requests.  This additional assignment
> 	  allows an Application_ID to be used to uniquely identify a
> 	  lock amongst all active locks established either by an EACA
> 	  or by an ACA.
> 

That is better.
I do not see why you need "Noy long before this MIB was defined".
It seems superfluous to me too. But it is better than "Recently".

> > - REFERENCE clauses of course need to be updated.
>  
> Right.
> 
> > - for t11FLockActiveGroup, the description clause does not say that
> >   (if write/create-mode is supported) that a lock can also be
> >   established.
>  
> I don't understand.  One of the objects in the t11FLockActiveGroup is
> t11FLockRowStatus, which is defined with a MAX-ACCESS of read-create
> and a MIN-ACCESS of read-only.  So, what do you want clarified ??
> 

The GROUP DESCRIPTION clause states:

    DESCRIPTION
           "A collection of objects containing information
           about current fabric locks."

That sounds as if it is only for reading/monitoring.
Where as (at least according to MAX-ACCESS clause) you can also use
it to actually create/establish a lock.

As I said, it is a NIT.

Bert
> Keith.

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