Subject: Re: [Gen-art] IETF LC review: draft-ietf-capwap-protocol-binding-ieee80211-07

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 04 Aug 2008 16:00:48 -0400

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:"

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 4 Aug 2008 15:25:05 -0700

Thanks for your review, Joel. Please see my comments below. 

Question:
	The document (in section 2.5) calls for specific DSCP values (46
and 

<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:

<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>

<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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 04 Aug 2008 21:42:00 -0400

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 5 Aug 2008 09:16:30 -0700

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:[email-masked]] 
Sent: Monday, August 04, 2008 6:42 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; IETF discussion list
Subject: Re: [Capwap] [Gen-art] IETF LC
review:draft-ietf-capwap-protocol-binding-ieee80211-07

and
> 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?
> 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.
> 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?

> <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:
> 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 
> <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
> 

> <PRC> Thanks for the proposed text. I have made a small modification, 
> so the text now reads:
> 
> <new text>
> 1.1.  Goals
> 
_________________________________________________________________
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf