Subject: Re: [ippm] 2nd WGLC for draft-ietf-ippm-twamp-07.txt

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Mon, 2 Jun 2008 10:33:02 -0700

Hi Al and authors,
	The draft addresses all of the open issues that we had apart
from enhancements that will hopefully be addressed by a subsequent
draft.
	One clarification about the SERVWAIT time.  I believe the
receipt of test packets should ONLY be covered by REFWAIT and that a
Server should be notified by the Reflector of such a timeout, so I would
change the paragraph under 3.1 

From
====
The Server MAY discontinue any established control connection when no
packet associated with that connection, AND no packet associated with
any test sessions started by that control connection have been received
for SERVWAIT seconds.

To
==
The Server MAY discontinue any established control connection when no
packet associated with that connection has been received within SERVWAIT
seconds prior to transitioning into active state.   A Stop-Sessions
packet MAY arrive at any length of time after the active state has been
entered.

The reason is that once an active state has been entered all packets
except for Stop-Sessions is to be discarded.   But inactivity before the
active state transition should result in the connection being closed.

Also, there are some minor spelling errors.

Thanks,
-Murtaza

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Henk Uijterwaal
> Sent: Friday, May 23, 2008 1:52 AM
> To: IETF IPPM WG
> Subject: [ippm] 2nd WGLC for draft-ietf-ippm-twamp-07.txt
> 
> 
> IPPM group,
> 
> This is a 2nd WGLC for the draft: draft-ietf-ippm-twamp-07.txt
> 
> During and after the first WGLC, a number of issues were 
> raised.  These
> have been addressed in this revision.   We like to start a 2nd WGLC
> in order to move the draft forward.
> 
> Please raise any remaining issues by Friday, May 6, 9:00 UTC. 
>  If you made comments during the previous WGLC, please check 
> that they have been properly addressed in the new version.
> 
> An URL for the draft is:
> 
>    http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-07.txt
> 
> 
> Matt & Henk
> 
> 
> --
> --------------------------------------------------------------
> ----------------
> Henk Uijterwaal                           Email: 
> henk.uijterwaal(at)ripe.net
> RIPE Network Coordination Centre          
> http://www.amsterdamned.org/~henk
> P.O.Box 10096          Singel 258         Phone: +31.20.5354414
> 1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
> The Netherlands        The Netherlands    Mobile: +31.6.55861746
> --------------------------------------------------------------
> ----------------
> 
> Is one of the choices leaving the office open?
>                                        Alan Greenspan on the 
> next elections _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
> 
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Al Morton <[email-masked]>
Date: Mon, 02 Jun 2008 16:56:47 -0400

Hi Murtaza,

Thanks for your review (over the weekend) and feedback.

There seems to be a problem with the spell-check in this
MSWord template - parts of the doc are not checked.
I'll try something else. Now on to the more important comment.

>change the paragraph under 3.1

I think you're trying to avoid any overlapping coverage of
SERVWAIT and REFWAIT, and I can appreciate that. Perhaps it makes
for a simpler implementation, too.  With either your proposal or the
current description in the text, the SERVWAIT process needs to
know which phase is active, control or test.  And, between the START
and STOP sessions commands, control packet monitoring for SERVWAIT
is suspended.

But if the current SERVWAIT covers problems during control or test phases,
do we really need REFWAIT?  Only if the *WAIT thresholds will be set
at different values, which I think is a reasonable possibility.

So, how about this replacement text:
The Server MAY discontinue any established control connection when no
packet associated with that connection has been received within SERVWAIT
seconds.   The Server SHALL suspend monitoring control connection activity
after receiving a Start-Sessions command, and SHALL resume after receiving a
Stop-Sessions command (IF the SERVWAIT option is supported). Note that the
REFWAIT time-out (described below) covers failures during test sessions.

Al

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Mon, 2 Jun 2008 14:06:24 -0700

That clarification works as after a Stop-Sessions command a new
Request-Session may follow in that case the SERVWAIT should be in effect
again.
 
-Murtaza

> From: Al Morton [mailto:[email-masked]] 
> Sent: Monday, June 02, 2008 1:57 PM
> To: Murtaza Chiba (mchiba); IETF IPPM WG
> Subject: Re: [ippm] 2nd WGLC for draft-ietf-ippm-twamp-07.txt
> 
> Hi Murtaza,
> 
> >Server should be notified by the Reflector of such a timeout, so I 
> >would change the paragraph under 3.1
> 
> SERVWAIT and REFWAIT, and I can appreciate that. Perhaps it 
> makes for a simpler implementation, too.  With either your 
> proposal or the current description in the text, the SERVWAIT 
> process needs to know which phase is active, control or test. 
>  And, between the START and STOP sessions commands, control 
> packet monitoring for SERVWAIT is suspended.
> 
> But if the current SERVWAIT covers problems during control or 
> test phases, do we really need REFWAIT?  Only if the *WAIT 
> thresholds will be set at different values, which I think is 
> a reasonable possibility.
> 
> The Server MAY discontinue any established control connection 
> when no packet associated with that connection has been 
> received within SERVWAIT
> after receiving a Start-Sessions command, and SHALL resume 
> after receiving a Stop-Sessions command (IF the SERVWAIT 
> option is supported). Note that the REFWAIT time-out 
> (described below) covers failures during test sessions.
> 
> Al
> 
> 
> >Server should be notified by the Reflector of such a timeout, so I 
> >would change the paragraph under 3.1
> >
> >From
> >====
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Henk Uijterwaal
> > > During and after the first WGLC, a number of issues were raised.  
> > > These
> > >  If you made comments during the previous WGLC, please check that 
> > > they have been properly addressed in the new version.
> > >
> > > An URL for the draft is:
> > >
> > >    
> > >                                        Alan Greenspan on the next 
> > > elections _______________________________________________
> > > ippm mailing list
> > > [email-masked]

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 06 Jun 2008 10:16:28 +0200

IPPM Group,

Henk Uijterwaal wrote:
> Henk Uijterwaal wrote:

>> During and after the first WGLC, a number of issues were raised.  These
> Oops, I meant: June 6, 2008.

That time has passed.

As far as I can see, there is one unanswered mail from Murtaza.  I'll
ask Al to answer that.  We'll also fix the spelling mistakes.  The
document will then be move to the IESG.

Matt & Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Is one of the choices leaving the office open?
                                       Alan Greenspan on the next elections
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm