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

Request Review of draft-ietf-hip-rfc5205-bis
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-28
Requested 2015-12-22
Authors Julien Laganier
Draft last updated 2016-01-11
Completed reviews Genart Last Call review of -08 by Jouni Korhonen (diff)
Genart Telechat review of -09 by Jouni Korhonen (diff)
Secdir Last Call review of -08 by Tina Tsou (diff)
Intdir Early review of -07 by Sheng Jiang (diff)
Intdir Early review of -07 by Zhen Cao (diff)
Opsdir Last Call review of -08 by Stefan Winter (diff)
Assignment Reviewer Stefan Winter
State Completed
Review review-ietf-hip-rfc5205-bis-08-opsdir-lc-winter-2016-01-11
Reviewed rev. 08 (document currently at 10)
Review result Has Issues
Review completed: 2016-01-11

Review
review-ietf-hip-rfc5205-bis-08-opsdir-lc-winter-2016-01-11

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