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(_at_)joelhalpern(_dot_)com]
Sent: Monday, August 04, 2008 6:42 PM
To: Pat Calhoun (pacalhou)
Cc: dstanley(_at_)arubanetworks(_dot_)com; gen-art(_at_)ietf(_dot_)org;
capwap(_at_)frascone(_dot_)com;
mmontemurro(_at_)rim(_dot_)com; 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf