Capwap Mailing List: Re: Proposed Resolution for Issue 224/89 (and part of 146)

[Margaret Wasserman (margaret]

There are at least a couple of existing implementations of the base  
CAPWAP spec that implement the current CAPWAP headers, messages and  
architecture.  If we adopt either of the proposed header  
optimizations, those implementations would have to change because  
current versions of those implementations would no longer be  
compatible with the CAPWAP specification.

Now, I know that anyone who implements an Internet-Draft understands  
that there may be substantial changes to the protocol, and I don't  
think that this consideration should stop us from making changes that  
add important functionality or significant benefits to the protocol.   
I just don't think it is worth invalidating the header processing  
code in existing implementations to further optimize the headers at  
this point.

This is a trade-off, and I realize that other people might feel  
differently.

Margaret

On Feb 1, 2007, at 12:54 PM, Sudhanshu wrote:

> Margaret <chair hat=off>,
>
> Just for the benefit of wider audience, can you be little more  
> specific on
> phrases used like "impact existing implementations" and "enough  
> benefit to
> warrant a non-backwards compatible" in your response?
>
> Thanks,
> -Suds
>
> -----Original Message-----
> From: Margaret Wasserman [mailto:margaret [at] thingmagic.com]
> Sent: Thursday, February 01, 2007 6:27 AM
> To: Jim Murphy
> Cc: capwap
> Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and  
> part of 146)
>
>
> Hi Jim,
>
> On Jan 31, 2007, at 5:45 PM, Jim Murphy wrote:
> > The rejection of this proposal for reasons of expediency makes
> > little sense in light of recent history for the following reasons:
> >
> > Firstly, I was asked by the working group chair to bring this  
> > proposal
> > to this list at last week's interim meeting. The implication of the
> > request was that indeed the proposal has merit and is worth the  
> > groups
> > time to consider it.
>
> Just to clarify...  I was the WG chair who asked you to bring this
> proposal to the list.  I did that for two reasons:
>
> (1) We had agreed not to consider new problems or proposals at the
> interim meeting that hadn't been discussed on the mailing list.  Only
> a small part of the WG was able to attend the interim meeting, and we
> did not want the attendees of the interim meeting to come to
> consensus on changes that would come as a complete surprise to the
> rest of the WG.
>
> (2) There seemed to be some support for the proposal in the interim
> meeting, so it seemed likely that there would be some support for it
> on the list.
>
> So far, I don't think that we have clear consensus for or against
> adopting this proposal, so we should keep discussing it to see if we
> can reach consensus on whether to adopt this proposal now or add it
> to the wish list.
>
> > Secondly, the expediency argument is a false economy.
> > The working group members, both the supporters and the detractors  
> > have
> > already invested their time considering the proposal through a
> > productive dialog on this email list. As a result of this dialog,
> > the proposal has been enhanced to address all the technical  
> > objections
> > and a technically superior specification is now at hand. It seems
> > shameful that after all technical issues have been addressed we now
> > want
> > to waste those efforts for the sake of expediency when in fact the
> > work to include the proposal is comparatively small.
>
> <chair hat=off>
>
> I (personally) agree with you that we should not reject this proposal
> for purposes of expediency.  Some technical arguments have been
> raised both for and against, and our analysis should focus on those
> issues.
>
> I am also personally concerned about making changes that will impact
> existing implementations (such as Dave Perkin's proposed header
> changes or this proposal) in this version of CAPWAP, unless there is
> a significant benefit to justify those changes.  I don't personally
> think, in either case, that eliminating up to 4 bytes in some packets
> is a large enough benefit to warrant a non-backwards compatible
> change to the CAPWAP header at this point.  Although, if we do decide
> to make one of these changes, I think we should strongly consider
> making the other change at the same time.
>
> Others may think differently, of course.
>
> </chair>
>
> > Finally, the expediency argument is further weekend by the fact that
> > the proposed text is included in this email. I've included it as both
> > clear text and a context diff.
>
> You have done an excellent job of stating this proposal very clearly,
> and if we do decide to adopt it that will make it very quick and easy
> to do so.  Thank you.
>
> Margaret
>
> _________________________________________________________________
> 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