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

[Keith McCloghrie <[e-mail]>]

Hi Brian,

Your words are fine.  I didn't mean to imply that either party is required
to agree with the other, but past experience showed that neither party had
the full range of technical knowledge needed to produce the desired result
without help from the other.

Thanks,
Keith.

> Keith,
> 
> No technical comment from me, but I was tickled by two of your
> phrases.
> 
>  > ...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.
> ...
>  > ...Thus, to comply with the decision of T11.5,
> 
> I trust that what you really mean is
> 
>   ...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
>   considered for the IETF standards track.
> 
> and
> 
>   ...Thus, to be consistent with the decision of T11.5
> 
> since the IETF is autonomous in its decisions.
> 
> Regards
>      Brian
> 
> Keith McCloghrie wrote:
> >>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