Subject: successful termination?

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Apr 2009 22:37:36 +0200

Folks,

As you may have noticed, all three base Shim6 documents have now been 
approved after extensive edits from IESG reviews. This is obviously a 
very happy outcome even if it took a long time. Thank you everyone who 
was involved in making this happen!

Last week I when I met the chairs and lead authors I asked what they 
believe should happen next. A lively discussion followed about the 
status of the technology, the WG, and its few remaining WG documents. 
But our main conclusion was that the working group participants should 
tell us what they have in mind.

Here's a couple of different alternatives:

1. Declare success and close the WG. The most important work now is 
implementation, testing, and deployments. The WG is not needed at this 
moment, and if it will later be needed, it is easy to create a 
maintenance WG. Or if a new effort for some bigger new piece of 
functionality is needed, the proper way to do that is through a BOF 
anyway. Question: how many implementations exist? Which ones are worked 
on actively? Is there any deployment or trial experience to report?

2. Put the WG into sleep for a year or two, and return when there's 
additional experience.

3. Work on the most important one(s) of the remaining WG documents 
(locator-pair-selection, api, applicability). Which one? Is there energy 
to do the work, including WG participants doing reviews, commenting on 
issues, etc?

4. Do something else that is important for Shim6. What?

We would like to move forward with this in a couple of weeks. The WG 
will either be closed or rechartered. Let us know if you are interested 
and if so, what you believe should be done.

Jari

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Apr 2009 13:55:19 -0700

In my opinion, there are two rational outcomes. One is to close the  
working group pending deployment reports, and recharter to address  
issues that arise in that deployment. The other is the locator pair  
issue, which should IMHO be conjoined with the RFC 3484 update ongoing  
in 6man. I would ask 6man to pick up the locator pair question.

On Apr 2, 2009, at 1:37 PM, Jari Arkko wrote:

> Folks,
>
> As you may have noticed, all three base Shim6 documents have now  
> been approved after extensive edits from IESG reviews. This is  
> obviously a very happy outcome even if it took a long time. Thank  
> you everyone who was involved in making this happen!
>
> status of the technology, the WG, and its few remaining WG  
> documents. But our main conclusion was that the working group  
> participants should tell us what they have in mind.
>
> implementation, testing, and deployments. The WG is not needed at  
> this moment, and if it will later be needed, it is easy to create a  
> anyway. Question: how many implementations exist? Which ones are  
> worked on actively? Is there any deployment or trial experience to  
> report?
>
> (locator-pair-selection, api, applicability). Which one? Is there  
> energy to do the work, including WG participants doing reviews,  
> commenting on issues, etc?
>
> will either be closed or rechartered. Let us know if you are  
> interested and if so, what you believe should be done.
>
> Jari
>
>

---

From: Geoff Huston <[email-masked]>
Date: Fri, 3 Apr 2009 08:37:14 +1100

> interested and if so, what you believe should be done.

 From my notes of that meeting with the AD I have:

There were the following drafts that are still WG documents at this  
stage:

- the outstanding applicability draft (draft-ietf-shim6- 
applicability-03.txt)

- the locator pair selection draft (draft-ietf-shim6-locator-pair- 
selection-04.txt)

- the API draft (draft-ietf-shim6-multihome-shim-api-07.txt)

There may be work on Illitsch's proposal to perform a faster algorithm  
in the failure detection / reachability area (he had a draft on this I  
recall)

There were areas about ULP / SHIM signalling to allow greater levels  
of control in an instance of a ULP and greater levels of feedback from  
the SHIM layer.

There appears to be interest in multipath TCP, andf the possible  
coupling of multipath TCP to Shim6

There was interest in proxy shim6 and a draft on the topic (draft- 
nordmark-shim6-esd-01.txt)

I must point out that the past two years has been spent largely  
waiting for the documents to clear the IESG, and the lack of work in  
this WG in the interim was due to a decision to await these core  
documents to be cleared through the IESG before picking up more work.

So if there is interst in picking up this work now, it would be good  
to hear from intersted individuals in response to Jari's call.

thanks,

   Geoff

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Apr 2009 08:01:52 +0200

Geoff,

> - the outstanding applicability draft 
> (draft-ietf-shim6-applicability-03.txt)
>
> - the locator pair selection draft 
> (draft-ietf-shim6-locator-pair-selection-04.txt)
>

Right.

> coupling of multipath TCP to Shim6

My understanding is that there are folks interested in pursuing 
multipath TCP, but they will have their own BOF, probably in Stockholm.

> There was interest in proxy shim6 and a draft on the topic 
> (draft-nordmark-shim6-esd-01.txt)

Right.

> documents to be cleared through the IESG before picking up more work.

Indeed.

> to hear from intersted individuals in response to Jari's call.

Yes.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Apr 2009 22:14:58 +0200

Thanks -- this was very useful input.

Jari

Olivier Bonaventure wrote:
> Jari,
> As you know, Sébastien Barré has written an implementation of shim6 that
> is fairly complete and integrated in the Linux kernel. If there are
> other implementations being developped, it would be interesting to do
> interoperability tests among them to check that all implementors have
> interpreted the shim6 specifications in the same manner.
>
> Concerning the additional work that could be useful to pursue the
> development of shim6, I would suggest the following :
>
> - document the issues in supporting shim6 in firewalls. shim6 creates
> new challenges for firewall vendors and documenting them would be useful
>
> - network operators have argued that one drawback of shim6 from their
> point of view is that host-based multihoming gives fewer tools for
> network operators to engineer their network. I would say that operators
> can have *different* tools to engineer their network. The solution being
> developped within the ALTO WG could serve as a basis for a technique to
> allow operators to influence the selection of the addresses by hosts in
> order to traffic engineer their network. This could be considered as an
> extension of the locator-pair-selection work
>
> - another possibility could be to look at the interactions between shim6
> and multiple tcp which have been discussed recently
>
>
> Olivier
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Apr 2009 15:06:57 -0700

On Apr 3, 2009, at 12:42 PM, Olivier Bonaventure wrote:

> Fred,
>> working group pending deployment reports,
>
> See http://tools.ietf.org/html/draft-barre-shim6-impl-02
> for a detailed implementation report about Linshim6
>
>> and recharter to address issues that arise in that deployment.
>
> We have mainly used this implementation in lab environment. If readers
> of this list are willing to deploy this implementation, we would be  
> very
> interested in participating in the tests.

That's pretty common for protocols in development. What I am  
suggesting is that the working group reconvene when there is  
operational deployment and issues resulting from it.

>> The other is the locator pair
> I think that alto could play an interesting role for shim6 as well,
> although I'm not sure that this fits entirely in the restricted alto  
> charter

My line of reasoning is similarity of objectives. Shim6 would like the  
originating system to know what address pair to use, knowing that a  
choice of address pair at some level determines a route - ingress  
filtering may result in traffic loss if the wrong source address is  
used, and the RTT through one path is different than another.

A case in point that one of the shim6 chairs will recall was discussed  
on the IAB perhaps a decade ago. At my request, he simulated the  
effect of alternative address pair choices by pinging two different  
addresses in Singapore from his office in Canberra. One route was  
relatively direct and had an RTT on the order of 80 ms; the other  
route went via the US west coast, and had an RTT on the order of 600  
ms. Assuming those were two addresses for the same server (they  
weren't, but that's another discussion), choice of address pair would  
have dramatic effects on the service as perceived by the user. And as  
it turns out, the lower RTT path isn't necessarily the path through  
the shortest number of AS's or etc. a list of rules based on prefix  
matching has value but isn't the final result.

3484bis would like to know how to select a source address given a  
destination address. If there is only one destination address, that is  
exactly the same problem, and if there are multiple destination  
addresses, it only addresses part of the problem.

So I would like, under whatever aegis, for the two efforts to  
cooperate or merge.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Apr 2009 13:58:33 +1200

Jari,

If I look at both Geoff's and Olivier's (relayed) comments,
it's clear to me that there is work to be done.

I agree that the address-pair selection issue is broader
than just shim6 (and is related to other things, such as
egress router selection). But there may still be some work
do here, on 'SHIM6 Requirements for Address Pair Selection',
even if the actual specification belongs in 6MAN.

I agree that there is commonality of interest with multipath
transport, but it's far from clear to me that there is
actual overlap in the mechanisms; SHIM6 is a layer 3 shim,
and multipath transport sure seems like a layer 4 shim,
which was a direction that MULTI6 explicitly choose not to
follow up.

That said, it's clear that the union of Geoff's and Olivier's
messages add up to a program of work, basically to find out if
SHIM6 is deployable and useful. I think it would be a shame
to pause before doing that.

  Brian

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 4 Apr 2009 21:53:24 -0700

> which was a direction that MULTI6 explicitly choose not to

I wondered how to interpret the phrase "actual overlap" in the above...
yes one solution works at transport and the other works at layer 3, so  
yes in terms of layers they are not at the same place.
But in terms of goals, would you agree that their goals overlap?

> to pause before doing that.

to see if I got it right: are you suggesting that we should first  
"find out if SHIM6 is deployable and useful", before making the  
decision on whether the WG should go dormant?

if so, how does one go about to find that out?
no matter how, I suppose this could be done quick?

Lixia

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Apr 2009 09:14:26 +1200

Hi Lixia,

> But in terms of goals, would you agree that their goals overlap?

Sort of. But the shim6 goals were clearly aimed at RFC3582,
whereas I understand the goals of multipath transport to be
more aimed at load sharing, with failover as a secondary effect.
However, the mechanisms are so different that I don't see anything
to gain by sticking them in the same room at the IETF.

> to see if I got it right: are you suggesting that we should first "find
> out if SHIM6 is deployable and useful", before making the decision on
> whether the WG should go dormant?

No, I'm suggesting we should recharter the WG now, with the items
that Geoff and Olivier describe, most of which speak to making
shim6 (more) useful. Actual deployment work items would fall
under v6ops, I suppose.

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 05 Apr 2009 17:50:07 -0400

Actually, there is one reason for possibly sticking shim6 and 
multi-pathing in the same room for a little while.  (Not for making them 
the same working group.)
As currently defined, shim6 will hide from multi-pathing the very 
information and control it wants.  This seems counter-productive.  A bit 
of cooperation ought to allow us to find a way to have the two bettter 
co-exist.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Apr 2009 10:12:10 +1200

Joel,

I thought about that, but forgot to mention it. Thanks for the
reminder.

The same issue arises for SCTP. That's discussed
in draft-ietf-shim6-applicability section 5.3, which could
be expanded appropriately. And the SHIM_DONTSHIM option
in draft-ietf-shim6-multihome-shim-api probably solves the problem.

Of course, a more intimate blending of layers 3 and 4 might
be more optimal, but that seems like a research issue at the
moment.

   Brian

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Apr 2009 14:30:54 +0300

You've sent a lot of good input. How do the people who have not said 
anything yet feel? Please speak up!

Jari

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 6 Apr 2009 23:03:45 -0700

> to gain by sticking them in the same room at the IETF.

Personally I see both having a goal of utilizing multiple paths,  
whether one at a time or multiple in parallel (isn't the former a  
special case of the later).
I would not make load sharing and failover as two necessarily  
separated issues. I believe the two are closely related to each other.  
For example multipath-TCP detect path failures through its  
simultaneous transmission over multiple paths, and conversely this  
simultaneous transmission over multiple paths makes its performance  
less dependent on prompt detection of the failure of any single path.
(And I have not mentioned the benefit of utilizing TCP's built-in  
feedback look for failure detection instead of pure overhead probing  
packets...)

Lixia

---

From: Thomas Narten <[email-masked]>
Date: Tue, 07 Apr 2009 11:42:27 -0400

> anything yet feel? Please speak up!

While there may be work that would be nice to have, is there actual
energy to do that work? I worry about that aspect.

Thomas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 07 Apr 2009 16:40:49 +0200

Hi Brian,

a couple of comments.

Brian E Carpenter escribió:
> egress router selection).
note that shim6 need to do both ULID pair selection and locator pair
selection (after a failure) and maybe the selection is different for
these cases (the typical example is that when used in conjunction with
MIPv6, probably the CoA is better as a locator  while the HoA is better
as a ULID. OTOH, maybe in general the option is not so different.

In the scope of 6man, they select an address pair that will play both
roles, so the criteria for selection maybe potentially different.

>  But there may still be some work
I think the story here is something like this.
Suppose we want to do multipath TCP.
One option is to do it a la SCTP, where the MPTCP exchanges all the
alternative addresses and includes different source dest address pairs
to select the different paths.
Now, the point that can be made is that shim6 already handles the
locator pair management which is far from trivial, espcially when
considering the security issues. So, why not let MPTCP to leverage on
shim6 do do the locator pair management and let the MPTCP to actually
decide which segments to send through each locator pair?

I mean, we can use a comibation of the shim6 API plus the forking
capabiltiies and maybe some new extension so that the MPTCP is not aware
of the actual address pairs, but knows that the underlying shim6 layer
has path diversity. So MPTCP simply will add some tags to state that
some segments should fly over one path and some other segments though an
alternative path.
So, in this case, each layer does what i does best. Shim6 handles the
multiple locator pairs, while MPTCP distribute the segments through the
different pahts based on congestion.

Makes sense?

If so, then we may need to do some work so that both mechanisms interact
reasonably.

> to pause before doing that.
agree

Regards, marcelo

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 10 Apr 2009 18:14:46 +0200

Tracking the RRG list, shim6 crops up quite often and often seems little
understood, or understood as it was rather than as it is.

So, I think it important that there is an obvious place for queries and issues
to be raised as and when needed, even if there has not been much evidence of
that so far, and this I see as an argument for keeping this list open, and
keeping it alive.

Yes, lack of group energy is a counter-argument.

Tom Petch

---

From: Thomas Narten <[email-masked]>
Date: Tue, 7 Apr 2009 11:42:27 -0400

Thomas

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Apr 2009 16:42:48 +1200

(catching up)

> If so, then we may need to do some work so that both mechanisms interact

Yes. It sounds like a more developed API is needed, so that MPTCP can
use what shim6 and LEAP have already discovered. That's different from
SCTP, where we just want to switch shim6 off.

    Brian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 29 Apr 2009 19:40:02 -0700

Dear all -

I apologize for getting involved in this interesting discussion only
now.  A few late comments from my side regarding the potential
continuation of the Shim6 working group:

In my opinion, this discussion has shown that there would be useful work
to do for a continued Shim6 working group.  In particular Marcelo's
proposal to evolve Shim6 as a locator-pair-providing substrate for
multi-path TCP is a very good idea.  One may even go a step further and
provide a similar service also for UDP-based applications.

A second potential future work topic is adding capabilities for network-
controlled traffic engineering to Shim6.  The (host-based) Six/One
protocol [1] could serve as a starting point for this.  Erik Nordmark,
too, had had ideas [2] for network-controlled traffic engineering.

[1] http://tools.ietf.org/html/draft-vogt-rrg-six-one-01
[2] http://tools.ietf.org/html/draft-nordmark-shim6-esd-01

A third potential future work topic is deployment facilitators for
Shim6.  This would include, in particular, a network-based variant of
Shim6, which would have at least the following two benefits:  First, it
could aid Shim6 adoption during the phase when (host-based) Shim6 is not
yet widely deployed.  Second, it would provide an option to keep multi-
homing control in the network, a feature that some network operators
apparently prefer as the discussion in early RRG days had shown.

One approach to design a network-based Shim6 variant would be to build
on Proxy Shim6 [3].  An alternative approach could be to build on
(network-based) Six/One Router [4].  As for the latter, it might be
possible to borrow techniques developed elsewhere in IETF:  As you may
know, the recently discussed NAT66 proposal is identical to Six/One
Router when used on only one side of a connection.  What is missing is
support for reverse translation when Six/One Router is used on both
sides of a connection, plus a distribution system for address mappings.
Support for reverse translation could be specified as an extension to
NAT66. Support for mapping distribution could be done as in Proxy Shim6.

[3] http://tools.ietf.org/html/draft-bagnulo-pshim6-02
[4] http://christianvogt.mailup.net/pub/2008/vogt-2008-six-one-router-design.pdf

- Christian

Delivery-date: Thu, 30 Apr 2009 02:42:24 +0000
Cc: Jari Arkko <[email-masked]>
From: Christian Vogt <[email-masked]>
To: shim6 <[email-masked]>, [email-masked]
Subject: Re: successful termination?
Date: Wed, 29 Apr 2009 19:40:02 -0700

Dear all -

I apologize for getting involved in this interesting discussion only
now.  A few late comments from my side regarding the potential
continuation of the Shim6 working group:

In my opinion, this discussion has shown that there would be useful work
to do for a continued Shim6 working group.  In particular Marcelo's
proposal to evolve Shim6 as a locator-pair-providing substrate for
multi-path TCP is a very good idea.  One may even go a step further and
provide a similar service also for UDP-based applications.

A second potential future work topic is adding capabilities for network-
controlled traffic engineering to Shim6.  The (host-based) Six/One
protocol [1] could serve as a starting point for this.  Erik Nordmark,
too, had had ideas [2] for network-controlled traffic engineering.

[1] http://tools.ietf.org/html/draft-vogt-rrg-six-one-01
[2] http://tools.ietf.org/html/draft-nordmark-shim6-esd-01

A third potential future work topic is deployment facilitators for
Shim6.  This would include, in particular, a network-based variant of
Shim6, which would have at least the following two benefits:  First, it
could aid Shim6 adoption during the phase when (host-based) Shim6 is not
yet widely deployed.  Second, it would provide an option to keep multi-
homing control in the network, a feature that some network operators
apparently prefer as the discussion in early RRG days had shown.

One approach to design a network-based Shim6 variant would be to build
on Proxy Shim6 [3].  An alternative approach could be to build on
(network-based) Six/One Router [4].  As for the latter, it might be
possible to borrow techniques developed elsewhere in IETF:  As you may
know, the recently discussed NAT66 proposal is identical to Six/One
Router when used on only one side of a connection.  What is missing is
support for reverse translation when Six/One Router is used on both
sides of a connection, plus a distribution system for address mappings.
Support for reverse translation could be specified as an extension to
NAT66. Support for mapping distribution could be done as in Proxy Shim6.

[3] http://tools.ietf.org/html/draft-bagnulo-pshim6-02
[4] http://christianvogt.mailup.net/pub/2008/vogt-2008-six-one-router-design.pdf

- Christian

Delivery-date: Tue, 21 Apr 2009 04:45:01 +0000
Date: Tue, 21 Apr 2009 16:42:48 +1200
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: marcelo bagnulo braun <[email-masked]>
CC: Jari Arkko <[email-masked]>, shim6 <[email-masked]>
Subject: Re: successful termination?

(catching up)

On 2009-04-08 02:40, marcelo bagnulo braun wrote:
> Hi Brian,
>=20
> a couple of comments.
>=20
> Brian E Carpenter escribi=C3=B3:
>> Jari,
>>
> MIPv6, probably the CoA is better as a locator  while the HoA is better=

>=20
>=20
>>  =20
>=20
> capabiltiies and maybe some new extension so that the MPTCP is not awar=
e
> some segments should fly over one path and some other segments though a=
n
> multiple locator pairs, while MPTCP distribute the segments through the=

>=20
>=20
> If so, then we may need to do some work so that both mechanisms interac=
t

    Brian
>=20
>=20
>>  =20
>=20
>=20
>=20

Delivery-date: Sun, 12 Apr 2009 21:25:30 +0000
Cc: John Ronan <[email-masked]>
From: Geoff Huston <[email-masked]>
To: shim6 <[email-masked]>
Subject: Shom6 Implementation report
Date: Mon, 13 Apr 2009 07:23:33 +1000

Due to some strange behaviour of the shim6 mail list manager John =20
Ronan <[email-masked]> was unable to send the following to the shim6 =20=

list

Geoff

Begin forwarded message:

> From: John Ronan <[email-masked]>
> Date: 12 April 2009 7:27:16 PM

> Hi
>
> The text of what I send was as follows
> --
> Hi,
>
> Recently TSSG has been doing some work based around the Shim6 =20
> protocol (in the FP7 Efipsans http://www.efipsans.org/ Project). The =20=

> Shim6 implementation used is S=E9bastien Barr=E9's LinShim6.
> The latest version of which is always available at the LinShim6 =
(http://inl.info.ucl.ac.be/LinShim6=20
> ) home page.
>
> We have taken a bare set-up we have been using in the lab, and made =20=

> a Ubuntu Live CD with it.
>
> It is available at http://scott.tssg.org/shim6/ and I've submitted =20
> it to the Sixxs BitTorrent Tracker.
>
> Also, TSSG has a dual-homed shim6 enabled machine =
(http://shim6.lab.tssg.org=20
> ) out on the Internet for anyone to test against.
>
> Regards
> John

Delivery-date: Sun, 12 Apr 2009 03:03:00 +0000
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: successful termination?
Date: Tue, 7 Apr 2009 11:42:27 -0400
From: Thomas Narten <[email-masked]>

Thomas

Delivery-date: Fri, 10 Apr 2009 17:52:54 +0000
Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "shim6" <[email-masked]>
Subject: Re: successful termination?
Date: Fri, 10 Apr 2009 18:14:46 +0200

Tom Petch

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "shim6" <[email-masked]>
Sent: Monday, April 06, 2009 1:30 PM
Subject: Re: successful termination?

> anything yet feel? Please speak up!

Delivery-date: Wed, 08 Apr 2009 12:55:31 +0000
Date: Tue, 07 Apr 2009 16:40:49 +0200
From: marcelo bagnulo braun <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: Jari Arkko <[email-masked]>, shim6 <[email-masked]>
Subject: Re: successful termination?

Hi Brian,

a couple of comments.

Makes sense?

agree

Regards, marcelo

>   Brian

Envelope-to: [email-masked]
Delivery-date: Tue, 07 Apr 2009 15:44:25 +0000
Message-Id: <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: shim6 <[email-masked]>
Subject: Re: successful termination?
Date: Tue, 07 Apr 2009 11:42:27 -0400
From: Thomas Narten <[email-masked]>

Thomas

Delivery-date: Tue, 07 Apr 2009 06:06:02 +0000
Cc: shim6 <[email-masked]>
From: Lixia Zhang <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Subject: Re: successful termination?
Date: Mon, 6 Apr 2009 23:03:45 -0700

Lixia

Delivery-date: Mon, 06 Apr 2009 12:16:14 +0000
Date: Mon, 06 Apr 2009 14:30:54 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: Re: successful termination?

Jari

Delivery-date: Sun, 05 Apr 2009 22:20:28 +0000
Date: Mon, 06 Apr 2009 10:12:10 +1200
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: "Joel M. Halpern" <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Handling multipath [Re: successful termination?]

Joel,

   Brian

>>> no matter how, I suppose this could be done quick?

Delivery-date: Sun, 05 Apr 2009 21:59:07 +0000
Date: Sun, 05 Apr 2009 17:50:07 -0400
From: "Joel M. Halpern" <[email-masked]>
To: Brian E Carpenter <[email-masked]>
CC: Lixia Zhang <[email-masked]>, shim6 <[email-masked]>
Subject: Re: successful termination?

Yours,
Joel

>> no matter how, I suppose this could be done quick?

Delivery-date: Sun, 05 Apr 2009 21:34:08 +0000
Date: Mon, 06 Apr 2009 09:14:26 +1200
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: Lixia Zhang <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: successful termination?

Hi Lixia,

   Brian

> no matter how, I suppose this could be done quick?

Delivery-date: Sun, 05 Apr 2009 05:03:07 +0000
Cc: shim6 <[email-masked]>
From: Lixia Zhang <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Subject: Re: successful termination?
Date: Sat, 4 Apr 2009 21:53:24 -0700

Lixia

Delivery-date: Sun, 05 Apr 2009 02:09:32 +0000
Date: Sun, 05 Apr 2009 13:58:33 +1200
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: Jari Arkko <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: successful termination?

Jari,

  Brian

Delivery-date: Fri, 03 Apr 2009 22:08:01 +0000
Cc: Jari Arkko <[email-masked]>, shim6 <[email-masked]>, [email-masked]
From: Fred Baker <[email-masked]>
To: [email-masked]
Subject: Re: successful termination?
Date: Fri, 3 Apr 2009 15:06:57 -0700

Delivery-date: Fri, 03 Apr 2009 20:16:24 +0000
Date: Fri, 03 Apr 2009 22:14:58 +0200
From: Jari Arkko <[email-masked]>
To: [email-masked]
CC: shim6 <[email-masked]>, =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
Subject: Re: successful termination?

Jari

Olivier Bonaventure wrote:
> As you know, S�bastien Barr� has written an implementation of shim6 that

Delivery-date: Fri, 03 Apr 2009 06:29:10 +0000
Date: Fri, 03 Apr 2009 08:01:52 +0200
From: Jari Arkko <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: shim6 <[email-masked]>, [email-masked]
Subject: Re: successful termination? Or interest in resumption of the work?

Geoff,

Right.

Right.

Indeed.

Yes.

Jari

Delivery-date: Thu, 02 Apr 2009 21:37:56 +0000
Cc: shim6 <[email-masked]>, [email-masked]
From: Geoff Huston <[email-masked]>
To: Jari Arkko <[email-masked]>
Subject: Re: successful termination? Or interest in resumption of the work?
Date: Fri, 3 Apr 2009 08:37:14 +1100

thanks,

   Geoff

Delivery-date: Thu, 02 Apr 2009 20:56:01 +0000
Cc: shim6 <[email-masked]>, [email-masked]
From: Fred Baker <[email-masked]>
To: Jari Arkko <[email-masked]>
Subject: Re: successful termination?
Date: Thu, 2 Apr 2009 13:55:19 -0700

> interested and if so, what you believe should be done.

Delivery-date: Thu, 02 Apr 2009 20:39:40 +0000
Date: Thu, 02 Apr 2009 22:37:36 +0200
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>, [email-masked]
Subject: successful termination?

Folks,

Jari