[imss] WG Last Call: draft-ietf-imss-fc-fcs-mib-00.txt

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

Comments/questions:

- 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

- 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.

- 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."

- 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.

  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. 

- 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.

- 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?

- 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.

- 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?

- Given the DESCRIPTION clause of t11FcsFabricDiscoveryStart, I 
  suggest to add  DEFVAL { noOp }

- 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.

- 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.

- 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.

- 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 }

  Because the SYNTAX used is a TC from RFC4044), that states:

   FcNameIdOrZero ::= TEXTUAL-CONVENTION
     STATUS current
     DESCRIPTION
             "The World Wide Name (WWN) associated with a Fibre Channel
             (FC) entity.  WWNs were initially defined as 64-bits in
             length.  The latest definition (for future use) is 128-bits
             long.  The zero-length string value is used in
             circumstances in which the WWN is unassigned/unknown."
    SYNTAX  OCTET STRING (SIZE(0 | 8 | 16))

  And so I would have expected that the t11FcsIeFabricName object would
  have been defined as:

  t11FcsIeFabricName  OBJECT-TYPE
    SYNTAX       FcNameIdOrZero
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
            "The Fabric_Name (WWN) of this Interconnect Element."
    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 { "" }
    ::= { t11FcsIeEntry 5 }

  I do see in sect "6.2.3.2.5 Interconnect Element Fabric Name" of
  http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf
    This standard does not define how this attribute is registered with
    the Fabric Configuration Server. The null value for the Interconnect
    Element Fabric Name attribute is 00 00 00 00 00 00 00 00h.

  So is the use of FcNameIdOrZero the proper syntax here??


- This is a real nit:
  t11FcsIeLogicalName  OBJECT-TYPE
    SYNTAX       OCTET STRING (SIZE (0..255))
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
            "The logical name of this Interconnect Element.
            When the logical name is unknown, this object contains
            the zero-length string."

  I would use a SYNTAX as follows:
    SYNTAX       OCTET STRING (SIZE (0 | 1..255))
  To indicate that zero has a special meaning.
  Ignore my ranting if you think this is nonsense.

- 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.

  This is true for more (may be all) cases where this TC T11ListIndexPointer
  is used.

- 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?

- 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?

- 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 tyhink 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.

- 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))

- 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?

- 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

- 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.

- Several objects in the t11FcsPlatformTable
  (like t11FcsPlatformVendorId, t11FcsPlatformProductId , etc)
  suggest (based on teh 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?
  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 woul still be fine.

  I also wonder if the length for t11FcsPlatformVendorId,
  t11FcsPlatformProductId can actually be zero, because table
  121 says that these are REQUIRED fields.

- 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


- 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.

- 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).

- It might be good to rename the notifications (for example)

    t11FcsReqRejectNotify NOTIFICATION-TYPE

  from xxxxNotify to xxxxNotification.
  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.


Bert

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