Subject: [Hipsec] WGLC comments: draft-ietf-hip-native-api-07-pre2

From: Varjonen Samu <[email-masked]>
Date: Mon, 13 Jul 2009 13:13:31 +0300

Hi,

Couple comments/questions on the draft-ietf-hip-native-api-07-pre2.

First some editorial stuff. In the introduction third paragraph it says 
"Host Identifier Tags (HITs)". It should be "Host Identity Tags (HITs)". 
HITs abreviation is also opened couple pragraphs down, while just saying 
"HITs" would be sufficient.

In introduction, with opportunistic mode I would refer to "[RFC5201] 
section 4.1.6."

Last paragraph in introduction, the "recap", the third goal is something 
that sounds exactly like draft-ietf-shim6-multihome-shim-api. Isn't it 
already defined in it, like the section 4.5 seems to be explanation of 
multihome-shim-api with HIP specific language. So isn't the third goal 
more like multihome-shim-api's goal?

The definition of macro HIP_ADDR_ANY is confusing. "HIP_ADDR_ANY, 
denotes means that the application accepts both HITs and any other type 
of addresses." First it has "denotes means", drop one. Third paragraph 
after the definition it says that applications might use HIP_ADDR_ANY 
when HIP-based connectivity fails and In section 4.4 Table 2 the 
correspondence from flags to macros says that if its not a *_HIT_TMP or 
*_HIT_PUBLIC it corresponds to macro HIP_ADDR_ANY. To me this looks like 
the definition should lose the HIT part and just say "accepts addresses".

Sorry If there is some overlapping with other comments on the draft, I 
have not been following the discussion on the list thoroughly ;)

BR,
Samu

---

From: Miika Komu <[email-masked]>
Date: Mon, 13 Jul 2009 15:58:14 +0300

Varjonen Samu wrote:

Hi,

here's an updated version with your comments:

http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-07-pre3.txt

Please check if you are ok with the changes.

> "HITs" would be sufficient.

Applied.

> In introduction, with opportunistic mode I would refer to "[RFC5201] 

Applied.

> more like multihome-shim-api's goal?

Changed to:

    "The third goal is to
    illustrate how HIP-aware applications can use the SHIM API
    [I-D.ietf-shim6-multihome-shim-api] to manually map locators to
    HITs."

> the definition should lose the HIT part and just say "accepts addresses".

I have changed HIP_ADDR_ANY to HIP_ENDPOINT_ANY. Does it work for you? 
In addition, I changed "connectivity fails" text as follows:

    The use of HIP_ENDPOINT_ANY macro in the context of outgoing
    communications is left for further experimentation in the context of
    opportunistic mode.  It can result in a data flow with or without
    HIP.

More about the _HIT_TMP variables in a short while in a separate email.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 13 Jul 2009 09:20:27 -0700

Miika,
Here are a few comments on the changes you made w.r.t. Samu's comments: 

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Monday, July 13, 2009 5:58 AM
> To: Varjonen Samu; [email-masked]
> Subject: Re: [Hipsec] WGLC comments: draft-ietf-hip-native-api-07-pre2
> 
> Varjonen Samu wrote:
> 
> Hi,
> 

OLD TEXT:

   However, the application can use three special macros to set a
   wildcard value manually into the ship_hit field.  The macros are 

NEW TEXT:

   However, the application can use four special wildcard constants.  
   The wildcards are

(and in general, change "macro" to "constant" in this section unless you
are talking about a macro function)

OLD TEXT:

The HIP_HIT_ANY denotes that the
   application accepts any type of HIT.

NEW TEXT:

The HIP_HIT_ANY denotes that the
   application accepts inbound HIP associations to any type of HIT.

Otherwise, I'm fine with the changes.

- Tom

---

From: Miika Komu <[email-masked]>
Date: Mon, 13 Jul 2009 21:41:08 +0300

Henderson, Thomas R wrote:

Hi,

new preversion is here based on your comments:

http://www.iki.fi/miika/docs/draft-ietf-hip-native-api-07-pre5.txt

> are talking about a macro function)

I replaced throughout the text because we don't really provide new 
macros at all.

> Otherwise, I'm fine with the changes.

I didn't apply this because it says few paragraphs later:

         The application also uses the HIP_HIT_ANY constant in ship_hit
	field to establish outgoing communications in Opportunistic
         mode <xref target="RFC5201" />, i.e., when the
         application knows the remote peer locator but not the
         HIT.

So the ANY constants apply for both inbound and outbound connections. 
Please suggest if this should be clarified in some way.