Subject: [Sip] Making sense of the SIP author drafts

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 9 Mar 2007 15:45:54 +0100

(as WG chair)

I have been attempting to make sense of the large number of author drafts out there which in some manner impact SIP. I have three categories:

-	Bugfixes (documents which may fall into the criteria identified in draft-drage-sip-essential-correction-01)
-	SIP extensions (which need to be SIP charter items due to RFC 3427)
-	Security (all SIP security issues are normally dealt with in the SIP WG, even if INFORMATIONAL)

Plus one where I don't know where to put the document.

The lists follow, but the information I need (from the authors if noone else is)

-	does the document belong or not belong in the SIP group as a result of this analysis?
-	have I categorised this correctly?
-	have I missed any drafts that should be here?
-	for the SIP extensions is there a document out there which lists the requirements, and if so, which document is it? By this I mean a some text, totally independent of the proposed solution which:

	identifies the need for a mechanism (A mechanism is needed such that ...)
	provides requirements (The mechanism MUST/SHOULD/MAY support ...)

Note that if such text does not exist, I strongly suggest that authors of SIP extensions with RFC 3427 impact think about providing such text if they want their document to progress, or else provide a rational explanation of why it is not needed. Such text may well belong with the SIPPING group for prior discussion.

None of the above implies any commitment of the SIP WG or IETF to further the work on such drafts, but I suspect if it is not complete on my list, with the information as requested above, then nothing is going to happen with it.

Regards

Keith

--------------------------------------------------------------------------------

Author drafts - bugfixes

draft-froment-sip-record-route-fix-00 (updates RFC 3261?, or is it just a BCP?)
draft-gurbani-sip-large-udp-response-00 (updates RFC 3261)
draft-munakata-sip-privacy-clarified-00 (updates RFC 3323?, defines new privacy values)
draft-hasebe-sipping-race-examples-02 (has RFC 2119 language against RFC 3261 behaviour) 

---------------------------------------------------------------------------------

Author drafts - extensions

draft-sinha-sip-block-01 (defines new response code)
draft-boulton-sip-control-framework-05 (defines new option tag and new SIP header field)
draft-johns-sip-outbound-middialog-draft-02 (extends existing outbound work)
draft-lee-sip-dns-sd-uri-00
draft-mahy-sip-remote-cc-05 (defines new option tag and new URI parameter)
draft-petithuguenin-sip-fragmentation-responses-02 (defines new header field, new response code, and new header field parameters)
draft-petithuguenin-sip-outbound-fragmentation-02 (extends STUN – does this belong with BEHAVE WG?)
draft-petrie-sip-event-param-err-00 (defines new response code and new header field – may be part of config framework chartered work)
draft-polk-sip-rph-new-namespaces-00 (defines new resource priority namespaces)
draft-rbhatia-anycast-sip-proxy-discovery-00
draft-rosenberg-sip-outbound-discovery-mid-dialog (defines new header field, new option tag, new URI parameter)
draft-rosenberg-sip-route-construct-02 (defines new option tag and new header field parameter)
draft-urpalainen-sip-xcap-diff-event-01 (defines new event package, may interrelate with config framework work)
draft-hewett-sipping-cal-00 (defines new header field, new option tag and new response code)
draft-hilt-sipping-overload-01 (defines new header field – requirements in draft-ietf-sipping-overload-reqs-00)
draft-jennings-sipping-pay-05 (defines new header field, new option tags, new response codes)
draft-jung-sipping-authentication-spit-00 (defines new response code)
draft-rajesh-sipping-303-01 (defines new response code)
draft-rajesh-sipping-605-01 (defines new response code)
draft-roach-sipping-callcomp-bfcp-00 (defines new option tag  - howver also defines BFCP extensions which need to go to XCON WG)
draft-schubert-sipping-header-integrity-reqs-00 (defines new option tag – however also defines SDP extensions which need to go to MMUSIC WG)
draft-stucker-sipping-early-media-indirection-00 (defines new option tag)
draft-vakil-sipping-notify-pause-00 (defines new header field paramter – extends RFC 3265)

-----------------------------------------------------------------------------

Author drafts - security

draft-dotson-sip-certificate-auth-02 (requirements document)
draft-dotson-sip-certificate-auth-sol-00 (solution for above)
draft-fries-sip-identity-usage-bcp-01 (proposed BCP for our identity RFCs)
draft-gurbani-sip-domain-certs-04
draft-jennings-sip-dtls-03 (currently being addressed in RAI WG – modifies URI parameter)
draft-greco-sipping-roaming-00
draft-schubert-sipping-header-integrity-reqs-00
draft-tschofenig-sipping-spit-policy-00
draft-wing-sipping-srtp-key-00  

------------------------------------------------------------------------------

Author drafts - not sure

draft-babiarz-pcn-sip-cap-00
draft-barnes-sip-em-ps-req-sol-00 (requirements draft probably best dealt with by SIPPING WG)
draft-dondeti-oma-sip-sdp-attrs-00 (believe this is a MMUSIC issue)
draft-sinnreich-sip-tools-01 (is this part of the hitchhiker’s guide work)
draft-worley-sip-dialog-03 (in scope of SIPPING?)
draft-worley-sip-gruu-implement-02 (in scope of SIPPING or incorporate in draft-ietf-sip-gruu? – anything left?)

---------------------------------------------------------------------------------
	
_______________________________________________
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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 09 Mar 2007 10:26:30 -0800

Inline.

> None of the above implies any commitment of the SIP WG or IETF to further the work on such drafts, but I suspect if it is not complete on my list, with the information as requested above, then noth…

[snip]

> draft-petithuguenin-sip-fragmentation-responses-02 (defines new header field, new response code, and new header field parameters)

This document defines a SIP extension that fixes a bug in SIP (i.e. SIP
response fragmented in some cases), so it can also be in the bugfixes
category.  If you agree, then I'll update the I-D to follow the
requirements in draft-drage-sip-essential-correction.

There is AFAIK no existing requirements document.  I will work on this,
with the authors of draft-gurbani-sip-large-udp-response-00 if they are
interested.

> draft-petithuguenin-sip-outbound-fragmentation-02 (extends STUN – does this belong with BEHAVE WG?)

You are right that this document describes a STUN extension, so it
should perhaps be in the BEHAVE WG.  But it also describes an extension
to Outbound.  So should I split the document in two, one for the STUN
usages (in the BEHAVE WG), and another one for the usage of the STUN
Usages in Outbound?

Anyway, I believe that the Outbound extension part of this document
belong to the SIP WG.  There is no existing requirements document, but I
think that it could be the same document than the one that need to be
written for draft-petithuguenin-sip-fragmentation-responses-02 (see above).

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 9 Mar 2007 20:11:07 +0100

(As WG chair)

Just to shed a bit more light on this and what the different categorisations mean. And I repeat that whatever work, we still need to build working concensus that we want to do the work. If you do not understand this process, there is education material in IETF linked from the IETF home page to provide guidance.

1)	bugfixes. This is where we agree the underlying specification (RFC 3261 or whatever) is broken, and therefore needs fixing. If we agree this, then it follows procedure in draft-drage-sip-essential-corrections and DOES NOT need a requirements document. Once we have agreed we have something that needs fixing, the working group identifies a solution in a WG draft. Roberts Sparks is leading this work, but you may end up drafting the WG internet-draft documenting the fix. In general, I am assuming that if we have working consensus that the base spec is broken, we have consensus to fix it. Further, if it is broken, we do want to fix it quickly.

2)	extensions. These are enhancements to SIP where in particular, RFC 3427 says SIP WG has to do the work. In general for these, we would expect requirements to come from some other group on these, and it is this group that I am emphasising that we need to identify the requirements input if it exists, and produce it in the appropriate WG if it does not.

3)	security. We have a philosophy of looking at all the SIP security issues (requirements and solutions) within SIP in order to relieve the load on the SIPPING group. This group therefore we control our own destiny, and can be a little more flexible in policing how work gets started.

There is obviously a grey area between 1) and 2) above, and it may mean that some existing drafts may have to be split to separate the bugfix from the extension.

Regards

Keith

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]] 
> Sent: Friday, March 09, 2007 2:46 PM
> To: [email-masked]
> Subject: [Sip] Making sense of the SIP author drafts
> 
> (as WG chair)
> 
> I have been attempting to make sense of the large number of 
> author drafts out there which in some manner impact SIP. I 
> have three categories:
> 
> -	Bugfixes (documents which may fall into the criteria 
> identified in draft-drage-sip-essential-correction-01)
> -	Security (all SIP security issues are normally dealt 
> with in the SIP WG, even if INFORMATIONAL)
> 
> -	for the SIP extensions is there a document out there 
> which lists the requirements, and if so, which document is 
> it? By this I mean a some text, totally independent of the 
> proposed solution which:
> 
> Note that if such text does not exist, I strongly suggest 
> that authors of SIP extensions with RFC 3427 impact think 
> about providing such text if they want their document to 
> progress, or else provide a rational explanation of why it is 
> not needed. Such text may well belong with the SIPPING group 
> for prior discussion.
> 
> None of the above implies any commitment of the SIP WG or 
> IETF to further the work on such drafts, but I suspect if it 
> is not complete on my list, with the information as requested 
> above, then nothing is going to happen with it.
> 
> Regards
> 
> Keith
> 
> 
> draft-froment-sip-record-route-fix-00 (updates RFC 3261?, or 
> is it just a BCP?) draft-gurbani-sip-large-udp-response-00 
> (updates RFC 3261) draft-munakata-sip-privacy-clarified-00 
> (updates RFC 3323?, defines new privacy values)
> draft-johns-sip-outbound-middialog-draft-02 (extends existing 
> outbound work) draft-lee-sip-dns-sd-uri-00
> draft-petithuguenin-sip-fragmentation-responses-02 (defines 
> new header field, new response code, and new header field parameters)
> draft-petrie-sip-event-param-err-00 (defines new response 
> code and new header field – may be part of config framework 
> chartered work) draft-polk-sip-rph-new-namespaces-00 (defines 
> new resource priority namespaces) 
> draft-rosenberg-sip-outbound-discovery-mid-dialog (defines 
> new header field, new option tag, new URI parameter)
> draft-urpalainen-sip-xcap-diff-event-01 (defines new event 
> package, may interrelate with config framework work) 
> draft-hilt-sipping-overload-01 (defines new header field – 
> requirements in draft-ietf-sipping-overload-reqs-00)
> draft-roach-sipping-callcomp-bfcp-00 (defines new option tag  
> - howver also defines BFCP extensions which need to go to 
> XCON WG) draft-schubert-sipping-header-integrity-reqs-00 
> (defines new option tag – however also defines SDP extensions 
> which need to go to MMUSIC WG) 
> draft-stucker-sipping-early-media-indirection-00 (defines new 
> option tag) draft-vakil-sipping-notify-pause-00 (defines new 
> header field paramter – extends RFC 3265)
> 
> draft-jennings-sip-dtls-03 (currently being addressed in RAI 
> WG – modifies URI parameter) draft-greco-sipping-roaming-00 
> draft-worley-sip-gruu-implement-02 (in scope of SIPPING or 
> incorporate in draft-ietf-sip-gruu? – anything left?)
>

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 9 Mar 2007 20:24:26 +0100

As I have clarified in a separate mail, bugfixes don't need requirements, but they will need to follow the procedures of

http://www.ietf.org/internet-drafts/draft-drage-sip-essential-correction-01.txt

Or the current version of that.

We have asked Robert to lead the bugfixes programme. 

I would welcome his take (and indeed that of anyone else) as to whether this is a RFC 3261 bug that needs fixing, or something else.

Keith

> From: Marc Petit-Huguenin [mailto:[email-masked]] 
> Sent: Friday, March 09, 2007 6:27 PM
> To: Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Sip] Making sense of the SIP author drafts
> 
> Inline.
> 
> new header 
> > field, new response code, and new header field parameters)
> 
> This document defines a SIP extension that fixes a bug in SIP 
> (i.e. SIP response fragmented in some cases), so it can also 
> be in the bugfixes category.  If you agree, then I'll update 
> the I-D to follow the requirements in 
> draft-drage-sip-essential-correction.
> 
> There is AFAIK no existing requirements document.  I will 
> work on this, with the authors of 
> draft-gurbani-sip-large-udp-response-00 if they are interested.
> 
> > draft-petithuguenin-sip-outbound-fragmentation-02 (extends 
> STUN – does 
> > this belong with BEHAVE WG?)
> 
> You are right that this document describes a STUN extension, 
> so it should perhaps be in the BEHAVE WG.  But it also 
> describes an extension to Outbound.  So should I split the 
> document in two, one for the STUN usages (in the BEHAVE WG), 
> and another one for the usage of the STUN Usages in Outbound?
> 
> Anyway, I believe that the Outbound extension part of this 
> document belong to the SIP WG.  There is no existing 
> requirements document, but I think that it could be the same 
> document than the one that need to be written for 
> draft-petithuguenin-sip-fragmentation-responses-02 (see above).
> 
> -- 
> Marc Petit-Huguenin           [                                 ]

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Fri, 9 Mar 2007 20:30:08 +0100

I missed the 2nd part of your mail relating to 

draft-petithuguenin-sip-outbound-fragmentation-02 

I would recommend that we try and identify some key requirements for this problem, and decide in Prague which WG progresses those requirements - assuming that there is likely to be some concensus on the problem (it may well be SIPPING). I believe you have an "If time permits..." slot in the SIP WG for this draft.

Once the requirements exist, they can be delivered to SIP and BEHAVE for each to work on their part of the problem.

Regards

Keith

---

From: Robert Sparks <[email-masked]>
Date: Fri, 9 Mar 2007 13:40:22 -0600

My initial impression:

Marc's draft looks (on a fast skim) to just use the extension  
mechanisms to address a problem, not normatively replace text in  
3261, so from that perspective, if/when consensus around it settled,  
it would be published directly and not go into the essential- 
correction process (with the caveat that I have only given it a fast  
skim).

That said, its a bit early to try to classify such things for any  
purpose other than setting rough expectations. Things can
(and probably will) change as drafts go through the consensus process.

RjS

On Mar 9, 2007, at 1:24 PM, Drage, Keith ((Keith)) wrote:

> As I have clarified in a separate mail, bugfixes don't need  
> requirements, but they will need to follow the procedures of
>
> I would welcome his take (and indeed that of anyone else) as to  
> whether this is a RFC 3261 bug that needs fixing, or something else.
>
> Keith
>
>
>
>> --------------------------------------------------------------------- 
>> -
>>> ----------

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 09 Mar 2007 13:31:11 -0800

Drage, Keith (Keith) wrote:
> I would recommend that we try and identify some key requirements for
> this problem, and decide in Prague which WG progresses those
> requirements - assuming that there is likely to be some concensus on
> the problem (it may well be SIPPING). I believe you have an "If time
> permits..." slot in the SIP WG for this draft.

Yes, I will add the question of where this work should progress on my
slides for the presentation (in case "[...] time permits.")

> 
> Once the requirements exist, they can be delivered to SIP and BEHAVE
> for each to work on their part of the problem.
> 
> Regards
> 
> Keith
> 
>> -----Original Message----- From: Marc Petit-Huguenin
>> [mailto:[email-masked]] Sent: Friday, March 09, 2007 6:27 PM To:
>> Drage, Keith (Keith) Cc: [email-masked] Subject: Re: [Sip] Making
>> sense of the SIP author drafts
>> 
>> Inline.
>> 
>> author drafts out there which in some manner impact SIP. I have
>> three categories:
>>> -	have I categorised this correctly? -	have I missed any drafts
>>> that should be here? -	for the SIP extensions is there a document
>>> out there
>> which lists the requirements, and if so, which document is it? By
>> this I mean a some text, totally independent of the proposed
>> solution which:
>> that authors of SIP extensions with RFC 3427 impact think about
>> providing such text if they want their document to progress, or
>> else provide a rational explanation of why it is not needed. Such
>> text may well belong with the SIPPING group for prior discussion.
>> IETF to further the work on such drafts, but I suspect if it is not
>> complete on my list, with the information as requested above, then
>> nothing is going to happen with it.
>>> Regards
>>> 
>>> Keith
>>> 
>>> 
>>> 
>> ----------------------------------------------------------------------
>> 
>>> ---------- Author drafts - extensions
>>> 
>> [snip]
>> 
>> This document defines a SIP extension that fixes a bug in SIP (i.e.
>> SIP response fragmented in some cases), so it can also be in the
>> bugfixes category.  If you agree, then I'll update the I-D to
>> follow the requirements in draft-drage-sip-essential-correction.
>> 
>> There is AFAIK no existing requirements document.  I will work on
>> this, with the authors of draft-gurbani-sip-large-udp-response-00
>> if they are interested.
>> 
>> should perhaps be in the BEHAVE WG.  But it also describes an
>> extension to Outbound.  So should I split the document in two, one
>> for the STUN usages (in the BEHAVE WG), and another one for the
>> usage of the STUN Usages in Outbound?
>> 
>> belong to the SIP WG.  There is no existing requirements document,
>> but I think that it could be the same document than the one that
>> need to be written for 
>> -- Marc Petit-Huguenin           [
>> ] Home: [email-masked] [RFC1855-compliant space for rent ]
>>  Work: [email-masked]            [                                 ]
>>