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

Keith McCloghrie <kzm@cisco.com> Mon, 31 December 2007 20:24 UTC

Return-path: <imss-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9RBe-0005hH-AC; Mon, 31 Dec 2007 15:24:38 -0500
Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1J9RBd-0005h7-A1 for imss-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 15:24:37 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9RBc-0005gz-Ti for imss@ietf.org; Mon, 31 Dec 2007 15:24:37 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9RBb-0005ki-2W for imss@ietf.org; Mon, 31 Dec 2007 15:24:36 -0500
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Dec 2007 12:24:34 -0800
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBVKOYPP016042; Mon, 31 Dec 2007 12:24:34 -0800
Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBVKOXsm014220; Mon, 31 Dec 2007 20:24:33 GMT
Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA10683; Mon, 31 Dec 2007 12:22:28 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200712312022.MAA10683@cisco.com>
To: bertietf@bwijnen.net
Date: Mon, 31 Dec 2007 12:22:28 -0800
In-Reply-To: <NIEJLKBACMDODCGLGOCNKEHBEEAA.bertietf@bwijnen.net> from "Bert Wijnen - IETF" at Dec 29, 2007 12:58:54 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13968; t=1199132674; x=1199996674; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:=20Keith=20McCloghrie=20<kzm@cisco.com> |Subject:=20Re=3A=20MIB=20Doctor=20review=20for=3A=20=20T11 -FC-SP-POLICY-MIB |Sender:=20; bh=xoCN2Hl6DmwjJdsPLq6wwNopMtDP3oO1DG7SIMpis88=; b=CLh3KHfG1ZsjjC9/99iULfmYWTOD2+s9tsB0IJvuQOz2E8jga1oHhZY+Fc 1xmMjwa9YiUAx1PF+M7zVarT1IKxX8jRT87FYVBO5vSHbSczHUVT6bjVuUO9 XlaZlpGBTkMKGBw22VdU3EpursT6UMCQJAIx5IkXIZc0zg7RHFB9w=;
Authentication-Results: sj-dkim-1; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b
Cc: imss@ietf.org, Dan Romascanu <dromasca@avaya.com>, Black_David <Black_David@emc.com>, Keith McCloghrie <kzm@cisco.com>
Subject: [imss] Re: MIB Doctor review for: T11-FC-SP-POLICY-MIB
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Bert,

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

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

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

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

Just the ones which reference Fabrics which have 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?

Yes.

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

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.

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

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

> - 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.
 
You are correct.  I'll fix it such that:

       SYNTAX       T11FcSpPolicyName (SIZE (8))

is used consistently in these situations.

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

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.

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

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

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

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

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

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

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.

> - 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?
 
Not necessarily.  See my response to your same comment for the previous
MIB module.

Thanks,
Keith.


_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss