Subject: [Hipsec] Preliminary minutes from the Monday HIP RR BOF

From: [email-masked] (Pekka Nikander)
Date: Fri Mar 5 19:25:02 2004

--Apple-Mail-18--766375674
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

Please find enclosed preliminary minutes from the
HIP RR BOF.  Basically, this contains the discussion
transcripts, the rest of the material to be added later.

Please send any corrections ASAP to me.  I haven't
had time to process all of the note taker notes yet,
so I may also make changes (mostly additions/names)
by my own.  I just wanted to get this out now so
that people may make corrections while they still
may remember what happened.  :-)

--Pekka

--Apple-Mail-18--766375674
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	x-unix-mode=0644;
	name="ietf59_hiprr_minutes.html"
Content-Disposition: attachment;
	filename=ietf59_hiprr_minutes.html

<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head>

  <title>IETF-59 HIP Releated Research BOF Summary and Minutes</title>

  <meta http-equiv="Content-Language" content="en" />
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <meta http-equiv="Content-Style-Type" content="text/css" />
  <style type="text/css">
    body {
      margin-left: 10%;
      margin-right: 10%;
      font-family: sans-serif;
      color: black;
      background: white;
    } 
    span.sc {
      color: red;
    }
    dd p {
      margin: 0;
    }
    dd ul {
      margin: 0;
    }
    dt {
      margin-top: 1em;
      margin-left: 1.5em;
    }
    p.note {
      color: green;
    }
  </style>

</head>

<body bgcolor="white" text="black">

<h1>Host Identity Protocol Related Research BOF (hiprr)</h1>

<p>These are the minutes for the Host Identity Protocol Related
Research BOF (hiprr) meeting, held at IETF-59 on Monday, March 1,
2004, at Seoul Lotte.  Thanks to Marcelo Bagnulo, Petri Jokela, Miika
Komu, Julien Lagnier, and Andrew McGregor, for the notes, on which
these minutes are based on.</p>

<div id="menu">
<ul>
  <li><a href="#decisions">Decisions made</a></li>
  <li><a href="#summary">Summary of the discussions</a></li>
  <li><a href="#details">Presentations and discussions</a></li>
</ul>
</div>

<div id="main">
<div id="decisions">
<a name="decisions"></a><h2>Decisions</h2>
<ol>
  <li>Should we continue to work on full blown non-HIP supporting proxies?
  <p>Yes.  Transition mechanisms are an important issue.</p></li>
  <li>Should we continue to work on NAT traversal?
  <p>Yes, but unclear how.  Pressure to work both on solutions that
  are friendly to current NAT boxes and on solutions that make NAT
  boxes friendly to HIP.</p></li>
  <li>Should we continue to work on the Lightweight HIP idea?
  <p>Yes (large interest).</p></li>
  <li>Should we continue to work on CELP?
  <p>Yes (some interest).</p></li>
  <li>Should we continue to work on DHT / HIP overlay / ... ideas?
  <p>Yes, but unclear where to focus</p></li>
  <li>Any additional important areas that we missed?
  <p>Applications point of view.</p></li>
</ol>
</div><!-- decisions -->

<div id="summary">
<a name="summary"></a><h2>Summary of discussions</h2>

<p class="note">This summary has been compiled by Pekka Nikander, based on the
discussion minutes, included <a href="#details">below.</a></p>

<h4>Points to pay attention to</h4>
<ul>
  <li></li>
</ul>

</div><!-- summary -->

<div id="details">
<a name="details"></a><h2>Presentations and Discussion</h2>

<h3>Research Group background and Status</h3>

<a href="XXX">Slides</a>

<p>As a continuation of the successful HIP BOF in Minneapolis and the
WG chartering discussions that followed, there is a clear need for a
research group that will study the consiquences of HIP or the ID/LOC
split in general.  However, ID / locator split major architectural
issue and the IAB wants to investigate it before making a decision.
There is hope that the discussion will be finished shortly, i.e.,
during the week In any case, there will be space for HIP research
group.  </p>

<dl>
  <dt>Dave Crocker:</dt><dd>What is going on this week about the
  id/loc split?  The plenary is often not good for resolving issues.</dd>

  <dt>Vern Paxon:</dt><dd>The IAB discussion will take place before
  the plenary, and results will then be presented there.  The plenary
  is then a place to see what the community things.</dd>
</dl>

<h3>HIP related research elsewhere</h3>

<a href="XXX">Slides</a>

<p>Pekka briefly discribed related research elswhere, including the
<a href="XXX">NewArch</a>,
<a href="http://www.ambient-networks.org">Ambient Networks</a> and
<a href="http://www.ist-daidalos.org">Daidalos</a> projects.</p>

<dl>
  <dt>Vern Paxon and others:</dt><dd>The NewArch project is done.</dd>

  <dt>Pekka Nikander:</dt><dd>Ok, but I see the work continuing.  We
  have to follow what's going on.</dd>

  <dt>Kevin Fall:</dt><dd>There has been lots of work on
  interoperability over networks that are not Internet
  networks. Separation is related to routing, there is SIGCOMM 2003 paper
  discussing the area.  The delay tolerant networking folks have been
  thinking about ID/Loc and have been doing IRTF stuff.  See
    <a href="http://www.dtnrg.org">www.dtnrg.org</a>.  [The SIGCOMM paper
  that Kevin mentioned is available through the DTN RG web
  pages.]</dd>
</dl>
 
<h3>HIP proxy / rendezvous broker</h3>

<a href="XXX">Slides</a>

<p>Lars Eggert gave a presentation related to
<a href="http://www.ietf.org/internet-drafts/draft-eggert-hip-rendezvous-00.txt">
draft-eggert-hip-rendezvous-00.txt</a>.</p>

<p>[The comments in the following discussion transcription have been
slightly reordered so that related comments are collected
together.]</p>

<dl>
  <dt>Erik Nordmark (clarifying question):</dt><dd>Why does a
  rendezvous server need to NAT, why not tunnel?</dd>

  <dt>Lars Eggert:</dt><dd>NAT is what the current architectura draft
  states.  Actually I will propose tunneling a couple of slides
  later.</dd>

  <dt>Greg Daley:</dt><dd>To me this looks like Mobile IP or like a
  VPN tunnel server endpoint.  You have a static address, like in MIP,
  which acts as the identifier.  Would it be worth comparing?</dd>

  <dt>Lars Eggert:</dt><dd>The difference really is that this kind of
  a relay is needed only if the other party does not understand
  HIP.</dd>

  <dt>Greg Daley:</dt><dd>It's the same thing with MIP. What is an
  advantage for HIP?</dd>

  <dt>Elliot Lear:</dt><dd>Could you comment differences with
  mipv6?</dd>

  <dt>Lars Eggert:</dt><dd>For the HIP-HIP case, a rendezvous can be
  anywhere, you don't need to have a fixed home network.</dd>

  <dt>James Kempf:</dt><dd>If you renumber the home network, your
  identity changes in Mobile, IP but not in HIP.</dd>

  <dt>Pekka Nikander:</dt><dd>The proposal it is very similar to MIP
  for non-HIP nodes.  On the other hand, if we consider only HIP
  hosts, there are no restrictions on where you put your rendezvous
  server, and you can have multiple rendezvous servers, even
  dynamically.</dd>

  <dt>Joe Touch:</dt><dd>Are you changing the DNS or modifying the
  entries? So the reverse lookups will be ambiguous anyway and lot of
  protocols will start failing?</dd>

  <dt>Lars Eggert:</dt><dd>There will be additional changes.</dd>

  <dt>Rob Austein (clarification):</dt><dd>You do not actually need to
  resign the entire zone if a single record is updated via DynDNS.
  You can do incremental signing.</dd>

  <dt>Miika Komu:</dt><dd> We should concentrate more on the
  HIP-to-HIP rendezvous server case.  If the peer does not understand
  HIP, we fall back to IP.</dd>

  <dt>Lars Eggert:</dt><dd>If the IP address in the DNS is the IP address
  of a randezvous server, such fallback would not work.</dd>

  <dt>Pekka Nikander:</dt><dd>We can't put the rendezvous server
  address in the DNS.  The WG must rethink this.  The WG is supposed
  to do the I1/UPDATE only rendezvous server, plus the rendezvous
  server DNS record.</dd>

  <dt>Kevin Fall:</dt><dd>The terminlogy used here seems to relate to
  I3 work.  Any comments?</dd>

  <dt>Pekka Nikander:</dt><dd>Distributed Hash Tables will come up in
  later presentations.</dd>

  <dt>Pekka Nikander (chairing):</dt><dd>Is this a topic that should
  be studied in the RG?  Or should we leave this for the WG?</dd>

  <dt>Juergen Quitteck:</dt><dd>This should be a work issue, because
  it is important to communicate hip and non hip nodes.</dd>

  <dt>Pekka Nikander (chairing):</dt><dd>There seems to be some
  interest.  I don't see any reason why we can't work on this.</dd>

</dl>

<h3>NAT problem statement</h3>

<a href="XXX">Slides</a>

<p>Juergen Quitteck gave a presentation related to
<a href="http://www.ietf.org/internet-drafts/draft-XXX-00.txt">
draft-XXX-00.txt</a>.</p>

<dl>
  <dt>Joe Touch:</dt><dd>Most of the reasons why you say NAT is bad is
  that NAT makes everything behind the network look like one host and
  this is what you don't want.  Most justifications for NAT are
  reasons for its brokenness.  Stop supporting them.</dd>

  <dt>JQ:</dt><dd>NAT is what the users do, you cannot stop them.</dd>

  <dt>PN:</dt><dd>If you do a loc/id split, NAT may become less evil,
  since you obtain stable id end-to-end.  Even if the locators are
  changed on the fly, the id is still stable.</dd>

  <dt>JQ:</dt><dd>This is not advertising nat, but to address the
  problems that NAT pose to HIP.  The point is to make HIP and NAT
  coexist.</dd>
  
  <dt>PN (clarification):</dt><dd>There are <strong>no</strong>
  problems with HIP and checksums in NAT traversal, since in HIP the
  pseudo header contains HITs, not IP addresses.</dd>

  <dt>PN (comment):</dt><dd>I'd like to mention a couple of problems
  with mobility and multihoming.  If a mobile host goes to a network
  behind a NAT, it already has an association. The NAT has to find out
  from the UPDATE packet the new address.  The SPI values is also
  problem: there may be collisions.  Should the SPIs be within or
  outside of the signature calculation?  DoS does not seem to be a
  problem.</dd>

  <dt>JQ:</dt><dd>The conflict with using same SPI can be solved with
  NATs that have more than one IP address available.</dd>

  <dt>Greg Daley:</dt><dd>99% of NATs are unmanaged, so what if they
  don't support the hip?  Stay in TCP or UDP so you don't rely on NAT
  upgrades?</dd>

  <dt>Tim Shepard:</dt><dd>I agree.  We won't get NATs upgraded.  HIP
  could be use to get IPv6 for home node behind a NAT.  Maybe even in
  such a way that v6 is never seen in core network, i.e., use 6to4.
  We can't upgrade NAts, but we can ask vendors to support 6to4. This
  seems like the right thing.</dd>

  <dt>Greg Labovitz:</dt><dd>We are a NAT implementer and we don't
  have problem changing NATs.</dd>

  <dt>Dave Crocker:</dt><dd>It is easy to get one person to do one
  thing, the problem is to get everybody to do it?<br /><br />Why did
  I stand up? Well, NATs are not a problem in the net, they are a
  problem in the IETF.  There are HIP things and then there are other
  things that HIP must cope with.  NAT is not core business for
  HIP.<br /><br /> There are couple of ways to deal with things.  If
  we wait for NAT boxes to change, we have to wait for a long long
  time.  If we don't wait, we have to manage difficult things. Thus,
  there are multiple ways to solve problems. Short term hacks will
  probably be long term (wrong way).  Hence, make the ugly thing and
  the right thing coexist.</dd>

  <dt>Pekka:</dt><dd>I'm not worried about NATs. If HIP happens there
  will be an incentive for NAT vendors to support HIP and for users to
  upgrade.  The boxes are cheap and get cheaper.<br /><br />We have to
  make a distinction between two different things:
    <ol>

       <li>compatibility with current NATs,</li>

       <li>HIP allows cross IP realm traversal, which we probably
       should not even call NAT</li>
     </ol>
  You could have multiple IP address realms and let traffic flow
  between them, while retaining the 3.5 layer end-to-end connectivity.
  We have tried to design the system to make things to work with 3.5
  routing.  The state in the layer 3.5 routers must be a soft
  state.</dd>

  <dt>Elliot Lear:</dt><dd>HIP solutions should be long term and
  problems solve in the long term ones.</dd>

  <dt>Gonzalo Camarillo:</dt><dd>You will never deploy HIP if you need
  to update NATs.  It is the same problem in SIP.  Don't require
  modifying NAT.</dd>

  <dt>Erik Nordmark:</dt><dd>Should we match HIP and NAT or decouple them
  the more possible?</dd>

  <dt>LQ:</dt><dd>The question is whether we want to make HIP more NAT
  friendly or NATs more HIP friendly.</dd>

</dl>

<h3>Lightweight HIP</h3>

<a href="XXX">Slides</a>

<p>Pekka presented an idea.  No questions or comments, but
considerable interest on working on the idea.</p>

<h3>CELP</h3>

<a href="XXX">Slides</a>

<p>Dave Croker gave a presentation related to
<a href="http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt">
draft-crocker-celp-00.txt</a>.</p>

<dl>

  <dt>Pekka (comment):</dt><dd> If we do id/locator split, we get into
  situation where we have two sets of different congestion control
  variables.  Some are related to the path and some to the flow. </dd>

  <dt>Dave:</dt><dd> I agree with you. The id-locator combination is
  both on the layer 3 and 4. This was not point of this discussion; a
  different discussion. If we solve this cleanly, it is good. </dd>
</dl>

<p>Presentation continues with security issues.</p>

<dl>

  <dt>Pekka:</dt><dd>Security issues were touched already today. If
  you do RR test using IKEv2 or MIPv6, there results are different
  from the security point of view.  A solution to this may be to add a
  a security related granularity parameter.  </dd>

  <dt>Dave:</dt><dd>We need to figure out the minimum level of
  security.  I propose naming the IP address pools with domain names,
  but this is handwaving that requires work.  One of the problems is
  that the DNS name -&gt; IP address -&gt; DNS name chain may not
  work.  There seems to be problems with operation and
  administration.</dd>

  <dt>Erik Nordmark:</dt><dd>I'm wondering about issues with a shared
  pool and multiple users. What is the key for looking up from the
  pool?  What if we have two users, (two connections), and they give a
  different key to retrieve the address from the pool?  Or if the
  users are attaching different informations to the same key?</dd>

  <dt>Dave:</dt><dd>I don't have an answer, needs more
  investigation. Multi-address parallel usage would be great.</dd>

  <dt>Pekka:</dt><dd>I have an example.  Consider using HIP and
  SCTP. HIP gets more addresses to the pool (rendezvous servers) than
  SCTP.</dd>

  <dt>Elliot Lear:</dt><dd>On the use of the domain names.  Firstly,
  there must be no circular dependencies.  Secondly, I was asked to
  write a draft for the
    <a href="http://www.ietf.org/XXX">multi6</a> WG,
    <a href="http://www.ietf.org/internet-drafts/draft-elliot-XX-01.txt">
    things to think about</a>.
  There are couple of points that are interesting.</dd>
</dl>

<p>Presentation continues.</p>

<dl>
  
  <dt>Dave (question):</dt><dd>Is this interesting? [A few few
  hands.]</dd>

  <dt>Pekka:</dt><dd>I have a gut feeling: DNS names are not going to
  work.  You dont put DNS names into the kernel.  Looks complicated.
  My personal feeling that it is a bad idea.</dd>

  <dt>Dave:</dt><dd>Your comments were mild compared to
  others. Interesting discussion.</dd>

  <dt>Andrew McGregor:</dt><dd>How to you manage the address pool in
  the DNS server??  DNS names are pronote to a dispute.</dd>

  <dt>Tim Shepard:</dt><dd>Needs cooperation from DNS admins.  This is
  a showstopper. It is hard to work on a protocol and deploy it if I
  can't use it on a network until I get cooperation form the
  administrator of the DNS.</dd>

  <dt>Dave Crocker:</dt><dd>From the CELP point of view, DNS provides
  two different services: lookup service and naming service.  We are
  not necessarily doing lookups.</dd>

  <dt>Erik Nordmark:</dt><dd>Locator pools apply, even if you
  introduce new name space.</dd>

  <dt>Dave Crocker:</dt><dd>We need an identifier space for pools.  We
  need some commonality between the users of the pool, in order for
  this to be useful.</dd>

  <dt>Kevin Fall:</dt><dd>Why not use URI space instead of FQDN?</dd>

  <dt>X:</dt><dd>you said: there should be a DB and a key. Key seems
  to be DNS names.</dd>

  <dt>Dave Crocker:</dt><dd>We need to add a few details before it is
  practical.</dd>

  <dt>xx:</dt><dd>The CELP acronym is already taken.</dd>

</dl>

<h3>Referrals problem statement</h3>

<a href="XXX">Slides</a>

<p>Pekka Nikander gave a presentation where he tried to clearly state
the referral problem but actually talked more about Distributed Hash
Tables (DHTs).  He really should not give that many presentations
during a single RG meeting.  [A note to those whose sense of irony is
limited:  remember who has compiled these minutes.]</p>

<dl>

  <dt>Joe Touch:</dt><dd>I have a little confusion here, why don't we
  want to use the DNS?</dd>

  <dt>PN:</dt><dd>The HI / HIT name space is flat.  You can't use
  DNS, as DNS requires hierarchy.</dd>

  <dt>JT:</dt><dd>Well, then, make the name space hiearchical.</dd>

  <dt>PN:</dt><dd>Earlier version of the HIP drafts contained an
  hierarchical name space as an alternative.  It was removed for the
  sake of simplicity and some other problems.  The HIP WG can
  certainly add it back if they want to.  In the Research Group side,
  though, I think that we want to explore the other
  possibilities.</dd>

  <dt>XX (from Deutche Telecom?):</dt><dd>The carriers may not want to
  use DHTs because of the amount of traffic generated.</dd>

  <dt>PN:</dt><dd>There may be a misunderstanding here.  The way I
  envision that we might use DHTs is not really P2P like, or at least
  not Napster like P2P.  It does not generate any more traffic than
  DNS.</dd>

  <dt>Rob Austein:</dt><dd>A problme with a DHT is the trust model.
  In the DNS you have somone in control of which servers you trust,
  and that is not possible in the DHT case.</dd>

  <dt>Pekka Nikander:</dt><dd>In DHT you can use several hash keys
  and several independent servers.</dd>

  <dt>Rob Austein:</dt><dd>So you must trust several strangers
  insteas of just one.</dd>

  <dt>PN:</dt><dd>The assumption is that you have a strong id check,
  so you just need enough replicas to find at least one set of valid
  data, i.e., one where the signature is valid. Remember, if we use
  DHT with HIP, we have a public key and the strong relation with HIT.
  The real problem is whether you get data back or not.  To solve
  this, you can make ten replicas or so.  This is not a perfect
  solution, there may be better ones, but is a solution.<br /><br />

  But yes, we have two problems: collusion (as I mention in the slide)
  and replay of old data.  The latter can be solved by always making
  more than one lookups, but that is bad from a performance point of
  view.</dd>

  <dt>PN:</dt><dd>So, basically, what I am saying is that we know how
  to make DHTs work in theory but not how in practice.</dd>

  <dt>Erik Nordmark:</dt><dd>Practical issues of how well it scales?
  In a large network we have many hosts joining and leaving?  We would
  have a million or more servers.  This is different if all internet
  uses this than the current DNS use or current DHT research use.</dd>

  <dt>Kevin Fall:</dt><dd>All this discussion relates to the new
  layer. Maybe i disagree on the issues on the agenda?</dd>

  <dt>Pekka Nikander:</dt><dd>We need a mechanism to get IP addresses
  from identifiers. We try to get attention from academic research.</dd>

  <dt>Kevin Fall:</dt><dd>This is distraction to the reseach group.
  There are other communities that are solving these problems.  We
  should focus on the problems that others are not solving.</dd>

  <dt>Pekka Nikander:</dt><dd>how about Erik's comments?</dd>

  <dt>Kevin Fall:</dt><dd>Research is going on but you have a
  different problem, yes.</dd>

  <dt>Thomas Henderson:</dt><dd>Any fresh ideas?</dd>

</dl>

<h3>Using any servers as rendezvous points</h3>

<a href="XXX">Slides</a>

<p>Tim Shepard described his idea of using any servers as rendezvous
servers.</p>

<dl>
  <dt>Tim Shepard:</dt><dd>About HIP rendezvous issues.  I'd like to
  have a system that doesn't use DNS at all, where end points
  recognize each other without using dns.  You just introduce each
  other once and then they know each other.  Server mobility is easy
  because the server remains fixes simultaneous movement: only one of
  the moving host has to maintain a association with the rvs
  could all hip nodes act as relays?</dd>

  <dt>Elliot Lear:</dt><dd>That was a great bar conversation. Really
  good questions.  May I disagree: it is ok to use DNS, its ok to fail
  if the resouce is not present.  First question: In simultaneous
  movement, what is the tolerable period to have stale info?  Second
  question: In moving from one location to another, how do you
  introduce the routing system, leave info in everywhere you go?</dd>

  <dt>James Kempf:</dt><dd>Two nodes moving at the same time. You lose
  the update.  When a node moves it tells the old router so that the
  traffic can flows to the new location.  So we can come up with a
  local link fixed routing protocol (for HIP, MIP...)<br /><br /> For
  VoIP, the maximum is 40 ms dropout period. This figure also works
  for HIP.  This work has not gone anywhere due to non-interest.</dd>

  <dt>Tim Shepard:</dt><dd>This is this same as Eliot mentioned.</dd>

  <dt>James Kempf:</dt><dd>Yes, approximately.  Router and node has to
  find out the movement. 40 ms is allowed, due to voip apps.</dd>

  <dt>Tim Shepard:</dt><dd>May be.  However, my basic observation is
  that if you have implemented HIP, you are only few lines [of code]
  away from a [I1-only] rendezvous server.</dd>

  <dt>Erik Nordmark:</dt><dd>If every node acts as a relay wouldn't
  this enable new attacks, is it worse tat than ipv4 today?  Consider
  open SMTP relays today. Here you have strong identity. You have to
  tell where they are coming from to get them shut up if needed. You
  can hide your IP address. If you have IP address, you can tell the ISP
  that this guy must be "closed".</dd>

  <dt>Kevin Fall:</dt><dd>This looks awfully lot like i3.  Refrasing,
  is is better to have an infra with storage capability, or is it
  better to be more active.</dd>

  <dt>Pekka Nikander:</dt><dd>This is one very good question. This is
  the third independent time that I hear I3 and HIP in same sentence.
  I am starting to wonder why</dd>

  <dt>X:</dt><dd>HIP identifiers like ethernet addresses from the
  forwarding point of view. You use the identifier only
  on the last part. Not so vulnerable.</dd>

  <dt>Tim Shepard:</dt><dd>I dont really understand the question. HIP
  ids can be proved to be owned.</dd>

  <dt>X:</dt><dd>Different thing. It is just equivalent to that
  point.</dd>

  <dt>Tim Shepard:</dt><dd>Are you saying that we should take only
  part of the HIT as the id. Possiblity of collisions gets greater. I
  don't know how to solve that.</dd>

</dl>

<h3>Open mike</h3>

<dl>

  <dt>Pekka:</dt><dd>People are working on the DHT problems elsewhere
  so we don't have to take so much effort on those things. Concentrate
  on understanding HIP effect to the Internet.</dd>

  <dt><span><a href="#stevekempf">Steve Kempf:</a></span></dt>
  <dd>What's impact on applications?</dd>

  <dt>Erik Nordmark:</dt><dd>Another thing, how IDs show up at the
  application layer. Does this change applications? Does this change
  the way to use applications?</dd>

  <dt>Pekka Nikander:</dt><dd>One of the questions is that we have an
  aulli mailing list, basically dead at the moment. Which is the right
  forum to look at application area?<br /><br />Maybe we should have a
  sub research group for application issues.  I don't know how to
  organize this kind of thing.</dd>

  <dt>Erik Nordmark:</dt><dd>Are there people in the room that
  understand application level identifiers? [No hands]</dd>

  <dt>XX:</dt><dd>This is a difficult question.</dd>

  <dt>Joe Touch:</dt><dd> I can take applications that use ip
  addressses in different ways. They will suffer from using HITs. Who
  understands apps. use of addresses?  Many bizzarre things out there.
  Is non-hip host talking to non-hip app on hip enabled device a problem?</dd>

  <dt>Erik Nordmark:</dt><dd>No idea, but does existence of HIP
  namespace change things in interesting ways?  What other kinds of
  IDs do applications use?</dd>

  <dt>XX:</dt><dd>There is also a body existing work related to these
  things. There are surveys about these issues.  Have been surveys of
  app protocol use of IP addresses.</dd>

  <dt>Keving fall:</dt><dd> Are these right things? Semantics, routing
  system, what layer routing system it relates to, hierarchical. Lot
  of things to cope with.</dd>

  <dt>Elliot Lear:</dt><dd> NSRP draft looks at some of this.  Remember
  also the draft mentioned earlier with the open questions.</dd>

  <dt>Pekka Nikander:</dt><dd>There are some answers in HIP
  architecture draft. Maybe they are not sufficient. The draft was in
  RFC Editor queue, but it is now back for editing.  Please review the
  architectural draft, needs to be stable as soon as possible.</dd>

  <dt>Pekka Nikander (chairing):</dt><dd>No more comments? Seems to be
  so that we have many of the correct problems.  The apps level
  identifiers stuff needs to thought in more detail.  We Need help
  from the apps people. </dd>
</dl>

</div>
<!-- details -->

<a name="stevekempf"></a>
<p id="stevekempf">Footnote:  I have no idea who Steve Kempf is, but
one of the note takers marked this particular speaker as "Steve"
while the other one attributed "Kempf".  The other's didn't have a
name recorded, or not even the comment recorded.</p>

</div><!-- main -->

<hr />

<div class="footer">
  <p class="validator">
  <a href="http://validator.w3.org/check/referer">
    <img src="http://www.w3.org/Icons/valid-xhtml10"
         border="0"
         alt="Valid XHTML 1.0!"
         height="31" width="88" /></a>
  </p>

  <p class="copyright">
  Copyright
  &#160;&#169;&#160; 2004 
  <a href="http://www.ietf.org">Internet Engineering Task Force</a>.
  </p>

</div>

</body>
</html>

--Apple-Mail-18--766375674--