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

[David Kessens (david.kessens]

Puneet,

On Thu, Feb 01, 2007 at 07:47:31PM -0800, Puneet Agarwal wrote:
> 
> Are you speaking as chair or as a member? 

Please allow me to add something to this as one of the Area Directors:

We are very late in the process to make any kind of changes. 

I see the following milestones on the charter:

Feb 2007                First WGLC for CAPWAP Base Protocol
May 2007                Final WGLC for CAPWAP Base Protocol

While the working group has been doing quite well regarding meeting
it's milestones, it is clear from the above that we really have
entered the final phases. What this means is that this is not a good
time to introduce any changes beyond what is necessary to fix known
issues. Sure, we can always find ways to make the protocol work
better, or make it a tiny bit more efficient. However, the cost will
be that we won't be able to deliver the protocol in a timely manner as
we agreed on in the charter. To say it in a different way, the cost in
the marketplace for being late is lost credibility for CAPWAP ad the
IETF, and if we are very late, obsolescence.

As an Area Director, I very much appreciate that the wg chairs are
taking the milestones seriously and are working hard to deal with the
remaining issues to help to get the protocol out of the door. That
doesn't mean that everything is cast in stone, but we better have some
real good reasons for making any changes that are outside the scope of
minimal changes to address remaining problems since we will only be
able to reach the end of this process if we are willing to declare a
draft 'good enough' as opposed to trying to achieve perfection.

David Kessens
---

> 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
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap

David Kessens
---