The changes in revision -08 address my concerns fully, and significantly improve the document. As far as I am concerned, the document is read for publication as a PS.
Thank you, Joel M. Halpern Joel M. Halpern wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-capwap-protocol-binding-ieee80211-07.txt > CAPWAP Protocol Binding for IEEE 802.11 > Reviewer: Joel M. Halpern > Review Date: August 2, 2008 > IETF LC End Date: Any day now > IESG Telechat date: N/A > > Summary: This document is almost ready for publication as a Proposed > Standard. > > > 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. > > 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.) > > 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. > > 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:" > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
