Subject: [Gen-art] 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