Subject: Re: WG review of proto and failure-detection documents
From: Geoff Huston <[email-masked]>
To: Marshall Eubanks <[email-masked]>
Cc: [email-masked]
Date: Tue, 31 Jan 2006 07:13:18 +1100

Thanks indeed Marshall - This is really appreciated, as I'd like to get 
this draft moving through the process and without some reviewers at this 
stage the process is stalled.

this is really appreciated

   Geoff

At 10:14 PM 30/01/2006, Marshall Eubanks wrote:
>I would be glad to review draft-ietf-shim6-proto-03.txt
>
>However, due to the length of this document and other constraints on
>my time, I estimate
>it would take order 2 weeks at a minimum. Also, it would take the
>nature more of a review from an interested
>outsider, as I have mostly lurked on this list.
>
>Regards
>Marshall
>
>On Jan 30, 2006, at 5:37 AM, Geoff Huston wrote:
>
>>Speaking of postings that have had minimal response, I'll also
>>repeat my call
>>for reviews of the following two documents below.
>>
>>Is there anyone willing to undertake to review these documents ?
>>
>>please?
>>
>>thanks,
>>
>>    Geoff
>>
>>
>>
>>With my co-chair hat on I'd like to encourage all WG members to
>>carefully review
>>draft-ietf-shim6-proto-03.txt and draft-ietf-shim6-failure- detection-03.txt
>>
>>These documents are now relatively mature and it would be
>>appreciated if we
>>could reach the point of a WG Last Call in the next couple of weeks.
>>
>>My concern is that I've seen no comments on the mailing list so far
>>on either
>>of these drafts, and while it would be tempting to reach the
>>conclusion that the
>>documents are sufficiently ready that no comment has been necessary, I
>>suspect that in fact few folk have been able to review the
>>documents so far.
>>
>>So could I ask WG members to please read and comment on these
>>documents so we
>>can get to a WG Last Call in a couple of weeks from now?
>>
>>many thanks,
>>
>>   Geoff
>>
>>
>

Delivery-date: Mon, 30 Jan 2006 11:14:36 +0000
Cc: [email-masked]
From: Marshall Eubanks <[email-masked]>
Subject: Re: WG review of proto and failure-detection documents
Date: Mon, 30 Jan 2006 06:14:01 -0500
To: Geoff Huston <[email-masked]>

I would be glad to review draft-ietf-shim6-proto-03.txt

However, due to the length of this document and other constraints on  
my time, I estimate
it would take order 2 weeks at a minimum. Also, it would take the  
nature more of a review from an interested
outsider, as I have mostly lurked on this list.

Regards
Marshall

On Jan 30, 2006, at 5:37 AM, Geoff Huston wrote:

> Speaking of postings that have had minimal response, I'll also  
> repeat my call
> for reviews of the following two documents below.
>
> Is there anyone willing to undertake to review these documents ?
>
> please?
>
> thanks,
>
>    Geoff
>
>
>
> With my co-chair hat on I'd like to encourage all WG members to  
> carefully review
> draft-ietf-shim6-proto-03.txt and draft-ietf-shim6-failure- 
> detection-03.txt
>
> These documents are now relatively mature and it would be  
> appreciated if we
> could reach the point of a WG Last Call in the next couple of weeks.
>
> My concern is that I've seen no comments on the mailing list so far  
> on either
> of these drafts, and while it would be tempting to reach the  
> conclusion that the
> documents are sufficiently ready that no comment has been necessary, I
> suspect that in fact few folk have been able to review the  
> documents so far.
>
> So could I ask WG members to please read and comment on these  
> documents so we
> can get to a WG Last Call in a couple of weeks from now?
>
> many thanks,
>
>   Geoff
>
>
>

Delivery-date: Mon, 30 Jan 2006 10:37:28 +0000
Date: Mon, 30 Jan 2006 21:37:14 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: WG review of proto and failure-detection documents

Speaking of postings that have had minimal response, I'll also repeat my call
for reviews of the following two documents below.

Is there anyone willing to undertake to review these documents ?

please?

thanks,

    Geoff

With my co-chair hat on I'd like to encourage all WG members to carefully 
review
draft-ietf-shim6-proto-03.txt and draft-ietf-shim6-failure-detection-03.txt

These documents are now relatively mature and it would be appreciated if we
could reach the point of a WG Last Call in the next couple of weeks.

My concern is that I've seen no comments on the mailing list so far on either
of these drafts, and while it would be tempting to reach the conclusion 
that the
documents are sufficiently ready that no comment has been necessary, I
suspect that in fact few folk have been able to review the documents so far.

So could I ask WG members to please read and comment on these documents so we
can get to a WG Last Call in a couple of weeks from now?

many thanks,

   Geoff

Delivery-date: Mon, 30 Jan 2006 10:35:36 +0000
Date: Mon, 30 Jan 2006 21:34:20 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: SHIM6 meting at  IETF65
Cc: [email-masked]

Hi,

We've had no response at all to this call for agenda items that was posted 
to the working group on Jan 20.

So lets try again  ---  are there any agenda items for the SHIM6 meeting at 
IETF 65?

regards,

    Geoff & Kurtis,

===============================

Hi,

  Its time to start thinking about SHIM6 agenda items for the next IETF 
meeting. Please forward any SHIM6 agenda items you might have to Kurtis and 
myself

We'd be interested in potential areas of extension of the base shim6 
protocol set, as well as ideas on the form of API interface for SHIM6.

regards,

  Kurtis & Geoff

Delivery-date: Sun, 29 Jan 2006 03:00:59 +0000
Date: Sun, 29 Jan 2006 09:07:53 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Fwd: Internet-Drafts Submission Cutoff Dates for the 65th IETF Meeting in Dallas, TX, USA 

>There are two (2) Internet-Draft cutoff dates for the 65th
>IETF Meeting in Dallas, TX, USA:
>
>February 27th: Cutoff Date for Initial (i.e., version -00)
>Internet-Draft Submissions
>
>All initial Internet-Drafts (version -00) must be submitted by Monday,
>February 27th at 9:00 AM ET. As always, all initial submissions with a
>filename beginning with "draft-ietf" must be approved by the
>appropriate WG Chair before they can be processed or announced.  The
>Secretariat would appreciate receiving WG Chair approval by Monday,
>February 20th at 9:00 AM ET.
>
>March 6th: Cutoff Date for Revised (i.e., version -01 and higher)
>Internet-Draft Submissions
>
>All revised Internet-Drafts (version -01 and higher) must be submitted
>by Monday, March 6th at 9:00 AM ET.
>
>Initial and revised Internet-Drafts received after their respective
>cutoff dates will not be made available in the Internet-Drafts
>directory or announced until on or after Monday, March 20th at 9:00
>AM ET, when Internet-Draft posting resumes.  Please do not wait until
>the last minute to submit.
>
>Thank you for your understanding and cooperation. If you have any
>questions or concerns, then please send a message to
>[email-masked].
>
>The IETF Secretariat
>
>FYI: The Internet-Draft cutoff dates as well as other significant dates
>for the 65th IETF Meeting can be found at 
>http://www.ietf.org/meetings/cutoff_dates_65.html.

Geoff

Delivery-date: Fri, 20 Jan 2006 06:09:55 +0000
Date: Fri, 20 Jan 2006 17:07:58 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: SHIM6 meting at  IETF65
Cc: [email-masked]

Hi,

  Its time to start thinking about SHIM6 agenda items for the next IETF 
meeting. Please forward any SHIM6 agenda items you might have to Kurtis and 
myself

We'd be interested in potential areas of extension of the base shim6 
protocol set, as well as ideas on the form of API interface for SHIM6.

regards,

  Kurtis & Geoff

Delivery-date: Tue, 17 Jan 2006 06:29:01 +0000
Date: Tue, 17 Jan 2006 16:22:41 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Review comments on draft-ietf-shim6-failure-detection-03.txt

With my WG Chair hat OFF, i'd like to offer some comments on the failure 
detection draft

Overall I found this to be a clear specification  - I have two comments / 
queries on the draft

1. Exploration termination

    Its clear that once you get bidirectional probe messages being 
exchanged the exploration algorithm terminates sucessfully with new locators.

    But what condition sets a no viable locator found state?

    Section 6.4 includes the comment that garbage collection on contexts 
terminates contexts that
    have failed due to the inability of the exploration process to find a 
working pair.

     section 5.3 is unclear as to termination - all I see is the text: 
"retrying the process as is necessary"

   Is there a termination condition for exploration?

2.  Probe timing

    What is the timing base for sending probe packets? I note that 5.3 
indicates that successive probe packets should undertake exponential 
backoff, but is there a start timer interval for probe packets?

     It seems to me that a relatively short initial timer can be used, and 
the exponential backoff  would extend this to longer inter-probe timings 
pretty rapidly.

    On a related note, is there a suggested maximum inter-probe time? At 
what point would exponential backoff not be applied any further?

Also the side note section 6.4 uses the term "happy" - is this a 
measureable  term? ;-)

regards,

    Geoff

Delivery-date: Mon, 16 Jan 2006 21:38:08 +0000
Date: Tue, 17 Jan 2006 08:37:55 +1100
To: "Spencer Dawkins" <[email-masked]>, <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt

In response to your query (and Erik can correct me if I'm wrong) It is my 
understanding in the specification that whenever the ULID pair is used as 
the locator pair then the SHIM6 extension header (the context value) is 
omitted from the packet. This allies to the initial contact pahse, and also 
in any subsequent time when the SHIM selects the ULID pair as the current 
locator pair.

i.e. it is my understanding that the packet header is simply an implicit 
"please perform an address substitution" instruction to the other end, and 
the locator pair plus the context value identifies the particular 
substitution to a ULID pair that the remote end should perform. If the 
locators are the ULID then no substitution is necessary, and no extension 
header is necessary.

At least thats the way I interpret the specification, and I was wondering 
if this should be explicitly stated in the spec.

regards,

Geoff

At 02:49 AM 17/01/2006, Spencer Dawkins wrote:
>I'm sorry, I misunderstood - I thought the comment was about whether to 
>continue encapsulating if we switch the ULID pair back to the original 
>pair or not; you are talking about the more basic decision whether to 
>switch the ULID pair back to the original pair or not.
>
>Thanks,
>
>Spencer
>
>----- Original Message ----- From: "Pierre Baume" <[email-masked]>
>To: "Spencer Dawkins" <[email-masked]>
>Cc: <[email-masked]>
>Sent: Monday, January 16, 2006 8:50 AM
>Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
>
>
>Hi Spencer,
>
>  Sorry for being vague. Better wording is welcome.
>
>  A combination of the following criteria (or more) could be used to
>choose the best ULID pair.
>
>- Processing time,
>- Bandwidth utilisation,
>- Financial cost,
>- Latency,
>- Reliability,
>- Etc.
>
>  My point was that, after a failure is fixed, the initial ULID pair
>might not be the best pair anymore.
>
>Pierre.
>
>
>On 1/16/06, Spencer Dawkins <[email-masked]> wrote:
>>
>>I'm not sure what the "costs" are in this statement. Are we just saying that
>>we're balancing the processing time to figure out that we no longer have to
>>encapsulate against the encapsulation overhead? or are you thinking of
>>something else?
>>
>>Spencer
>>
>>----- Original Message -----
>>From: Pierre Baume
>>To: Geoff Huston
>>Cc: [email-masked] ; [email-masked] ; [email-masked]
>>Sent: Monday, January 16, 2006 2:55 AM
>>Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
>>
>>Hi Geoff and all,
>>
>>On 1/16/06, Geoff Huston <[email-masked]> wrote:
>>[...]
>>
>> > 9 - section 11 - Sending ULP payloads
>> >
>> > As a meta consideration here, is there any logical reason to prefer the
>> > initial ULIDs as locators?
>>
>>   For what it's worth, I don't think that this belongs within the protocol.
>>The protocol should make it possible (maybe via a negotiation), but the
>>decision needs to be left to the hosts (and their parameters/options). They
>>might want it in some cases and in some cases not. It depends on the 'costs'
>>associated with the ULID pairs.
>>
>>Pierre.
>
>
>
>

Delivery-date: Mon, 16 Jan 2006 21:35:28 +0000
Date: Tue, 17 Jan 2006 08:33:47 +1100
To: Pierre Baume <[email-masked]>, Spencer Dawkins <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
Cc: [email-masked]

this illustrates the difference between explicit locator preferences and 
the lack of locator prefs.

If the ULP (application actually) has a demand for particular path 
characteristics then, in the context of this base specification, the 
interaction between the  SHIM6 and the ULP would be for the ULP to request 
a forked context and then request the active locator set from the SHIM, and 
then (by setting a NO SHIM flag in the API) probe the locator pairs and 
discover their path  characteristics according to the ULP's preferences - 
then communicate the relative preferences back tot he SHIM using an 
explicit preference signalling to the SHIM.

But my comment was, as I noted in the mail to Spencer - in the _absence_ of 
any preference indicators, then is the ULID a "preferred" locator over 
other locators?

Geoff

At 01:50 AM 17/01/2006, Pierre Baume wrote:
>Hi Spencer,
>
>   Sorry for being vague. Better wording is welcome.
>
>   A combination of the following criteria (or more) could be used to
>choose the best ULID pair.
>
>- Processing time,
>- Bandwidth utilisation,
>- Financial cost,
>- Latency,
>- Reliability,
>- Etc.
>
>   My point was that, after a failure is fixed, the initial ULID pair
>might not be the best pair anymore.
>
>Pierre.
>
>
>On 1/16/06, Spencer Dawkins <[email-masked]> wrote:
> >
> > I'm not sure what the "costs" are in this statement. Are we just saying 
> that
> > we're balancing the processing time to figure out that we no longer have to
> > encapsulate against the encapsulation overhead? or are you thinking of
> > something else?
> >
> > Spencer
> >
> > ----- Original Message -----
> > From: Pierre Baume
> > To: Geoff Huston
> > Cc: [email-masked] ; [email-masked] ; [email-masked]
> > Sent: Monday, January 16, 2006 2:55 AM
> > Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
> >
> > Hi Geoff and all,
> >
> > On 1/16/06, Geoff Huston <[email-masked]> wrote:
> > [...]
> >
> > > 9 - section 11 - Sending ULP payloads
> > >
> > > As a meta consideration here, is there any logical reason to prefer the
> > > initial ULIDs as locators?
> >
> >   For what it's worth, I don't think that this belongs within the protocol.
> > The protocol should make it possible (maybe via a negotiation), but the
> > decision needs to be left to the hosts (and their parameters/options). They
> > might want it in some cases and in some cases not. It depends on the 
> 'costs'
> > associated with the ULID pairs.
> >
> > Pierre.
> >

Delivery-date: Mon, 16 Jan 2006 21:35:19 +0000
Date: Tue, 17 Jan 2006 08:29:59 +1100
To: "Spencer Dawkins" <[email-masked]>, <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt

Yes Spencer, I was indeed thinking about the additional packet overhead of 
the shim6 header and the additional processing overhead in the hosts, and 
the slightly higher overhead in processing any associated ICMP messages.

i.e. it _could_ be that "all other things being equal in terms of locator 
preference" the ULID  locator pair, if viable, should be considered as the 
highest pref locataor pair"

Alternatively, it could be an implementation matter and, as is the case in 
this draft, a matter left unstated in the specification (and left as an 
implementation decision).

regards,

   Geoff

At 12:37 AM 17/01/2006, Spencer Dawkins wrote:
>I'm not sure what the "costs" are in this statement. Are we just saying 
>that we're balancing the processing time to figure out that we no longer 
>have to encapsulate against the encapsulation overhead? or are you 
>thinking of something else?
>
>Spencer
>----- Original Message -----
>From: <mailto:[email-masked]>Pierre Baume
>To: <mailto:[email-masked]>Geoff Huston
>Cc: <mailto:[email-masked]>[email-masked] ; 
><mailto:[email-masked]>[email-masked] ; 
><mailto:[email-masked]>[email-masked]
>Sent: Monday, January 16, 2006 2:55 AM
>Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
>
>Hi Geoff and all,
>
>On 1/16/06, Geoff Huston <<mailto:[email-masked]>[email-masked]> wrote:
>[...]
>
> > 9 - section 11 - Sending ULP payloads
> >
> > As a meta consideration here, is there any logical reason to prefer the
> > initial ULIDs as locators?
>
>   For what it's worth, I don't think that this belongs within the 
> protocol. The protocol should make it possible (maybe via a negotiation), 
> but the decision needs to be left to the hosts (and their 
> parameters/options). They might want it in some cases and in some cases 
> not. It depends on the 'costs' associated with the ULID pairs.
>
>Pierre.

Delivery-date: Mon, 16 Jan 2006 15:51:12 +0000
From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
Date: Mon, 16 Jan 2006 09:49:19 -0600

I'm sorry, I misunderstood - I thought the comment was about whether to 
continue encapsulating if we switch the ULID pair back to the original pair 
or not; you are talking about the more basic decision whether to switch the 
ULID pair back to the original pair or not.

Thanks,

Spencer

----- Original Message ----- 
From: "Pierre Baume" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 16, 2006 8:50 AM
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt

Hi Spencer,

  Sorry for being vague. Better wording is welcome.

  A combination of the following criteria (or more) could be used to
choose the best ULID pair.

- Processing time,
- Bandwidth utilisation,
- Financial cost,
- Latency,
- Reliability,
- Etc.

  My point was that, after a failure is fixed, the initial ULID pair
might not be the best pair anymore.

Pierre.

On 1/16/06, Spencer Dawkins <[email-masked]> wrote:
>
> I'm not sure what the "costs" are in this statement. Are we just saying 
> that
> we're balancing the processing time to figure out that we no longer have 
> to
> encapsulate against the encapsulation overhead? or are you thinking of
> something else?
>
> Spencer
>
> ----- Original Message -----
> From: Pierre Baume
> To: Geoff Huston
> Cc: [email-masked] ; [email-masked] ; [email-masked]
> Sent: Monday, January 16, 2006 2:55 AM
> Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
>
> Hi Geoff and all,
>
> On 1/16/06, Geoff Huston <[email-masked]> wrote:
> [...]
>
> > 9 - section 11 - Sending ULP payloads
> >
> > As a meta consideration here, is there any logical reason to prefer the
> > initial ULIDs as locators?
>
>   For what it's worth, I don't think that this belongs within the 
> protocol.
> The protocol should make it possible (maybe via a negotiation), but the
> decision needs to be left to the hosts (and their parameters/options). 
> They
> might want it in some cases and in some cases not. It depends on the 
> 'costs'
> associated with the ULID pairs.
>
> Pierre.
>

Delivery-date: Mon, 16 Jan 2006 14:50:37 +0000
Date: Mon, 16 Jan 2006 15:50:09 +0100
From: Pierre Baume <[email-masked]>
To: Spencer Dawkins <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
Cc: [email-masked]

Hi Spencer,

  Sorry for being vague. Better wording is welcome.

  A combination of the following criteria (or more) could be used to
choose the best ULID pair.

- Processing time,
- Bandwidth utilisation,
- Financial cost,
- Latency,
- Reliability,
- Etc.

  My point was that, after a failure is fixed, the initial ULID pair
might not be the best pair anymore.

Pierre.

On 1/16/06, Spencer Dawkins <[email-masked]> wrote:
>
> I'm not sure what the "costs" are in this statement. Are we just saying t=
hat
> we're balancing the processing time to figure out that we no longer have =
to
> encapsulate against the encapsulation overhead? or are you thinking of
> something else?
>
> Spencer
>
> ----- Original Message -----
> From: Pierre Baume
> To: Geoff Huston
> Cc: [email-masked] ; [email-masked] ; [email-masked]
> Sent: Monday, January 16, 2006 2:55 AM
> Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
>
> Hi Geoff and all,
>
> On 1/16/06, Geoff Huston <[email-masked]> wrote:
> [...]
>
> > 9 - section 11 - Sending ULP payloads
> >
> > As a meta consideration here, is there any logical reason to prefer the
> > initial ULIDs as locators?
>
>   For what it's worth, I don't think that this belongs within the protoco=
l.
> The protocol should make it possible (maybe via a negotiation), but the
> decision needs to be left to the hosts (and their parameters/options). Th=
ey
> might want it in some cases and in some cases not. It depends on the 'cos=
ts'
> associated with the ULID pairs.
>
> Pierre.
>

Delivery-date: Mon, 16 Jan 2006 13:39:15 +0000
From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
Date: Mon, 16 Jan 2006 07:37:24 -0600

This is a multi-part message in MIME format.

------=_NextPart_000_19AB_01C61A6F.B16276B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm not sure what the "costs" are in this statement. Are we just saying =
that we're balancing the processing time to figure out that we no longer =
have to encapsulate against the encapsulation overhead? or are you =
thinking of something else?

Spencer
  ----- Original Message -----=20
  From: Pierre Baume=20
  To: Geoff Huston=20
  Cc: [email-masked] ; [email-masked] ; [email-masked]=20
  Sent: Monday, January 16, 2006 2:55 AM
  Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt

  Hi Geoff and all,

  On 1/16/06, Geoff Huston <[email-masked]> wrote:
  [...]

  > 9 - section 11 - Sending ULP payloads=20
  >=20
  > As a meta consideration here, is there any logical reason to prefer =
the
  > initial ULIDs as locators?

    For what it's worth, I don't think that this belongs within the =
protocol. The protocol should make it possible (maybe via a =
negotiation), but the decision needs to be left to the hosts (and their =
parameters/options). They might want it in some cases and in some cases =
not. It depends on the 'costs' associated with the ULID pairs.=20

  Pierre.

------=_NextPart_000_19AB_01C61A6F.B16276B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I'm not sure what the "costs" are in =
this=20
statement. Are we just saying that we're balancing the processing time =
to figure=20
out that we no longer have to encapsulate against the encapsulation =
overhead? or=20
are you thinking of something else?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Spencer</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[email-masked] href=3D"mailto:[email-masked]">Pierre =
Baume</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">Geoff Huston</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> ; <A =
title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> ; <A=20
  title=[email-masked]=20
  href=3D"mailto:[email-masked]">[email-masked]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, January 16, 2006 =
2:55=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Review comments on =

  draft-ietf-shim6-proto-03.txt</DIV>
  <DIV><BR></DIV>Hi Geoff and all,<BR><BR>On 1/16/06, Geoff Huston =
&lt;<A=20
  onclick=3D"return top.js.OpenExtLink(window,event,this)"=20
  href=3D"mailto:[email-masked]" target=3D_blank>[email-masked]</A>&gt;=20
  wrote:<BR>[...]<BR><BR>&gt; 9 - section 11 - Sending ULP payloads =
<BR>&gt;=20
  <BR>&gt; As a meta consideration here, is there any logical reason to =
prefer=20
  the<BR>&gt; initial ULIDs as locators?<BR><BR>&nbsp; For what it's =
worth, I=20
  don't think that this belongs within the protocol. The protocol should =
make it=20
  possible (maybe via a negotiation), but the decision needs to be left =
to the=20
  hosts (and their parameters/options). They might want it in some cases =
and in=20
  some cases not. It depends on the 'costs' associated with the ULID =
pairs.=20
  <BR><BR>Pierre.<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_19AB_01C61A6F.B16276B0--

Delivery-date: Mon, 16 Jan 2006 08:56:39 +0000
Date: Mon, 16 Jan 2006 09:55:48 +0100
From: Pierre Baume <[email-masked]>
To: Geoff Huston <[email-masked]>
Subject: Re: Review comments on draft-ietf-shim6-proto-03.txt
Cc: [email-masked], [email-masked], [email-masked]

------=_Part_15518_8648628.1137401748630
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Geoff and all,

On 1/16/06, Geoff Huston <[email-masked]> wrote:
[...]

> 9 - section 11 - Sending ULP payloads
>
> It is implied by the text here that if SHIM6 context reestablished use of
> the initial locator pair as the current locators (ie. start with ULID =3D
> locators, switch to new locators and then switch back to original ULID =
=3D
> locator) then no packet transforms as specified in section 11.1 are
> required. Should this be called out in the text?
>
> As a meta consideration here, is there any logical reason to prefer the
> initial ULIDs as locators?

  For what it's worth, I don't think that this belongs within the protocol.
The protocol should make it possible (maybe via a negotiation), but the
decision needs to be left to the hosts (and their parameters/options). They
might want it in some cases and in some cases not. It depends on the 'costs=
'
associated with the ULID pairs.

Pierre.

------=_Part_15518_8648628.1137401748630
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Geoff and all,<br><br>On 1/16/06, Geoff Huston &lt;<a href=3D"mailto:gih=
@apnic.net" target=3D"_blank" onclick=3D"return top.js.OpenExtLink(window,e=
vent,this)">[email-masked]</a>&gt; wrote:<br>[...]<br><br>&gt; 9 - section 1=
1 - Sending ULP payloads
<br>&gt; <br>&gt; It is implied by the text here that if SHIM6 context rees=
tablished use of
<br>&gt; the initial locator pair as the current locators (ie. start with U=
LID =3D<br>&gt; locators, switch to new locators and then switch back to or=
iginal ULID =3D<br>&gt; locator) then no packet transforms as specified in =
section=20
11.1 are<br>&gt; required. Should this be called out in the text?<br>&gt; <=
br>&gt; As a meta consideration here, is there any logical reason to prefer=
 the<br>&gt; initial ULIDs as locators?<br><br>&nbsp;
For what it's worth, I don't think that this belongs within the
protocol. The protocol should make it possible (maybe via a
negotiation), but the decision needs to be left to the hosts (and their
parameters/options). They might want it in some cases and in some cases
not. It depends on the 'costs' associated with the ULID pairs.
<br><br>Pierre.<br>

------=_Part_15518_8648628.1137401748630--

Delivery-date: Mon, 16 Jan 2006 01:45:18 +0000
Date: Mon, 16 Jan 2006 12:39:39 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Review comments on draft-ietf-shim6-proto-03.txt
Cc: [email-masked], [email-masked]

So with my WG chair hat off, I've reviewed the protocol draft 
(draft-ietf-shim6-proto-03.txt) and I have prepared a set of comments. They 
are devided into general approach comments about document and editorial nits.

In this posting I'll make a number of general comments on the draft. I'll 
send the editorial nits directly to the document authors if thats ok.

1 - Protocol Overview vs Protocol Specification

I was confused whether section 4 is a part of the actual protocol 
specification or whether it was a more general set of overview comments 
about the characteristics of the particular approach described here. What 
threw me was a number of MUSTs in section 2, which lead me th think this 
was part of the specfication, while most of the section was of a more 
discussive style.

It appears that sections 7 through 14 are the actual protocol 
specification, while section 4 is in deed a discussive section rather than 
a specification.

One way to clarify this would be to remove the RFC2460 MUSTS SHOULDs, etc 
from section 4, and use an introductory sentence to note that this is an 
informal overview of the protocol, and note that the protocol specification 
is contained in the following sections.

It may also be useful to encapsulate the current sections 7 though 14 into 
a single section 7 and call it "Protocol Specification", although this is 
more of a personal style preference.

2 - section 1.4 - Multicast

Could this be better relocated into section 16 (Implicatons Elsewhere)? 
with a single line statement in 1.2 ( Non-Goals) that IP multicast is not 
supported in Shim6?

3 - section 1.5 renumbering implications

Could this be better relocated into section 16 (Implications Elsewhere?). 
It semes a better fit there than in section 1

4 - section 1.7 Traffic Engineering

It may also be appropriate to include some considerations of traffic 
engineering in section 19, and note in section 19 some of the issues 
related to externally generated triggers for locator change and 
externally-supplied locator preferences that would allow some form of TE 
responses at a host.

5 - Section 3 - Assumptions

The assumptions note the consideration of Ingress Filtering and 
source-based path selection considerations, and appears to state the same 
assumption twice. Perhaps an appendix should include further text in the 
source address / site exit selection / path selection considerations that 
are implictly assumed in this specification. It may also be useful to 
reference some of the previous multi6 work on the issues of source address 
section / site exit router selection.

6 - Section3 - Assumptions

I suspect that we assume that there are no IPv6 NATS on the path - perhaps 
this should be explicitly stated

7 - Section 4.6 - comment on Mobile IPv6

It may make sense to explicitly call out the "for further study" comment in 
this section in section 19.

8 - Section 8 - handling ICMP error messages

It may be me, but I found this section somewaht opaque. Either a diagram or 
some further text may help in terms of understanding what transforms are to 
be applied to the ourter ICMP packet header locators and what transforms 
are to be appied to the inner packet segment that is in the payload of the 
ICMP packet.

9 - section 11 - Sending ULP payloads

It is implied by the text here that if SHIM6 context reestablished use of 
the initial locator pair as the current locators (ie. start with ULID = 
locators, switch to new locators and then switch back to original ULID = 
locator) then no packet transforms as specified in section 11.1 are 
required. Should this be called out in the text?

As a meta consideration here, is there any logical reason to prefer the 
initial ULIDs as locators?

10 - section 19 Possible protocol extensions

possible additional parts here could include:

- allowing the API to trigger a locator change as well as locator preference?

- allowing external triggers for locator preference and locator switch (TE 
related)

Delivery-date: Sun, 15 Jan 2006 20:48:35 +0000
Date: Mon, 16 Jan 2006 07:47:15 +1100
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: WG review of proto and failure-detection documents

With my co-chair hat on I'd like to encourage all WG members to carefully review 
draft-ietf-shim6-proto-03.txt and draft-ietf-shim6-failure-detection-03.txt

These documents are now relatively mature and it would be appreciated if we
could reach the point of a WG Last Call in the next couple of weeks.

My concern is that I've seen no comments on the mailing list so far on either
of these drafts, and while it would be tempting to reach the conclusion that the
documents are sufficiently ready that no comment has been necessary, I
suspect that in fact few folk have been able to review the documents so far.

So could I ask WG members to please read and comment on these documents so we 
can get to a WG Last Call in a couple of weeks from now?

many thanks,

  Geoff