Document: draft-ietf-hip-applications-01.txt
Reviewer: David L. Black
Review Date: 27 May 2007
IETF LC End Date: 28 May 2007
IESG Telechat date: unknown

Summary:
This draft is on the right track, but has open issues, described
in the review.

Comments:

Section 3.2 is the major open issue.  It describes two techniques:
- Use of HITs and LSIs instead of IP addresses in HIP-unaware
	applications.
- Use of a DNS name extension to cause connection via HIP (and
	presumably use of HITs and LSIs instead of IP addresses).
Both of these are problematic.

The latter technique runs into DNS extension concerns already
expressed by the IAB and the former will run into trouble in
circumstances where an IP address is expected - log files are
discussed as an example below.  There are enough concerns here,
that this section needs major work, or it needs to be replaced
by recommendations that DNS not be used in the fashion described
in this section and that HITs and LSIs not be substituted for
IP addresses in applications that aren't expecting them -
in addition to the log file example discussed below, there
are probably user interface situations where this difference
will not be transparent in a fashion that matters.

---

The third paragraph in Section 3 has a couple of problems:
- The reference to the shim6 WG is questionable.  RFCs
	live forever, WGs don't, so this sort of reference
	should not be used unless it's really needed, and
- Reference [4] appears to be a problem - this looks like
	a discussion draft (not for RFC publication) in the
	shim6 WG that expired a while ago (e.g., it's not
	in the I-D Tracker).
This doesn't seem critical to the remainder of Section 3,
so I suggest just deleting this paragraph and reference [4].

In section 3.1,  the parenthetical "(can not)" raises a
question - is the situation in which the application can
issue a HIP-specific setsockopt() or similar call, but
otherwise use the unmodified sockets API relevant here?

Section 3.2 proposes replacing the IP addresses returned to
a HIP-unaware application with HITs or LSIs.  This seems
somewhat risky, as even if the HIT or LSI is never visible
to a user, it's likely to turn up in log records, where it
will be confused with an IPv6 address.  This is effectively
a referral to the application or human that analyzes the log,
but it's a very important case (in particular it escapes
the "won't work over NATs" criticism of referrals, as log
analysis should be aware of NAT configuration).  The
potential for a HIP-unaware application writing logs that
cause HITs and LSIs to be mistaken for IP addresses needs
to be discussed.  As indicated above, display of a HIT or LSI
as an IPv6 address in a user interface may be another problem
area.

Just citing the IAB draft that has concerns about DNS name
suffixes isn't enough - those concerns should be discussed
here in the specific context of HIP (how do they apply/not
apply to HIP in particular as opposed to the draft's general
discussion?).

At the end of Section 3.2, the discussion of HIT and LSI
routability is problematic, and in particular, the notion
of a fully (potentially globally) routable LSI seems just
plain wrong.  I would just delete this paragraph, as I fail
to see the benefit of opening the lid on this Pandora's box.

idnits 2.04.07 found a couple of outdated references:

  == Outdated reference: draft-laganier-ipv6-khi has been
     published as RFC 4843

  == Outdated reference: A later version (-08) exists of
     draft-ietf-shim6-proto-07