-----Original Message-----
From: Shinta Sugimoto [mailto:shinta(_at_)sfc(_dot_)wide(_dot_)ad(_dot_)jp]
Sent: Sunday, February 06, 2011 3:29 PM
To: Roni Even
Cc:
draft-ietf-shim6-multihome-shim-api(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
gen-
art(_at_)ietf(_dot_)org; 'IETF-Discussion list'
Subject: Re: Gen-ART LC review of draft-ietf-shim6-multihome-shim-api-
15
Dear Roni,
Thank you very much for your review. Please find my answers inline.
(11/02/01 17:27), Roni Even wrote:
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-shim6-multihome-shim-api-15
Reviewer: Roni Even
Review Date:2011-2-1
IETF LC End Date: 2011-2-10
IESG Telechat date:
Summary: This draft is almost ready for publication as Informational
RFC.
Major issues:
Minor issues:
1.In section 8.2 the path exploration parameters are different from
RFC
5534, missing keep alive interval. Why the difference.
You are right. Keepalive Interval is missing in the parameter set that
we defined in our draft. We did not put in the draft as we thought that
the value will be determined according to the recommendation given in
RFC5534 (i.e., the interval should be set one-half to one-third of the
Keepalive Timeout value), but I agreed that we should make it explicit
in our draft.
I suggest to make the following changes in Section 8.2:
1) change the structure (shim_pathexplore{}) as follows:
struct shim_pathexplore {
uint16_t pe_probenum; /* # of initial probes */
uint16_t pe_keepaliveto; /* Keepalive Timeout */
uint16_t pe_keepaliveint; /* Keepalive Interval */
uint16_t pe_initprobeto; /* Initial Probe Timeout */
uint32_t pe_reserved; /* reserved */
};
2) Add pe_keepaliveint and its description as below.
pe_keepaliveint
Indicates interval of REAP keepalive messages in seconds to be
sent by
the host when there is no outbound traffic to the peer host. The value
shall be set according to the recommendation given in [RFC5534].
Does this sound reasonable to you?
2.In section 11.1 you discuss conflict resolution for SHIM6, is this
also relevant for HIP or is it a specific SHIM6 problem. This also
relates to the issue of conflict resolution discussed in the security
section.
No, the issue addressed in Section 11.1 is not relevant to HIP. It is
an
issue specific to SHIM6. Note that the concept of context forking is
not
defined in the HIP RFC. As for the texts in Section 14 (Security
Considerations), the texts in Section 14.1.1 apply to HIP and SHIM6.
When there is no indication of specific protocol name (i.e., HIP or
SHIM6), a term shim sub-layer refers to both HIP and SHIM6. This is an
assumption in this document.
3.The last sentence in appendix A "Any solution is needed to overcome
the problem mentioned above" is not clear, does it mean that there is
no
solution to the context forking problem. Section 11.1 claims that
using
the procedure described it addresses this issue, am I missing
something.
No, the issue discussed in Appendix A cannot be solved by the solution
(or I had better say recommendation) explained in section 11.1. They
are
simply different issues. With regard to the issue described in Appendix
A, there is no solution as far as I know. To avoid the confusion, I
suggest to change the last sentence of Appendix A as follows: "It is
for
further study how to solve the issue described above." Does this make
sense?
Nits/editorial comments:
1.In 8.2 for pe_keepaliveto, what are the units, I assume it is
seconds.
Yes, you are right. Let us update the text to make it clear.
2.In section 7 section paragraph "in which one ore" should be "in
which
one or"
OK, thanks. Let us correct the typo.
Again, thank you very much for your review!
Regards,
Shinta