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 , and it is *one* domain name. All sub-sections of 3.3 there also only describe RRs which contain one , 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