Subject: [imss] MIB Doctor review for: T11-FC-SP-POLICY-MIB

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Sat, 29 Dec 2007 00:58:54 +0100

[bcc: to MIB doctors list]

This is a review of the module as extracted from the
prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document

- I see:

   t11FcSpPolicyMIB  MODULE-IDENTITY
       LAST-UPDATED  "200702190000Z"
       ORGANIZATION  "T11"

  I think that IETF IMSS WG should be included as one of
  the ORGANIZATIONs that worked on this MIB module

- I see:

   t11FcSpPoAdminFabricName OBJECT-TYPE
      SYNTAX       FcNameIdOrZero (SIZE (8))
      MAX-ACCESS   read-only
      STATUS       current
      DESCRIPTION
           "The administratively-specified name for this Fabric, as
           specified in the active Switch Membership List Object.
           This value is meaningful only when Static Domain_IDs are
           in use in a Fabric (see FC-SW-4).  Static Domain_IDs are
           administratively enabled by a setting of the Switch Flags
           in each Switch Entry in the Switch Membership List Object.
           If Static Domain_IDs are not in use, this value might be
           '0000000000000000'h.

           The t11FamEnable, t11FamFabricName and
           t11FamConfigDomainIdType objects defined in the
           T11-FC-FABRIC-ADDR-MGR-MIB module are also concerned with
           the use of an administratively-specified name for a Fabric
           and Static Domain_IDs.  When FC-SP Policy is in use in a
           Fabric, the values of t11FamEnable, t11FamFabricName and
           t11FamConfigDomainIdType must be read-only and reflect the
           active Policy Objects.  For example, the value of
           t11FamFabricName must reflect the value of
           t11FcSpPoAdminFabricName."

   And I then wonder if the SIZE (8) is indeed intended or if it ought
   to be SIZE (8 | 16).

   Futher, when reading the restrinctions on t11FamEnable, t11FamFabricName
   and t11FamConfigDomainIdType that this MIB module imposes on another
   MIB module, I wonder
   - is that for all entries in the t11FamTable? In other words, once
     you use the POLICY-MIB, would it apply to all Fabrics, or just to the
     ones fro which there are entries in this Table.
   - And is that a "must be read-only" a dynamic thing? In other words,
     once an Active Policy gets deactivated, doe the objects in the
     t11FamTable then become read-write again?
   - Depending on the answers, would it make sense to add more to the
     DESCRIPTION clause?
   - Depending on the answers, would it make sense to IMPORT these
     obecjts and use them in the MODULE-CONFORMANCE to indicate that
     MAX-ACCESS is read-only ??

- I find this a bit confusing:

    t11FcSpPoSummaryPolicyType OBJECT-TYPE
       SYNTAX       T11FcSpPolicyObjectType
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "The 'Identifier' which specifies the type of this
           Policy Object."

   It is just the "type" is it not? ANd it is indicated by the valu of this
   object whioch is an enumeration. So wht is the 'Identifier'?
   Why no just say:

       DESCRIPTION
           "The type of this Policy Object."

- When I read (in the TC-MIB about T11FcSpPolicyNameType and
T11FcSpPolicyName,
  I sort of assumed/thought that these two would always be used in
combination.
  However in this POLICY-MIB I see the T11FcSpPolicyNameType (subtypef in
  OBJECT-TYPE t11FcSpPoSwMembSwitchNameType) being used together with:
    t11FcSpPoSwMembSwitchName OBJECT-TYPE
       SYNTAX       FcNameIdOrZero (SIZE (8))
  Is that not at least somewhat weird and possibly confusing?
  I can see that it is not absolutely flawed, but I am not sure we want to
  do this sort of thing, do we?

  Further in the POLICY-MIB I see how I expected it to see, namely when
  t11FcSpPoSwConnAllowedNameType and t11FcSpPoSwConnAllowedName are bing
used.
  And in this case it has the same subtypes as above. So
    t11FcSpPoSwConnAllowedName OBJECT-TYPE
       SYNTAX       T11FcSpPolicyName
  Could possibly be changed to
    t11FcSpPoSwConnAllowedName OBJECT-TYPE
       SYNTAX       T11FcSpPolicyName (SIZE (8))

  In any event, here we see already inconsistency within the same MIB
Module.

- I see:

   t11FcSpPoIpMgmtEntryNameType OBJECT-TYPE
      SYNTAX       InetAddressType
      MAX-ACCESS   not-accessible
      STATUS       current
      DESCRIPTION
           "The combination of t11FcSpPoIpMgmtNameType,
           t11FcSpPoIpMgmtNameLow and t11FcSpPoIpMgmtNameHigh
           specify the IP Address range of this IP Management
           Entry in the IP Management List Object.

           The FC-SP specification does not allow the use of a
           DNS domain name to specify the address at the lower end
           or at the higher end of the IP Address range, nor does it
           allow the specification of a zone index.  Therefore, the
           type of address must be one of: 'ipv4', or 'ipv6'."

   You are not using MUST (as in RFC2119), yet, when I read

                                                     Therefore, the
           type of address must be one of: 'ipv4', or 'ipv6'

   then I think I would subtype the SYNTAX as

      SYNTAX       InetAddressType (ipv4(1), ipv6(2))

   That makes the requirement machine readable.
   By using

    t11FcSpPoIpMgmtEntryNameLow OBJECT-TYPE
       SYNTAX       InetAddress (SIZE(4 | 16))

   You basically do the same.

- When I read
    t11FcSpPoWkpDescrDestPort OBJECT-TYPE
       SYNTAX       Unsigned32 (0..65535)
  and its DESCRIPTION clause, I wonder why you do not use InetPortNumber
TC??

- I am surprised/confused by this:

   t11FcSpPoWkpDescrWkpNumber OBJECT-TYPE
      SYNTAX       Unsigned32 (0..255)
      MAX-ACCESS   read-only
      STATUS       current
      DESCRIPTION
           "When the 'wkpWildcard' bit is set in the corresponding
           instance of t11FcSpPoWkpDescrFlags, this object specifies
           the IP protocol number of the Well-Known Protocol."
      REFERENCE
           "- INCITS xxx/200x, T11/Project 1570-D/Rev 1.8,
           Fibre Channel - Security Protocols (FC-SP), 13 June 2006,
           section 7.1.7.1 and table 131.
            - http://www.iana.org/assignments/protocol-numbers."

   In those protocol numbers listed at IANA, is there any other protocol
   that one would sensibly use except TCP and UDP ???
   I do see that you just represent what table 130 (not 131) on page 138
   in the T11 document shows. I still find it strange

- For this

   t11FcSpPoAttribExtension OBJECT-TYPE
      SYNTAX       OBJECT IDENTIFIER
      MAX-ACCESS   read-only
      STATUS       current
      DESCRIPTION
           "For some types of Attribute Policy Object, the value of
           this MIB object points to type-specific MIB objects which
           contain individual/broken-out parts of the Attribute Policy
           Object's value.  If this object doesn't point to such
           type-specific MIB objects, then it contains the value:
           zeroDotZero.

           In particular, when the value of t11FcSpPoAttribType
           indicates 'AUTH_Negotiate Message Payload', one or more
           Authentication Protocol Identifiers and their associated
           Authentication Protocol Parameters are embedded within the
           value of the corresponding instance of t11FcSpPoAttribValue;
           MIB objects to contain these individual values are defined
           in the t11FcSpPoAuthProtTable.  Thus, for an 'AUTH_Negotiate
           Message Payload' Attribute, the value of this object
           contains the OID of t11FcSpPoAuthProtTable."

   Is it really the idea that you would point to the table, or would
   you rather point to the relevant first part of t11FcSpPoAuthProtParams

Some of the above comments apply equally well to the Non-Active Policy
Objects. I won't repeat them.

- I see:

   t11FcSpPoNaSummaryHashStatus OBJECT-TYPE
      SYNTAX       INTEGER {
                     calculate(1),
                     correct(2),
                     stale(3)
                   }
      MAX-ACCESS   read-create
      STATUS       current
      DESCRIPTION
           "When read, the value of this object is either:

             correct -- the corresponding instance of
                        t11FcSpPoNaSummaryHashValue contains
                        the correct value; or
             stale   -- the corresponding instance of
                        t11FcSpPoNaSummaryHashValue contains
                        a stale (possibly incorrect) value;

           Writing a value of 'calculate' is a request to re-calculate
           and update the value of the corresponding instance of
           t11FcSpPoNaSummaryHashValue.  Writing a value of 'correct'
           or 'stale' to this object is a ('wrongValue') error."
      DEFVAL      { stale }

   And the STorageType object t11FcSpPoStorageType that is controlling this
   table entry states:
          Even if an instance of this object has the value
          'permanent(4)', none of the information defined in
          this MIB module for the given Fabric needs to be
          writable."

   So how does a stale value for a permanent row get re-calculated?

- For your counters, you write:

           This counter has no discontinuities other than those
           which all Counter32's have when sysUpTime=0."

  So  if the instrumentation restarts, it keeps track of the values?
  Of is the instrunmentation alsways a monolithic entity together with
  the main/master SNMP agent?

Bert Wijnen

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

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 31 Dec 2007 12:22:28 -0800 (PST)

Bert,

>   the ORGANIZATIONs that worked on this MIB module
 
Done.

>    And I then wonder if the SIZE (8) is indeed intended or if it ought

Table 108 of FC-SP (which in this case is listed in the REFERENCE clause)
limits the size to 8 bytes.

>      ones fro which there are entries in this Table.

Just the ones which reference Fabrics which have entries in this table.

>      t11FamTable then become read-write again?

Yes.

>    - Depending on the answers, would it make sense to add more to the

I think the phrase "When FC-SP Policy is in use in a Fabric," is a concise
way of stating when (and for which instances) the dependence exists.

>      MAX-ACCESS is read-only ??
 
I think the relationship is on a per-instance basis, i.e., if FC-SP
Policy is only being used on some (virtual) Fabrics, then only some
of the t11FamXxxx objects must be read-only.

However, consideration of your comment exposes two related issues:

The first is that there's a minor flaw in RFC 4439, in that a
MIN-ACCESS clause is defined for t11FamConfigDomainIdType but did not
get added (as it should have) for t11FamEnable and t11FamFabricName.
In other words, I think fixing RFC 4439 would be the way to address
your comment (even though that probably won't happen).

The second is that t11FcSpPoAdminFabricNameis read-only, as indeed it
must be because it's part of the Active Policy which cannot be modified
once it's active.  So, how is the Fabric name specified when Policy is
in use ??  I believe the answer is that t11FcSpPoNaSummaryFabricName
needs to be added as a read-create object in the t11FcSpPoNaSummaryTable.
If the WG agrees, then I will add this new object.

>            "The type of this Policy Object."
 
I used "'Identifier'" because that it is the term used in FC-SP.  I too
believe think it is confusing, but it is a type, because the REFERENCE
clause lists section 7.1.3.1 which says:

   Policy Object Identifier fields: the identifier of a Policy Object (see
   table 102).

and table 102 enumerates the six possible values.  (I guess that for those
types which have at most one active policy object, the type can be used
as an implicit identifier.)

Would you prefer the DESCRIPTION to say:

             "The 'Identifier' (i.e., the type) of this Policy Object."

>   In any event, here we see already inconsistency within the same MIB
 
You are correct.  I'll fix it such that:

is used consistently in these situations.

>    You basically do the same.

You haven't mentioned t11FcSpPoNaIpMgmtEntryNameType, which is defined
like this:

   t11FcSpPoNaIpMgmtEntryNameType OBJECT-TYPE
       SYNTAX       InetAddressType
                    -- INTEGER { ipv4(1), ipv6(2) }

where the subtype is put in an ASN.1 comment as a convenience for
developers because it avoids the compile error which SMICng generates
for "InetAddressType (ipv4(1), ipv6(2))".

So, I suggest I add the same ASN.1 comment for t11FcSpPoIpMgmtEntryNameType.

>   and its DESCRIPTION clause, I wonder why you do not use InetPortNumber
 
I will change it.

>    in the T11 document shows. I still find it strange

As you note, the intent was to reproduce what FC-SP allows, and that does
have the future potential of an SCTP-based protocol.

>    you rather point to the relevant first part of t11FcSpPoAuthProtParams

This pointer needs to apply generically in any/all cases, and so its
definition cannot be too specific.  E.g., for the example given in the
DESCRIPTION, it needs to point to "one or more ... Identifiers and ...".
So, I think the problem you've identified is that the example is too
specific.  How about I fix it like this:

                                   ....  Thus, for an 'AUTH_Negotiate
         Message Payload' Attribute, the value of this object
         contains an OID within the t11FcSpPoAuthProtTable, e.g.,
         of the whole table, of an individual row, or of an individual
         instance within the table."

>    So how does a stale value for a permanent row get re-calculated?

A hash value only becomes 'stale' after a modification of the Policy
object(s) for which it is the hash value.  (The intent of havign this
separate object is so that teh hash doesn't have to be re-calculated
after each and every modification of multiple Policy Objects.)
So, for Policy objects in a 'permanent(4)' row, their hash value will
be 'correct' permanently.

>   the main/master SNMP agent?
 
Not necessarily.  See my response to your same comment for the previous
MIB module.

Thanks,
Keith.