Subject: Re: [Sipping] Proposed revised layout for draft-ietf-sipping-config-framework

From: [email-masked]
Date: Thu, 9 Nov 2006 13:58:10 -0500

Hi Keith, all, 

Thanks for doing this.  As a first pass, I do like the overall structure 
proposed.  Seems to break down the complexity in a nice rational flow of 
bite-sized pieces. 

Not clear to me the restructuring would necessarily reduce overall size of 
the doc.  Even though there would be some redundancy removed (hopefully), 
since the structuring itself costs words too.  Important part is getting 
it to be easy to understand and implement correctly.  As long as 
necessary, but no longer. 

I have a few detailed tweaks suggested, and a couple of questions: 

o Sec 3, suggest *brief* subsection "Scope and Requirements Overview" (or 
some such) to clearly define what the spec does and does not address, esp 
that it does not cover actual data formats and related.  This might help 
focus and remove debates that do not belong in this doc.  Maybe this would 
be 1st sub-sec of Overview, or a stand-alone section. 

o Sec 3.1 Profile Life Cycle  Unclear what is intended by this.  What 
would content be here. 

o Sec 3.1 Reference model.  Modulo answers to above, I'd bet this should 
really be the first technical content subsec.  Reference model typically 
helps frame everything else.  Definitely needs a pretty picture to show 
relation of the various elements. 

o Message flow diagrams, showing general flow from high level, would be 
very helpful, preferably fairly early in the doc.  Not sure where this 
would go, but probably close to Reference Model, or maybe even part of it. 
  (Sec 8 Examples should contain examples in grueling detail.)  When we 
met on Tuesday, I think there was general head-nodding that this would be 
helpful. 

o Sec 5.1.1.1 - 5.1.1.3  Forming X URI, suggest these should be ordered in 
same sequence as they are actually used, ie Local Network, then Device, 
then User.  There may be other places where this general principal could 
be applied as well. 

-- Peter Blatherwick

"Drage, Keith \(Keith\)" <[email-masked]>
09.11.06 10:26

        To:     <[email-masked]>
        cc: 
        Subject:        [Sipping] Proposed revised layout for draft-ietf-sipping-config-framework

During the breakout session on the config framework we decided that the
existing material in this document was essentially covering the right
material and scope, but that a new structure was needed and then a
rewrite of the text that goes into those sections. 

There is a hope that during this rewrite, much duplicate material will
be removed and the document will become shorter as well as the main goal
of making the document more understandable.

To follow normal RFC drafting rules
To follow guidelines for SIP extensions (RFC 4485)
To follow requirements for defining Event packages (RFC 3265)

Comments are welcome, this is a strawman.

------------------------------------------------------------------------
-------------

Abstract

1                Introduction

2                Terminology

3                Overview

                 Much of the information in the existing section 4 seems 
to be
appropriate to be 
                 here. 
 
                 Suggest also that the definition of different profile 
types is
moved here from 
                 the event package definition. That then leaves the way 
forward
for the event 
                 package to assign parameters to the different profile 
types.

3.1              Profile Life Cycle

3.2              Reference model

                 This will say that the document describes this in terms 
of UA
acting as Device, 
                 and of a Profile Delivery Server, which consists of two 
parts:
                 *               Profile Notification Server
                 *               Profile Content Indirection Server
                 Indicate that the Profile Content Indirection Server is 
optional
to implement

3.3              Profile types and data model

                 Include here section 6 and stuff from the event package 
that is
not event 
                 package specific. Leave only the coding in the event 
package.

4                Use cases

Text from section 5 of the document.

5                Processing Rules

                 Place in this section the content indirection 
requirements.

                 Need to clearly distinguish all requirements for profile 
content
server and 
                 profile delivery server.

5.1              Device Behaviour

5.1.1            Profile delivery server discovery

5.1.2            Forming URIs for subscription

                 Needs to include content from 7.13

5.1.1.1          Device URIs
5.1.1.2          User URIs
5.1.1.3          Local Network URIs

5.1.3            Enrollment with Profile Server
5.1.4            Notification of Profile Changes
5.1.5            Retrieval of Profile Data

                 split to cover from both profile notification server and 
profile
content 
                 indirection server.

5.1.5            Upload of Profile Changes

                 only from profile content indirection server

5.2              Profile Notification Server Behaviour

5.2.1            Enrollment with Profile Server

5.2.2            Notification of Profile Changes

5.2.3            Retrieval of Profile Data

5.3              Profile Content Indirection Server Behaviour

5.3.1            Retrieval of Profile Data

5.3.2            Upload of Profile Changes

6                Event Package Definition

                 The sub-breakdown here comes from RFC 3265 however the 
idea of
RFC 
                 3265 is not to slavishly follow, but to make sure all the
information is 
                 contained. Therefore it is proposed that the examples are 
moved
out of this 
                 level to a later point in the document.
                 Remove all text relating to content indirection from the
existing event package 
                 definition except for the passing of the URI.

                 The idea is that this defines the package, but material 
relating
to the use of 
                 the package goes elsewhere. 

6.1              Event Package Name

6.2              Event Package Parameters

                 Move out the profile type introduction to the overview.

6.3              SUBSCRIBE Bodies

6.4              Subscription Duration

6.5              NOTIFY Bodies

6.6              Notifier Processing of SUBSCRIBE Requests

6.7              Notifier Generation of SUBSCRIBE Requests

6.8              Subscriber Processing of NOTIFY Requests

6.9              Handling of Forked Requests

6.10             Rate of Notifications

6.11             State Agents

7                Instructions for Data Set Authors

                 Substantially new.

                 Data set authors need to register a mime type for their 
data
set.

8                Examples

                 See section 7.12 of existing document.

9                IANA Considerations

9.1              SIP Event Package

9.2              New HTTP Event Header

10               Security Considerations

                 Much of the procedural text in here actually needs to go 
back
into the main 
                 text ? where there are already some requirements. The 
text here
should then 
                 refer to that text rather than repeat it.

11               References

11.1             Normative References

11.2             Informative References

------------------------------------------------------------------------
----------

Regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP