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

From: The IESG <[email-masked]>
Date: Thu, 01 Dec 2005 09:59:35 -0500

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2005-12-15.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-nsm-mib-04.txt

_______________________________________________
imss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 20 Dec 2005 14:26:09 +0100

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:[email-masked]]
> Sent: Monday, December 12, 2005 23:09
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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:
> >
> 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".
>

---

From: [email-masked]
Date: Fri, 23 Dec 2005 21:33:08 -0500

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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Friday, December 16, 2005 2:56 AM
> To: Keith McCloghrie
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Black, David; [email-masked]
> 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
>  > 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
>   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: