Re: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB):

[Keith McCloghrie <[e-mail]>]

Bert

Thanks for your first (of many, I'm sure!!) sets of comments on the document.

> Here are my comments/questions on the T11-FC-SP-TC-MIB module
>
> 1. I find it somewhat weird to see:
> 
>      t11FcTcMIB  MODULE-IDENTITY
>         LAST-UPDATED  "200708130000Z"
>         ORGANIZATION  "For the initial versions, T11.
>                        For later versions, the IETF's IMSS Working
> Group."
> 
>    The one version that gets formally published is the one in the
>    upcoming RFC. At that time there are basically no "initial" versions
>    other than the one in the RFC. 

First, I feel it's valuable to acknowledge T11 in the MIB module itself, not
just in the RFC, because: a) they deserve the acknowledgement, and b) it
indicates that this MIB benefitted from their Fibre Channel expertise.

Second, RFC 2578 says:

   The ORGANIZATION clause, which must be present, contains a textual
   description of the organization under whose auspices this information
   module was developed.

and there were two such organizations: an initial one and a later one.
So, we could change the word "version" to something else if you like,
but otherwise, I think it's kosher.

Would you prefer it to say something like:

          ORGANIZATION  "This MIB module was a coordinated development
                         of two organizations: T11 began the development
                         and the IETF's IMSS Working Group finished it."

> 2. looking at T11FcSpPolicyHashFormat and T11FcSpPolicyHashValue I
> wonder
>    if/how often the TCS will need to be updated? And when that is done,
>     a. do we then want to create a new RFC or
>     b. should this become an iana  maintained module? 
 
The definition is intentionally designed such that the answers to your
questions are: never, no, and no.  That is, the TC provides a REFERENCE
to the location in FC-SP where values are defined, the syntax of both
objects is based on the field sizes, not on assigned values, and the
DESCRIPTION lists the "first two" assignments, but only as an FYI, not
as the definitive specification.  In other words, the TCs are written
so that they do not have to be updated when new assignments are made,
which avoids the work of creating a new RFC and avoids creating extra
work for IANA.

>    If we need to create a new MIB module ourselves (option a), then
>    we could be more specific this time by making the SYNTAX for
>    T11FcSpPolicyHashValue as follows:
> 
>        SYNTAX        OCTET STRING (SIZE (20 | 32))
> 
>    because there are no other lengths possible given the currently
>    specified/valid formats.
 
See above -- the syantax is based on the field size, not on the currently
assigned values.  That is, it is based on Table 106, not on Table 107,
of FC-SP (06-157v3)

> 3. I am not sure if (how) it is wise to merge values from
>    3 different tables in the FC-SP spec (tables 17/18, 48 and 52)
>    into one Textual Convention for the code and one for CodeExp.
>  
>        T11FcSpAuthRejectReasonCode
>        T11FcSpAuthRejReasonCodeExp
> 
>    In some cases, not all values are valid, are they? The set of
>    reasons and Reason Explanations is different for the 3
>    types of messages listed in the DESCRIPTION clause.
> 
>    Maybe it is OK, but I am somewhat worried.

If they were three unrelated values, then I would share your concern. 
However, all three types are potential values of a reason code (or
reason code explanation).  In effect, the merge here is the same
as woudl be done by using a C-language "union" construct, but the
SMIv2 doesn't have one.  The merge is possible in this case because
the combined set of potential values can all be included uniquely by
assigning a unique named-number enumeration for each one.

> 4. T11FcSpPolicyNameType
>    I find it very unfriendly that Internationalized names are not
>    defined/allowed. But I do see that the base spec [FC-SP] does
>    not allow it, so I guess we can only model the spec that T11
>    has approved (or will approve).

Perhaps, Claudio and David can take this comment back to T11 for
consideration in FC-SP2.

> 5. Personal and subjective preference: I would rename
> 
>      T11FcSpAlphaNumNameOrNull
> 
>    into
> 
>      T11FcSpAlphaNumNameOrNone
> 
>    The "Null" often makes people think of 0 (zero).
 
I checked existing RFCs, and I found one xxOrNull and four xxOrNone
TCs, two of which (VlanIdOrNone and VlanIdOrAnyOrNone) are
integer-valued with "None" representing zero !!  So, the precedent is
not that clear (except for the one you defined yourself:-).  Perhaps
the greatest clarity would be:  T11FcSpAlphaNumNameOrAbsent ??

> 6. As reported by the SYNTAX checkers, I would change the underlying
>    SYNTAX for T11FcSpiIndex and T11FcSpPrecedence to be 
> 
>     SYNTAX   Unsigned32 (0..4294967295)
> 
>    instead of:
> 
>     SYNTAX   Unsigned32  -- the default range: (0..4294967295)

I did change them, but please note that RFC 2578 defines it as:

  Unsigned32 ::=
      [APPLICATION 2]
          IMPLICIT INTEGER (0..4294967295)

so the change is unquestionably redundant.

> 7. I wonder if it would be good (I think it would be) to add a
>    REFERENCE clause to each of the Encryption and Authentication
>    algorithms specified by the OBKECT-IDENTITIES.

It will be somewhat repetitious because all of the ENCR_xxx are in
Table 70, and all of the AUTH_xxx are in Table 71, but if you're
concerned that the macros could be extracted and displayed individually
rather than as part of the MIB, then yes, there is a circumstance
where it would be advantageous.

Thanks,
Keith.


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