Subject: [Capwap] [Fwd: Informational RFC to be: draft-narasimhan-ietf-slapp-01.txt]

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Feb 2007 12:17:21 +0200

The following request to publish draft-narasimhan-ietf-slapp as an
Informational RFC was submitted to the RFC Editor. Please let me know if
there are any issues or comments. 

Dan

>>
>> IESG,
>>
>> This RFC-to-be was submitted to the RFC Editor to be published as
>> Informational: draft-narasimhan-ietf-slapp-01.txt.
>>
>> Please let us know if this document conflicts with the IETF standards

>> process or other work being done in the IETF community.
>>
>> Four week timeout expires on 20 February 2007.
>>
>> _________________________________________________________________
>>
>> NOTE to IESG about:  draft-narasimhan-ietf-slapp-01.txt
>>
>> This document, submitted to the RFC Editor as an independent 
>> submission by the WG chair, was a partial product of the CAPWAP 
>> working group.
>> Its publication now is intended to be provide historical record of 
>> input to the WG product, and as such the RFC Editor is exercising 
>> minimal editorial control over it.
>>
>> The RFC Editorial Board raised considerable issue with the principle 
>> of publishing such a "WG spinoff" document as an independent 
>> submission, rather than as a WG or individual submission.  This led 
>> the RFC
> Editor
>> to request a policy opinion from the IAB, but no such policy opinion 
>> was provided.
>>
>> We do not regard publication of this document as an independent 
>> submission to be a precedent.  However, we would REALLY like to clear

>> our ISR queue, and so we are proceeding with its publication.
>>
>> We intend to include the following RFC Editor Note, in addition to 
>> any note requested by the IESG:
>>
>>
>> 	"RFC Editor Note:
>>
>> 	This document was originally submitted to the CAPWAP Working
>> 	Group.  It is being published now as a historical record of the
>> 	development of CAPWAP ideas; it is not an official Working
>> 	Group product."
>>
>> ___________________________________________________
>>
>>                  SLAPP : Secure Light Access Point Protocol
>>
>>    The CAPWAP problem statement [3] 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 [3] 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.
>>
>>    In this draft, we present 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.
>> We
>>    have also presented 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 draft is written to specifically
>>    address the problem stated in [3], 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).
>>
>> Sincerely,
>>
>> Sandy Ginoza - USC/ISI
>> Request for Comments Documents
>>
>>
>>
>>
> 
> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 6 Feb 2007 08:14:04 -0500

Hi Dan,

Don't we usually hold-off on publishing alternative proprietary  
protocols until after the IETF standard protocol is published?

I'd prefer to see publication of this draft and the one you mentioned  
in your previous message (draft-iino-capwap-wicop-02.txt) delayed  
until after the standards-track CAPWAP RFC is published.

Thanks,
Margaret

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 6 Feb 2007 20:56:18 +0200

Margaret,

As you probably know according to RFC 3932 the final decision for
publication of these documents belongs to the RFC Editor. The IESG has
an advisory role concerning the relation of the documents to work being
done in the IETF. The IESG may still decide to publish the documents
despite a negative recommendation from the IESG, with an appropriate
IESG note.

Is this you opinion as an individual? 

You may want to check the consensus of the WG, you still have until 2/19
for this purpose, and a position backed by WG consensus may have more
weight in the recommendation that the iESG will make. 

Dan

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Tuesday, February 06, 2007 3:14 PM
> To: Romascanu, Dan (Dan)
> Cc: capwap
> Subject: Re: [Capwap] [Fwd: Informational RFC to be: 
> draft-narasimhan-ietf-slapp-01.txt]
> 
> 
> Hi Dan,
> 
> Don't we usually hold-off on publishing alternative 
> proprietary protocols until after the IETF standard protocol 
> is published?
> 
> I'd prefer to see publication of this draft and the one you 
> mentioned in your previous message 
> (draft-iino-capwap-wicop-02.txt) delayed until after the 
> standards-track CAPWAP RFC is published.
> 
> Thanks,
> Margaret
> 
> 
> > Informational RFC was submitted to the RFC Editor. Please 
> let me know 
> > if there are any issues or comments.
> >
> > Dan
> >
> >
> >
> >>>
> >>> IESG,
> >>>
> >>>    The CAPWAP problem statement [3] describes a problem 
> that needs 
> >>> to
> >
> >>> be
> >>>    and Access Controllers (AC) from multiple, different 
> vendors.   
> >>> One

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 6 Feb 2007 14:33:08 -0500

Hi Dan,

Yes, I was expressing my personal opinion.  I personally think that  
publication of these drafts should be delayed until after the CAPWAP  
RFCs are published.  Other members of the WG are encouraged to share  
their opinions, so that we can see if any WG consensus exists on this  
topic.

For WG members who may not be familiar with this process, the  
documents in question were submitted as individual submissions to the  
RFC editor.  The authors have requested that they be published as RFC  
Editor Informational documents, and the guidelines for publication of  
such documents are described in RFC 3932, which can be found here:

http://www.ietf.org/rfc/rfc3932.txt?number=3932

As RFC 3932 indicates, the RFC editor has already conducted a  
technical review of these documents, and they are not requesting  
further technical review.  The RFC editor is now asking the IESG to  
review the documents for conflicts with the IETF standards process or  
work being done in the IETF community.

Here is a description from RFC 3932 of a situation in which the IESG  
may claim that a document conflicts with ongoing work:

    Rejected Alternative Bypass: A WG is working on a solution to a
    problem, and a participant decides to ask for publication of a
    solution that the WG has rejected.  Publication of the document will
    give the publishing party an RFC number to refer to before the WG is
    finished.  It seems better to have the WG product published first,
    and have the non-adopted document published later, with a clear
    disclaimer note saying that "the IETF technology for this  
function is
    X".

As input to the IESG's decision, Dan has asked for the CAPWAP WG's  
opinion about whether these two drafts (draft-narasimhan-ietf- 
slapp-01.txt and draft-iino-capwap-wicop-02.txt) interfere with work  
being done in the CAPWAP WG.

So, what do you all think about this situation?  Would the  
publication of these documents as RFCs at this time conflict with the  
work of the CAPWAP WG, as described above?  Or should the IESG return  
a response that indicates that these documents are related to our  
work, but that they do not conflict with it?

Thanks,
Margaret