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

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

I won't loose sleep over it.
But it is quite common that "IETF WG xxx" is mentioned in the
organization clause, and also in the acknowledgemens section.

But I leave that to authors/editors, WG chair and AD.

Bert
Happy new year

> -----Original Message-----
> From: Robert Snively [mailto:[e-mail]] 
> Sent: zondag 31 december 2006 18:42
> To: Keith McCloghrie; Wijnen, Bert (Bert)
> Cc: [e-mail]; [e-mail]
> Subject: RE: [imss] Rereview of: draft-ietf-imss-fc-fcs-mib-01.txt
> 
> As I understand it (RFC2418, clause 2), IETF working groups 
> exist for a relatively short time and for a determined and 
> focused purpose.  They do not have an identifiable or 
> recorded membership and after 6 months all their documents 
> that have not become RFCs are deleted from the IETF files.  
> In addition, recognition for the effort of developing an RFC 
> is not granted to the imss working group, but rather to the 
> author.  As a result, it does not seem to me particularly 
> useful to mention IMSS as an organization in this context.  
> If any organization beyond T11 were relevant, it would 
> probably be the IETF or at the lowest granularity, the 
> hosting area, the Operations and Management Area.
> 
> I would recommend NOT mentioning IMSS in the ORGANIZATION clause.
> 
> Bob
> 
> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]]
> Sent: Sunday, December 31, 2006 6: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
> 

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