Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of 146)

From: Margaret Wasserman <[email-masked]>
Date: Thu, 1 Feb 2007 09:26:32 -0500

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

---

From: "Sudhanshu" <[email-masked]>
Date: Thu, 1 Feb 2007 09:54:39 -0800

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:[email-masked]] 
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,

<chair hat=off>

</chair>

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 1 Feb 2007 13:08:37 -0500

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

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 1 Feb 2007 19:47:31 -0800

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:[email-masked]] 
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.

Margaret

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

> 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
>
>> 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.
>
> 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.
>
> can reach consensus on whether to adopt this proposal now or add it to

> the wish list.
>> 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 
>> 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>
>
> for purposes of expediency.  Some technical arguments have been raised

> both for and against, and our analysis should focus on those issues.
>
> changes or this proposal) in this version of CAPWAP, unless there is a

> significant benefit to justify those changes.  I don't personally 
> 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.
>

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 1 Feb 2007 19:58:30 -0800

Hi Abhijit,
 
"[Abhijit]  That is the goal of this mailing list - creating consensus.
All I am saying is that there are 

              bigger issues to be finalized before we start discussing
optimizations."

I agree with your statement for the control plane.  However the data
plane is all about optimizations. We should not be arbitrarily wasting
32 bits in a header for no reason.

Hence these optimizations are definitely worth it at this time as the
main impetus is the data plane.

Thanks.

-Puneet

________________________________

From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Monday, January 29, 2007 9:08 PM
To: Sudhanshu; [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Hi Sudhanshu,
Please see my responses in-line,.
 
Thanks,
Abhijit

----- Original Message ----
From: Sudhanshu <[email-masked]>
To: Abhijit Choudhury <[email-masked]>; [email-masked]
Sent: Monday, January 29, 2007 7:39:16 PM
Subject: RE: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Abhijit, 

Don't hang on to your calculation of 32 bit per packet in 1G pipe line.

*	CAPWAP is not designed only for the Greenfield deployments. And
there will be lots of a/b/g APs which will be supporting CAPWAP, if it
ever became a popular standard. 
*	There will be hardly any AP with real 1G throughput any time
soon. Most of them will be supporting max ~ 2xx mbps. And overhead has
to be calculated on 2xx Mbps. 

[Abhijit]  The 1G link I referred to was the link between the WTP and
AC.   The up-link of WTPs will be

              gradually changing over to 10/100/1000 MACs as Gig
interfaces on L2/L3 switches become 

              ubiquitous.   In that case, no matter what your WTP
throughput, the 

              CAPWAP encapsulated packet will be transmitted by the WTP
towards the AC at 1G rate.  The special

              packet format is reducing the header by 32 bits, which
means  32ns is being optimized away on this link.  

              You have to justify that that amount of time is worth
adding additional code in the data path.

*	Not every architecture/every system will support the pure pipe
line processing. And in that case, 4 byte DMA back-n-forth may be
unnecessary overhead on memory bandwidth and processing both in AP and
Switch 

[Abhijit]  Typically DMA is done on chunks of data.  Packet descriptors
are often allocated for 32, 64 or 128 bytes at a time.

             It is not clear that reducing your packet length by 4 bytes
will make much of a difference in storage or 

             DMA bandwidth.

*	CAPWAP is not designed for the LAN environment only. In that
case 1G bandwidth is a luxury, even in today's world.

[Abhijit]  Agreed. But you have to look at where the primary use of
CAPWAP is going to be.

If you to look back and review why after 3+ years, we still don't have a
standard, everybody may have their own opinion. But in the best interest
of moving forward, let's looks for the consensus.

[Abhijit]  That is the goal of this mailing list - creating consensus.
All I am saying is that there are 

              bigger issues to be finalized before we start discussing
optimizations.

_Suds

________________________________

From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Sunday, January 28, 2007 10:50 PM
To: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Folks,

I'm sure there are many more optimizations that can be

made in the spec. It's been close to three years since

this WG started, and we still don't have a spec out.

Meanwhile, the WLAN industry has been impatiently waiting

for this standard.  It can be argued that if this spec 

is not ratified soon it might lose its relevance. 

At this point in time, as a group, we need to 

focus on fixing items that need fixing because they 

are broken. We cannot afford to spend time

debating "nice-to-have"s and changing perfectly working

items in the spec because we want to make some minor

optimizations. 

If the packet format in the current spec is broken, we 

should surely fix it. If 32 bits on a 1Gig link 

is all that is being optimized by this new packet 

format and additional code in the data path, I'd argue 

that this is not what this WG should be spending its time on. 

There are a whole bunch of decisions that need to be made 

before this spec can be sent out for last call. We need to

focus on those items and get this spec out asap.

. 

Thanks,

Abhijit

-----Original Message-----
From: Jim Murphy [mailto:[email-masked]] 
Sent: Friday, January 26, 2007 11:57 PM
To: Bob O'Hara (boohara)
Cc: [email-masked]
Subject: Re: [Capwap] Proposed Resolution for Issue 224/89 (and part of
146)

Bob,

I see no reason why this optimization can not be used in the control
channel as well. If so, then the concerns about the data and control
channel having to be exactly the same are eliminated with the added
benefit of improved performance in each case.

That said, I think we could improve the format a bit based on feedback
from Sudhanshu and some new observations based on the idea of packet
header overlay.

The basic idea is that Version and Type fields are what is needed for
the "preamble" and exist for every type of packet. However, only
8 bits are required. We then define the DTLS shim and CAPWAP Header to
include the preamble. The resulting format is something like this:

CAPWAP Preamble
         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

    Version:  A 4 bit field which contains the version of CAPWAP used in
       this packet.  The value for this draft is zero (0).

    Payload Type:  A 4 bit field which specifies the payload type that
       follows the preamble header.  Unsupported values MUST be silently
       dropped. The following values are supported:

       0 -  Clear text.  If the packet is received on the data UDP port,
          the CAPWAP stack MUST treat this as a clear text CAPWAP data
          packet.  If received on the control UDP port, the CAPWAP stack
          MUST treat this as a clear text CAPWAP control packet.  If the
          control packet is not a Discovery Request or Response packet,
          it is illegal and MUST be dropped.

       1 -  DTLS Payload.  The packet is either a DTLS packet and MAY be
          a data or control packet, based on the UDP port it was
received
          on (see section Section 3.1).

CAPWAP DTLS shim:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version| Type  |                    Reserved
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or, said slightly differently:

CAPWAP DTLS shim:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Preamble      |                    Reserved
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For the header we then have the following:

CAPWAP Header:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version| Type  |  HLEN   |  RID    |  WBID
|T|F|L|W|M|K|Flags|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Fragment ID          |     Frag Offset         |Rsvd
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note, Version/Type are the CAPWAP preamble.

Essentially, what we have created a de-multiplexing scheme that has the
following properties:

  - Its performance characteristics are no worse than those of the -04
    preamble. In fact, demuxing directly off the preamble type is
    very attractive from a performance perspective.
  - It does not waste 32 bits in the clear path case.
  - It works equally well for the data path and the control path so
    it is a universal solution.
  - It provides for a powerful extensibility feature that will enhance
    the longevity of the protocol.

Other notes:

  - I have transposed RID and HLEN to give the hint of a TLV structure.
    I think this is a useful concept that we should support in the
    protocol.

  - I belive the F and L flags could be moved to the Rsvd area of the
    fragmentation super frame as suggested by David Perkins. This opens
    up some more flag space in the first super frame.

Thanks,

Jim

Bob O'Hara (boohara) wrote:
>  
> It's always fun to be part of an exercise to optimize something until 
> it can't be optimized any further, and let's be clear about it.  That 
> is what we are doing here.  The current preamble, common to both 
> control and data packets, works.  What is being proposed is to make 
> the data packet preamble as short as possible, by reducing its size by
32 bits.
> This comes at the cost of having the control and data packet formats 
> diverge.
> 
> Let me propose some reasons for keeping the preamble of the control 
> and data packets the same as they were.
> 
> 1. A DTLS-protected packet, either control or data, is handled exactly

> the same way to produce the decrypted CAPWAP payload.  This decrypted 
> payload can then be passed to software for processing (either control 
> or
> data) or can be passed to fast path hardware for data path processing.
> 
> 2. 32 bits take exactly 32ns to transmit at a gigabit per second, 
> which is likely to be the predominant connection for both WTPs and
ACs.
> Optimizing the protocol to save these 32ns is a foolish economy.  Is 
> there a dire cost that we encounter, in order to send these bits?
> 
> 3. Having two different CAPWAP preambles doubles the cost of 
> development of this portion of the protocol (particularly if the 
> CAPWAP header cracking is done in hardware), doubles the hardware 
> necessary to process this portion of the packet (perhaps even that 
> necessary to process the entire packet), and doubles the number of
bugs to discover and fix.
> 
> I believe these practical reasons outweigh the reasons presented for 
> making the change to the header.
> 
>  -Bob
>  
> From: Jim Murphy [mailto:[email-masked]]
> Sent: Thursday, January 25, 2007 12:19 AM
> To: [email-masked]
> Please consider the following alternative proposal to optimize the 
> data channel when no DTLS encryption is present. With this proposal, 
> CAPWAP data channels running in the clear will not require the CAPWAP 
> preamble. However, CAPWAP data channels running DTLS must have the 
> CAPWAP preamble.
> 
> The CAPWAP preamble is modified as follows:
> 
> [...]
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

> 1
>  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |Version| Type  |                    Reserved
> |P|
>  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [...]
>      P: Must be 1. Indicates that this is a CAPWAP preamble.
> [...]
> 
> The CAPWAP Header is modified as follows:
> 
> [...]
>          0                   1                   2                   3
>          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0

> 1
>  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|K|    Flags
> |P|
>  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [...]
>      P: Must be 0. Indicates that this is a CAPWAP preamble.
> [...]
> 
> The basic idea is to overlay the CAPWAP preamble and the first
> 32 bits of the CAPWAP Header. Note the intentional overlap of the 
> Version field and the P bit. Essentially the P bit is a type indicator

> that indicates the type of super field present. A 1 indicates a CAPWAP

> preamble, a 0 indicates the first 32 bits of the CAPWAP Header.
> 
> Any data packet on a clear (unencrypted) data channel looks as follows

> (to illustrate the use of the P bit):
> 
>         CAPWAP Plain Text Data Packet:
>         +--------------------------------+
>         | IP  | UDP | CAPWAP | Wireless  |
>         | Hdr | Hdr | Header | Payload   |
>         |     |     | P=0    |           |
>         +--------------------------------+
> 
> Any data packet on an encrypted data channel or a DTLS session 
> establishment packet looks as follows:
> 
>          DTLS Secured CAPWAP Data Packet:
>         +------------------------------------------------------+
>         | IP  | UDP | CAPWAP | DTLS | CAPWAP | Wireless | DTLS |
>         | Hdr | Hdr | p-amble| Hdr  |  Hdr   | Payload  | Trlr |
>         |     |     | P=1    |      |        |          |      |
>         +------------------------------------------------------+
>                               \----- authenticated -----/
>                                     \------- encrypted --------/
> 
> A switching entity need only check the CAPWAP Version and then the P 
> bit to determine if the CAPWAP packet needs DTLS processing.
> If the P but is not set, the switching entity may immediately assume 
> only a CAPWAP header and commences de-encapsulation and possible 
> reassembly processing.
> 
> This proposal serves the following purposes:
> 
>   - The CAPWAP preamble is present only when really needed.
Specifically
>     to identify CAPWAP packet attributes outside of the DTLS
encrypted/
>     authenticated area when DTLS is used.
> 
>   - Eliminates the waste of 32 bits of header information to convey a
>     single bit of information when in the clear.
> 
>   - Allows for the continued use of the CAPWAP preamble for other
>     purposes, such as DTLS session de-multiplexing to deal with the
>     issue of QoS reordering. (see earlier email from Mani - The QoS
DTLS
>     factor)
> 
> Please let me know if you have any questions.
> 
> Thanks,
> 
> Jim
> 

 

________________________________

Never Miss an Email
Stay connected with Yahoo! Mail on your mobile. Get started!
<http://us.rd.yahoo.com/evt=43909/*http:/mobile.yahoo.com/services?promo
te=mail> 

________________________________

Access over 1 million songs - Yahoo! Music Unlimited.
<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=36035/*http://music.yah
oo.com/unlimited/> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: "Partha Narasimhan" <[email-masked]>
Date: Thu, 1 Feb 2007 20:03:41 -0800

While I am not speaking one way or another on this particular issue
given I haven't paid enough attention to it yet, I would definitely not
agree with closing any issues or prematurely ending any discussion on
them purely on the basis that it would break existing implementations.
This is a dangerous trend because it creates an environment where the
first implementation of an early draft could force the entire group to
comply with the decisions taken in that implementation on incomplete or
open issues. Anyone that goes ahead with an implementation of an early
draft (potentially sprinkled with open issues and incomplete
definitions) should understand the risks involved in doing that.

Thanks
partha

> From: Puneet Agarwal [mailto:[email-masked]]
> Sent: Thursday, February 01, 2007 7:48 PM
> To: Margaret Wasserman; Sudhanshu
> Cc: capwap
optimizations,
> that there may be substantial changes to the protocol, and I don't
think
> >> The rejection of this proposal for reasons of expediency makes
little
> > did not want the attendees of the interim meeting to come to
consensus
> > can reach consensus on whether to adopt this proposal now or add it
to
> >> productive dialog on this email list. As a result of this dialog,
the
> > for purposes of expediency.  Some technical arguments have been
raised
> > changes or this proposal) in this version of CAPWAP, unless there is
a
> > is a large enough benefit to warrant a non-backwards compatible
change

---

From: David Kessens <[email-masked]>
Date: Thu, 1 Feb 2007 23:03:57 -0800

Puneet,

> 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
---

> > and if we do decide to adopt it that will make it very quick and easy 

David Kessens
---

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 5 Feb 2007 09:16:41 -0500

Hi Puneet,

I was expressing my opinion as an individual.

Margaret