Skip to main content

Using the Host Identity Protocol with Legacy Applications
draft-ietf-hip-applications-04

Yes

(Jari Arkko)
(Mark Townsley)

No Objection

(Cullen Jennings)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

Abstain

(Lisa Dusseault)

Recuse

(David Ward)

Note: This ballot was opened for revision 04 and is now closed.

Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Lars Eggert Former IESG member
(was No Objection) Yes
Yes (2007-06-05) Unknown
Section 3.1., paragraph 3:
>    There are a number of ways that HIP could be used in such a scenario.

  I'd be good to discuss that at least the "opportunistic" and "use DNS
  to map IP to HI" ways can incur additional delays compared to using
  plain IP: For opportunistic HIP, you don't know if the other guy
  speaks HIP, so you need to wait for a while before you can be
  reasonably sure no I2 will come in anymore. The DNS adds some
  roundtrips for the lookups.


Section 3.2., paragraph 1:
>    If host identifiers are bound to domain names (with a trusted DNS)
>    the following are possible:

  A third option would be to temporarily cache the HITs returned with a
  DNS lookup, indexed by the IP addresses returned in the same entry,
  and pass the IP addresses up to the application as usual. If an
  application connects to one of those IP addresses within a short time
  after the lookup, initiate a base exchange using the cached HITs. The
  benefit is that this removes the uncertainty/delay associated with
  opportunistic HIP, because you know the peer speaks HIP.
Mark Townsley Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection (2007-06-04) Unknown
While this discusses altering the results from DNS lookups to support
HIP, it doesn't go into the details of whether this is done via one of
the typical OS APIs in use or via a customized DNS server or some
combination.  An interesting issue is that certain high-performance
server applications (typically email and web servers) bypass the
OS-provided DNS APIs and perform DNS lookups directly.  This is
necessary because some OS DNS implementations do not support multiple
lookups in progress at the same time.  So how these mechanisms work
may vary by the application.  There is also the question of applications
which have not yet been upgraded to support IPv6 APIs and the impact
this has on these techniques.  Consider these things to think about if
a revision is made which goes into more technical depth.
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection (2007-06-06) Unknown
It would be useful to define either in the Abstract or in the Introduction what is meant by 'legacy applications' in this document (i.e. applications that are not HIP aware running in a HIP-aware system)
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection (2007-06-06) Unknown
I support Lisa's comment.  If this has not received apps area review it should.

Good document.
Tim Polk Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
(was Discuss) Abstain
Abstain () Unknown

                            
David Ward Former IESG member
Recuse
Recuse () Unknown