* Multi6 application referral issues, Erik Nordmark (submitted by Kurt Erik Lindqvist)

     - Background is to do scalable multihoming for IPv6. Dumping the
       problem into the routing system will not be scalable.

     - Site connected to multiple ISPs. Each ISP will provide a prefix.

     - Keep the IPv6 socket API stable. The API will be fed something
       that will look like a 128-bit IPv6 address.

     - The Design-team have been looking at a shim-layer. The problem
       remain the same no matter at what layer we introduce the shim.

     - Possible solution approaches

       Do nothing

       Only worry about the problem during connection establishment;
       Choose a working locator pair

       Introduce multiple locators and a sub-layer in the stack which
       will make transport communication survive by being able to

    - Implications, the application will only see a
      128-quantifier. The identifier. Called ULID

    - The ULID could be one of the locators, or it could be something
      that isn't reachable. Key point is not if the ULID is actually
      reachable, but weather we need multiple ULIDs.

    - Likely outcome: A new identifier name-space would either take a
      long time to deploy (registry, fees etc) OR use the DNS AAAA and
      PTR records. The last implies a hierarchical name-space, i.e
      managed.

    - Good news is that this does not change the API. getnameinfo does
      not change. DNS lookups remains the same.

    - Possible approaches, instead of using lists of addresses, use
      FQDN. But that is not a universal solution. Use a single IP
      address. Looking for feedback.

    - ??: There are changes to how IPv6 address are represented in a
      URI.

    - Ted Hardie: Question from a higher-level perspective what is the target
      for multihoming. From an application perspective, if there is
      not difference between two identifiers, they are working,
      reachable, the applications should not care which one it
      picks. It's when they are not the same the application needs to
      able to pick one of them.

    - Erik: What we have looked at is when one ID fails. The
      application should not have to care, that is up to lower-layers
      to handle and present a stable view to the application.

    - Brian Carpenter: There is an analogy to a problem we already
      have. If you have one IPv4 and Ipv6 address for a single
      name. Which one should you use? If you want to do referral in a
      p2p application you don't really know which to pick or
      send. Multi6 is not a new problem, the same problem occurs
      otherwise as well. Multi6 might be pushing the problem. We still
      don't know what will happen in the multi6 WG, but this is the
      most likely path forward, and the applications will have to deal
      with it.

    - There might be a need for a new socket API call to return the
      set of locators for the local and remote end.

    - Dave Crocker: Have spent sometime on this topic for both
      multihoming and mobility. Listening to this I am not clear what
      problem this solves for applications. Applications are the users
      of this layer and service. How could multi6 make decisions for
      what the application layer needs.

    - Erik: We are using divide and concur and I am here to get this
      feedback.

    - Dave Crocker: Applications only want higher reliability of the
      underlying layers.

    - ??: You might want to look at higher level APIs.

    - Ted Hardie: Is there a fundamental assumption that because A and
      B can setup communication with one set of source locators, A and
      C can use the same source locators. That might not the be the
      case when VPNs are in use. How do I know this and verify this.

    - ??: Do you want to tackle this at the application or the
      Internet layer. The application really only needs one address to
      bind to.

    - Eliot: The teams really need to work together. There are several
      approaches and we don't really know which way we are going. We
      need to do engineering decisions.

    - ??: What is the differences to HIP?

    - Erik: ...

    - ??: The scope of the application protocol that deals with

    - Pekka Nikkander: We had a workshop on Saturday, and concluded
      that there is a need for a layer where

    - Christian Huitema: I am always amazed when we get something that
      is supposed to make it simpler. This does not makes thing
      simpler.

    - ERik: multi6 does not make life simpler

    - Christian: There are two types of applications, does that don't
      care about addresses at all and use APIs. And those that do, and
      they already know how to handle multiple addresses. The
      applications already have their own "shim layer".

    - John Klensin: I usually try to avoid death-at-11 talks. We are
      where we are because the hour glass is as it is. Apps make a
      call and magic happens. If we move into a world where we say
      that the apps needs to understand the topology, we are moving to
      where this goes somewhere else. We are asking more of the
      applications than they can. If this is the request we will kill
      Ipv6.

    - Erik: No one is asking this of apps. We are trying to avoid this.

    - John: But you are asking the apps to eventually handles various
      identifiers.

    - Pete Resnick: Yes, there are many apps that handle their own
      shim, but there are also quite a few that do this with breaking
      the connection. Johns warnings has to be heeded.

brabson entered the room.
ggm: tomorrow, 9am, this room, second session Wednesday
ggm: Scott does blue sheet fascism
ggm: please send presentation materials to Scott H to get into proceedings
ggm: Open Mike.
ggm: Chris Newman draft on 'comparator' in i8n. do once, not every app doing different approaches. came out of IMAP-EXT, sort/thread. want to generalize
ggm: eg use in SIEVE, WEBDAV, w3c protocols
ggm: seeking review from community, naming conventions. looking for volunteer from SIEVE/WEBDAV communities to do detailed reviews, make sure useful
ggm: Juta? puts hand up from SIEVE.
ggm: could be useful offline, cache information, label collation, implementation in client matching label, can use offline.
ggm: [yet another unnamed person] I'll read it.
ggm: Scott. doing i8n comparisons, not addressing topic, going to point to this.
ggm: [q] Chinese/Taiwanese comparators?
ggm: John K remind me, I will get into this can of worms
ggm: idea is to keep abstraction, refer to UNICODE/ISO stuff
resnick: (I think he offered to find people to get into this can of worms. ;)
ggm: John K. have problem with email addresses. want names LHS to be IDN. (in LHS@RHS) efforts to do this got lost in the weeds.
ggm: from standpoint of more extreme ends of i8n community, the differing Chinese stuff, wg process was too chaotic, s/n noise bad, deterministic pronouncements from people with opinions but no knowledge too high. to avoid that problem, do something more focused, with people with expertise., Paul Hoffman started ML process to get proposal to IETF. seemed to work for while, but also collapsed due to differences on how to do this. same people couldn't participate for similar problems which killed IDN.
ggm: in process of thrashing, looking for quick/good fix to exit. not finding any. but community is going to move to non-interop proposals of their own. either inside or outside of IETF
ggm: r[?Larry Masinter? ] report on URI revision issues. v6 link local addresses, going to spin off separate draft
ggm: drafts being proposed, Paul H simpler, radically different. want discussion. schemes from 1738, URI schemes seeking to obsolete the document, 6-7 drafts on schemes, in different states of discussion. would benefit from review. discussion on updating mailto: for i8n
ggm: all drafts individual submissions. draft hoffman, draft hansen. need webpage to point to them.
ggm: [?] implementation survey?
ggm: larry discussion on URI list generally from people with experience. eg found ftp: URI not following draft
ggm: Paul Hoffman. apps area list active enough to use?
ggm: is there apps area web page? better holder of gang of URIs for a while?
ggm: Scott. me? apps ML for discussion. need to promote. Ted and I are in some discussions about website
ggm: Larry; take individ. submissions being watched by AD, or think are subject to IETF review but not in WG, list them there.
ggm: Paull H I will send mail about URI schemes.
ggm: Scott its moderated list.
brabson left the room.
resnick left the room (Disconnected).
ggm: Scott no more to talk about? Blue sheets
ggm: done.