Hi Adam,
On 5/10/18 02:34, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-hip-rfc4423-bis-19: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc4423-bis/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for everyone's work on updating RFC 4423.
thanks for comments!
> In general, I agree with Mirja's point that section 11 seems a bit disjoint
> from the rest of the document, and would be better served as an appendix. It's
> also somewhat jarring to have a document whose abstract talks about a "new
> namespace" and a "new protocol layer," which goes on to describe conclusions
> from twelve years of deployment experience. I would recommend re-working all
> uses of the word "new" (which, in most cases, can be achieved by either
> removing the word "new" from sentences, or replacing it with "HIP").
Agreed. I replaced "new" (namespace/layer) to "HI/additional" (depending
on the context) throughout the document.
> The remainder of my comments are editorial nits.
>
> ---
>
> §2.1:
>
>> +---+---+
>> | Term | Explanation |
>> +---+---+
>> | Public key| The public key of an asymmetric cryptographic key |
>> | | pair. Used as a publicly known identifier for|
>> | | cryptographic identity authentication. Public is |
>> | | a a relative term here, ranging from "known to|
>> | | peers only" to "known to the world." |
>
> Nit: this text contains a doubled "a" ("...a a relative...").
thanks
> ---
> §2.2:
>
> Nit: The change in spacing in this table makes certain terms difficult to read
> (e.g., "HIP base exchange HIP packet" appears to be a single term until the
> table is closely examined.) Consider reverting to the spacing from RFC 4423.
done
> ---
>
> §3.1:
>
>> o The names should have a fixed length representation, for easy
>
> Nit: "fixed-length" is a compound adjective, and should be hyphenated.
> cf. https://www.google.com/search?q=compound+adjective
>
>> (e.g the TCB).
>
> Nit: The conventional form would call for "(e.g., the TCB)"
> cf. https://www.google.com/search?q="e.g."+punctuation+comma
>
>> o The names should be long lived, but replaceable at any time. This
>
> "long-lived"
>
>> designed, it can deliver all of the above stated requirements.
>
> "above-stated"
fixed, thanks
> ---
>
> §4:
>
>> In theory, any name that can claim to be 'statistically globally
>> unique' may serve as a Host Identifier. In the HIP architecture, the
>> public key of a private-public key pair has been chosen as the Host
>> Identifier because it can be self managed and it is computationally
>
> "self-managed"
fixed
> ---
>
> §6.5:
>
>> The control plane between two hosts is terminated using a secure two
>> message exchange as specified in base exchange specification
>
> "two-message"
fixed
> ---
>
> §7:
>
>> control plane, protected by asymmetric key cryptography. Also, S-RTP
>> has been considered as the data encapsulation protocol [hip-srtp].
>
> "SRTP" rather than "S-RTP".
fixed
> ---
>
> §8:
>
>> Besides this "native" NAT traversal mode for HIP, other NAT traversal
>> mechanisms have been successfully utilized, such as Teredo
>> [varjonen-split].
>
> Please cite RFC 4380 for "Teredo." e.g.:
>
> Besides this "native" NAT traversal mode for HIP, other NAT traversal
> mechanisms have been successfully utilized, such as Teredo [RFC4380],
> as described in [varjonen-split].
changed this to:
such as Teredo [RFC4380]
(as described in further detail in [varjonen-split]).
> ---
>
> §8:
>
>> can map to a single IP address on a
