[storm] Protocol Action: 'Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)' to Proposed Standard (draft-ietf-storm-ifcpmib-07.txt)

The IESG <iesg-secretary@ietf.org> Mon, 22 November 2010 20:49 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 221BA28C165; Mon, 22 Nov 2010 12:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id OcHwLBHHeHyI; Mon, 22 Nov 2010 12:49:21 -0800 (PST)
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id A1B2628C16E; Mon, 22 Nov 2010 12:49:20 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 3.09
Message-ID: <20101122204920.21872.61500.idtracker@localhost>
Date: Mon, 22 Nov 2010 12:49:20 -0800
Cc: storm mailing list <storm@ietf.org>, Internet Architecture Board <iab@iab.org>, storm chair <storm-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [storm] Protocol Action: 'Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)' to Proposed Standard (draft-ietf-storm-ifcpmib-07.txt)
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Nov 2010 20:49:22 -0000

The IESG has approved the following document:
- 'Definitions of Managed Objects for Internet Fibre Channel Protocol
  (draft-ietf-storm-ifcpmib-07.txt) as a Proposed Standard

This document is the product of the STORage Maintenance Working Group.

The IESG contact persons are David Harrington and Lars Eggert.

A URL of this Internet Draft is:

Technical Summary

This document defines Management Information Base (MIB) objects to
allow a network management protocol to be used to monitor and manage
local iFCP gateway instances, including the configuration of iFCP sessions
between gateways. This document updates, and obsoletes, RFC4369.

Working Group Summary

The WG process to create this document went very smoothly, in large part
owing to the existing publication of RFC4369. Comments were constructive
and were easily addressed with minor changes to the draft version. The
document was well-received and Working Group consensus was easily

Document Quality

The document is of high quality, and while written to support iFCP, has
architectural relevance to other current Internet protocols supporting the
SCSI family. The iFCP protocol, now largely historical, is deployed in
numerous products. The MIB objects in the document are therefore
expected to be relevant to iFCP management, as well as to provide a basis
for additional related efforts. 

The area director is a MIB Doctor, and he found the module to be in good shape.
The document went through an independent MIB Doctor review, and certain SMIv2 requirements were addressed.
It passes libsmi syntax checks, id-nits, and RFC4181 guidelines.


Document Shepherd:  Tom Talpey (STORM WG co-chair), 
Responsible Area Director:  David Harrington
This document defines no new IANA registries.

RFC Editor Note

The authors of RFC 4369 are listed in the Authors' Addresses, but did not work on this update.
They were added to ensure they got credit for the original published version of this document.
They should not need to be contacted during auth48.