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

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

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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