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

Sorry for the delayed appearance of this message to the list -
it was caught in the IETF spam-trap, which I only just got
a "round tuit" for emptying ...

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: imss-bounces@ietf.org [mailto:imss-bounces@ietf.org] On 
> Behalf Of Brian E Carpenter
> Sent: Friday, December 16, 2005 2:56 AM
> To: Keith McCloghrie
> Cc: roger_cummings@symantec.com; Orly_n@rad.co.il; 
> imss@ietf.org; bwijnen@lucent.com; Black, David; iesg@ietf.org
> Subject: Re: [imss] Last Call: 'Fibre-Channel Name Server 
> MIB' to Proposed Standard
> 
> 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
> imss@ietf.org
> https://www1.ietf.org/mailman/listinfo/imss
> 

_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss