Hi,
thanks for reviewing the document! Comments follow:
Gray, Eric wrote:
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.
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 (?).
____________________________________________________________
Under subsection "Parameter Type" (bottom of page 87), you
"... a HIP parameter ..." or "... HIP parameters ..." ?
... a HIP parameter...
____________________________________________________________
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, ..."
Ok, this looks better.
___________________________________________________________
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
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.
__________________________________________________________
A similar condition exists for NOTIFY - which is the
name of both a packet and a parameter. This might be
This will be fixed (NOTIFY message, NOTIFICATION parameter
perhaps).
_________________________________________________________
At the top of page 59, you say:
"... MUST not ..." should be "... MUST NOT ..."
Ok, fixed.
Thanks,
Petri
--
Petri Jokela e-mail: [EMAIL PROTECTED]
Research Scientist phone: +358 9 299 2413
Ericsson Research, NomadicLab mobile: +358 44 299 2413
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
