Skip to main content

SLAPP: Secure Light Access Point Protocol
draft-narasimhan-ietf-slapp-01

Revision differences

Document history

Date Rev. By Action
2012-08-22
01 (System) post-migration administrative database adjustment to the No Objection position for Cullen Jennings
2012-08-22
01 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
01 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2012-08-22
01 (System) post-migration administrative database adjustment to the Abstain position for Mark Townsley
2009-05-01
01 Amy Vezza
[Note]: 'This document is an independent submission via the RFC Editor.  In conformance with RFC 3932, Section 4, the IESG requests the
  publication of …
[Note]: 'This document is an independent submission via the RFC Editor.  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."' added by Amy Vezza
2009-05-01
01 Amy Vezza State Change Notice email list have been change to capwap-chairs@tools.ietf.org, rfc-editor@rfc-editor.org from capwap-chairs@tools.ietf.org
2007-05-08
01 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-05-08
01 Amy Vezza
[Note]: 'This document is an independent submission via the RFC Editor.  In conformance with RFC 3932, Section 4, the IESG requests the
  publication …
[Note]: 'This document is an independent submission via the RFC Editor.  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."' added by Amy Vezza
2007-05-08
01 Amy Vezza IESG state changed to Approved-announcement sent
2007-05-08
01 Amy Vezza IESG has approved the document
2007-05-08
01 Amy Vezza Closed "Approve" ballot
2007-05-02
01 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to Abstain from Discuss by Mark Townsley
2007-05-02
01 Dan Romascanu
[Note]: 'This document is an independent submission via the RFC Editor.   In conformance with RFC 3932, Section 4, the IESG requests the
  publication …
[Note]: 'This document is an independent submission via the RFC Editor.   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."

' added by Dan Romascanu
2007-04-30
01 Cullen Jennings [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings
2007-04-27
01 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss by Tim Polk
2007-04-26
01 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2007-04-20
01 (System) Removed from agenda for telechat - 2007-04-19
2007-04-19
01 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2007-04-19
01 Cullen Jennings [Ballot discuss]
I would like to understand why publish at all. Would prefer historic.
2007-04-19
01 Cullen Jennings [Ballot discuss]
Like do understand why publish at all. Would prefer historic.
2007-04-19
01 Cullen Jennings [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings
2007-04-19
01 Mark Townsley
[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option …
[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option 3 from section 3 of RFC3932:

  3. The IESG thinks that publication is harmful to the IETF work done
      in WG capwap and recommends not publishing the document at this time.

I understand that there is precedent for publication of overlapping input into the standards process (IPFIX was identified) but remain unconvinced. There is plenty of other precedent showing that overlapping independent work is delayed until standards track work is finished, and is a significant part of the spirit of the IESG review procedures instilled in RFC 3932.

Beyond this, this particular document is hardly fit for publication in current form.

1. Section 6.2 invents its own file download mechanism without thought for congestion control or other transport issues

2. Section 4.6.1 tries to handwave that WTP discovery can occur in one of no less than 6 different ways, none of which (save perhaps #1, static config) is specified in such way to be implemented. For example:

-    2.  DHCP options: As part of the DHCP response, the DHCP server could
        be configured to use option 43 to deliver the IP address of an AC
        to which the WTP should address the SLAPP discover request
        packet.  If the IP address of an AC is handed to the WTP as part
        of the DHCP response, then the WTP should address the SLAPP
        discover request packet to this IP address.

For reference, option 43 is an option for carrying vendor-specific information, and "could" is hardly the normative language necessary for a protocol specification.

One sentence is devoted to "Multicast discovery" with "[TBD]" at the end. Are we really going to allocate a Multicast address for this protocol?

DNS is mentioned as a "discovery" method, with no mention of what record type to use (again, a casual "[TBD]" inserted here).

In fact....

% grep  IANA draft-narasimhan-ietf-slapp-01.txt
    registered with, IANA).
                3-255  - RESERVED (to IANA)
    from, and registered with, IANA).  This field appears once for each
% grep  TBD draft-narasimhan-ietf-slapp-01.txt
    packet is a UDP packet addressed to port [TBD] designated as the
    port [TBD] and the destination port is the same as the source port
        multicast address [TBD].
        an AC [TBD].  If this DNS query succeeds, then the WTP should
    AC for this exchange will be [TBD].
    is TBD; when GRE encapsulates 802.3 frames the ether type in the GRE
    header is TBD2.

...yet there is no IANA Considerations section in the document.

I can't read anymore. This document is not fit for publication at any level of protocol specification, even Historic as this implies that at one time it might have been valid for implementation. The -01 version is hardly changed from -00. At best, this looks like a "first cut" of a protocol that needs a whole lot of work given that it tries to cover auto-discovery, file transport, L2 encapsulation over IP, Security, etc.

Given this document's gaping holes in design, coupled with its vast scope and apparant lack of review, I believe there is no chance for interoperability and a significant possibility for harm if one attempted to use this as a basis for implementation. I reiterate my stance that this document could be harmful if published in this form. Additional RFC Editor cycles should not be spent on this document without significant improvement from the authors first.
2007-04-19
01 Mark Townsley
[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option …
[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option 3 from section 3 of RFC3932:

  3. The IESG thinks that publication is harmful to the IETF work done
      in WG capwap and recommends not publishing the document at this time.

I understand that there is precedent for publication of overlapping input into the standards process (IPFIX was identified) but remain unconvinced. There is plenty of other precedent showing that overlapping independent work is delayed until standards track work is finished, and is a significant part of the spirit of the IESG review procedures instilled in RFC 3932.

Beyond this, this particular document is hardly fit for publication in current form.

1. Section 6.2 invents its own file download mechanism without thought for congestion control or other transport issues

2. Section 4.6.1 tries to handwave that WTP discovery can occur in one of no less than 6 different ways, none of which (save perhaps #1, static config) is specified in such way to be implemented. For example:

-    2.  DHCP options: As part of the DHCP response, the DHCP server could
        be configured to use option 43 to deliver the IP address of an AC
        to which the WTP should address the SLAPP discover request
        packet.  If the IP address of an AC is handed to the WTP as part
        of the DHCP response, then the WTP should address the SLAPP
        discover request packet to this IP address.

For reference, option 43 is an option for carrying vendor-specific information, and "could" is hardly the normative language necessary for a protocol specification.

One sentence is devoted to "Multicast discovery" with "[TBD]" at the end. Are we really going to allocate a Multicast address for this protocol?

DNS is mentioned as a "discovery" method, with no mention of what record type to use (again, a casual "[TBD]" inserted here).

In fact....

% grep  IANA draft-narasimhan-ietf-slapp-01.txt
    registered with, IANA).
                3-255  - RESERVED (to IANA)
    from, and registered with, IANA).  This field appears once for each
% grep  TBD draft-narasimhan-ietf-slapp-01.txt
    packet is a UDP packet addressed to port [TBD] designated as the
    port [TBD] and the destination port is the same as the source port
        multicast address [TBD].
        an AC [TBD].  If this DNS query succeeds, then the WTP should
    AC for this exchange will be [TBD].
    is TBD; when GRE encapsulates 802.3 frames the ether type in the GRE
    header is TBD2.

...yet there is no IANA Considerations section in the document.

I can't read anymore. This document is not fit for publication at any level of protocol specification, even Historic as this implies that at one time it might have been valid for implementation. The -01 version is hardly changed from -00. At best, this looks like a "first cut" of a protocol that needs a whole lot of work given that it tries to cover auto-discovery, file transport, L2 encapsulation over IP, etc.

Given this document's gaping holes in design, coupled with its vast scope and apparant lack of review, I believe there is no chance for interoperability and a significant possibility for harm if one attempted to use this as a basis for implementation. I reiterate my stance that this document could be harmful if published in this form. Additional RFC Editor cycles should not be spent on this document without significant improvement from the authors first.
2007-04-19
01 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2007-04-18
01 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2007-04-18
01 Mark Townsley
[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option …
[Ballot discuss]
First, I believe this document is clearly overlapping with capwap, and could be harmful to the work done there, at least meriting option 3 from section 3 of RFC3932:

  3. The IESG thinks that publication is harmful to the IETF work done
      in WG capwap and recommends not publishing the document at this time.

I understand that there is precedent for publication of overlapping input into the standards process (IPFIX was identified) but remain unconvinced. There is plenty of other precedent showing that overlapping independent work is delayed until standards track work is finished, and is a significant part of the spirit of the IESG review procedures instilled in RFC 3932.

Beyond this, this particular document is hardly fit for publication in current form.

1. Section 6.2 invents its own file download mechanism without thought for congestion control or other transport issues

2. Section 4.6.1 tries to handwave that WTP discovery can occur in one of 6 different ways, none of which (save perhaps #1, static config) is specified in such way to be implemented. For example:

-    2.  DHCP options: As part of the DHCP response, the DHCP server could
        be configured to use option 43 to deliver the IP address of an AC
        to which the WTP should address the SLAPP discover request
        packet.  If the IP address of an AC is handed to the WTP as part
        of the DHCP response, then the WTP should address the SLAPP
        discover request packet to this IP address.

For reference, option 43 is an option for carrying vendor-specific information, and "could" is hardly the normative language necessary for a protocol specification.

One sentence is devoted to "Multicast discovery" with "[TBD]" at the end. Are we really going to allocate a Multicast address for this protocol?

DNS is mentioned as a "discovery" method, with no mention of what record type to use (again, a casual "[TBD]" inserted here).

In fact....

% grep  IANA draft-narasimhan-ietf-slapp-01.txt
    registered with, IANA).
                3-255  - RESERVED (to IANA)
    from, and registered with, IANA).  This field appears once for each
% grep  TBD draft-narasimhan-ietf-slapp-01.txt
    packet is a UDP packet addressed to port [TBD] designated as the
    port [TBD] and the destination port is the same as the source port
        multicast address [TBD].
        an AC [TBD].  If this DNS query succeeds, then the WTP should
    AC for this exchange will be [TBD].
    is TBD; when GRE encapsulates 802.3 frames the ether type in the GRE
    header is TBD2.

...yet there is no IANA Considerations section in the document.

I can't read anymore. This document is not fit for publication at any level of protocol specification, even Historic as this implies that at one time it might have been valid. The -01 version is hardly changed from -00. At best, this looks like a "first cut" of a protocol that needs a whole lot of work given that it tries to cover auto-discovery, file transport, L2 encapsulation over IP, etc.

I see no good reason to publish this document at all in this form. Given the gaping holes in design, lack of review and iteration, and vast scope, there is a lot possibility for harm if anyone tries to implement this.
2007-04-18
01 Mark Townsley [Ballot Position Update] New position, Discuss, has been recorded by Mark Townsley
2007-04-18
01 Magnus Westerlund
[Ballot discuss]
I strongly argue that we should recommend the RFC-editor to not publish this document as it describes a protocol that lacks basic congestion …
[Ballot discuss]
I strongly argue that we should recommend the RFC-editor to not publish this document as it describes a protocol that lacks basic congestion control mechanisms. The authors should start with reading:
http://www.ietf.org/internet-drafts/draft-eggert-tsvwg-udp-guidelines-02.txt
And then consider if they really need to implement the protocol on top of UDP instead of TCP, with the possible special UDP function for broadcast discovery of ACs.

To go into more detail. The protocol is clearly intended to be used in a general IP network environemnt as described in section 3, Topology. It performs both simple request response actions and bulk data transfers (Image Download). It has no rate control function at all. It has no reaction to losses, other than retransmitting. This is a protocol that is dangerous to itself and other traffic from a congestion point of view.
2007-04-18
01 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund
2007-04-18
01 Yoshiko Fong
IANA Evaluation Comments:


The IANA consideration section is not clear on what actions
are requested of IANA.

No IANA Considerations section but registrations observed
in …
IANA Evaluation Comments:


The IANA consideration section is not clear on what actions
are requested of IANA.

No IANA Considerations section but registrations observed
in the document.
2007-04-17
01 Russ Housley
[Ballot comment]
The Abstract should not contain references like [3].  These references
  need to be replaced with text that points to an RFC by …
[Ballot comment]
The Abstract should not contain references like [3].  These references
  need to be replaced with text that points to an RFC by number.  It is
  important to remember that the Abstract is copied into an RFC index.
2007-04-17
01 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2007-04-17
01 Tim Polk
[Ballot discuss]
This discuss has two parts.

The first part is a discuss discuss: As I read the IESG note, a standards track protocol is …
[Ballot discuss]
This discuss has two parts.

The first part is a discuss discuss: As I read the IESG note, a standards track protocol is forthcoming for capwap.  Publication of the slapp specification as "Informational" may cause confusion, particularly since the standards track protocol is still under development.  (1) Wouldn't it be better to progress this specification as "Historic"? (2) Should we delay publication of this spec until the standards track protocol is published?

The second part is a normal discuss position:

The security considerations text begins with

    This document describes a protocol, SLAPP, which uses a different
    protocol, DTLS, to provide for authentication, key exchange, and bulk
    data encryption of a negotiated control protocol.  It's security
    considerations are therefore those of DTLS.

I believe that is an oversimplification.

    This document describes a technology independent protocol for controller discovery,
    security association establishment, and control protocol negotiation.  Authentication,
    key exchange, and bulk data encryption are required during the security assocation
    phase.  This protocol depends upon DTLS [7] to provide authentication, key exchange,
    and bulk data for security association establishment.  As a result, the security
    considerations described in [7] apply to the security association establishment phase
    of this protocol.
2007-04-17
01 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2007-04-16
01 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-04-13
01 Dan Romascanu
[Note]: 'This document is an independent submission via the RFC Editor. In conformace with RFC 3932, Section 4, the IESG requests the publication of …
[Note]: 'This document is an independent submission via the RFC Editor. In conformace 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 a current IETF work in progress or a published IETF work. This RFC itself is not a candidate for any level of Internet Standard. 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."
' added by Dan Romascanu
2007-04-13
01 Dan Romascanu
[Note]: 'This document is an independent submission via the RFC Editor. In conformace with RFC 3932, Section 4, the IESG requests the publication of …
[Note]: 'This document is an independent submission via the RFC Editor. In conformace 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 a current IETF work in progress or a published IETF work.

   This RFC itself is not a candidate for any level of Internet
   Standard.  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."
' added by Dan Romascanu
2007-04-11
01 Dan Romascanu [Ballot Position Update] New position, Yes, has been recorded for Dan Romascanu
2007-04-11
01 Dan Romascanu Ballot has been issued by Dan Romascanu
2007-04-11
01 Dan Romascanu Created "Approve" ballot
2007-04-11
01 (System) Ballot writeup text was added
2007-04-11
01 (System) Last call text was added
2007-04-11
01 (System) Ballot approval text was added
2007-04-11
01 Dan Romascanu State Changes to IESG Evaluation from Publication Requested by Dan Romascanu
2007-04-11
01 Dan Romascanu Placed on agenda for telechat - 2007-04-19 by Dan Romascanu
2007-02-06
01 Dan Romascanu Responsible AD has been changed to Dan Romascanu from Brian Carpenter
2007-02-05
01 Dinara Suleymanova Placed on agenda for telechat - 2007-02-08 by Dinara Suleymanova
2007-01-25
01 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-03-23
01 Bert Wijnen I-D Resurrection was requested by Bert Wijnen
2006-03-21
01 Dan Romascanu I-D Resurrection was requested by Dan Romascanu
2005-11-16
(System) Posted related IPR disclosure: NextHop Technologies 's statement about IPR claimed in draft-narasimhan-ietf-slapp-01.txt
2005-09-07
(System) Posted related IPR disclosure: Cisco's Statement about IPR claimed in draft-singh-capwap-ctp-02.txt, draft-iino-capwap-wicop-02.txt, internet-drafts/draft-narasimhan-ietf-slapp-01.txt
2005-06-01
01 (System) New version available: draft-narasimhan-ietf-slapp-01.txt
2005-04-05
00 (System) New version available: draft-narasimhan-ietf-slapp-00.txt