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

[Puneet Agarwal (pagarwal]

Hi Margaret,

Are you speaking as chair or as a member? 

Any change will require changes to the way existing implementations are
done. Rejecting Jim's proposal for "existing" implementations is
completely arbitrary as by definition this draft is a work in progress.
The first time the CAPWAP preamble was even proposed was at the last
IETF  and we never even had a serious debate on how the whole thing
worked (I had raised the same issue at the CAPWAP interim too). To say
that something first proposed at the last IETF is somehow cast in stone
is really stretching your argument about existing implementations. Hence
the existing code argument does not hold.

There are sound technical merits in Jim's proposal and should be
seriously considered. I do not see any technical arguments against it. I
fully support Jim's proposal and propose that it should be adopted in
the next rev (-05) of the draft.

Thanks.

-Puneet

-----Original Message-----
From: Margaret Wasserman [mailto:margaret [at] thingmagic.com] 
Sent: Thursday, February 01, 2007 10:09 AM
To: Sudhanshu
Cc: 'capwap'
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)


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

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

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