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

[Hadriel Kaplan <[e-mail]>]

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