|
|
Yes, I should be able to produce a new version today, and make the
submission to internet-drafts@xxxxxxxx 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@xxxxxxxxx]
> > Sent: Monday, December 12, 2005 23:09
> > To: iesg@xxxxxxxx
> > Cc: imss@xxxxxxxx; black_david@xxxxxxx; roger_cummings@xxxxxxxxxxxx;
> > bwijnen@xxxxxxxxxx; Orly_n@xxxxxxxxx
> > 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/imss
|
|