Subject: [Capwap] AD review ofdraft-ietf-capwap-protocol-binding-ieee80211-06 T9

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 29 Jun 2008 08:49:56 -0700

The AD Review Comment is:

   T9. Section 6.16 - for all statistics counters in this message -
explain 1. do 
   they start counting from 0 at initialization? What is the behavior
when the 
   device loses power? What is the behavior when they reach maximal
value? 
   Minimal interval between two rollover events

I'm not sure that I'm addressing your last point, especially since it is
rather difficult to gauge the interval, because while a couple of fields
representing received/transmitted packets, others represent events that
will occur vary infrequently. So I am proposing the following, but if
this is not sufficient, let me know what you would like me to provide. I
can do quick math for the tx/rx fields, assuming full throttle, but
others would be nothing more than a "wild guess".

<text>
6.16.  IEEE 802.11 Statistics

   The IEEE 802.11 Statistics message element is sent by the WTP to
   transmit its current statistics, and contains the following fields.
   All of the fields in this message element are set to zero upon WTP
   initialization.  The fields will roll over when they reach their
   maximum value of 65535.  Due to the nature of each counter
   representing different data points, the roll over event will vary
   greatly across each field.
</text>

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jun 2008 18:21:18 +0200

All this is good. About the rollover time, the reason it is desirable to
be included in specifications is for the receiving application, firmware
or human to know what is the largest interval they need to look into the
value of the object in order to make sure that no two rollover events
are being missed. Can we add something like 'Applications or human
operators using these counters need to be aware about the minimal
possible times between rollover events in order to make sure that no
consecutive rollover events are missed.'? 

Dan

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Sunday, June 29, 2008 6:50 PM
> To: [email-masked]
> Subject: [Capwap] AD 
> reviewofdraft-ietf-capwap-protocol-binding-ieee80211-06 T9
> 
>    T9. Section 6.16 - for all statistics counters in this 
> message - explain 1. do 
>    they start counting from 0 at initialization? What is the 
> behavior when the 
>    device loses power? What is the behavior when they reach 
> maximal value? 
> I'm not sure that I'm addressing your last point, especially 
> since it is rather difficult to gauge the interval, because 
> while a couple of fields representing received/transmitted 
> packets, others represent events that will occur vary 
> infrequently. So I am proposing the following, but if this is 
> not sufficient, let me know what you would like me to 
> provide. I can do quick math for the tx/rx fields, assuming 
> full throttle, but others would be nothing more than a "wild guess".
> 
> <text>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 29 Jun 2008 21:49:15 -0700

I'm ok including this text, but I'm not sure that everyone will
understand its intended meaning. What about "AC implementations should
provide some notification, using whatever means are available (e.g.,
syslog, CLI notification), when a counter has rolled over."?

PatC 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Sunday, June 29, 2008 9:21 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: [Capwap] AD

Dan

> I'm not sure that I'm addressing your last point, especially since it 
> is rather difficult to gauge the interval, because while a couple of 
> fields representing received/transmitted packets, others represent 
> events that will occur vary infrequently. So I am proposing the 
> following, but if this is not sufficient, let me know what you would 
> like me to provide. I can do quick math for the tx/rx fields, assuming

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 30 Jun 2008 13:29:40 +0200

You are actually going one step further and beyond what I intended, by
placing a new requirement on the AC. What I had in mind is documenting
in the specification the need for application awareness about rollovers
in the ACs, but not the automation of the process by using
notifications. 

Dan

> Sent: Monday, June 30, 2008 7:49 AM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: [Capwap] AD 
> I'm ok including this text, but I'm not sure that everyone 
> will understand its intended meaning. What about "AC 
> implementations should provide some notification, using 
> whatever means are available (e.g., syslog, CLI 
> notification), when a counter has rolled over."?
> 
> PatC 
> 
> All this is good. About the rollover time, the reason it is 
> desirable to be included in specifications is for the 
> receiving application, firmware or human to know what is the 
> largest interval they need to look into the value of the 
> object in order to make sure that no two rollover events are 
> being missed. Can we add something like 'Applications or 
> human operators using these counters need to be aware about 
> the minimal possible times between rollover events in order 
> to make sure that no consecutive rollover events are missed.'? 
> 
> Dan
>  
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 30 Jun 2008 10:16:33 -0700

Ok, then if you believe your original sentence addresses your comment,
I'll go with it and consider this issue closed.

PatC 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, June 30, 2008 4:30 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: Re: [Capwap]
ADreviewofdraft-ietf-capwap-protocol-binding-ieee80211-06 T9

Dan

> All this is good. About the rollover time, the reason it is desirable 
> to be included in specifications is for the receiving application, 
> firmware or human to know what is the largest interval they need to 
> look into the value of the object in order to make sure that no two 
> rollover events are being missed. Can we add something like 
> 'Applications or human operators using these counters need to be aware

> about the minimal possible times between rollover events in order to 
> make sure that no consecutive rollover events are missed.'?
> 
> Dan
>  
>