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

So Keith and co-authors/editors, I am going to assume a new revision 
to address these IETF Last Call comments, right?
Any idea when I can expect that? Today maybe ?
If so, I can probably get the doc on Jan 5 IESG agenda.

AS far as I know, the below were the only IETF Last Call Comments.

Bert
> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Monday, December 12, 2005 23:09
> To: iesg@ietf.org
> Cc: imss@ietf.org; black_david@emc.com; roger_cummings@symantec.com;
> bwijnen@lucent.com; Orly_n@rad.co.il
> Subject: Re: [imss] Last Call: 'Fibre-Channel Name Server MIB' to
> Proposed Standard
> 
> 
> > 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