Docstoc

PPT Version - ietf-ag

Document Sample
PPT Version - ietf-ag Powered By Docstoc
					SIP Configuration Framework
 (draft-ietf-sipping-config-framework-12)


            SIPPING – IETF 69
               July 24, 2007

               Mary Barnes
              (WG co-chair)


                                            1
                                  History (1/3)
●   2001
     ●   Document presented to the SIP WG (individual submission)
●   2002 (Jun)
     ●   Document adopted as a SIPPING WG document in IETF#54
●   2003 (Mar)
     ●   First WG version of document available (19 pages)
           ●   Content incomplete.
●   2005
     ●   Draft-06 presented for first WGLC
     ●   Draft -07, reflecting WG consensus via previous regime, sent to the AD
           ●   AD returns document due to OMA concerns and other issues
     ●   Draft -08 produced to address issues
           ●   XCAP dependencies split to separate doc
●   2006 (Mar)
     ●   One remaining issue discussed at IETF#65
           ●   How does the device know the profile delivery server supports XCAP (e.g. how specific
               of path can go in the document parameter)?

                                                                                                       2
                                  History (2/3)
●   2006 (Sep)
     ●   Document went stale; draft -08 marked “Dead”
●   2006 (Oct )
     ●   Document revived by Editor
     ●   Second WGLC (draft -09)
          ●   Conclusion: Document needs serious editorial work.
●   2006 (Nov)
     ●   Adhoc meeting held at IETF#67
          ●   Proposed new table of contents on the SIPPING WG mailing list
●   2006 (Dec)
     ●   Design team formed
          ●   (current team; in alphabetical order) Alvin Jiang, Cullen Jennings, Dan Petrie, Francois
              Audet, Gonzalo Camarillo, Jason Fischl, Josh Littlefield, Martin Dolly, Mary Barnes,
              Peter Blatherwick, Roni Even, Sam Ganesan, Sumanth Channabasappa
     ●   New Editor (Sumanth Channabasappa) assigned




                                                                                                         3
                                 History (3/3)
●   2006 (Dec)
     ●   Design team discusses suggestions
●   2007 (Feb, Mar)
     ●   Design team submits drafts -10 and -11
           ●   Based on the layout proposed on the SIPPING WG mailing list
●   2007 (Mar)
     ●   draft-11 discussed at IETF#68
           ●   Further comments provided
●   2007 (Apr-May)
     ●   Design team incorporates comments from IETF#68
     ●   draft-12 submitted
●   2007 (June)
     ●   Third WGLC held
●   ?007
     ●   Work completed!



                                                                             4
                  Where are we today?
●   Current WG document is the result of extensive design team activity
     ●   Based on WG proposed and accepted direction.
     ●   Per the proposed table of contents.
●   Current version a result of many conference calls and revisions
     ●   Weekly and bi-weekly calls, with countless hours of editing and re-
         arranging content for readability and clarity
     ●   3 draft revisions
          ●   Nearly a dozen intermediate versions since Dec. 2006
●   Third WGLC held in June 2007
     ●   Extended nearly two weeks
●   WGLC Feedback:
     ●   Many (including design team) believe draft either Ready or Almost Ready
     ●   Document is large
     ●   Document is complex
     ●   Document is difficult to read.



                                                                                   5
              Document is “Large”?
●   Document has a lot of supporting material
●   To illustrate, the current version (draft-12) has
    64 pages
    ●   20 pages of framework explanation
         ●   i.e., details, framework requirement, security
    ●   12 pages defining the event package
    ●   12 additional pages
         ●   Abstract, TOC, terms, IANA, references, etc.
    ●   14 pages of informative material
         ●   Attempt to meet clarity, “just give me the basics”, etc.
    ●   6 pages of change summaries
         ●   To be deleted in the published version


                                                                        6
          Document is “Complex”?
●   There’s a whole lotta stuff in the document (based on
    WG request):
    ●   Requirements
    ●   Use Cases
    ●   Framework
    ●   Event Package
    ●   Examples
    ●   Security Requirements & Analysis
●   Reality is that if we were to charter this work under
    today’s guidelines, we would likely have many
    documents (if not a separate WG).
●   Complexity is a result of necessity of meeting
    requirements – it really is a complex problem space.


                                                            7
        Comments on “Readability”?
●   Polarization
    ●   Document is large and complex
    ●   Document does not have enough detail
●   Design team has re-arranged and shifted
    text multiple times, adding diagrams, etc. to
    aid clarity, thus there may be some
    duplication.
●   There is a lotta stuff in the document.


                                                8
                Plans for today
●   Let’s summarize the I-D, changes in -12,
    and WGLC comments
    ●   WG feedback should focus on technical
        issues
●   Once the issues are discussed, let’s
    discuss the way forward for this document.




                                                9
Discussions on the I-D
      Sumanth Channabasappa
         sumanth@cablelabs.com
    (On behalf of the design team)




                                     10
                    As a Refresher…
                                    In-Scope
●   Profile Delivery
    ●   Profile Enrollment
         ●   How does the client discover a profile delivery server and request
             profiles?
    ●   Content Retrieval Protocols
         ●   How does the client retrieve profile data via content indirection
             (optional)?
    ●   Change Notification
         ●   How is the client informed of changes to profile data?
●   Profile Types
    ●   local-network, device, user

                                                                                  11
                  As a Refresher…
                               In-Scope
●   Event Package
    ●   ‘ua-profile’ event package based on SUBSCRIBE/NOTIFY
        (RFC3265) for profile enrollment
●   Securing Profile Delivery
    ●   How does a client obtain Identities and Credentials?
    ●   How is Profile Delivery secured?




                                                               12
                    As a Refresher…
                                   Out-of-scope
●   Profile Data
    ●   Profile data delivered to the client
    ●   Separate I-Ds in progress
●   Profile Error Notification
    ●   How does the client notify the profile delivery server of erroneous
        or incomprehensible profile data?
●   HTTP Bootstrap
    ●   Removed by design team, as simplification of the framework
         ● A new I-D now provides similar functionality, seen as

           complimentary
              ●   draft-veikkolainen-sipping-app-config



                                                                         13
          IETF#68 suggestions
●   Replace ‘device-id’ with ‘+sip.instance’ within the
    contact header (specified in OUTBOUND)
●   Add ‘Executive Summary’
●   Add IANA registry for the 'profile-type' parameter
●   Use “_sipuaconfig” instead of “sipuaconfig”
●   Add Backoff and Retry mechanisms
●   Beef up the security section
●   Other editorial suggestions


                                                      14
                      Changes to -12
●   Addressed technical and editorial comments from
    IETF#68
●   In addition:
    ●   Removed the HTTPS bootstrapping section
         ●   Considered out-of-scope, as indicated earlier
    ●   Removed 'Profile Change Modification‘
         ●   Profile changes and push to configuration servers are out of scope
    ●   Added informative details such as a detailed State Diagram
         ●   Clarifies implementer needs
    ●   Added backoff/retry details
         ●   Prevents avalanche scenarios and facilitates scalability




                                                                                  15
        WGLC comments (technical)
●   Do we need three profile types?
    ●   Yes, we agreed to this in IETF#68
●   Do we need the multiple discovery mechanisms?
    ●   Yes, to address the wide variety of deployments (based on
        earlier feedback)
●   Do we need to handle race conditions (200 OK and
    NOTIFY)?
    ●   No, this is applicable to SUBSCRIBE & NOTIFY in general
●   Can we verify that the security requirements do not
    override those in OUTBOUND (e.g., use of multiple TLS
    connections)?
    ●   Yes, the design team will investigate this


                                                                    16
                    Next Steps
●   Propose to update document addressing
    most recent technical issues.
●   Remove some extra text:
    ●   Change log
    ●   Some intro material that seems redundant.
●   Submit the document to the WG for a two
    week re-review period.



                                                    17
                  I-D Link
http://www.ietf.org/internet-drafts/draft-ietf-
  sipping-config-framework-12.txt




                                                  18

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:5/8/2013
language:Unknown
pages:18
yaofenji yaofenji
About