Subject: Re: [Capwap] Is the process working?

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 23 Aug 2006 12:44:41 -0700

> On the "conspiracy theory", said nothing about that.
> I only said that there is no WG visibility into what is going 
> on with the editors.
To repeat, the editors were on the road and on vacation.

> Also, don't see a process in place other 
> than use the issue tracker, which seems not to be working.  
> Also see you dismissing issues that you don't understand or 
> are difficult instead of addressing. On the other hand, I do 
> see you trying to move forward, where it seems like the rest 
> of the WG has abandoned the effort.

The protocol is not done until we are done with all of the issues
we need to resolve. I understand the desire to prioritize, and the
editor's plans is to have text for the MUX/Port issue in -03. However, 
I've sent at least a dozen, if not more, new e-mails to the
list, most of them trying to address issues you have raised. while
we are working out the details of other changes, could you perhaps
spend time on those? 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, August 23, 2006 9:55 AM
> To: Pat Calhoun (pacalhou)
> Cc: Nelson, David; [email-masked]
> Subject: RE: [Capwap] Is the process working?
> 
> HI,
> 
> Yes, there are many "silly" things in the CAPWAP spec.
> Getting them out is a good thing. 
> 
> 
> I propose that we put aside the "polishing" and work over the 
> WG mailing list on resolving the packet formats. I've done a 
> proposal. I don't believe I've seen much feedback. Why not 
> just use my last proposal? I'd like to ask the WG co-charis 
> to call for WG consenses on that proposal contained in a 
> message sent on July 24. It resolves the MUX-FLUX and several 
> other problems.
> 
> Regards,
> /david t. perkins
> 
> On Wed, 23 Aug 2006, Pat Calhoun (pacalhou) wrote:
> > Folks,
> > 
> > The editors are working this issue. We will post text, and 
> the WG will 
> > have a chance to review and comment. No need to assume conspiracy 
> > theories, or broken process - we're simply a tad behind due 
> to travel 
> > and summer holidays.
> > 
> > > The issue is that fundamentals have not yet been defined in 
> > > technically sound and complete descriptions. Some believe 
> that the 
> > > LWAPP document and the CAPWAP docs have met this test 
> because there 
> > > is "working product". That has been the ultimate answer 
> to all hard 
> > > questions. However, there are two holes with this logic. 
> The first 
> > > is that it has not been demonstrated that anyone has 
> taken the LWAPP 
> > > documentation and write code that interoperates with the 
> airespace 
> > > products (showing that the code and documents match, and 
> the LWAPP 
> > > docs are sufficient to do an implementation).
> > 
> > I think we went through this before Dave, but we can have this 
> > pointless discussion in public if you insist. When Airespace was 
> > acquired, a group of independent engineers implemented the spec. 
> > Granted, they had access to some of the original engineers, 
> so it is 
> > likely that some questions were answered outside the specification. 
> > However, the document, as described, was implemented by a separate 
> > engineering team.
> > 
> > I don't think anyone, or certainly not me, stated that the document 
> > was ready for publication as-is, but it has been implemented by two 
> > teams.
> > 
> > > Secondly, that the same assumptions from LWAPP transfer 
> to CAPWAP. 
> > > An example of this is that using DTLS (which encapsulates (and 
> > > encrypts) the complete payload) causes problems not found 
> in LWAPP 
> > > (which encrypts only a portion of the message.
> > 
> > Yes, this is true. Any changes made to the original specification 
> > introduces risk in a protocol - regardless of the WG. This is a big 
> > concern of mine, and is one reason why I prefer 
> minimalistic changes, 
> > where possible. However, in the end the interop process will help 
> > point out problematic areas.
> > 
> > Perhaps we can once more put this discussion to bed. It 
> really doesn't 
> > help the WG make progress in achieving our milestones. Decisions in 
> > the past have been made, and we need to be marching forward.
> > 
> > Now back to your comment on process. The editors, and WG, need 
> > everyone's help in resolving comments. There are many open threads 
> > that I need the list to respond to, as comments that created the 
> > issues were overly vague (e.g., "something or other is silly and 
> > broken").
> > 
> > Thanks,
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:[email-masked]]
> > > Sent: Tuesday, August 22, 2006 4:01 PM
> > > To: Nelson, David
> > > Cc: [email-masked]
> > > Subject: Re: [Capwap] Is the process working?
> > > 
> > > HI,
> > > 
> > > See inline below...
> > > 
> > > On Tue, 22 Aug 2006, Nelson, David wrote:
> > > > David T. Perkins writes...
> > > > 
> > > > > I'm surprise and distrubed to say the least about the
> > > statement "We
> > > > > are working out the details..."!
> > > > > 
> > > > > Why? Because such work is being done without WG visibility.
> > > > > 
> > > > > It would be proper, and I believe would result in a 
> much better 
> > > > > outcome if this was done via an open interim meeting.
> > > > 
> > > > The appropriate way to make such decisions in the IETF is
> > > for someone
> > > > to propose a resolution to each issue (from the tracker
> > > tool) to the
> > > > WG mailing list and call for consensus.
> > > This is only appropriate at specific places in a document life 
> > > cycle. I don't believe the CAPWAP document is there yet.
> > > 
> > > > I've seen a series of such
> > > > messages from the document editors in the last week or so.  
> > > It looks
> > > > as if the process is working.
> > > Yes, the process is working, but the results are useless in many 
> > > cases!
> > > Having process that works can get in the way of any real forward 
> > > progress. That is what I believe is happening here.
> > > We need to throw out the bug tracker.
> > >  
> > > > Interim meetings are great for high-bandwidth, low-latency 
> > > > communication.  However, in the final analysis, the I-D
> > > Editor(s) MUST
> > > > post the proposed changes to WG work items to the list and
> > > the chairs
> > > > declare that consensus is achieved before the changes are
> > > incorporated
> > > > into a revised draft.
> > > I believe there is a lot of "talking past each other". Email has 
> > > made this much worse.
> > > 
> > > > If your complaint is that you expect to first see the
> > > resolutions in
> > > > the text of a revised I-D, before those changes have been
> > > proposed and
> > > > discussed on the WG mailing list, you have a valid 
> process issue.
> > > > Is that your concern?  If not, I think your concerns 
> are premature.
> > > The above seemed stated backwards. Is this what you meant?
> > > 
> > > 
> > > Regards,
> > > /david t. perkins
> > > 
> > > _________________________________________________________________
> > > 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