Re: Informational RFC to be: draft-narasimhan-ietf-slapp-01.txt

The IESG has no problem with the publication of 'SLAPP : Secure Light 
Access Point Protocol' <draft-narasimhan-ietf-slapp-01.txt> as an 
Informational RFC. 

The IESG would also like the RFC-Editor to review the comments in the 
datatracker 
(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13058&rfc_flag=0) 
related to this document and determine whether or not they merit 
incorporation into the document. Comments may exist in both the ballot 
and the comment log. 

The IESG contact person is Dan Romascanu.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-narasimhan-ietf-slapp-01.txt

The process for such documents is described at http://www.rfc-editor.org/indsubs.html.

Thank you,

The IESG Secretary

Technical Summary

    The CAPWAP problem statement (RFC 3990) describes a problem that 
    needs to be addressed before a wireless LAN (WLAN) network designer 
    can construct a solution composed of Wireless Termination Points 
    (WTP) and Access Controllers (AC) from multiple, different vendors.  
    One of the primary goals is to find a solution that solves the 
    interoperability between the two classes of devices (WTPs and ACs) 
    which then enables an AC from one vendor to control and manage a WTP 
    from another.

    The interoperability problem is more general than as stated in the
    CAPWAP problem statement because it can arise out of other
    networks that do not necessarily involve WLAN or any wireless
    devices.  A similar problem exists in any network that is composed of
    network elements that are managed by a centralized controller where
    these two classes of devices are from different vendors and need to
    interoperate with each other such that the network elements can be
    controlled and managed by the controller.

    A possible solution to this problem is to split it into two parts -
    one that is technology or application independent which serves as a
    common framework across multiple underlying technologies, and another
    that is dependent on the underlying technology that is being used in
    the network.  For example, methods and parameters used by an 802.11
    AC to configure and manage a network of 802.11 WTPs are expected to
    be quite different than that used by an equivalent 802.16 controller
    to manage a network of 802.16 base stations.  The architectural
    choices for these two underlying technologies may also be
    significantly different.

    This document defines a protocol that forms the common
    technology-independent framework and the ability to negotiate and
    add, on top of this framework, a control protocol that contains a
    technology-dependent component to arrive at a complete solution.  It 
    also defines two such control protocols - an 802.11 Control
    protocol, and another a more generic image download protocol, in this
    draft.

    Even though the text in this document is written to specifically
    address the problem stated in RFC 3990, the solution can be applied 
    to any problem that has a controller (equivalent to the AC) managing 
    one or more network elements (equivalent to the WTP).

Working Group Summary

    This document was a candidate protocol submission for the Control and
    Provisioning of Wireless Access Points (CAPWAP) Working Group. It is
    being published for informational and historical reference purposes.

Protocol Quality

    The evaluation of the candidate protocols for CAPWAP is being
    described in RFC 4565.

    This document is not a candidate for any level of Internet
    Standard.  The document has not had complete IETF review for such
    things as security, congestion control, or inappropriate interaction 
    with deployed protocols.

Note to RFC Editor

   The IESG takes note that this submission is being published for 
   historic reference, with the intention to document an initial
   submission for the CAPWAP protocol. In order to avoid confusion, the
   IESG recommends that this document  be published only after the 
   approval and publication of the CAPWAP protocol (draft-ietf-capwap-
   protocol-specification) as Proposed Standard. 

   The IESG believes that the appropriate status at the publication of 
   this RFC would be 'Historic', and that the note 'Obsoleted by RFC
   xxxx' should be added on the front page, where xxxx will be the RFC 
   number of the CAPWAP protocol specification. 

   RFC Editor, please make the following changes:

   1. Place either in or immediately following the "Status of this Memo"
   section of the finished RFC the IESG note below

   2. Add the note 'Obsoleted by RFC xxxx' on the front page, where xxxx

   will be the RFC number of the CAPWAP protocol specification.

   3. Update the boilerplate according to RFC 4748

   4. Rename 'References' Section as 'Informative References'

   5. Replace outdated reference draft-ietf-capwap-objectives by RFC 4564

   6. Replace outdated reference draft-rescorla-dtls by RFC 4347

   7. Replace obsolete reference: RFC 2246 by RFC 4346

IESG Note

  In conformance with RFC 3932, Section 4, the IESG requests the
  publication of the following note:

  "This RFC documents the SLAPP protocol as it was when submitted to
  the IETF as a basis for further work in the CAPWAP WG, and therefore
  it may resemble the CAPWAP protocol specification (RFC XXXX), as well
  as other current IETF work in progress or published IETF work.
  This RFC is being published solely for the historical record. The 
  protocol described in this RFC has not been thoroughly reviewed and may
  contain errors and omissions. 

  RFC XXXX documents the standards track solution for the CAPWAP
  Working Group and obsoletes any and all mechanisms defined in this RFC.
  This RFC itself is not a candidate for any level of Internet 
  Standard and should not be used as a basis for any sort of deployment 
  in the Internet.

  The IETF disclaims any knowledge of the fitness of this
  RFC for any purpose, and in particular notes that it has not had
  complete IETF review for such things as security, congestion control,
  or inappropriate interaction with deployed protocols.  The RFC Editor
  has chosen to publish this document at its discretion."

IANA Note

   As this document is not a candidate for standardization or deployment
   in the Internet, IANA is not required to take any action.

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