Re: [imss] Rereview of: draft-ietf-imss-fc-fcs-mib-01.txt

[Keith McCloghrie <[e-mail]>]

Thanks, Bert.  I agree that it would be good to mention IMSS (as well
as T11) in the ORGANIZATION clause of the MODULE-IDENTITY, and since
that will require a new version of the I-D, I can add a WRITE-SYNTAX
clause (for t11FcsDiscoveryStatus) as you suggest at the same time.

So, a question for David (after he returns from his vacation two weeks
from now) and/or Dan: shall I submit an updated I-D with the these two
changes ?

Keith.
 
> I have re-reviewed this MIB document.
> My first review was the revision zero version.
> My comments to that one and the answer provided by Keith
> are attached below. I am happy with the new revision
> and/or the answers that were given by Keith.
> 
> No major issues anymore, So I think this doc is ready.
> 
> You may want to consider this:
> 
> - I wonder if the IETF IMSS WG should also be mentioned in
>   the ORGANIZATION clause of the MODULE-IDENTITY
> 
> - For object t11FcsDiscoveryStatus I read in the DESCRIPTION
>   clause that one can only SET it to localOnly via SNMP.
>   I suggest to also express this in the MODULE-COMPLIANCE
>   by changing:
> 
>     OBJECT   t11FcsDiscoveryStatus
>     MIN-ACCESS   read-only
>     DESCRIPTION
>             "Write access is not required."
> 
>   into something like:
> 
>     OBJECT   t11FcsDiscoveryStatus
>     WRITE-SYNTAX INTEGER { localOnly(3) }
>     MIN-ACCESS   read-only
>     DESCRIPTION
>             "Write access is not required.
>              However, if write access is supported, then one can only
>              write (SET) the value to 'localOnly'.
>             "
> 
>   It was discussed in the below inetraction between Keith and myself.
>   I can live if you do not change the MODULE-COMPLIANCE.
> 
> Bert
> 
> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]] 
> Sent: woensdag 6 september 2006 0:04
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [imss] WG Last Call: draft-ietf-imss-fc-fcs-mib-00.txt
> 
> Bert,
> 
> Thanks for the comments.  My responses are below.
> 
> Keith.
> -----------------
> 
> > - In the MODULE-IDENTITY, I see:
> > 
> >     REVISION  "200608140000Z"
> >     DESCRIPTION
> >             "Initial version of this MIB module."
> >     ::= { mib-2 nnn }                     -- to be determined later
> >   
> >   I think I would make that:
> > 
> >     REVISION  "200608140000Z"
> >     DESCRIPTION
> >             "Initial version of this MIB module, published as RFC
> yyyy."
> >     -- RFC-Editor, replace yyyy with actual RFC number & remove this
> note
> >     ::= { mib-2 nnn }  -- to be assigned by IANA.
> >     -- RFC Editor: replace nnn with IANA-assigned number & remove this
> 
> > note
> > 
> > - To avoid later comments, I would also add this to the DESCRIPTION
> >   clause of the MODULE-IDENTITY itself:
> > 
> >            Copyright (C) The Internet Society (2006).  This version of
> >            this MIB module is part of RFC yyyy;  see the RFC itself
> for
> >            full legal notices."
> > 
> >    -- RFC Editor: replace yyyy with actual RFC number & remove this 
> > note
>  
> Oops.  All of this WG's other recent drafts have the required
> boilerplate; I'm not sure how this one slipped through without it.
> 
> > - I wonder if we would not better rename these TCs (for naming
> consistency):
> > 
> >      FcIeType, FcPortState, FcPortTxType
> >  
> >   and name them instead as follows:
> > 
> >      T11FcIeType, T11FcPortState, T11FcPortTxType
> > 
> >   Or are these 3 TCs extending the set of FcXxxx TCs in RFC4044?
> >   If so, the I'd suggest to add at least a small SMI comment to state
> that,
> >   so that it is clear why the names are as chosen.
>  
> I named them to be consistent with FcPortType, and, *if* we were
> updating
> RFC4044, then I'd put them in there, but we're not.   So, rather than
> add a "small SMI comment", I'd prefer to change their names.
> 
> > - For consistency, but also for betetr info in the DESCRIPTION clause,
> >   I would consider to change:
> > 
> >   FcPortTxType ::= TEXTUAL-CONVENTION
> >     STATUS  current
> >     DESCRIPTION
> >             "The technology of the port transceiver:
> > 
> >                 unknown        - unknown (includes the 'null' type)
> >                 other          - some other technology
> >                 shortwave850nm - Short wave laser - SN (850 nm)
> >                 longwave1550nm - Long wave laser - LL (1550 nm)
> >                 longwave1310nm - Long wave laser cost
> >                                  reduced - LC (1310 nm)
> >                 electrical     - Electrical - EL."
> > 
> >   into:
> > 
> >   FcPortTxType ::= TEXTUAL-CONVENTION
> >     STATUS  current
> >     DESCRIPTION
> >             "The technology of the port transceiver:
> > 
> >                 unknown(1)        - unknown (includes the 'null' type)
> >                 other(2)          - some other technology
> >                 shortwave850nm(3) - Short wave laser - SN (850 nm)
> >                 longwave1550nm(4) - Long wave laser - LL (1550 nm)
> >                 longwave1310nm(5) - Long wave laser cost
> >                                     reduced - LC (1310 nm)
> >                 electrical(6)     - Electrical - EL."
>  
> OK.
> 
> > - I am a bit surprised by:
> > 
> >   T11ListIndexPointer ::= TEXTUAL-CONVENTION
> >     STATUS  current
> >     DESCRIPTION
> >             "Objects with this syntax point to a list of elements
> >             contained in a table, by holding the same value as the
> >             object with syntax T11ListIndex defined in the table's
> >             INDEX clause, or, zero to indicate an empty list.
> >             The definition of an object with this syntax must
> >             identify the table(s) into which it points."
> >     SYNTAX  Unsigned32 -- the default range of (0..4294967295)
> > 
> >   First, I would make it:  SYNTAX Unsigned32 (0..4294967295)
> >   instead of putting that in a SMI comment field.
>  
> The reason I added the ASN.1 comment was to dispel all ambiguity, i.e.,
> to make it clear that the definition intentionally uses the default
> range.  Thus, there is no reason to include the default range explicitly
> in the syntax.  Why do we have a default range if we're not allowed to
> use it ??
> 
> >   Second, I think we normally would use a name of
> > 
> >     T11ListIndexOrZero ::= TEXTUAL-CONVENTION
> > 
> >   To complement the T11ListIndex TC, which does not include the zaero.
> > 
> >   Third, we also normally do not prescribe what a value of zero means,
> >   but we normally say something aka (this is from
> InetrfaceIndexOrZero):
> > 
> >             "This textual convention is an extension of the
> >             InterfaceIndex convention.  The latter defines a greater
> >             than zero value used to identify an interface or interface
> >             sub-layer in the managed system.  This extension permits
> the
> >             additional value of zero.  the value zero is
> object-specific
> >             and must therefore be defined as part of the description
> of
> >             any object which uses this syntax.  Examples of the usage
> of
> >             zero might include situations where interface was unknown,
> >             or when none or all interfaces need to be referenced."
> > 
> >   We in fact have quite a few of these XxxSomeIndex and
> XxxSomeIndexOrZero
> >   TCs, which all (i believe) follow/use that same concept. I would
> strongly
> >   suggest that we do so here as well.
> > 
> >   Mmmm... I see that for some other TCs in the FC/IMSS/IPS space you
> do
> >   not follow the InterfaceIndex/InetrfaceInexOrZero so closely either.
> >   Oh well... Up to you and the WG. I personally like the
> InterfaceIndeOrZero
> >   approach better. 
>  
> OK, I'll rename the TC to T11ListIndexPointerOrZero.
> 
> > - I see REFERENCE clauses aka:
> > 
> >     REFERENCE
> >             "ANSI INCITS xxx-200x, Fibre Channel - Generic Services 5,
> >             FC-GS-5 T11/Project 1677-D/Rev 8, Table 124."
> > 
> >   which relates to this reference (I guess):
> > 
> >    [FC-GS-5]
> >      "Fibre Channel - Generic Services - 5 (FC-GS-5)", ANSI INCITS
> >      xxx-200x, T11/Project 1677-D/Rev 8.00
> >      http://www.t11.org/t11/stat.nsf/upnum/1677-d, September 2004.
> > 
> >   Do we know when we will get a stable reference?
> >   It is normative, so we may have to say something about that.
> > 
> >   I guess Keith already stated that David or Claudio should answer
> this 
> >   question.
>  
> Claudio said this morning that revision 8.5 is the final one.
> So, I need to go ahead and update the MIB based on Rev 8.5, including
> adding any new enumerations which have been defined since Rev 8.0.
> 
> > - For t11FcsFabricDiscoveryRangeLow and
> t11FcsFabricDiscoveryRangeHigh,
> >   is the value in these objects included in teh range? My read would
> >   say they are. But we may want to make that clear by stating it?
>  
> OK, I'll change:
> 
>             "The discovery by a particular switch operates
>             within all existing Fabrics that have a fabric
>             index within a specific range.  ...
> to:
>             "The discovery by a particular switch operates
>             within all existing Fabrics that have a fabric
>             index within a specific inclusive range.  ...
> 
> > - For t11FcsFabricDiscoveryStart, how long does discovery take?
> >   The reason I ask, is that if it may take a while, that we might
> >   want to consider a value like "discoveryInProgress(3) ??
> >   Just thinking aloud, I can also live with what we have in there now.
>  
> I think this is already available since 'inProgress' is one of the
> defined values for t11FcsDiscoveryStatus.
> 
> > - t11FcsFabricDiscoveryTable
> >   I guess that this table gets created/instantiated by the agent
> everytime
> >   it starts. There are no default values for the two objects 
> >   t11FcsFabricDiscoveryRangeLow and t11FcsFabricDiscoveryRangeHigh.
> >   So how is the behavioud if I issue a DiscoveryStart when these
> objects
> >   have not been SET yet? Should we define DEFVALs?
> 
> Just adding DEFVALs would be a temptation to write sloppy applications,
> because an NMS can not be sure whether a particular entry has been used
> or not since the last reboot.  Thus, invoking DiscoveryStart without
> checking the values of RangeLow and RangeHigh, would be very sloppy.
> Given that an application needs to check, then it also has to change the
> values if they're wrong.  Thus, the simplest way to write such an
> application is to always specify the range explicitly (i.e., write
> RangeLow and RangeHigh) at the same time as invoking DiscoveryStart.
> 
> So, I propose to add a recommendation to the DESCRIPTION like this:
> 
>   t11FcsFabricDiscoveryStart  OBJECT-TYPE
>       SYNTAX       INTEGER {
>                        start(1),
>                        noOp(2)
>                    }
>       MAX-ACCESS   read-write
>       STATUS       current
>       DESCRIPTION
>               "This object provides the capability to trigger the start
>               of a discovery by a Fabric Configuration Server.  If this
>               object is set to 'start', then the discovery is started on
>               those fabrics which have their fabric index value in the
>               range specified by t11FcsFabricDiscoveryRangeLow and
>               t11FcsFabricDiscoveryRangeHigh.  It is recommended that
>               whenever an instance of this object is set to 'start',
>               that the desired range be concurrently specified by
>               setting the corresponding instances of
>               t11FcsFabricDiscoveryRangeLow and
>               t11FcsFabricDiscoveryRangeHigh.
> 
> > - Given the DESCRIPTION clause of t11FcsFabricDiscoveryStart, I 
> >   suggest to add  DEFVAL { noOp }
> 
> Since the value when read is always 'noOp', to specify a DEFVAL would
> either be redundant, or worse, it would weaken the definition because a
> DEFVAL is only advisory, whereas the statement:  "the value when read is
> always 'noOp'" is mandatory.
> 
> > - I suppose that SETTING t11FcsDiscoveryStatus to one of
> >                      inProgress(1),
> >                      completed(2),
> >   would have no effect? I.e. it would be ignored?
> >   Whatever the intended behaviour is to be, we probably do best to
> >   be specific as to what we want an agent to do.
> > 
> >   I personally kind of like to add something to the MODULE-COMPLIANCE<
> >   which states that the WRITE-SYNTAX is  localOnly(3) and that
> >   the SYNTAX is all 3 values. I think that expresses that only the
> >   one value that makes sense can be SET/written.
> > 
> >   I personally might do a similar thing for
> t11FcsFabricDiscoveryStart,
> >   but that one at least explains what to do if I set the value to
> >   something that does not trigger an action.
>  
> I prefer to add a sentence to the DESCRIPTION of t11FcsDiscoveryStatus,
> like this:
> 
>             It is an error for a manager to set the value of this
>             object to anything other than 'localOnly'."
> 
> > - t11FcsDiscoveryStatus has no persistency (or so is my reading of
> >   the DESCRIPTION clause) and will be set to localOnly upon a restart?
> >   If so, it might be usefull to add a sentence about that, just to be
> >   explicit and clear.
>  
> It already has this sentence:
> 
>             Initially when the switch comes up, all instances of this
>             object have the value: 'localOnly'
> 
> Do you want me to change "switch comes up" to "agent restarts" ??
> 
> > - For objects t11FcsIeName and t11FcsIeDomainId, I wonder if a zero
> >   (i.e. zero length OCTET STRING) are really valid. If not, then we
> >   should add a SIZE and RANGE restriction.
>  
> FC-GS-5 says:
> 
>   6.2.3.2.1 Interconnect Element Name
> 
>   The format of the Interconnect Element Name attribute, as used by the
>   Fabric Configuration Server, shall be identical to the Name_Identifier
>   format defined in FC-FS. If the Interconnect Element is a Switch (see
>   FC-SW), the Interconnect Element Name attribute shall be the
>   Switch_Name of the Switch.
> 
>   This standard does not define how this attribute is registered with
> the
>   Fabric Configuration Server.  The null value for the Interconnect
>   Element Name attribute is 00 00 00 00 00 00 00 00h.
> 
> and
> 
>   6.2.3.2.3 Interconnect Element Domain Identifier
> 
>   The format of the Interconnect Element Domain Identifier attribute, as
>   used by the Fabric Configuration Server, shall be identical to the
>   Domain Identifier format defined in FC-SW-3.
> 
>   This standard does not define how this attribute is registered with
> the
>   Fabric Configuration Server.  The null value for the Interconnect
>   Element Domain Identifier attribute is 00h.
> 
> Since t11FcsIeDomainId can have a value of zero, FcDomainIdOrZero (which
> is defined as "SYNTAX  Integer32 (0..239)")  should not be restricted.
> 
> For t11FcsIeName, the "null" value is specified as all zeros, rather
> than the zero-length value.  So, yes, I'll add a restricted range:
> 
>   t11FcsIeName  OBJECT-TYPE
>       SYNTAX       FcNameIdOrZero (SIZE(8 | 16))
> 
> > - This definition seems strange:
> > 
> >   t11FcsIeFabricName  OBJECT-TYPE
> >     SYNTAX       FcNameIdOrZero
> >     MAX-ACCESS   read-only
> >     STATUS       current
> >     DESCRIPTION
> >             "The Fabric_Name (WWN) of this Interconnect Element.
> >             When the Fabric_Name is unknown, this object contains
> >             the all-zeros value: x'00 00 00 00 00 00 00 00'."
> >     REFERENCE
> >             "ANSI INCITS xxx-200x, Fibre Channel - Generic Services 5,
> >             FC-GS-5 T11/Project 1677-D/Rev 8, section 6.2.3.2.5."
> >     DEFVAL { '0000000000000000'h }
> >     ::= { t11FcsIeEntry 5 }
> 
> I'll add a restricted range here too.
> 
>   t11FcsIeFabricName  OBJECT-TYPE
>       SYNTAX       FcNameIdOrZero (SIZE(8 | 16))
> 
> > - I see this:
> > 
> >   t11FcsIeMgmtAddrListIndex  OBJECT-TYPE
> >     SYNTAX       T11ListIndexPointer
> >     MAX-ACCESS   read-only
> >     STATUS       current
> >     DESCRIPTION
> >             "The management address list for this Interconnect
> Element.
> >             This object points to an entry in the
> >             t11FcsMgmtAddrListTable."
> > 
> >   Reading the DESCRIPTIOn clause, I wonder why one would not use a 
> >   RowPointer. The fact is that the pointer does not point to "an
> entry"
> >   in the t11FcsMgmtAddrListTable, but to a SET of such entries.
> >   So I guess the DESCRIPTION clause could be clarified.
> 
> It is sufficient (and simpler) for this TC to be an Unsigned32, whereas
> RowPointer is an OID.
>  
> As a clarification, I've added this sentence to
> T11ListIndexPointerOrZero's
> DESCRIPTION:
> 
>               Note that such a table could have one row per list, or
>               it could have one row per element of a list.
>  
> > - I see:
> >  
> >   t11FcsIeInfoList  OBJECT-TYPE
> >     SYNTAX       OCTET STRING (SIZE (0..252))
> >     MAX-ACCESS   read-only
> >     STATUS       current
> >     DESCRIPTION
> >             "The information list for this Interconnect Element.
> >             This object contains the following substrings in order:
> >             vendor name, model name/number and release code/level,
> >             followed by zero or more substrings of vendor-specific
> >             information. Each substring is terminated with a byte
> >             containing a null value (x'00')."
> > 
> >   And that reads as if it is ASCII information to be (potentially) 
> >   consumed by human beings.  So in that case, the IETF wants it to
> >   be an internationalized string.  Comment?
>  
> FC-GS-5 requires the individual values to be ASCII strings (terminated
> by nulls).  I'll edit the DESCRIPTION to be:
> 
>             The value of this object is formatted as specified in
>             FC-GS-5, i.e., it contains the following substrings in
>             order:  vendor name, model name/number and release
>             code/level, followed by zero or more substrings of
>             vendor-specific information. Each substring is terminated
>             with a byte containing a null value (x'00')."
> 
> > - I see:
> > 
> >   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."
> 
> > - SMICng gave a warning about the indexing of
> > 
> >   t11FcsPortListEntry  OBJECT-TYPE
> >     SYNTAX       T11FcsPortListEntry
> >     MAX-ACCESS   not-accessible
> >     STATUS       current
> >     DESCRIPTION
> >             "An entry which identifies that the port which has the
> >             port name, t11FcsPortName, is in a particular list of
> >             ports, which is known to a switch (identified by
> >             fcmInstanceIndex and fcmSwitchIndex)."
> >     INDEX   { fcmInstanceIndex,  fcmSwitchIndex,
> >               t11FcsPortListIndex, t11FcsPortName }
> >     ::= { t11FcsPortListTable 1 }
> > 
> >   I read Keiths explanation, which seemed fine. But now that I am
> >   reviewing the MIB module in details and try to understand things,
> >   now I am no so sure this is goodness.
> > 
> >   So, that t11FcsPortname is a value (embedded in the index) that
> >   should help me find more detailed info, right?
> >   So how do I find that info? I think I need to go to the
> >   t11FcsPortTable, which is indexed by:
> > 
> >     INDEX   { fcmInstanceIndex, fcmSwitchIndex,
> >               t11FcsFabricIndex, t11FcsPortName }
> > 
> >   So assuming that the index values for fcmInstanceIndex,
> fcmSwitchIndex,
> >   are the same in both tables, I can see that I can pick up 3 index
> >   values from the list of t11FcsPortsList in the t11FcsPortsListTable.
> >   But I am missing the 3rd index of the t11FcsPortnameTable, namely
> >   t11FcsFabricIndex. So how am I going to wuickly pick that up?
> >   Or how exactly are the tables connected/linked?
> > 
> >   Maybe I need to study it deeper... but I'd prefer an explanation of
> >   the people who created these tables with the current indexing
> schemes.
>  
> To generate an answer to your question, I needed to re-review the
> structure of the tables, and in doing so, I now think that the current
> structure is more open-ended/flexible than it needs to be -- having a
> less open-ended structure would make the MIB simpler.  Specifically, the
> MIB currently has a table whose only purpose is to identify a list of
> (not necessarily related) ports.  However,
> 
> - each IE is either a virtual IE attached to one virtual Fabric, or
>   (if virtual Fabrics are not in use) it's a physical IE.
> - each port is either a virtual port attached to one virtual Fabric, or
>   (if virtual Fabrics are not in use) it's a physical port.
> - GS-5 mentions that an IE has a "port list" and has a dotted line from
> the
>   "Interconnect Element Object" to the "Port Object" in its "Figure 7 --
>   Interconnect Element and Port attributes".
> - However, all ports in an IE's port list will be attached to the same
>   Fabric as that IE is attached to.  In other words, the relationship
>   between IEs and ports is hierarchical.
> - Thus, it would be simpler to:
> 
>   - delete the t11FcsPortListTable,
>   - delete the t11FcsIePortListIndex object, and
>   - insert t11FcsIeName into the INDEX of the t11FcsPortTable, i.e.,
>     change the INDEX-ing of the t11FcsPortTable to be:
> 
>       INDEX   { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex,
>                 t11FcsIeName, t11FcsPortName }
> 
> Increasing the INDEX clause from four to five objects makes it a little
> more cumbersome, but the length is still far short of the maximum
> length.
> 
> With these changes, while there will no longer be any explicit mention
> of a "port list" in the MIB, the list of ports on an IE will be all the
> rows in t11FcsPortTable which have the same values for the first four
> index objects, i.e., the value of t11FcsPortName will be the only index
> value for which they differ.  So, a "port list" is (implicitly) a set of
> adjacent rows in the t11FcsPortTable.
> 
> David, since this is a MIB design change, may I suggest you ask the WG
> for approval of this as a separate/individual question.
> 
> > - for
> >  
> >   t11FcsPortName  OBJECT-TYPE
> >     SYNTAX       FcNameIdOrZero
> >     MAX-ACCESS   not-accessible
> >     STATUS       current
> >     DESCRIPTION
> >             "The Port_Name (WWN) of the port for which this row
> >             contains information."
> > 
> >   I wonder if a zero value (zero length OCTET STRING) is really valid?
> >   If not, then we may need to limit it with a SIZE paramter aka
> >     SYNTAX       FcNameIdOrZero SIZE (8 | 16)
> > 
> >   But,  I do see that in sect "6.2.3.3.1 Port Name" of document
> >   http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf, it says:
> > 
> >       The null value for the Port Name attribute is
> >       00 00 00 00 00 00 00 00h.
> > 
> >   So... is the SYNTAX of FcNameIdOrZero appropriate here? 
> >   In any event, the name SIZE seems to be fixed at 8 octets for the
> >   PortName, so at least one would then define the syntax as:
> > 
> >     SYNTAX       FcNameIdOrZero (SIZE (8))
>  
> A length of 16 is still a possibility -- section 6.2.3.3.1 refers to
> FC-FS, in which section 15 (table 66) includes one format which has a
> length of 128 (bits).
> 
> So, I'll chaneg it to:
>  
>       SYNTAX       FcNameIdOrZero (SIZE(8 | 16))
> 
> > - For:
> > 
> >   t11FcsPortModuleType  OBJECT-TYPE
> >     SYNTAX       Unsigned32 (0..255)
> >     MAX-ACCESS   read-only
> >     STATUS       current
> >     DESCRIPTION
> >             "The port module type of this port."
> >     REFERENCE
> >             "ANSI INCITS xxx-200x, Fibre Channel - Generic Services 5,
> >             FC-GS-5 T11/Project 1677-D/Rev 8, section 6.2.3.3.4."
> > 
> >   It seems better to create a TC that ENUMerates the valid values?
> 
> The choice between using either an enumerated value, or, a numeric value
> to be looked up in another specification, is a trade-off of convenience
> versus maintenance.  For something which changes frequently, it's better
> that the MIB *not* contain a list which is frequently out-of-date; for
> something which changes infrequently, it's better to have the
> convenience of enumeration.
>  
> Specifically, for those objects defined in this MIB as enumerations,
> when a new value is defined in T11, the new value cannot be used in the
> MIB until the MIB is updated.  When the MIB syntax is Unsigned32, new
> values can be used in the MIB as soon as they are defined by T11.
> 
> So, we intentionally chose to specify some objects in this MIB as
> enumerations, and others as binary values, based on the frequency at
> which new values can be expected to be defined and used -- not just in
> the now completed GS-5, but also in GS-6 and its successors.
> 
> > - For:
> > 
> >   t11FcsPortSpeedCapab  OBJECT-TYPE
> >     SYNTAX       OCTET STRING (SIZE (2))
> > 
> >   It seems that the references document and section say that it is a
> BITS
> >   construct ??
> > 
> > - Same for t11FcsPortOperSpeed
>  
> While the Capability could be a BITS, OperSpeed would only ever have one
> bit set, i.e., not a BITS.  However, both of these are further examples
> of the enumerated versus numeric trade-off mentioned above.  That is,
> port speed is another area where new enumerations can be expected and
> will need to be used.
> 
> > - For:
> > 
> >   t11FcsPlatformName  OBJECT-TYPE
> >     SYNTAX       OCTET STRING (SIZE (0..255))
> > 
> >   It seems to me that the SYNTAX better be:
> > 
> >     SYNTAX       OCTET STRING (SIZE (0 | 3..256))
> > 
> >   because http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf
> >   section 6.2.3.4.2 tells me:
> > 
> >     The Platform Name attribute may be registered using the
> >     protocol described in 6.2.2.3. The null value for the
> >     Platform Name attribute is a zero-length Platform Name.
> > 
> >   So maybe that is how we can get a length of zero. But I am
> >   not even sure about that. It is also possible that the
> >   first byte would be valued at zero. Is the format octet 
> >   included in this case? Not clear from the PDF file for me.
> > 
> >   If I understand the PDF file correctly, then (it speaks about
> >   reserved to be of length 254-m) then there are 2 octets (1 for
> >   length, one for format) plus 254 for the actual name. So that
> >   would be a max size of 256 in my view.
>  
> Many of the format specifications in the GS-5 spec. are like this:
> 
>               Logical Name length (m)     1
>               Logical Name                m
>               Reserved                  255-m
> 
> where the aggregate length (of the three sub-fields) is 256 bytes.
> 
> So, the way that I interpret the Platform Name field:
> 
>               Platform Name length (m)     1
>               Platform Name                m
>               Platform Name Format         1
>               Reserved                   254-m
> 
> is similarly, to have an aggregate length is 256 bytes.  Therefore, the
> correct MIB syntax is:
> 
>      SYNTAX       OCTET STRING (SIZE (0..254))
> 
> where the range is the value of m.
> 
> > - Several objects in the t11FcsPlatformTable
> >   (like t11FcsPlatformVendorId, t11FcsPlatformProductId , etc)
> >   suggest (based on the SYNTAX of SnmpAdminString) that the value
> >   can be an internationalized human readable string.
> >   But the table 121 in the PDF file, section 6.2.3.4.5 seems to
> >   tell me that they are all ASCII. So what is it?
> 
> It's the format as specified in section 6.2.3.4.5, which is a subset of
> SnmpAdminString, which I believe means that using SnmpAdminString as the
> syntax is fine.
> 
> >   I know that IETF is not happy with using DisplayString, but if
> >   that is what the underlying technology (outside IETF) uses, then
> >   we should at least not suggest that it is different.
> >   I could accept that we say "we want to be prepared for UTF-8 
> >   strings, but for now it is ASCII as per DC-GS-5)". But it 
> >   might be good to then explicitly state so in the DESCRIPTION
> >   clauses of these objects.
> > 
> >   At the other hand, the objects are all read-only, and so even
> >   if they only present ASCII data (in UTF-8 that is exactly the
> >   same), then it would still be fine.
> 
> How about I leave it as SnmpAdminString, and point to GS-5 for the
> definition of which characters are valid:
> 
>             "The identifier of the vendor of this platform, in
>             the format specified by FC-GS-5."
> 
> >   I also wonder if the length for t11FcsPlatformVendorId,
> >   t11FcsPlatformProductId can actually be zero, because table
> >   121 says that these are REQUIRED fields.
> 
> The table gives their minimum length when they are present, *but* a
> "Platform Attribute Block" doesn't necessarily contain them all.
>  
> > - For:
> > 
> >   t11FcsPlatformFC4Types  OBJECT-TYPE
> >     SYNTAX       OCTET STRING (SIZE (0 | 32))
> > 
> >   should be 
> >     SYNTAX       OCTET STRING (SIZE (0 | 20))
> > 
> >   that is what I read in table 121 of
> >   http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf
> 
> The text which follows the table says:
> 
>    Supported FC-4 Types: This is an 8 word (256 bit) bit mask that
>    indicates what FC-4 types are supported on this platform (see
> 5.2.3.8).
>    FCP-2 (FC-4 type 08h) is represented by bit 8 of word 0. The Fabric
>    Configuration Server shall not attempt validation of the FC-4 Types
>    attribute, and any value shall be accepted for this attribute.
> 
> I think the table has a typo.
> 
> > - Object t11FcsNodeName. Is it supposed to represent this:
> > 
> >   6.2.3.4.6 Platform Node Name
> >      The format of the Platform Node Name attribute, as used by
> >      the Fabric Configuration Server, shall be identical to the
> >      Name_Identifier format defined in FC-FS. Zero or more
> >      Platform Node Name attributes may be associated with a 
> >      Platform object. Node Names are registered to associate
> >      a Platform with the Nodes.
> >      This attribute may be registered using the protocol described
> >      in 6.2.2.3. The null value for the platform Node Name
> >      attribute is 00 00 00 00 00 00 00 00h
> > 
> >   That last description of 8 hex zeroes for a null value seems
> >   to conflict with the underlying
> > 
> >     SYNTAX       FcNameIdOrZero
> > 
> >   that you are using in the MIB.
>  
> Ok, I'll change it to:
>  
>       SYNTAX       FcNameIdOrZero (SIZE(8 | 16))
> 
> > - W.r.t.
> >  
> >   t11FcsNotifyControlTable OBJECT-TYPE
> >     SYNTAX       SEQUENCE OF T11FcsNotifyControlEntry
> >     MAX-ACCESS   not-accessible
> >     STATUS       current
> >     DESCRIPTION
> >             "A table of control information for notifications
> >             generated due to Fabric Configuration Server events.
> > 
> >             Values written to objects in this table should be
> >             persistent/retained over agent reboots."
> > 
> >   I have the same questions/concerns about the "should be persistent"
> >   as I had for the RSCN MIB module. 
> >   So we can probably resolve this one in the same way (or leave it
> >   if everyone thinks that I worry too much).
>  
> OK.
> 
> > - It might be good to rename the notifications (for example)
> > 
> >     t11FcsReqRejectNotify NOTIFICATION-TYPE
> > 
> >   from xxxxNotify to xxxxNotification.
> 
> I chose to use t11FcsReqRejectNotify because t11FcsReqRejectNotification
> is 33 characters long, and I think using t11FcsReqRejectNotify is a
> clearer abbreviation than t11FcsReqRejNotification.
> I guess I could go for:
> 
>      t11FcsRqRejectNotification NOTIFICATION-TYPE
> 
> if you prefer.
> 
> >   But I agree that this is really nitpicking. 
> >   For consistency with (most) other MOB modules and notifications
> >   I think my argument makes sense though.
> > 
> > - For the notifications (and the control there-of), it again seems
> >   that the Transport Area may want us to say somehting about the
> >   max number of nitifications to be expected per second/minute/xxx
> >   or to provide a control varianle that a NMS can SET.
>  
> Their motivation is good, and is applicable to data-plane events, but
> asking for a max number per unit time for every type of notification is
> too simplistic.  E.g., it's unreasonable to ask how many
> t11FcsDiscoveryCompleteNotify notifications can be generated in a
> second/minute/xxx -- how big is the network, how many virtual fabrics
> need to be discovered, how quickly can the operator ask for another
> discovery after the last one completes ??
> 
> If a max rate is specified by an NMS, such that notifications can be
> suppressed due to their volume, then there needs to be some mechanism
> for the NMS to know that suppression(s) have happened/are happening,
> which means more notification-types and objects need to be defined.
> That is, it increases the complexity, which is not warranted unless
> there can really be a "flood" of notifications.
> 
> For notifications, like all the ones in this MIB, which are generated
> due to control plane events (and providing that none of them are able to
> start a chain-reaction), the extra complexity is not warranted.
> 
> _______________________________________________
> imss mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/imss
> 

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