[imss] RE: A couple of loose ends

["Wijnen, Bert (Bert)" <[e-mail]>]

These suggested resolutions seem fine to me.
My main objective of my comments was to get things
clear enough so that other people (and also I myself)
can understand how things are supposed to work.

Bert

> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]]
> Sent: Tuesday, September 26, 2006 19:13
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: A couple of loose ends
> 
> 
> 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