1 / 6

The Story so far…

The Story so far…. rfc3427bis is now in IETF Last Call Received some comments, could use more SIPCORE and DISPATCH charters now in external review This is the right time to comment on the charters! Discussions on rai@ietf.org or mail ye ADs This is our high-bandwidth channel. SIPCORE.

homer
Download Presentation

The Story so far…

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Story so far… • rfc3427bis is now in IETF Last Call • Received some comments, could use more • SIPCORE and DISPATCH charters now in external review • This is the right time to comment on the charters! • Discussions on rai@ietf.org or mail ye ADs • This is our high-bandwidth channel

  2. SIPCORE • Consistent feedback that SIP’s job was still too big and complicated • Long-suffering chairs • Scope of RFC3261-RFC3265 is a bit arbitrary • What it means: if you Update any of those specifications, work must be Standards Track and must be in SIPCORE • Does not explicitly bar other work… should it? • This could lead to absurdities – work splits and spreads • This group should be more manageable

  3. DISPATCH • A lot of the questions and discussions have focused on DISPATCH • The idea: a forum that helps good work in RAI find a chartered home • What kind of deliverables? • Charters, problem statement -00s, radioactivity assessments • Double jeopardy? If not, why not? • If implemented correctly, DISPATCH needn’t be a BoF to decide to have a BoF • More like an Open Area meeting • DISPATCH discussion may lead to BoFs without WGs • RTPSEC is an example of this approach • May merely point work to existing WGs and charters • Even for intended WGs, pre-BoF adhoc meetings are now the norm • This could provide communal meeting time for that purpose • Not radically novel

  4. rfc3427bis • Elimination of the P- header process • Now Informational headers can exist without a “P-” and can be produced anywhere • Some provisos: not related to security, purely informational in nature • But what is “informational”, really…? • Leaves many things untouched: • option-tags, event packages, URI and header parameters • Should we change those? Maybe. Let’s do this first.

  5. Disposition of Existing Work • Short version: work will find new homes • Some existing work may be grandfathered into SIPCORE/DISPATCH milestones • But after the transition all new deliverables will conform to the new charters • Some existing work will be farmed out to other groups • Some existing work may be entered into the DISPATCH process • Cases where we’re having problems, or work is new and shiny

  6. Is that it? • Certainly this will not solve all our problems • Intention is to reorganize around smaller, more focused efforts • Reducing interworking between work groups and with other standards bodies • Ongoing work looking at other methods of reducing delays • Helpful work by Henning, Hannes and Markus • We need community input on other changes we should make

More Related