Protocol Action: 'Finding FCIP Entities Using SLPv2' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Thu, 24 June 2004 18:50 UTC

Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12252 for <ietf-announce-archive@ietf.org>; Thu, 24 Jun 2004 14:50:31 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdZIu-0005vn-EJ for ietf-announce-archive@ietf.org; Thu, 24 Jun 2004 14:50:32 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdZ1Z-0002QA-00 for ietf-announce-archive@ietf.org; Thu, 24 Jun 2004 14:32:38 -0400
Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BdYos-0007Fq-00; Thu, 24 Jun 2004 14:19:30 -0400
Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BdYj2-00022x-Aq; Thu, 24 Jun 2004 14:13:28 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXNp-0002wc-K2; Thu, 24 Jun 2004 12:47:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdCya-0005Xe-2d for ietf-announce@megatron.ietf.org; Wed, 23 Jun 2004 15:00:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05264 for <ietf-announce@ietf.org>; Wed, 23 Jun 2004 15:00:01 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdCyY-0005qg-0e for ietf-announce@ietf.org; Wed, 23 Jun 2004 15:00:02 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdCxV-0005SI-00 for ietf-announce@ietf.org; Wed, 23 Jun 2004 14:58:58 -0400
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdCwq-00050P-00; Wed, 23 Jun 2004 14:58:16 -0400
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BdCs1-0004Tt-De; Wed, 23 Jun 2004 14:53:17 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1BdCs1-0004Tt-De@megatron.ietf.org>
Date: Wed, 23 Jun 2004 14:53:17 -0400
Cc: ips mailing list <ips@ietf.org>, Internet Architecture Board <iab@iab.org>, ips chair <Elizabeth.Rodriguez@DotHill.com>, ips chair <black_david@emc.com>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Finding FCIP Entities Using SLPv2' to Proposed Standard
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60

The IESG has approved the following document:

- 'Finding FCIP Entities Using SLPv2 '
   <draft-ietf-ips-fcip-slp-09.txt> as a Proposed Standard

This document is the product of the IP Storage Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

Technical Summary

      draft-ietf-ips-fcip-slp-09.txt describes the use of the Service
      Location Protocol Version 2 (SLPv2) to perform dynamic discovery of
      participating FCIP Entities. Implementation guidelines, service
      type templates, and security considerations are specified. FCIP is
      a pure FC encapsulation protocol that transports FC frames. As
      defined by the IPS WG, it interconnects Fibre Channel switches over
      TCP/IP networks.


Working Group Summary

    The Working Group had consensus to advance this documents to Proposed
    Standard. The SLPv2 and discovery aspects were given review and
    discussion on the mailing list by Erik Guttman and James Kempf, and this
    was an active discussion.   This document had a revision following
    IESG review which was concerned about the Security Considerations and
    some text originally present on NAT, which was viewed as needing to be
    in a more general document and as not providing significant guidance.
    
Protocol Quality

    The documents were reviewed for the IESG by Erik Guttman, James Kempf,
    Thomas Narten and Allison Mankin.    David Black addressed the issues
     of the security review.

RFC Editor Notes

-----
  Section 4.2 NAT and NAPT Considerations - delete this entire section

-----
 Section 5.2 - remove the line:
       #  snmp://192.0.2.0

-----
 Section 6.1. Security Implementation - section is replaced by new text:

  OLD:

6.1.  Security Implementation


   Security for SLPv2 in an IP storage environment is specified in [IPS-
   SEC].


   IPsec SHOULD be implemented for SLPv2 as specified in [IPS-SEC]. This
   includes ESP with a non-null transform to provide both authentication
   and confidentiality.


   SLPv2 authentication is OPTIONAL to  implement  and  use,  and  SLPv2
   authentication SHOULD be implemented when IPsec is not supported.
  

  NEW:


6.1.  Security Implementation


   Security for SLPv2 in an IP storage environment is specified in
   [RFC3723]. IPsec is mandatory-to-implement for IPS clients and servers.
   Thus, all IP storage clients, including those invoking SLP, can be
   assumed to support IPsec. SLP servers, however, cannot be assumed
   to implement IPsec, since there is no such requirement in standard
   SLP.   In particular, SLP Directory Agents (DA) may be running on machines
   other than those running the IPS protocols.

   IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this
   includes ESP with a non-null transform to provide both authentication
   and confidentiality.

   Because the IP storage services have their own authentication
   capabilities when located, SLPv2 authentication is OPTIONAL
   to implement and use (as discussed in more detail in [RFC 3723]).

Change the draft's normative reference [IPS-SEC] to [RFC 3723].


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce