Document: draft-ietf-mip4-vpn-problem-solution-03.txt Reviewer: Suresh Krishnan [suresh.krishnan@ericsson.com] Review Date: 27 NOv 2007 IESG Telechat DAte: 29 Nov 2007 Summary: This draft is well written and easy to read, but I do have a couple of comments I would like addressed. Meta comments ============= * This is just my personal view but I am not sure if BCP is the right intended status for this document. It requires changes to the node implementations and requires behavioral changes on some nodes. Perhaps needs to be Standards track * T_MONITOR is a new configuration knob that is added to the MN (that possibly requires changes to implementation). This needs to be clearly stated prior to use. Also, it would be nice to mention the associated signaling traffic reduction vs detection latency reduction compromise, so that the admins can make an informed decision as to the value of this. Minor ===== Section 3.3 =========== Bullet 2: The following text is redundant since it is covered by bullet 3. "If a previous registration reply from the x-HA has been received, the MN SHOULD de-register with the x-HA." It makes sense to remove this Section 3.4 =========== * It is not clear who this requirement is on? "Therefore, it is required that x-HA and i-HA addresses MUST be different" Can you please clarify who ensures this Section 3.6 =========== * It is not clear what "inside" means here since it refers to the x-HA The registration process can be improved in many ways. One simple way is to make the x-HA detect whether a registration request came from inside or outside. If it came from inside, the x-HA can simply drop the registration request. Editorial ========= * Push the basic topology figure to right after the first paragraph of section 2. The draft does not have an Intended Status. From the ID tracker, I figured out that it is BCP, but it is perhaps better to explicitly state it in the draft.