Subject: [Sipping] Query about draft-ietf-sipping-config-framework-12

From: "Donald Stewart (CV/ETL)" <[email-masked]>
Date: Fri, 14 Sep 2007 16:48:54 +0200

Dan and Sumanth et al,
	The following is Figure 6 copied from
draft-ietf-sipping-config-framework-12, with a number added to each
state to help me describe my questions.

                                +---------------+
                                | 0. Initialize |
                                +-----+---------+
                                      |
                                      |
                                      V
                               +-------------+
                               |      1.     |
                               |   Prepare   |
                    +--------->|  Enrollment |<------------------+
                    |          |   Request   |                   |
                    |          +------+------+                   |
             +------+------+          |                          |
             | 5. Failure  | Enroll. Req. prepared               |
         +-->|  Handling & |      /Send Req                      |
         |   |   Delay     |          |                          |
         |   +-------------+          V                          |
         |       ^    ^        +-------------+                   |
         |       |    |        |  2. Await   |                   |
         |       |    +--------+  Enrollment |                   |
         |       |    Timeout, |  acceptance |                   |
         |       |   non-2xx/- +------+------+                   |
         |       |                    |                          |
         |   Timeout            200 OK/-                    Enrollment
         |  /Terminate                |                       Timeout/-
         |   Enrollment               V                          |
         |       |            +--------------+                   |
         |       |            | 3. Enrollment|                   |
         |       +------------+   accepted   |                   |
    Retries Exceeded          |(await NOTIFY)|                   |
   /Retry Enrollment          +---+------+---+                   |
         |                        |      |                       |
         |                        |      |                       |
         |   NOTIFY w. Content Ind|      |  NOTIFY w. Profile    |
         |     /Retrieve Profile  |      |  /Accept Profile      |
         |           +------------+      +------------+          |
         |           |                                |          |
         |           V                                V          |
         |     +------------+                   +------------+   |
         |     |     6.     |                   |     4.     |   |
         +-----+ Retrieving |    Retrieved      | Enrollment +---+
            ,->|   Profile  +--/Apply Profile-->| Successful |
           /   |            |                   |(monitoring)|<--.
      Timeout  +--+---------+                   +--+----+----+    :
      /Retry      ;      ^                         |    :         ;
           `------'      |   NOTIFY w. Cont.Ind    |    `-------'
                         +---/Retrieve Profile-----+   NOTIFY w. Profile
                                                          /Apply Profile

                        Figure 6: Device State Diagram

The transition from state 3 to state 5 is performed when the subscriber
fails to receive a NOTIFY within the period of a timeout.
*	Where is that timeout defined?
*	When is the timeout started - on sending the SUBSCRIBE or on
receipt of the 200 OK?

The transition from state 3 to state 5 includes an action "Terminate
Enrollment".
*	What does the subscriber do in this action?  I think it needs to
send a SUBSCRIBE to the PDS containing an Expires: 0 header.  Is this
correct?
*	Could you add a description of this action to the document?

The transition from state 6 to state 5 includes an action "Retry
Enrollment"
*	What does the subscriber do in this action?
*	Could you add a description of this action to the document?

The transition from state 4 to state 1 is performed when the enrollment
timeout expires.
*	Why don't you show the notifier re-subscribing to keep the
enrollment alive?
*	Why don't you show a NOTIFY arriving from the PDS informing the
subscriber that the enrollment has been terminated?

The last three paragraphs of section 6.1.1 say:
"A PDS that admits the enrollment request verifies applicable policies,
identifies the requested profile data and prepares a SIP notification to
the device.  Such a notification can either contain the profile data or
contain content indirection information that results in the device
performing profile content retrieval.  The PDS then transmits the
prepared SIP notification.  When the device successfully receives and
accepts the SIP notification, profile enrollment is complete.

When it receives the SIP notification indicating enrollment acceptance,
the device MUST make the new profile effective within the specified
timeframe, as described in Section 7.2.

Once profile enrollment is successful, the PDS MUST consider the device
enrolled for the specific profile, for the duration of the
subscription."

The two parts I have highlighted in bold seem to say that the PDS should
not consider the subscription to exist until the 200 OK to the first
NOTIFY is received.  This contradicts my understanding of the action on
the transition from state 3 to state 5 in Figure 6.

I think the PDS must treat the subscription as started when it sends the
200 OK, because that is when the PDS starts the subscription timer,
whose duration is placed in the Expires header in the 200 OK (and in a
real implementation, the PDS must secure the existence of the
subscription some time; sending the 200 OK seems like an appropriate
moment).  If the subscription does not exist until the 200 OK (NOTIFY)
is received, and if the subscriber responds with a non-2xx final
response that includes a Retry-After, the PDS is in an odd position of
having to retry the NOTIFY even though the subscription does not yet
"exist".

Can you clarify this area of design (and if appropriate, update the
document)?

Don Stewart
Systems Manager
Ericsson Limited 
Registered Office: Unit 4, Midleton Gate, Guildford Business Park,
Guildford, Surrey, GU2 8SG.  Registered Number in England and Wales:
942215 
This communication is confidential and intended solely for the
addressee(s). Any unauthorised review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you in
error, please notify the sender by replying to this transmission and
delete the message without disclosing it. Thank you.

Ericsson Limited does not enter into contracts or contractual
obligations via electronic mail, unless otherwise agreed in writing
between the parties concerned.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorised amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any
such corruption, interception, amendment, tampering or viruses or any
consequences thereof. 

_______________________________________________
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