Re: [hiprg] IRSG review of draft-irtf-hip-experiment

["Henderson, Thomas R" <[e-mail]>]

Martin,
Thanks for providing the IRSG review of this draft.  Responses inline below:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Martin Stiemerling
> Sent: Tuesday, June 21, 2011 7:49 AM
> To: [e-mail]
> Subject: [irsg] IRSG review of draft-irtf-hip-experiment
> 
> Dear all,
> 
> Here is my review of draft-irtf-hip-experiment-12.
> 
> The draft is basically fine and it provides an excellent overview about
> the HIP experiments, their outcomes, and lessons learnt.
> 
> There are a few nits:
> - Section 1, Introduction:
> The draft -12 dates May 2011, but the intro says it compiles data from
> 2004 to 2009. Wasn't there any further work until May 2011?

We haven't been updating it with recent work since it would always be a moving target and we would like to publish it with the material gathered through 2009.  So I propose no change here.

> - Section 2.1, Figure 1:
> It is not clear from the figure what is user space and what is kernel
> space. This doesn't match the text on page 7, bottom. This might be
> confusing to an average reader.

Suggested rephrase:

Old text:
   A common way to partition the HIP implementation is to implement a
   keying daemon in user-space that interacts with kernel-level support
   for ESP, as shown in Figure 1.  However, the HIPL project has
   demonstrated that it is also possible to support HIP with a purely
   kernel-level implementation.

New text:
   A HIP implementation typically consists of a key management process
   that coordinates with an IPsec-extended stack, as shown in Figure 1.
   In practice, HIP has been implemented entirely in user-space, entirely
   in the kernel, or as a hybrid with a user-space key management process
   and a kernel-level ESP.

> - Section 2.3.1, page 10, 1st paragraph:
> s/4) a ad-hoc/4) an ad-hoc

OK

> - Section 2.3.1, page 11, paragraph starting with "Over time...":
> I suggest to split this paragraph after "...1) and 3). I.e., starting
> "Implementing the first approach..." as a new paragraph.

OK

> - Section 2.4, page 16, 3rd paragraph:
> The conclusion of the first sentence isn't that obvious for an average
> reader. It would be good to give a reference/hint why running IPv6 apps
> over IPv4 (and vice versa) is made possible by HIP.

Old text:
   HIP makes it possible to use IPv6 applications over the IPv4 network
   and vice versa.  The interfamily portion of the BEET patch in the
   Linux kernel was found more difficult to complete compared with the
   single-family processing.  All three open source HIP implementations
   have demonstrated some form of interfamily handoff support. 

New text:
   HIP makes it possible to use IPv6 applications over the IPv4 network
   and vice versa.  This has been called interfamily operation (flexibility
   between different address families) and is enabled by the fact that the
   transport pseudoheader is based on HITs regardless of whether the 
   application or the underlying network path is based on IPv4.  
   All three open source HIP implementations have demonstrated some form of 
   interfamily handoff support.  The interfamily portion of the BEET patch
   in the Linux kernel was found more difficult to complete compared with the
   single-family processing.   (new paragraph break here)

> - Section 3.5, page 20, 3rd paragraph:
> s/200 rps/200 requests per second/

OK

> - Section 5.4, page 24, paragraph starting with "A HIP-aware...":
> The last sentence is not completely correct, as a change of the IP
> address may remove a firewall (or any other network entity) from the
> data packet path between source and destination. In this case, the
> firewall would not be able to learn any of the changes anymore. I
> suggest adding at the end of the sentence ", if still on the path."

OK

If no other comments, I will publish the -13 version before the cutoff next Monday.

- Tom