Subject: [Gen-art] Gen-ART Review of draft-ohara-capwap-lwapp-04.txt

From: Spencer Dawkins <[email-masked]>
Date: Mon, 16 Apr 2007 13:32:23 -0500

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ohara-capwap-lwapp-04
Reviewer: Spencer Dawkins
Review Date: 16 April 2007
IESG Telechat date: 19 April 2007

Summary: Given that this document is an Independent Submission, and will 
include an IESG Note pointing to current work in CAPWAP, the General Area 
director should vote no-obj.

Comments:

The intention of this document, as I understand it, is to capture the 
version of the LWAPP protocol when it entered the IETF for standardization. 
Given this intention, I reviewed lightly and tried to focus on points that 
might affect implementation and interoperation. If the intention is to 
publish in the current state, that would make sense, too.

3.3.4 - discussion of "fragmentation" could probably benefit from more 
consistent identification of the specific kind of fragmentation that's 
taking place. For example, 3.4.5 is especially overloaded when it says

   IPv6 does MTU discovery so fragmentation and re-assembly is not
   necessary for UDP packets.

This could be taken as "don't have to support frag/reassembly at the LWAPP 
level" or as an implicit deprecation of host-based frag/reassembly in IPv6, 
and it's not clear to me which level of fragmentation is being referred to.

Note that the authors still have a note that says

   [ed: IP fragmentation may raise security concerns and bring
   additional configuration requirements for certain firewalls and NATs.
   One alternative is to re-use the layer 2 (application layer)
   fragmentation reassembly.  Comments are welcomed.]

6.2.4 - Several message element descriptions contain text like "Note this 
message element is only valid when LWAPP uses the IP/UDP layer 3 transport". 
It would be necessary to define behavior when invalid message elements are 
received in most protocols, if you expect interoperation between independent 
implementations. 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art