Great. I had forgotten to mention that I had created tracker #174 for this issue. I will mark this one resolved. PatC -----Original Message----- From: Joel M. Halpern [mailto:jmh@xxxxxxxxxxxxxxx] Sent: Monday, August 04, 2008 6:42 PM To: Pat Calhoun (pacalhou) Cc: dstanley@xxxxxxxxxxxxxxxxx; gen-art@xxxxxxxx; capwap@xxxxxxxxxxxx; mmontemurro@xxxxxxx; IETF discussion list Subject: Re: [Capwap] [Gen-art] IETF LC review:draft-ietf-capwap-protocol-binding-ieee80211-07 Thank you. Those changes address my concerns very well. Please work with your document shepherd to determine when a new draft should be produced with those changes. I appreciate your prompt response, Joel Pat Calhoun (pacalhou) wrote: > Thanks for your review, Joel. Please see my comments below. > > > Question: > The document (in section 2.5) calls for specific DSCP values (46 and > 34) to be used on management frames. Two questions: > Is this the decimal value of the 6 bit DSCP field, or the decimal > value of the 8 bit ToS field, or a hex value? > More important question: The DSCP RFCs make it very clear that the > meanings of DSCP values are locally defined by network operators. As > such, shouldn't this be defined in terms of the intend PHB, not the > DSCP? I.e. define the desired behavioral treatment, and indicate the > common code point used to represent that treatment? If the meanings > of these code points in this environment is standardized, then there > MUST be a reference so that a reader can figure out what that standard is. > > <PRC> Fair comment. I would propose the following text: > > <new text> > 2.6. Quality of Service for IEEE 802.11 MAC Management Messages > > It is recommended that IEEE 802.11 MAC Management frames be sent by > both the AC and the WTP with appropriate Quality of Service values, > listed below, to ensure that congestion in the network minimizes > occurrences of packet loss. > > 802.1p: The precedence value of 7 (decimal) SHOULD be used for all > IEEE 802.11 MAC management frames, except for Probe Requests which > SHOULD use 4. > > DSCP: All IEEE 802.11 MAC management frames SHOULD use the > Expedited Forwarding per-hop behavior (see [RFC2598]), while IEEE > 802.11 Probe Requests should use the Low Drop Assured Forwarding > per-hop behavior (see [RFC2598]). > </new text> > > Confusion: > In section 6.9 describing the Multi-Domain Capability, the text > refers to "the associated domain country string" There is no domain > country string in the particular information element being defined. > And there appears to be no domain country string defined elsewhere in > the document. So what is the "associated domain country string", how > is it associated, and how is the implementor supposed to know what is > meant? > (There are lots of explicit cross-references to the IEEE specs for the > fields being sent. But no reference at all for the domain country > string.) > > <PRC> Thanks for pointing this out. I have modified the text to > include a reference to the "IEEE 802.11 WTP Radio Configuration" > message element, where the Country String can be found. > > Minor: > If it is necessary to revise the document, it would be a good idea to > do > > some work on the Introduction. This document, which provides the > protocol bindings, should actually explain what it means to provide > the protocol bindings. The reader should not be left to guess. I > suspect the WG felt that the sentence beginning "Use of CAPWAP control > message fields ..." covers the issue. It hints at it. A sentence or > two (assuming I have properly inferred the goal) stating that binding > consists of defining how a the CAPWAP protocol is to be used with a > specific technology, would solve this concern. > > <PRC> While I suspect that anyone reading this particular document > would have read the base, and be familiar with the protocol concepts, > it still doesn't hurt to be a tad clearer in the introduction. I would > propose some small modifications, which would result in the following: > > <new text> > 1. Introduction > > The CAPWAP protocol [I-D.ietf-capwap-protocol-specification] defines > an extensible protocol to allow an Access Controller to manage > wireless agnostic Wireless Termination Points. The CAPWAP protocol > itself does not include any specific wireless technologies, but > instead relies on binding specification to extend the technology to a > particular wireless technology. > > This specification defines the Control And Provisioning of Wireless > Access Points (CAPWAP) Protocol Binding Specification for use with > the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP > control message fields, new control messages and message elements are > defined. The minimum required definitions for a binding-specific > Statistics message element, Station message element, and WTP Radio > Information message element are included. > </new text> > > Also, it seems that the goals are mostly the general CAPWAP goals. So > it might be better if the first sentence of 1.1 read "Th goals of this > CAPWAP protocol binding are to make the capabilities of the CAPWAP > protocol available for use in conjunction with 802.11 wireless networks. > > The capabilities to be made available can be summarized as:" > > <PRC> Thanks for the proposed text. I have made a small modification, > so the text now reads: > > <new text> > 1.1. Goals > > The goals of this CAPWAP protocol binding are to make the > capabilities of the CAPWAP protocol available for use in conjunction > with IEEE 802.11 wireless networks. The capabilities to be made > available can be summarized as: > </new 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 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf