Subject: [Gen-art] Gen-ART LC Review of draft-ietf-hip-base-06.txt

From: "Gray, Eric" <[email-masked]>
Date: Wed, 13 Sep 2006 20:02:26 -0400

Authors (Thomas/Petri/Pekka/Robert),

	I am the Gen-ART assigned Last Call reviewer for 
this draft: draft-ietf-hip-base-06.txt

	For background on Gen-ART, please see the FAQ at:

	http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html

	Please resolve these comments along with any other Last 
Call comments you may receive.

Summary:
-------

I believe this draft is nearly ready for publishing as an
Experimental RFC.

I have the following minor comments, NITs and requests for 
clarification...

=============================================================

In the Introduction section (1.0), you say:

"Other elements of the HIP architecture are specified in 
 other documents, including how HIP can be combined with 
 a variant of the Encapsulating Security Payload (ESP) 
 for integrity protection and optional encryption, 
 mobility and multi-homing extensions to HIP, extensions
 to the Domain Name System (DNS) for storing Host 
 Identities there, proposals on added HIP-related 
 infrastructure into the networks, and techniques for NAT 
 traversal."

Which "other documents"?  It might help if this was set
up as a bullet list with specific references for each of
the bullets.
____________________________________________________________

Under subsection "Parameter Type" (bottom of page 87), you 
say "... a HIP parameters ..."  Should this be either -

"... a HIP parameter ..." 

	or 

"... HIP parameters ..."

	?
____________________________________________________________

Under this same section, after listing type codes assigned
by this specification (sections 5.2.3 through 5.2.18), you
say:

"The type codes 0 through 1023 and 61440 through 65535 are 
 reserved for future base protocol extensions, and are 
 assigned through IETF Consensus."

In my quick look at the list, it looks as if these values 
are all taken from these ranges.  I suggest changing the 
wording to reflect this - for example - by starting with
"With the exception of the above assigned type codes, ..."
___________________________________________________________

Can you differentiate the double place-holder names (two
for each of ECHO_RESPONSE and ECHO_REQUEST)?  In the draft, 
you list each as two separate values (in each case, one for 
one context and the other for another context), each with a 
different assigned value.

This seems messy/confusing.  Perhaps you could (using the
ECHO_RESPONSE as an example) make the place holder names
along these lines:

	ECHO_RESPONSE_COV   =   961
	ECHO_RESPONSE_UNCOV = 63425

?

I think you could then say - 

"There are 2 ECHO_RESPONSE types: ECHO_RESPONSE_COV and 
 ECHO_RESPONSE_UNCOV" 

- (in the text in section 5.2.18).  If you want to keep 
the names short, perhaps ECHO_RESP_COV and ECHO_RESP_UCO
- or you could use the "_2" convention you use with HMAC
and HIP_SIGNATURE?

The editing requirements to fix this are non-trivial as
there are places where ECHO_REPONSE is correct and others
where it should be one or the other specific type values.
I believe ECHO_RESPONSE applies where you talk about the
object (format, etc.) while one of the other terms should
apply if you are talking about the actual type number.

The same observations and analogous changes would apply 
to ECHO_REQUEST.

For one thing, the current wording will likely "sticky
things up" during IANA review.  Short of including all
of the approriate explanatory text in the file they use
to list assigned numbers, a simple listing of assigned
values is going to be ambiguous.
__________________________________________________________

A similar condition exists for NOTIFY - which is the 
name of both a packet and a parameter.  This might be
somewhat easier to dis-ambiguate - clearly one is a
packet type while the other is a parameter type - but 
may this still may be a point of confusion. 

A developer looking at the assigned numbers file may
confuse one with the other.  We could argue that this
is a "darwinian influence" in the long-term viability
of individual developers, but we're not really in this
to make life difficult, are we?  :-)

I suggest either NOTIFY_PKT and NOTIFY_PAR, or NOTIFY 
and NOTIFY_2 (you pick which is associated with the 
packet and which the parameter) - at least where you
are clearly talking about the assigned type number.

I believe that - unlike the above case - it is always
the case that you are either talking about the NOTIFY
packet or the NOTIFY parameter, hence the editing to
fix this is simpler.
_________________________________________________________

At the top of page 59, you say:

"An UPDATE that does not contain a SEQ parameter is 
 simply an ACK of a previous UPDATE and itself MUST 
 not be acked."

"... MUST not ..." should be "... MUST NOT ..."

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Petri Jokela <[email-masked]>
Date: Thu, 21 Sep 2006 16:15:16 +0300

Hi,

thanks for reviewing the document! Comments follow:

> up as a bullet list with specific references for each of

This can be edited in the specification. All these "other
elements" are I-Ds at the moment, but as they are not
falling into "Normative references" but into "Informative
references" in their role in the Introduction there
should be no problem adding these (?).

> "... a HIP parameter ..."  or  "... HIP parameters ..." ?

... a HIP parameter...

Ok, this looks better.

This sounds like a good proposal. I got also a proposal from Tom
for naming:

ECHO_REQUEST_SIGNED	897
ECHO_REQUEST_UNSIGNED	63661
ECHO_RESPONSE_SIGNED	961
ECHO_RESPONSE_UNSIGNED	63425

This affects multiple places in the document so I'll need to take
a closer look at it and fix all occurrences of these parameters.

This will be fixed (NOTIFY message, NOTIFICATION parameter
perhaps).

> "... MUST not ..." should be "... MUST NOT ..."

Ok, fixed.

Thanks,

Petri

-- 
Petri Jokela				e-mail: [email-masked]
Research Scientist			phone:  +358 9 299 2413
Ericsson Research, NomadicLab		mobile: +358 44 299 2413