Subject: [Capwap] Latest Status of CAPWAP Open Issues

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 19 Jun 2008 09:49:58 -0700

All,

Given the numerous messages dealing with all of issues raised by the
IESG, and the few additional ones discovered while fixing them, here is
an update on all of the issues, and what I'm waiting for in order to
move forward.

Issue 61: T20. The original request to change the enum lists to start at
zero was not acceptable to some due to the fact that it would be
incompatible with version -10 of the draft. Based on an agreement with
Dan, I have simply marked zero (0) as reserved. I am waiting for
confirmation that this is acceptable

Issue 103: Invalid Length Information Message Element. This was raised
on the list, and pointed out a valid issue that the length field for
this message element was incorrect. It needed to be 20, not 18. I am
waiting for confirmation that this is acceptable (although I can't see
why anyone would argue against it).

Issue 102: Join to Image Data state transition issue on the AC. This is
another issue raised on the list, and required that some new text be
added to this state transition description on the AC. While there are a
number of possible ways to fix this issue, I took the simplest and more
direct route to minimize the amount of text. I believe that anyone
implementing -10 would have assumed the change I made.

Issue Issue 53: T12. Dan raised an issue that he finds the way the
message element diagram was constructed was confusing. I have proposed
new text, and am waiting for confirmation that he is comfortable with
this change. If we opt to go down this route, I would also need to
change the WTP Board Data and WTP Descriptor message elements. This does
not introduce an compatibility issue with -10, it is simply an editorial
change that helps make the text clearer.

Issue 65: T24. The IESG raised an issue that they believed that the
Image Data and Image Identifier message elements should have a length
field. I made this change, but Margaret does not believe this change is
really necessary, and since it introduces an incompatibility issue with
-10, she would prefer that I back the change out. I am waiting for other
folks to provide their opinions. I agree the length is not necessary.

Issue 42: T1. This issue stated that any variable length field, or
length field, must have a stated maximum value. Many instances of this
was addressed via other technical comments from the IESG, but I went
through the draft and found a few more, which I combined into this
issue. I am waiting for the OK to close this issue.

Issue 99: CAPWAP Timers not referencing timers properly. This is a minor
change, but while fixing another issue, I found that the CAPWAP timers
message element was not referring to the timers in section 4.7. This fix
simply added the references.

Issue 73: T32. The IESG questioned whether the number of bits in a field
of the WTP Operational Statistics is sufficient. Reading the message
element, I couldn't really understand what this was trying to do, so I
asked the LWAPP developers, and this was an idea that never turned into
anything, and do not have any recommendations on how to make the
language clearer. Since I have no idea what someone would use this for,
I cannot really fix this message element - and would propose deleting
it. I am ok leaving it in, but I'd like to see the text cleaned up, and
would ask that whomever wants me to leave it in, provide text.

Issue 74: T33. This one was a question on whether the
statistics/counters in both the WTP Radio Statistics and the WTP Reboot
Statistics were intended to wrap around or reset. I modified the text to
state it is the former. I am waiting for confirmation that this change
is ok.

Issue 63: T22. The IESG asked why the length field was set to a specific
value. There was obviously some confusion about what information was
included, and I have provided a response on what this meant. I am
waiting to hear from Dan on how to proceed. I do not believe a fix is
required.

Issue 41: CAPWAP DTLS Timer Clarification. This is a small change that
provides some clarification on the use of timers. This does not
introduce an incompatibility issue with -10, as I suspect most people
ended up figuring out (the hard way) that the timers should have behaved
based on my change.

Issue 101: Error in message element figure in 4.6.32. This is a small
editorial change to a broken message element diagram. No incompatibility
with -10.

Issue 100: Editorial issue in 4.6.15. This is a small editorial change
to add a separator between an enumerated value and its description. No
technical change.

Issue 89: E8. I have rejected this issue since the creator of the
comment had simply not understood that the use of alpha/numeral/special
symbols was only for the AC, not the WTP. I am waiting for Dan's OK.

Issue 82: E1. I have changed the text to address the editorial issue
raised, and am waiting for Dan's OK.

Issue 86: E5. I have changed the text to address the editorial issue
raised, and am waiting for Dan's OK.

Issue 85: E4. I have changed the text to address the editorial issue
raised, and am waiting for Dan's OK.

Issue 97: E16. The IESG pointed out that some timers in section 4.7 were
not really timers, and needed to move to another place in the spec. Only
one of the sections they pointed to needed to move, and I have. I have
rejected the rest of the request. I am waiting for Dan's OK.

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: Thu, 19 Jun 2008 19:12:42 +0200

See in-line. 

BTW, in all this dialog you need to replace 'the IESG'  by 'the AD'
(me). This was not yet the IESG review but the AD review. Only after the
document passes IETF LC it lands on the table of the IESG. 

Dan

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Thursday, June 19, 2008 7:50 PM
> To: [email-masked]
> Subject: [Capwap] Latest Status of CAPWAP Open Issues
> 
> All,
> 
> Given the numerous messages dealing with all of issues raised 
> by the IESG, and the few additional ones discovered while 
> fixing them, here is an update on all of the issues, and what 
> I'm waiting for in order to move forward.
> 
> Issue 61: T20. The original request to change the enum lists 
> to start at zero was not acceptable to some due to the fact 
> that it would be incompatible with version -10 of the draft. 
> Based on an agreement with Dan, I have simply marked zero (0) 
> as reserved. I am waiting for confirmation that this is acceptable

OK with me. 

> 
> Issue 103: Invalid Length Information Message Element. This 
> was raised on the list, and pointed out a valid issue that 
> the length field for this message element was incorrect. It 
> needed to be 20, not 18. I am waiting for confirmation that 
> this is acceptable (although I can't see why anyone would 
> argue against it).

Not raised by me. Ok with whatever consensus the WG reaches. 

> 
> Issue 102: Join to Image Data state transition issue on the 
> AC. This is another issue raised on the list, and required 
> that some new text be added to this state transition 
> description on the AC. While there are a number of possible 
> ways to fix this issue, I took the simplest and more direct 
> route to minimize the amount of text. I believe that anyone 

Not raised by me. Ok with whatever consensus the WG reaches. 

> 
> Issue Issue 53: T12. Dan raised an issue that he finds the 
> way the message element diagram was constructed was 
> confusing. I have proposed new text, and am waiting for 
> confirmation that he is comfortable with this change. If we 
> opt to go down this route, I would also need to change the 
> WTP Board Data and WTP Descriptor message elements. This does 
> not introduce an compatibility issue with -10, it is simply 
> an editorial change that helps make the text clearer.

OK with me. 

> 
> Issue 65: T24. The IESG raised an issue that they believed 
> that the Image Data and Image Identifier message elements 
> should have a length field. I made this change, but Margaret 
> does not believe this change is really necessary, and since 
> it introduces an incompatibility issue with -10, she would 
> prefer that I back the change out. I am waiting for other 

If the WG reaches the consensus that length is not needed I will buy it.
I would however suggest to put some text on the lines of what Margaret
was explaining in her message. 
 
> 
> Issue 42: T1. This issue stated that any variable length 
> field, or length field, must have a stated maximum value. 
> Many instances of this was addressed via other technical 
> comments from the IESG, but I went through the draft and 
> found a few more, which I combined into this issue. I am 
> waiting for the OK to close this issue.

Ok with me. 

> 
> Issue 99: CAPWAP Timers not referencing timers properly. This 
> is a minor change, but while fixing another issue, I found 
> that the CAPWAP timers message element was not referring to 
> the timers in section 4.7. This fix simply added the references.

OK with me.

> 
> Issue 73: T32. The IESG questioned whether the number of bits 
> in a field of the WTP Operational Statistics is sufficient. 
> Reading the message element, I couldn't really understand 
> what this was trying to do, so I asked the LWAPP developers, 
> and this was an idea that never turned into anything, and do 
> not have any recommendations on how to make the language 
> clearer. Since I have no idea what someone would use this 
> for, I cannot really fix this message element - and would 
> propose deleting it. I am ok leaving it in, but I'd like to 
> see the text cleaned up, and would ask that whomever wants me 
> to leave it in, provide text.

I prefer the message to be taken out. 

> statistics/counters in both the WTP Radio Statistics and the 
> WTP Reboot Statistics were intended to wrap around or reset. 
> I modified the text to state it is the former. I am waiting 
> for confirmation that this change is ok.

OK, but I also raised here the issue of an estimation of the minimal
wrap-up time and I did not see this answered yet. 

> 
> Issue 63: T22. The IESG asked why the length field was set to 
> a specific value. There was obviously some confusion about 
> what information was included, and I have provided a response 
> on what this meant. I am waiting to hear from Dan on how to 
> proceed. I do not believe a fix is required.

>From your last explanation I understand now values can be 6 or 8. If
this is correct, OK with me. 

> 
> Issue 41: CAPWAP DTLS Timer Clarification. This is a small 
> change that provides some clarification on the use of timers. 
> This does not introduce an incompatibility issue with -10, as 
> I suspect most people ended up figuring out (the hard way) 
> that the timers should have behaved based on my change.

Ok with me. 

> 
> Issue 101: Error in message element figure in 4.6.32. This is 
> a small editorial change to a broken message element diagram. 
> No incompatibility with -10.

Ok with me

> 
> Issue 100: Editorial issue in 4.6.15. This is a small 
> editorial change to add a separator between an enumerated 
> value and its description. No technical change.

Ok with me

> 
> Issue 89: E8. I have rejected this issue since the creator of 
> the comment had simply not understood that the use of 
> alpha/numeral/special symbols was only for the AC, not the 
> WTP. I am waiting for Dan's OK.

I cannot find your answer, but I trust you with this one. 

> 
> Issue 82: E1. I have changed the text to address the 
> editorial issue raised, and am waiting for Dan's OK.
> 
> Issue 86: E5. I have changed the text to address the 
> editorial issue raised, and am waiting for Dan's OK.
> 
> Issue 85: E4. I have changed the text to address the 
> editorial issue raised, and am waiting for Dan's OK.
> 
> Issue 97: E16. The IESG pointed out that some timers in 
> section 4.7 were not really timers, and needed to move to 
> another place in the spec. Only one of the sections they 
> pointed to needed to move, and I have. I have rejected the 
> rest of the request. I am waiting for Dan's OK.

OK for all these editorial issues.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 19 Jun 2008 13:31:50 -0400

Hi Pat,
> I prefer the message to be taken out.

FWIW, deleting this message element makes the most sense to me, too.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 19 Jun 2008 13:40:06 -0400

Hi Pat,
> was explaining in her message.

You could add something like:

"There is no length included in the Image Data and Image Identifier  
message elements because their lengths can be inferred from the  
lengths of the received messages."

Margaret

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 19 Jun 2008 11:45:30 -0700

Based on Dan's comments, here is the latest:

Issues remaining open:
Issue 102: Waiting for WG consensus
Issue 103: Waiting for WG consensus
Issue 53: T12. Dan is OK with the change, so I need to propagate the
change to two other message elements. I will take this to a separate
thread.
Issue 65: T24. Dan is willing to go the way the WG takes. I would
propose Margaret's approach, which we will take to a separate thread.
Issue 73: T32. Both Dan and Margaret are ok removing the message
element. I will take this to another thread.
Issue 74: T33. Pat owes Dan a response to the unanswered question.

Closed Issues:
Issue 61: T20. Closing issue 61.
Issue 42: T1. Closing issue 42.
Issue 99: CAPWAP Timer References. Closing issue 99.
Issue 63: T22. Closing issue 63.
Issue 41: CAPWAP Timer Clarification. Closing issue 41.
Issue 101: Error in message element figure in 4.6.32. Closing issue 101
Issue 100: Editorial issue in 4.6.15. Closing issue 100
Issue 89: E8. Closing issue 89
Issue 82: E1. Closing issue 82
Issue 86: E5. Closing issue 86
Issue 85: E4. Closing issue 85
Issue 97: E16. Closing issue 97

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, June 19, 2008 10:13 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: Re: [Capwap] Latest Status of CAPWAP Open Issues

See in-line. 

Dan

> IESG, and the few additional ones discovered while fixing them, here 
> is an update on all of the issues, and what I'm waiting for in order 
> to move forward.
> 
> Issue 61: T20. The original request to change the enum lists to start 
> at zero was not acceptable to some due to the fact that it would be 
> incompatible with version -10 of the draft.
> Based on an agreement with Dan, I have simply marked zero (0) as 
> reserved. I am waiting for confirmation that this is acceptable

OK with me. 

> 
> Issue 102: Join to Image Data state transition issue on the AC. This 
> is another issue raised on the list, and required that some new text 
> be added to this state transition description on the AC. While there 
> are a number of possible ways to fix this issue, I took the simplest 
> and more direct route to minimize the amount of text. I believe that 
> anyone implementing -10 would have assumed the change I made.

> change the WTP Board Data and WTP Descriptor message elements. This 
> does not introduce an compatibility issue with -10, it is simply an 
> editorial change that helps make the text clearer.

OK with me. 

> field. I made this change, but Margaret does not believe this change 
> is really necessary, and since it introduces an incompatibility issue 
> with -10, she would prefer that I back the change out. I am waiting 
> for other folks to provide their opinions. I agree the length is not 
> necessary.

> length field, must have a stated maximum value.
> Many instances of this was addressed via other technical comments from

> the IESG, but I went through the draft and found a few more, which I 
> combined into this issue. I am waiting for the OK to close this issue.

Ok with me. 

> 
> Issue 99: CAPWAP Timers not referencing timers properly. This is a 
> minor change, but while fixing another issue, I found that the CAPWAP 
> timers message element was not referring to the timers in section 4.7.

> This fix simply added the references.

OK with me.

> 
> Issue 73: T32. The IESG questioned whether the number of bits in a 
> field of the WTP Operational Statistics is sufficient.
> Reading the message element, I couldn't really understand what this 
> was trying to do, so I asked the LWAPP developers, and this was an 
> idea that never turned into anything, and do not have any 
> recommendations on how to make the language clearer. Since I have no 
> idea what someone would use this for, I cannot really fix this message

> element - and would propose deleting it. I am ok leaving it in, but 
> I'd like to see the text cleaned up, and would ask that whomever wants

> me to leave it in, provide text.

> statistics/counters in both the WTP Radio Statistics and the WTP 
> Reboot Statistics were intended to wrap around or reset.
> I modified the text to state it is the former. I am waiting for 
> confirmation that this change is ok.

> 
> Issue 63: T22. The IESG asked why the length field was set to a 
> specific value. There was obviously some confusion about what 
> information was included, and I have provided a response on what this 
> meant. I am waiting to hear from Dan on how to proceed. I do not 
> believe a fix is required.

> provides some clarification on the use of timers.
> This does not introduce an incompatibility issue with -10, as I 
> suspect most people ended up figuring out (the hard way) that the 
> timers should have behaved based on my change.

Ok with me. 

> editorial change to a broken message element diagram.

Ok with me

Ok with me

> comment had simply not understood that the use of 
> alpha/numeral/special symbols was only for the AC, not the WTP. I am 
> waiting for Dan's OK.

> Issue 97: E16. The IESG pointed out that some timers in section 4.7 
> were not really timers, and needed to move to another place in the 
> spec. Only one of the sections they pointed to needed to move, and I 
> have. I have rejected the rest of the request. I am waiting for Dan's 
> OK.