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

["Elwell, John" <[e-mail]>]

>From this list it would seem SIPPING has relatively few work items. I
thought the exercise was partly aimed at reducing the load on SIP and
SIPPING.

John 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Cullen Jennings
> Sent: 12 February 2009 01:55
> To: Jonathan Rosenberg; [e-mail]
> Subject: Re: [RAI] RAI reorganization - allocation of existing work
> 
> 
> 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.
> 
> _______________________________________________
> RAI mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rai
>