Benoit Claise has entered the following ballot position for
draft-ietf-hip-rfc5206-bis-13: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
Hi Tom,
please see inline.
On 15.09.2016 06:48, Tom Henderson wrote:
On 09/12/2016 07:28 AM, Mirja Kuehlewind wrote:
Mirja Kühlewind has entered the following ballot position for
draft-ietf-hip-rfc5206-bis-13: No Objection
Mirja, thank you for the review; responses inline below.
- Tom
--
5206-bis specifies how to user RVS for the 'double-jump' mobility problem.
3.2.3 1) says:
1. The mobile host sending an UPDATE to the peer, and not receiving an
ACK, MAY resend the UPDATE to a rendezvous server (RVS) of the peer, if
such a server is known.
But it DOES know there is an RVS IF
Mirja,
Inline below (the points still being discussed)
On Thu, 15 Sep 2016, Mirja Kühlewind wrote:
3) section 4: Can you give any hints how large the lifetime typically
should be? Can only the original address have an unbounded lifetime (see
section 5) or can I also set the lifetime value i
On Thu, 15 Sep 2016, Benoit Claise wrote:
--
COMMENT:
--
I support Alexey's comment:
This document doesn't have "Changes since RFC " section as required
On Thu, 15 Sep 2016, Robert Moskowitz wrote:
5206-bis specifies how to user RVS for the 'double-jump' mobility problem.
3.2.3 1) says:
1. The mobile host sending an UPDATE to the peer, and not receiving an ACK,
MAY resend the UPDATE to a rendezvous server (RVS) of the peer, if such a
serv
