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

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 7 Feb 2007 08:32:38 -0800 (PST)

As a member of the eval team, I favor referencing RFC 4565 in CAPWAP RFCs. I believe that should be it. RFC 4565 clearly explains all four protocols (by the way there was one more, i.e. three documents that were not recommended not two) and makes recommendations on the way to go which is what is happening now.

For historical purposes, the expired drafts can always be found in the draft repositories.

Regards,

Behcet

----- Original Message ----
From: Margaret Wasserman <[email-masked]>
To: "Romascanu, Dan ((Dan))" <[email-masked]>
Cc: capwap <[email-masked]>
Sent: Tuesday, February 6, 2007 1:33:08 PM
Subject: Re: [Capwap] [Fwd: Informational RFC to be: draft-narasimhan-ietf-slapp-01.txt]

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

On Feb 6, 2007, at 1:56 PM, Romascanu, Dan ((Dan)) wrote:

> 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
>>
>>
>> On Feb 6, 2007, at 5:17 AM, Romascanu, Dan (Dan) wrote:
>>
>>>
>>>
>>> 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
>>

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

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

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 7 Feb 2007 10:31:50 -0800

I disagree. These are separate protocols and do not need to be
referenced.
 
I also agree that the RFC publication should be held back. There is a
large class of customers out there that do not understand the difference
between standards and informational RFCs. To them, an RFC is an RFC and
since it is published by IETF, it good enough for adoption. I believe
that the IETF would best serve the Internet Community by making sure
that the first RFC published by the WG is *the* standard.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Behcet Sarikaya [mailto:[email-masked]] 
	Sent: Wednesday, February 07, 2007 8:33 AM
	To: Margaret Wasserman; Romascanu, Dan ((Dan))
	Cc: capwap
	Subject: Re: [Capwap] [Fwd: Informational RFC to
be:draft-narasimhan-ietf-slapp-01.txt]

	As a member of the eval team, I favor referencing RFC 4565 in
CAPWAP RFCs. I believe that should be it. RFC 4565 clearly explains all
four protocols (by the way there was one more, i.e. three documents that
were not recommended not two) and makes recommendations on the way to go
which is what is happening now.
	 
	For historical purposes, the expired drafts can always be found
in the draft repositories.
	 
	Regards,
	 
	Behcet

	----- Original Message ----
	From: Margaret Wasserman <[email-masked]>
	To: "Romascanu, Dan ((Dan))" <[email-masked]>
	Cc: capwap <[email-masked]>
	Sent: Tuesday, February 6, 2007 1:33:08 PM
	Subject: Re: [Capwap] [Fwd: Informational RFC to be:

	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:

	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

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

---

From: Hong Cheng <[email-masked]>
Date: Fri, 09 Feb 2007 12:18:19 +0800

Hi Pat,

Your concern is not a valid reason for NOT publishing the draft. I think 
the proper way to go is placing a clear disclaimer in the informational 
RFC.

If people can adopt an informational RFC without really reading through 
it carefully, it cannot be helped. Even if we public those RFCs after 
the WG standard track RFC, they may take them as CAPWAP-v2 and use those 
instead of the WG *standard* RFC.

As your email pointed out, these informational RFCs are defining 
different protocols (with different names than the *standard* CAPWAP 
protocol), I don't think people would be confused.

cheers

Cheng

Pat Calhoun (pacalhou) wrote:
> I disagree. These are separate protocols and do not need to be referenced.
>  
> between standards and informational RFCs. To them, an RFC is an RFC 
> and since it is published by IETF, it good enough for adoption. I 
> believe that the IETF would best serve the Internet Community by making 
> sure that the first RFC published by the WG is *the* standard.
>  
> 
> Pat Calhoun
>     ------------------------------------------------------------------------
>     *From:* Behcet Sarikaya [mailto:[email-masked]]
>     *Sent:* Wednesday, February 07, 2007 8:33 AM
>     *To:* Margaret Wasserman; Romascanu, Dan ((Dan))
>     *Cc:* capwap
>     *Subject:* Re: [Capwap] [Fwd: Informational RFC to
>     As a member of the eval team, I favor referencing RFC 4565 in CAPWAP
>     RFCs. I believe that should be it. RFC 4565 clearly explains all
>     four protocols (by the way there was one more, i.e. three documents
>     that were not recommended not two) and makes recommendations on the
>     way to go which is what is happening now.
>      
> ------------------------------------------------------------------------
>