Re: [imss] Last Call: 'Fibre-Channel Name Server MIB' to Proposed Standard

[Keith McCloghrie <[e-mail]>]

> The IESG has received a request from the Internet and Management Support
> for Storage WG to consider the following document:
>
> - 'Fibre-Channel Name Server MIB '
>    <draft-ietf-imss-fc-nsm-mib-04.txt> as a Proposed Standard

draft-ietf-imss-fc-nsm-mib-04.txt is the second in a series of Fibre
Channel MIBs which are being defined in the T11.5 working-group of
INCITS, and then passed onto the IETF's IMSS Working Group to be
approved as Internet Standards.  T11.5 is presently working on the
content of last few MIBs in the series.

In the T11.5 meeting last week, the review of Letter Ballot comments
for the Fibre Channel Zone Server MIB prompted a discussion about
having consistency in the MIB representation of error codes across all
types of Rejects (SW_RJT's, CT_IU Rejects, LS_RJT's).  The outcome of
the discussion was this: since Fibre Channel defines error codes in a
consistent manner for all "Generic Services" (defined in the FC-GS-5
specification), so too should each of the MIBs define objects in a
consistent manner to represent those error codes.  Specifically, since
FC-GS-5 defines error codes as consisting of three separate values:

  Reason-Code,
  Reason-Code-Explanation, and
  Reason-Vendor-Specific-Code

each of the relevant MIBs should define three separate objects, one for
each of these three values.

One such relevant MIB is the Fibre-Channel Name Server MIB in
draft-ietf-imss-fc-nsm-mib-04.txt, presently in IETF Last Call, which
defines a notification to be generated when a request is rejected.  Two
of the objects that it requires to be included in that notification are:

            t11NsRejectReasonCode, t11NsRejReasonCodeExp,

representing the Reason-Code and Reason-Code-Explanation, but it does
not specify an object representing the Reason-Vendor-Specific-Code.
Thus, to comply with the decision of T11.5, the MIB contained in
draft-ietf-imss-fc-nsm-mib-04.txt should be updated to contain an
object for the Reason-Vendor-Specific-Code.

The specific edits which would be required for this change are listed
below.

Keith.
---------------------

The edits to draft-ietf-imss-fc-nsm-mib-04.txt are to insert 
lines (those marked with an asterisk in the margin) as follows:

1. The addition of one additional OBJECT-TYPE in the t11NsRejectTable:

   T11NsRejectEntry ::= SEQUENCE {
       t11NsRejectCtCommandString   OCTET STRING,
       t11NsRejectReasonCode        T11NsGs4RejectReasonCode,
       t11NsRejReasonCodeExp        T11NsRejReasonCodeExpl,
*      t11NsRejReasonVendorCode     OCTET STRING
   }

2. The definition of the additional object:

*  t11NsRejReasonVendorCode OBJECT-TYPE
*      SYNTAX        OCTET STRING (SIZE(1))
*      MAX-ACCESS    read-only
*      STATUS        current
*      DESCRIPTION
*             "A registration reject vendor-specific code.   This
*             object contains the vendor-specific code of the most
*             recent Name Server Registration request failure for the
*             particular port on the particular fabric."
*      ::= { t11NsRejectEntry 4 }

3. The insertion of t11NsRejectReasonVendorCode as an additional
object in the t11NsRejectRegNotify notification:

  t11NsRejectRegNotify NOTIFICATION-TYPE
      OBJECTS   { t11FamLocalSwitchWwn,
                  t11NsRegPortName, t11NsRejectCtCommandString,
                  t11NsRejectReasonCode, t11NsRejReasonCodeExp,
*                 t11NsRejReasonVendorCode }
      STATUS    current
      DESCRIPTION
             "This notification is generated ...

             The value of t11NsRejectCtCommandString indicates
             the rejected request, and the values of
             t11NsRejectReasonCode, t11NsRejReasonCodeExp and
*            t11NsRejReasonVendorCode indicate the reason for
             the rejection.
             ...

4. The inclusion of the new object in the relevant object group:

  t11NsNotifyControlGroup  OBJECT-GROUP
      OBJECTS { t11NsRejectCtCommandString,
                t11NsRejectReasonCode,
                t11NsRejReasonCodeExp,
*               t11NsRejReasonVendorCode,
                t11NsInfoSubsetRejReqNotfyEnable }
      STATUS current
      DESCRIPTION
             "A collection ...

5. Update of the example in section 5.5 which mentions "each pair of
t11NsRejectReasonCode and t11NsRejReasonCodeExp objects" so that it
refers to "each set of t11NsRejectReasonCode, t11NsRejReasonCodeExp
and t11NsRejectReasonVendorCode objects".

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