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

[Cullen Jennings <[e-mail]>]

It would be great if a new WG on topics such as SIP security spun up.  
However, it would be the wrong direction to be delaying things that  
were already WG drafts while we sort out a new WG. It would just add  
delay and unlikely to improve the final RFCs. I also don't want the  
discussion about should we change the way SIP can be modified to get  
derailed on the topic of should we continue work on some particular  
working group draft that is lacking energy.

So my goal is to find a home for everything that is currently a WG  
item. This results in SIP not changing much on day one but a key goal  
of the transition transition is to allow much of the work that would  
have to happen in SIP today to migrate or be done in working groups  
outside SIPCORE in the future.

On Feb 13, 2009, at 15:37 , Hadriel Kaplan wrote:

>
> Yeesh, that doesn't bode well for SIPCORE being any less than SIP  
> today.
>
> I thought in Jon's email he said part of this change would mean on- 
> going security work would find a new home, but you have it all going  
> to SIPCORE.
> Is that an oversight?
>
> -hadriel
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf  
> Of
> > Cullen Jennings
> > Sent: Wednesday, February 11, 2009 8:55 PM
> > 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