Subject: RE: [Sip] Outbound-05: Editorial comments

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 7 Nov 2006 08:48:48 +0100

Hi, 

>If you're only interested in chapter 8 (and you're probably 
>not alone), wouldn't it make more sense if the STUN, 
>keep-alive usage were described in a separate draft?

Well, that is what I proposed before, when commenting outbound-04. 

But, the decission that seems to have been made at some meeting was to
keep it in the outbound draft. And I can live with that, as long as it
is clearly separated from the outbound mechanism, which I don't think it
is - eventhough the addition of chapter 8 IS a good improvement from
outbound-04.

Regards,

Christer

> ----- Original Message -----
> From: "Christer Holmberg (JO/LMF)" <[email-masked]>
> To: "Rohan Mahy" <[email-masked]>
> Cc: <[email-masked]>; "Rohan Mahy" <[email-masked]>
> Sent: Monday, November 06, 2006 5:58 PM
> Subject: RE: [Sip] Outbound-05: Editorial comments
> 
> 
> 
> Hi Rohan,
> 
> Without commenting individual replies you gave, my main issue 
> is that I
> want to be able to use STUN keep-alive without having to implement/use
> outbound, and I want that to be clear in the spec.
> 
> So, if I only want to implement STUN keep-alive, and read chapter 8, I
> shouldn't have read or implement outbound, and I think that should be
> clearly indicated in the spec.
> 
> Regards,
> 
> Christer
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:[email-masked]] 
> > Sent: 4. marraskuuta 2006 1:17
> > To: Christer Holmberg (JO/LMF)
> > Cc: [email-masked]; Rohan Mahy
> > Subject: Re: [Sip] Outbound-05: Editorial comments
> > 
> > Hi Christer,
> > 
> > Comments inline.
> > 
> > On 10/30/06, Christer Holmberg (JO/LMF) 
> > <[email-masked]> wrote:
> > >
> > > Hi,
> > >
> > > Some editorial comments on outbound-05:
> > >
> > > Abstract:
> > > ---------
> > >
> > > Instead of:
> > >
> > > "It also defines keep alive behaviors needed to keep NAT 
> > bindings open"
> > >
> > > ...I propose that we should say something like:
> > >
> > > "It also defines how SIP implements the STUN keepalive usage 
> > > [reference]"
> > 
> > I-D/RFC formatting guidelines prohibit references in the Abstract.
> > 
> > > Introduction:
> > > -------------
> > >
> > > Instead of:
> > >
> > > "The key idea of this specification"
> > >
> > > ...I propose that we should say something like:
> > >
> > > "The key idea of the outbound mechanism defined in this 
> > specification"
> > >
> > > Because, the are two key ideas in the spec: the outbound 
> > mechanism and 
> > > the STUN keepalive for SIP.
> > 
> > No, the key idea in this specification is about 
> > oubound-initiated flows.  STUN is a detail specified in a 
> > single chapter.
> > 
> > > Instead of:
> > >
> > > "This mechanism also uses a keep alive mechanism over 
> each flow so 
> > > that the UA can detect when a flow has failed."
> > >
> > > ...I propose that we should say something like:
> > >
> > > "This specification also defines how SIP implements the 
> > STUN keepalive 
> > > usage. The keepalive mechanism is used by outbound to keep NAT 
> > > bindings, and to allow the UA to detect when a flow has 
> failed. The 
> > > keepalive mechanism can also be used as a stand-alone 
> function, or 
> > > together with other SIP extensions".
> > 
> > I am fine with your first two sentences.
> > 
> > 
> > > Chapter 3.5:
> > > ------------
> > >
> > > Instead of:
> > >
> > > "This specification describes using STUN 
> > [I-D.ietf-behave-rfc3489bis] 
> > > over the same flow as the SIP traffic to perform the keepalive."
> > >
> > > ...I propose that we should say something like:
> > >
> > > "This specification describes the usage of the STUN 
> keepalive usage 
> > > [I-D.ietf-behave-rfc3489bis] over the same flow as the SIP 
> > traffic to 
> > > perform the keepalive. The SIP implementation of the STUN 
> keepalive 
> > > usage is described in chapter 8 of this specification."
> > 
> > This change just seems to add extra bulk to the spec.  I 
> > don't see how this makes anything clearer.
> > 
> > > Chapter 8:
> > > ----------
> > >
> > > In generel I think this chapter is good, but I don't think 
> > we should 
> > > talk about "flows" here, becuase the chapter is not part of 
> > outbound 
> > > itself (I also still strongly think that we should define a 
> > flag which 
> > > can be inserted in Path/Service-Route, but that issue is 
> > discussed in 
> > > another thread).
> > >
> > > So, I think it would be enough to say something like:
> > >
> > > "The STUN messages can be used to verify that 
> connectivity is still 
> > > available, and to provide periodic keepalives in order to 
> keep NAT 
> > > bindings open.
> > >
> > > ...and:
> > >
> > > "A SIP node MUST NOT send STUN requests unless it has an explicit 
> > > indication that the target next hop SIP server claims to 
> > support STUN."
> > 
> > All the text in this section was put there to satisfy 
> > someone.  We had consensus on the list to go forward with the 
> > proposal I described with respect to STUN.  I believe this 
> > section accurately expresses that consensus and the email I 
> > sent out describing what I would do.
> > 
> > thanks,
> > -rohan
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip