[imss] A couple of loose ends

[Keith McCloghrie <[e-mail]>]

Bert,

In order to make further progress in updating the text of the I-D's,
there are two loose ends that I would like to resolve.

One is:

> From: "Wijnen, Bert (Bert)" <[e-mail]>
> To: Keith McCloghrie <[e-mail]>
> Cc: [e-mail]
> Subject: RE: [imss] WG Last Call: draft-ietf-imss-fc-fcs-mib-00.txt
> Date: Wed, 6 Sep 2006 14:51:38 +0200 
> 
> ...
>
> > >   t11FcsMgmtAddr  OBJECT-TYPE
> > >     SYNTAX       SnmpAdminString
> > >     MAX-ACCESS   read-only
> > >     STATUS       current
> > >     DESCRIPTION
> > >             "The management address of this entry.
> > >             The format of this object may be based on the
> > >             format of the Uniform Resource Locator (URL).
> > >             For example, for SNMP, see RFC 4088."
> > > 
> > >   So it syas "the format MAY be based on..." (my emphasis on MAY).
> > >   So, does that mean it may also be based on something else?
> > >   How do I determine what the actual format is?
> >  
> > On re-reading FC-GS-5, I see that it's required to be a URL, and
> > it's the use of 4088 which is not required.  So, I'll change it to:
> > 
> >             The format of this object is a Uniform Resource Locator
> >             (URL), e.g., for SNMP, see RFC 4088."
> 
> But is a URL normally represented by UTF-8?
> I doubt it?
> 
> I know that (RFC 2788) has:
> 
>   -- Uniform Resource Locators are stored in URLStrings.
> 
>   URLString ::= TEXTUAL-CONVENTION
>       DISPLAY-HINT "255a"
>       STATUS current
>       DESCRIPTION
>           "A Uniform Resource Locator represented in accordance
>            with RFCs 1738 and 2368, presented in the NVT ASCII
>            charset defined in RFC 854."
>       SYNTAX OCTET STRING (SIZE (0..255))
> 
> Would that not be more appropriate?

Yes, I am changing t11FcsMgmtAddr's syntax to be URLString.

The other loose end is:

> From: "Wijnen, Bert (Bert)" <[e-mail]>
> To: [e-mail], [e-mail]
> Date: Thu, 7 Sep 2006 17:50:44 +0200
> Cc: [e-mail]
> Subject: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB in
>       draft-ietf-imss-fc-zs-mib-00.txt
>
> ...
>
> - 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?

I think the issue is that the current text in the MIB is not explicit
enough in explaining when rows exist in the table.  In reviewing your
comments and determining how to update the text to address them, I'm
now planning to provide a more explicit explanation by adding this text
to the DESCRIPTION of the t11FLockTable:

           Each entry in this table represents either:

           1) a current fabric lock,
           2) an in-progress attempt, requested via SNMP, to setup
              a lock, or
           3) a failed attempt, requested via SNMP, to setup a lock.

           If an entry is created via t11FLockRowStatus but the
           attempt to obtain the lock fails, then the entry continues
           to exist until it is deleted via t11FLockRowStatus, or
           it is overwritten by the lock being established via
           a means other than SNMP, but note that rows created via
           SNMP are not retained over restarts."

A purist might argue that this design has a single table for two functions:
1) for current locks, and 2) SNMP attenpts to setup a lock, which should
be kept in separate tables, so that the "overwritten by the lock being
established via a means other than SNMP" could not happen, but I don't
think the "overwritten" is a large enough issue to warrant the extra
complication of two tables.  D'you agree ?

So, I see the addition of the above text as a clarification, not as a change.

Keith.

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