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

From: "Roni Even" <[email-masked]>
Date: Tue, 1 Feb 2011 10:27:24 +0200

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.

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.

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.

Nits/editorial comments:

1.       In 8.2 for pe_keepaliveto, what are the units, I assume it is
seconds.

2.       In section 7 section paragraph "in which one ore" should be "in
which one or"

---

From: "Roni Even" <[email-masked]>
Date: Sun, 6 Feb 2011 17:51:51 +0200

Hi Shinta,
I am OK with all your proposals
Thanks
Roni

> -----Original Message-----
> From: Shinta Sugimoto [mailto:[email-masked]]
> Sent: Sunday, February 06, 2011 3:29 PM
> To: Roni Even
> Cc: [email-masked]; gen-
> [email-masked]; '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:
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> >
> > 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
> > 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

---

From: Shinta Sugimoto <[email-masked]>
Date: Sun, 06 Feb 2011 22:29:24 +0900

Dear Roni,

(11/02/01 17:27), Roni Even wrote:
> Review Date:2011–2–1
> IETF LC End Date: 2011–2–10
>
> IESG Telechat date:
>
> 1.In section 8.2 the path exploration parameters are different from RFC

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].

> relates to the issue of conflict resolution discussed in the security

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.

> 2.In section 7 section paragraph “in which one ore” should be “in which
> one or”

Regards,
Shinta