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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]