Subject: Gen-ART review of draft-ietf-mip4-vpn-problem-solution-03.txt

From: Suresh Krishnan <[email-masked]>
Date: Tue, 27 Nov 2007 09:41:12 -0500

I am the assigned Gen-ART reviewer for
draft-ietf-mip4-vpn-problem-solution-03.txt

For background on Gen-ART, please see the FAQ at
<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.

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.

Cheers
Suresh

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