Re: Issue 217
From: Margaret Wasserman (margaretthingmagic.com)
Date: Thu, 12 Apr 2007 08:46:21 -0700 (PDT)

Hi Abhijit,

I'm sorry for not mentioning Sudhanshu's correction in the previous message. This is a necessary correction, as Pat has already indicated.

I view this as a helpful amendment to the text that Pat circulated, and not as an objection to the proposed changes.

Thanks to you, and especially to Sudhanshu for noticing this!

Margaret


On Apr 11, 2007, at 3:13 PM, Abhijit Choudhury (achoudhu) wrote:

I agree with Sudhanshu on Issue 217. Fig. 3 needs to be made
consistent with the accepted text.

In Fig 3. in the bindings doc, we need to replace

        Protected               AC

with

        Protected               WTP/AC


Here is the updated figure:
---------------------------------------------------------------------- --
------
MAC header field Location
Frame Control:
Version AC
ToDS AC
FromDS AC
Type AC
SubType AC
MoreFrag WTP/AC
Retry WTP
Pwr Mgmt -
MoreData WTP
Protected WTP/AC
Order AC
Duration: WTP
Address 1: AC
Address 2: AC
Address 3: AC
Sequence Ctrl: WTP
Address 4: AC
QoS Control: AC
Frame Body: AC
FCS: WTP


       Figure 3: Population of the IEEE 802.11 MAC header Fields for
                              Downlink Frames

---------------------------------------------------------------------- --
------


Thanks,
Abhijit



-----Original Message-----
From: Sudhanshu [mailto:sudhanshu.ietf [at] gmail.com]
Sent: Wednesday, April 11, 2007 12:04 PM
To: 'Margaret Wasserman'; 'capwap'
Subject: Re: [Capwap] Fwd: CONSENSUS CONFIRMATION: #138, #217, #247,
#248,#249, #250, #251 & #252

Please see my inline comments.

-----Original Message-----
From: Margaret Wasserman [mailto:margaret [at] thingmagic.com]


248 Both IPv4 and IPv6 Addresses not required.
[Suds] Reiterate my previous position, sending both addresses IPv4 and
IPv6 should not be precluded, especially in the "Discovery Response".

217 What is frame format with WTP encrypts/decrypts?

No one objected to including the previously-agreed fix in the new document.

[Suds] As I said in my previous response, proposed resolution should
also address figure 3.
        "Protected" field will be edited by both AC/WTP.

There were also four substantive issues discussed by the group:


249 UDP-Lite as optional transport for CAPWAP

There was no disagreement with the editors' proposed resolution.

[Suds] I disagree with this assessment. As the issues subject says,
UDP-lite should be optional, but the proposed solution does not make it
clear. UDP and UDP-lite both option should be valid for IPv6.


251 Retransmission of control packets is not exponential

There was no disagreement with the editors' proposed resolution.

[Suds] I am not very clear behind this timer getting tied with the echo
interval. Editor(s) please comment.



_________________________________________________________________ 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

Results generated by Tiger Technologies using MHonArc.