I think there is some confusion here. Adding the MUX header
(preamble)
to the CAPWAP header was not proposed until Nov. 22. This is
independent
of the port issue.
Thanks,
Jim
Dorothy.Gellert nokia.com wrote:
> Hi Jim-
>
> The call for consensus on the port issues was made on
the list by the
> chairs in late Sept, (Sept 19th) and the final
resolution deterimined on
> the list on Oct 10th. I've included the final WG
decision as there was
> so much discussion on this topic over the last year.
>
> Best Regards,
> DorothyG
>
>
>
>
>
>
> -----Original Message-----
> From: ext Jim Murphy [mailto:jmurphytrapezenetworks.com]
> Sent: Friday, January 19, 2007 12:52 AM
> To: Pat Calhoun (pacalhou)
> Cc: capwapfrascone.com
> Subject: Re: [Capwap] Proposed Resolution for Issue
224/89 (and part of
> 146)
>
>
>
> Pat Calhoun (pacalhou) wrote:
>> Puneet,
>>
>> Addressing your specific list of options:
>> 1) Continuing to bring up the removal of the MUX is
simply a waste of
>> time. The WG has decided, so let's move on please.
>
> When was this WG decision made? Your original proposal
(this thread) was
> made on Nov. 22, 2006 (after the IETF meeting) and we
are merely
> discussing the merits of the proposal on the mailing
list, as we should.
>
> Thanks,
>
> Jim
>
>
____________________________________________________________
_____
> To unsubscribe or modify your subscription options,
please visit:
> htt
p://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lis
ts.frascone.com/pipermail/capwap
>
>
>
------------------------------------------------------------
------------
>
> Subject:
> LACK OF CONSENSUS: 2-port/mux issue
> From:
> <margaretthingmagic.com>
> Date:
> Tue, 10 Oct 2006 08:53:41 -0600
> To:
> <capwapfrascone.com>
>
> To:
> <capwapfrascone.com>
> CC:
> <Dorothy.Gellertnokia.com>,
<mmaniavaya.com>
>
>
> Hi All,
>
> Over the past few months, we have had an open issue in
the CAPWAP WG
> that we refer to as the "2-port/mux issue".
The current CAPWAP
> protocol specification indicates that the CAPWAP
protocol will run
> over two UDP ports, one for control traffic and one for
data
> traffic. Proposals have been made to move to a
single-port approach
> or to allow for a single-port option.
>
> There has been much discussion of this issue, including
e-mail
> discussion and presentations at WG meetings. We have
consulted with
> the IESG, and the outcome of those discussions has been
sent to the
> group. At this point, we believe that every interested
party has had
> an opportunity to present technical facts in support of
his/her
> position, and we believe that the WG is aware of the
technical
> differences between the two approaches. So, it is time
to determine
> the resolution of this issue.
>
> The WG chairs have reviewed the status of this issue,
and we have
> found that the WG does not have consensus to modify the
> demultiplexing mechanism described in the current
CAPWAP
> specification, either to move to a single-port approach
or to add a
> single-port option. Therefore, in the absence of any
new technical
> information, we are closing this discussion. Editors,
please close
> this issue in the issue tracker with a resolution
indicating that
> there is no WG consensus to make this change.
>
> We realize that this has been a contentious issue for
the WG, and
> that some people may be dissatisfied with this
resolution. We all
> would have preferred our technical discussions to
converge on a
> single correct choice, but that hasn't happened. In
this case, it is
> possible to build a viable CAPWAP protocol using either
approach, and
> both approaches have advantages and disadvantages that
are weighed
> differently by different parties. Unless new technical
information
> comes to light, we do not believe that continued
discussion of this
> issue will lead to consensus on the technical
superiority of either
> approach.
>
> The WG chairs have reviewed the history of this issue
to determine
> how to move forward, given that our technical
discussions have not
> converged. The two-port approach was part of the
original LWAPP
> specification, and It was also included in the -00
version of the
> CAPWAP specification that was accepted as a WG work
item in early
> 2006. There was WG consensus to accept LWAPP as the
basis of the
> CAPWAP specification, therefore the WG chairs believe
that WG
> consensus would be required to change the
demultiplexing mechanism.
> Despite lengthy discussion, the WG has not reached
consensus to do that.
>
> We would like to thank everyone who has participated in
this
> discussion. We hope that we will be able to put this
issue behind us
> and continue to work together towards a well-defined
and widely-
> deployed CAPWAP specification.
>
> Best Regards,
>
> Dorothy Gellert, Mahalingam Mani & Margaret
Wasserman
> The CAPWAP WG Co-Chairs
>
>
>
>
>
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
htt
p://lists.frascone.com/mailman/listinfo/capwap
Archives: http://lis
ts.frascone.com/pipermail/capwap
|