Re: Gen-ART LC review of draft-ietf-shim6-multihome-shim-api-15

[Shinta Sugimoto <[e-mail]>]

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