Last Call Review of draft-ietf-hip-rfc5205-bis-08
review-ietf-hip-rfc5205-bis-08-opsdir-lc-winter-2016-01-11-00

Hello,

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.

These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed
in last call may be included in AD reviews during the IESG review.
Document editors and WG chairs should treat these comments just like any
other last call comments.

Summary: Ready with issues

Major issues: none

Minor issues:

1)

Section 5.6.

I don't get it :-) This reads like there can be a list of more than one
rendezvous server in a response. So some kind of concatenation occurs.
However, reading bespoke section 3.3 of RFC1035 I only see the construct
<domain-name>, and it is *one* domain name. All sub-sections of 3.3
there also only describe RRs which contain one <domain-name>, not a list.

So, how is the actual wire format if say two RVS servers exist?

In this same section, you use the term "wire-encoded format" which does
not exist in RFC1035.

If what you mean is in one of RFC1035's numerous Updates: RFCs - maybe
it is worth citing those as the reference...

Later in section 6 it becomes clear that "whitespace" is the delimiter;
but where to find that information in RFC1035 section 3.3?

2)

Again 5.6: This construct of having an implicit ordering within one RR,
which then possibly gets invalidated if more than one RR is present,
does not sound very intuitive or useful. From an operational
perspective, it becomes impossible to select the best-available RVS
server if ordering is lost.

Other RRs have solved this with a more explicit ordering. See for
example the order/preference fields of the NAPTR RR; or more simply the
MX RR.

Removing the implicit order and potential breakup of this ordering with
an extra order or preference field in the RR would make selection of the
RVS node more deterministic.

Nits:

1)

The introduction does a good job at explaining most of the concepts
around HIP, but misses the notion of "I1". That term shows up as

"An Initiator willing to establish a HIP association with a Responder
served by an RVS would typically initiate a HIP exchange by sending an
I1 towards ..."

A reader unfamiliar with HIP (like myself) would probably appreciate
either an explanation of a reference where to look up the term "I1".

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me



http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66




Attachment:


0x8A39DC66.asc




Description:

 application/pgp-keys




Attachment:


signature.asc




Description:

 OpenPGP digital signature