Re: [RAI] RAI reorganization - allocation of existing work

[Cullen Jennings <[e-mail]>]

The allocation is not easy - Here is a rough take. It's very draft. It  
proposes that some of the work get spun up as new small focused  
efforts at IETF 74. Specifically DISPATCH would spin up something on  
Info Framework, Config, and Overload. Jon is going to send some more  
email about this but here is *rough* list of all current WG items that  
have not been sent to the IESG and where they might map to.


SIP Milestones:

X.509 extended key usage for SIP
draft-ietf-sip-eku
--> SIPCORE

Termination of early dialog prior to final response
draft-ietf-sip-199
--> SIPCORE

Delivering request-URI and parameters to UAS via proxy
draft-rosenberg-sip-target-uri-delivery
--> SIPCORE

INFO package framework
draft-ietf-sip-info-events-03
--> Dispatch/Info

Guidelines for double route recording
draft-ietf-sip-record-route-fix
--> SIPCORE

X.509 Certificates for TLS use in SIP
draft-ietf-sip-domain-certs
--> SIPCORE

Using SAML for SIP
draft-ietf-sip-saml
--> OBE? (Overcome by events)

Location Conveyance with SIP
draft-ietf-sip-location-conveyance
--> GEOPRIV

MIME body handling in SIP
draft-ietf-sip-body-handling-05
--> SIPCORE

Example security flows
--> OBE?

Identify requirements for test matrix to move SIP to Draft Standard
--> SIPCORE

Essential corrections to RFC 3261 (1st batch)
draft-ietf-sip-ipv6-abnf-fix
--> SIPCORE

Mechanisms for UA initiated privacy
draft-ietf-sip-ua-privacy
--> AD Sponsor




SIPPING Milestones:

Presence Scaling Requirements to IESG
draft-ietf-sipping-presence-scaling-requirements
--> Dispatch/Overload

User Agent Profile for Media Policy
draft-ietf-sipping-media-policy-dataset (last updated May 2008)
--> Dispatch/Config

Schema and Guidelines for SIP User Agent Profile Datasets
draft-ietf-sipping-profile-datasets
--> Dispatch/Config

Overload Design Considerations
draft-ietf-sipping-overload-design
--> Dispatch/Overload

NAT Scenarios
  draft-ietf-sipping-nat-scenarios
--> MUSIC or Grandfather SIPCORE




On Feb 10, 2009, at 7:32 AM, Jonathan Rosenberg wrote:

>
>
> Jon Peterson wrote:
>> Existing working group items will find a home somewhere as a part  
>> of the transition process. I don't think we yet have an exhaustive  
>> mapping of what will live where, but, we recognize that it may be  
>> necessary to grandfather chartered work into SIPCORE or DISPATCH in  
>> order to minimize disruption to ongoing efforts (we just wouldn't  
>> let those groups pick up new milestones/deliverables that fall  
>> outside their defined scope).
>
> This could end up being a bad situation if we ended up having  
> DISPATCH and SIPCORE full of old items, unable to spend time on  
> their real, new charters.
>
> I'd love to see a table which proposes an allocation of the existing  
> SIP/SIPPING work to other groups (e.g., location conveyance ->  
> geopriv). I'd also go so far as to propose that big, unfinished  
> pieces of work in sipping (like the config framework documents) be  
> immediately placed into a BoF/WG which meets in San Fran (formally  
> or informally).
>
> I think that exercise will give us a really good idea of how easy it  
> will be to push work into other groups.
>
> -Jonathan R.