Subject: [MIB-DOCTORS] MIB doctor review part 2 (T11-FC-SP-TC-MIB): draft-ietf-imss-fc-fcsp-mib-00.txt

From: "WIJNEN, Bert \(Bert\)" <[email-masked]>
Date: Mon, 26 Nov 2007 18:08:52 +0100

[bcc to MIB doctors]

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. 

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? 

   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.

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.

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

5. Personal and subjective preference: I would rename

     T11FcSpAlphaNumNameOrNull

   into

     T11FcSpAlphaNumNameOrNone

   The "Null" often makes people think of 0 (zero).

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)

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.

Bert

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors