Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW

From: Randall Stewart <[email-masked]>
Date: Thu, 05 Apr 2007 11:46:30 -0400

Lars Eggert wrote:
> On 2007-3-14, at 16:33, ext Janardhan Iyengar wrote:
>> (I'm assuming we're LC'ing on -18, and not -17, as the subject suggests)
> 
> Right. There was an interim revision to address some issues.
> 
> Thanks for the review!
> 
> It looks as if we have consensus to request publication, and will do so 
> once -19 becomes available, which should address the issues people have 
> raised during the LC.
> 
> Lars
> 
> 
Lars:

Just had an offline comment.. and its valid too..
Somewhere in our editing (merging the asconf extended)
we took out the Supported Extensions Parameter.. opps.

I will add this to the things that need to be done to
clean up.. sorry about that... not sure how it was deleted.

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Lars Eggert <[email-masked]>
Date: Fri, 6 Apr 2007 11:05:24 +0300

On 2007-4-5, at 18:46, ext Randall Stewart wrote:
> Lars Eggert wrote:
>> It looks as if we have consensus to request publication, and will  
>> do so once -19 becomes available, which should address the issues  
>> people have raised during the LC.
>

Thanks for keeping on top of things.

WG: The -20 revision has just appeared; please take a quick look.  
Unless someone yells, we'll request publication next week.

Lars

---

From: <[email-masked]>
Date: Tue, 10 Apr 2007 10:37:25 -0500

Hi,

Just been reading the latest ADDIP draft and something puzzles me.  May
be I'm missing something but this bit doesn't sound right to me.  I'm
looking at section 5.2 "Upon reception of an ASCONF chunk" and in
particular rule D2-ext).  The question I have is why would we want to
scan down all the ASCONF chunks in a packet to find an association match
when surely the first chunk MUST match the current association?  I am
thinking that if the first chunk does NOT match then all subsequent
chunks must be null and void.  

After all if the first chunk was received on it's own and it didn't
match an association it would be rejected.

Sorry if I'm a bit late to the party here. :/

Ronnie
---
Ronnie Sellar			Emerson Network Power, Embedded
Computing
Tel: +44 131 475 7015		Suite 4, 2 Anderson Place
Fax: +44 131 475 7001		Edinburgh EH6 5NP
mailto:[email-masked]	http://www.artesyncp.com

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: 06 April 2007 09:05
> To: ext Randall Stewart
> Cc: [email-masked]; Randall Stewart; [email-masked]
> Subject: Re: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 
> starts NOW
> 
> >> It looks as if we have consensus to request publication, 
> and will do 
> >> so once -19 becomes available, which should address the 
> issues people 
> >> have raised during the LC.
> >
> > Somewhere in our editing (merging the asconf extended) we 
> took out the 
> > Supported Extensions Parameter.. opps.
> >
> > I will add this to the things that need to be done to clean 
> up.. sorry 
> > about that... not sure how it was deleted.
>

---

From: Peter Lei <[email-masked]>
Date: Tue, 10 Apr 2007 13:59:25 -0500

Hi Ronnie,

Consider the case where the bundling of the ASCONF chunks is for
a singly-homed endpoint which changes its address more than once.
Further, assume that the peer endpoint did in fact process the
first chunk and sent an ASCONF-ACK which gets lost somewhere in
the network.

In this case, the source address and lookup address from the
first chunk may not find an association (since it processed the
first delete address and it no longer exists in the assoc), but
the second ASCONF chunk's lookup address should (since this one
should correspond to a valid address in the assoc).

Thus, you must process through all the asconf chunks that may be
bundled together in order to do an appropriate assoc lookup.

--peter

---

From: <[email-masked]>
Date: Wed, 11 Apr 2007 02:27:13 -0500

Hi Peter,

Thanks for that explanation.  I hadn't quite got round to considering
that the first ASCONF may have already been processed.  Doh !

That clears things up.

Ronnie
---

> From: Peter Lei [mailto:[email-masked]] 
> Sent: 10 April 2007 19:59
> To: Sellar, Ronnie [ECB/EDI]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Consider the case where the bundling of the ASCONF chunks is 
> for a singly-homed endpoint which changes its address more than once.
> Further, assume that the peer endpoint did in fact process 
> the first chunk and sent an ASCONF-ACK which gets lost 
> somewhere in the network.
> 
> first chunk may not find an association (since it processed 
> the first delete address and it no longer exists in the 
> assoc), but the second ASCONF chunk's lookup address should 
> (since this one should correspond to a valid address in the assoc).
> 
> Thus, you must process through all the asconf chunks that may 
> be bundled together in order to do an appropriate assoc lookup.
> 
> --peter
> 
> > Just been reading the latest ADDIP draft and something puzzles me.  
> > May be I'm missing something but this bit doesn't sound 
> right to me.  
> > I'm looking at section 5.2 "Upon reception of an ASCONF 
> chunk" and in 
> > scan down all the ASCONF chunks in a packet to find an association 
> > match when surely the first chunk MUST match the current 
> association?  
> > I am thinking that if the first chunk does NOT match then all 
> > subsequent chunks must be null and void.
> > 
> >> Subject: Re: [Tsvwg] WGLC for 
> draft-ietf-tsvwg-addip-sctp-17 starts 
> >> NOW
> >>