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

["Joel M. Halpern" <jmh at joelhalpern.com>]

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 aFrom ietf-bounces at ietf.org  Mon Aug  4 13:02:15 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2FB3828C18B;
	Mon,  4 Aug 2008 13:02:15 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id B555B28C141;
	Mon,  4 Aug 2008 13:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.355
X-Spam-Level: 
X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=1.244, 
	BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id tJGXm5m-f75e; Mon,  4 Aug 2008 13:02:12 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net
	[64.62.209.72])
	by core3.amsl.com (Postfix) with ESMTP id B12DD3A68AB;
	Mon,  4 Aug 2008 13:02:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by hermes.tigertech.net (Postfix) with ESMTP id 6A76943052B;
	Mon,  4 Aug 2008 13:02:00 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from [10.10.10.100] (pool-71-161-51-162.clppva.btas.verizon.net
	[71.161.51.162])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hermes.tigertech.net (Postfix) with ESMTP id 6503743011C;
	Mon,  4 Aug 2008 13:01:58 -0700 (PDT)
Message-ID: <48975FF0.7060907 at joelhalpern.com>
Date: Mon, 04 Aug 2008 16:00:48 -0400
From: "Joel M. Halpern" <jmh at joelhalpern.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Mary Barnes <mary.barnes at nortel.com>
Subject: Re: [Gen-art] IETF LC review:
	draft-ietf-capwap-protocol-binding-ieee80211-07
References: <F66D7286825402429571678A16C2F5EE04920289 at zrc2hxm1.corp.nortel.com>
In-Reply-To: <F66D7286825402429571678A16C2F5EE04920289 at zrc2hxm1.corp.nortel.com>
Cc: dstanley at arubanetworks.com, gen-art at ietf.org, dromasca at avaya.com,
	mmontemurro at rim.com, IETF discussion list <ietf at ietf.org>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

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
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


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
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf