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

["Bert Wijnen - IETF" <[e-mail]>]

Inline

Bert Wijnen

> -----Oorspronkelijk bericht-----
> Van: Keith McCloghrie [mailto:[e-mail]]
> Verzonden: maandag 31 december 2007 21:22
> Aan: Bert Wijnen - IETF
> CC: [e-mail]; Black_David; Keith McCloghrie; Dan Romascanu
> Onderwerp: Re: MIB Doctor review for: T11-FC-SP-POLICY-MIB
>
>
> 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.
>
I can live with it as long as it is indeed understood.
So one reference makes it clear. But the REFERENCE to RFC4439 confused me,
because there the FcNameIdOrZero TC is used without subtyping, so it allows
for zero, 8 and 16 I think. That got me to ask the question.

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

Maybe yes, maybe no. It is good to get confimration from you that I more
or less indeed did understand what the intention was/is. I wonder if it
is so obvious to all readers of this MIB module. Specifically the "must be
read-only" to be dynamic is not so obvious I think.
Maybe adding some extra text might help.

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

Might be good to also make that "on a per instance basis" more explicit
in the DESCRIPTION clause.

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

Yep I see that now.
I suspect we do not have a good tool (or at least I do not know which
one) that will check if all objects that are read-write and for which
you would want them to be allowed with MIN-ACCESS of something else.
And checking manually is cumbersome (and erroneous) process as
we now find out.

> 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.
>
Mmm... I guess I had assumed that would be picked up vi
  fcmInstanceIndex, t11FcSpPoFabricIndex
But had not actually checked that. Anyway, I can live with your suggested
change.


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

OK thanks for explaining how/why you used the (for me confusing) term.
Adding that clarification in parentheses does help I think.

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

Why a comment if the types are really restricted (as is also stated in
the DESCRIPTIONs and in the SIZE restrictions for teh Address itself.
Why not just subtype it, so it is clear and machine readable and
consistent with the SIZE restrictions in the ...Address object?

> > - 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.
>
Understood. Still find it strange. But can live with it.
In practice I guess it won't matter that much.

> > - 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."
>
Yes,
Makes it clearer I think.

> > 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.
>
OK, would it make sense to document that?

> > - 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.
>
Yep seen that and responded to in the other email.

Bert
> Thanks,
> Keith.
>



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