Subject: Gen-ART LC Review of draft-ietf-hip-bone-06

From: Ben Campbell <[email-masked]>
Date: Fri, 11 Jun 2010 13:51:17 -0500

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-hip-bone-06
Reviewer: Ben Campbell
Review Date: 2010-06-11
IETF LC End Date: 2010-06-11
IESG Telechat date: 2010-06-17

Summary: Ready for publication as an experimental RFC. I have a few minor editorial comments that I think should be considered in any remaining edits, but should not block publication.

Major issues: None

Minor issues: None

Nits/editorial comments:

-- General:

 IDNITS turns up some outdated references and boilerplate questions. Please check.

-- Section 1, paragraph 2: "HIP BONE,"

   Please expand on first mention

-- Section 1, last paragraph

   I'm not sure we can assume the reader knows what you mean by "customary sections."

-- 3.2.2, para 3, last sentence: "Given that each operation requires the attacker to generate a new key pair, the attack is completely impractical"

It would be better to avoid hyperbole when describing the practicality of an attack. Perhaps something to the effect of "impractical with current technology and techniques"?

-- 3.4, 2nd paragraph, last sentence: "with such straightforward approach."
   
Missing article

-- 5.1, paragraph 2: "The enrollment server of an overlay that were to use HITs derived from public keys as Node IDs could just authorize users to use the public keys and HITs associated to their nodes."
   
I have trouble parsing the first part of the sentence, around "that were to use".

-- 5.3, paragraph 1:"Nodes in an overlay need to establish connection with other nodes"
  
Connections (singular/plural mismatch)

-- 5.5, paragraph before last bullet list: "It is assumed that areas not covered by a particular HIP BONE instance specification are specified by the peer protocol or elsewhere."
   
This seems more a requirement than an assumption.

-- 6.1:"[ TBD by IANA; 980 ]"
   
Does this mean IANA has already picked the number? Or is it a recommended number? (Pattern repeats for other registrations)

---

From: Ari Keränen <[email-masked]>
Date: Tue, 15 Jun 2010 10:43:53 +0300

Hi Ben,

Thanks for the review! Comments inline.

On 06/11/2010 09:51 PM, Ben Campbell wrote:
> Summary: Ready for publication as an experimental RFC. I have a few
> minor editorial comments that I think should be considered in any
> remaining edits, but should not block publication.
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
> 
> -- General:
> 

OK, these should be fixed when we run the draft through xml2rfc next time.

> -- 3.2.2, para 3, last sentence: "Given that each operation requires
> the attacker to generate a new key pair, the attack is completely
> impractical"
> 
> It would be better to avoid hyperbole when describing the
> practicality of an attack. Perhaps something to the effect of
> "impractical with current technology and techniques"?
> 
> -- 5.1, paragraph 2: "The enrollment server of an overlay that were
> to use HITs derived from public keys as Node IDs could just authorize
> users to use the public keys and HITs associated to their nodes."
> 
> -- 5.5, paragraph before last bullet list: "It is assumed that areas
> not covered by a particular HIP BONE instance specification are
> specified by the peer protocol or elsewhere."
> 

We'll fix/rephrase these.

> Does this mean IANA has already picked the number? Or is it a
> recommended number? (Pattern repeats for other registrations)

It's a recommended number. Most of the IANA assigned numbers in HIP are 
not given sequentially, so it makes sense to propose a sensible value 
for IANA.

Cheers,
Ari

---

From: SM <[email-masked]>
Date: Wed, 16 Jun 2010 07:58:40 -0700

Hi Ari,
At 00:43 15-06-10, Ari Keränen wrote:
>It's a recommended number. Most of the IANA 
>assigned numbers in HIP are not given 
>sequentially, so it makes sense to propose a sensible value for IANA.

This recommended number was in a previous version 
of the draft since January 26.  If you want to 
propose a sensible value for IANA, I suggest that 
you ask IANA about it before putting it in an 
I-D.  Once a number is in the I-D, an implementor 
may start using it and it can turn into a problem 
if IANA assigns a different number.

Regards,
-sm

---

From: Ari Keränen <[email-masked]>
Date: Fri, 18 Jun 2010 13:35:29 +0300

Hi,

> if IANA assigns a different number.

This is how we have done it with pretty much all the HIP-documents 
updating HIP-specific registries, and has worked well so far (I don't
remember any case when IANA had not allocated the proposed value). Of 
course this requires that one checks all the active HIP documents and 
the IANA reserved values list before selecting a value, and still 
there's a non-zero chance for a conflict, but these would be anyway 
resolved by IANA once (and if) the document becomes an RFC.

Possibly IANA could have a "pre registration" registry for the values in 
drafts, but probably this would just cause more work than resolving the 
conflicts (which are uncommon anyway) before the publication. Especially 
since the proposed values sometimes change during the lifetime of the 
draft, e.g., because a parameter is moved from signed to unsigned 
portion of the packet or it becomes a critical parameter.

That said, we can have a look with future drafts if some more 
coordination with these allocations is needed.

Cheers,
Ari

---

From: SM <[email-masked]>
Date: Fri, 18 Jun 2010 11:02:13 -0700

Hi Ari,
At 03:35 18-06-10, Ari Keränen wrote:
>Possibly IANA could have a "pre registration" 
>registry for the values in drafts, but probably 
>this would just cause more work than resolving 
>the conflicts (which are uncommon anyway) before 
>the publication. Especially since the proposed 
>values sometimes change during the lifetime of 
>the draft, e.g., because a parameter is moved 
>from signed to unsigned portion of the packet or 
>it becomes a critical parameter.

Some registries have provisional and permanent registration.

>That said, we can have a look with future drafts 
>if some more coordination with these allocations is needed.

That may be the easier path.

Regards,
-sm