Subject: [Gen-art] review: draft-ietf-netext-pmip6-lr-ps-05

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 09 Mar 2011 16:59:29 -0500

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-netext-pmip6-lr-ps-05
     PMIPv6 Localized Routing Problem Statement
Reviewer: Joel M. Halpern
Review Date: 7-March-2011
IETF LC End Date: 14-March-2011
IESG Telechat date: 17-March-2011

Summary: This document is close to ready for publication as an 
Informational RFC.

Moderate issues:
     The abstract is misleading.  It reads as if the problem is allowing 
communication between a PMIP mobile node and a correspondent, wherever 
the correspondent is.  Even the introduction is somewhat hazy on its 
scope, sometimes referring to the generalized notion of correspondent 
node, and sometimes seeming to mean just the sub-case of two nodes, both 
attached to MAGs, in the same domain.  It is only in the conventions and 
terminology that "Localized Routing" is actually defined in a way to 
make clear what problem is of interest.

Minor issues:
	In the introduction, the word "problem space" is used to describe what 
is being covered in this document.  However, the document includes 
sections such as section 4, Functional Requirements for Localized 
Routing which are not about the problem, but rather about what 
mechanisms are needed for a solution.  Rather than argue about what 
belongs in this document, or the document name, I would suggest 
clarifying in the introduction what this document is actually doing.
	While the arguments at the end of section 3.1 sound plausible, they 
are, as far as I can tell, quite controversial in the mobile industry. 
I have heard speakers make exactly opposite assertions about several of 
these claims.  As such, I think this paragraph ought to be toned down.
	I found myself confused by the text in section 5. I think that the 
problem is that I assume that a "Local Mobility Agent" will be in the 
same domain as the Mobile Access Gateway handling the client the LMA is 
supporting (otherwise it sems not to be local.)  Given the discussion of 
Roaming, and the way it is constructed, this appears not to be the case. 
  If there is no such domain coupling requirement, then could you please 
add a note to that effect somewhere early in the document (possibly in 
the introduction along with a better description of the problem.)

Nits/editorial comments: