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

["Roni Even" <[e-mail]>]

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

> -----Original Message-----
> From: Shinta Sugimoto [mailto:[e-mail]]
> Sent: Sunday, February 06, 2011 3:29 PM
> To: Roni Even
> Cc: [e-mail]; gen-
> [e-mail]; '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