Subject: Re: [Sip] draft-ietf-sip-outbound and STUN keepalives

From: Cullen Jennings <[email-masked]>
Date: Mon, 31 Jul 2006 22:59:57 -0700

Yep - I think the intention was to do as Jonathan said.

On Jul 21, 2006, at 11:19 AM, Jonathan Rosenberg wrote:

> Right. I mentioned this in the behave meeting. The idea is that  
> rfc3489bis formally defines the usage, and calls out additional  
> things that an actual protocol that uses it, would have to say.  
> Then sip-outbound says those things.
>
> -Jonathan R.
>
> Christer Holmberg (JO/LMF) wrote:
>
>> Hi Keith,
>> I am ok with the proposal.
>> In the "STUN keep-alive: Where to document it?" thread (http:// 
>> www1.ietf.org/mail-archive/web/sip/current/msg15227.html) it is  
>> discussed where different things related to STUN keep-alive should  
>> be documented. Some things MAY have to be documented in 3489bis.
>> Regards,
>> Christer
>>  -----Original Message-----
>> From: Drage, Keith (Keith) [mailto:[email-masked]] Sent: 20.  
>> heinäkuuta 2006 15:11
>> To: [email-masked]'
>> Subject: [Sip] draft-ietf-sip-outbound and STUN keepalives
>> (As WG chair)
>> Previous mails on the SIP list have expressed the view that the  
>> STUN keepalive mechanism should be documented separately as it is  
>> a useful mechanism in its own right.
>> See http://www3.ietf.org/proceedings/06jul/slides/sip-5.pdf slide  
>> 5 for the issue as raised at the IETF #66 meeting.	
>> After discussion with the editor, the WG chairs propose the  
>> following:
>> -	that the documentation on STUN keepalive will REMAIN in the  
>> outbound document, and WILL NOT be split to a separate specification;
>> -	that the STUN keepalive mechanism WILL BE separated within the  
>> outbound specification, such that it is clear that it can be  
>> implemented independently of the rest of the outbound  
>> specification, and so that the keepalive material is clearly  
>> referencable in its own right.
>> We believe that this meets the requirements of at least most of  
>> the working group, and for pragmatic reasons we want to work  
>> against more fragmentation of the SIP documentation.
>> If you have problems with this proposal and desire a different  
>> solution, then please raise your concerns to the list, or direct  
>> to the WG chairs, in response to this mail.
>> regards
>> Keith
>> Keith Drage
>> [email-masked]
>> tel: +44 1793 776249
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol Use sip- 
>> [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
>
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ  
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>
> _______________________________________________
> 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