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

Yes, I should be able to produce a new version today, and make the
submission to internet-drafts@ietf.org today.

Keith.

> 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