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

[[e-mail]]

Keith,

Go ahead and submit a revised draft, including the mention of the IMSS
WG as having developed the MIB, since that does seem to be common
practice.  The existence of the imss WG and the RFCs it produced will
archived long-term on the IETF web site, long after the WG completes
its work.

Thanks,
--David

> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]] 
> Sent: Sunday, December 31, 2006 9:53 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [imss] Rereview of: draft-ietf-imss-fc-fcs-mib-01.txt
> 
> 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
> 
> 

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