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

["WIJNEN, Bert \(Bert\)" <[e-mail]>]

Inline

Bert Wijnen  

> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]] 
> Sent: Thursday, November 29, 2007 10:05 AM
> To: WIJNEN, Bert (Bert)
> Cc: [e-mail]
> Subject: Re: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB):
> 
> 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."
> 

Sounds fine to me.

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

OK

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

Thanks for the explanation. If the WG is OK with that (which I guess
is the ase cuase no concern was raised in WG LC), then fine.
 
> > 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.
>

I think that would be good
 
> > 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 ??
>

I can live with Null. Absent would be somewhat better to my
subjective preference; so would None. Up to you.
 
> > 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.
> 

Thanks for the change.
I like it to see an explicit statement that zero is valid in the
index.

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

That is what the REFERENCE clause is intended for I think.

Bert
> Thanks,
> Keith.
> 


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