Subject: [Sipping] New Version Notification for draft-ietf-sipping-config-framework-13

From: IETF I-D Submission Tool <[email-masked]>
Date: Thu, 25 Oct 2007 16:43:12 -0400

A new version of I-D, draft-ietf-sipping-config-framework-13.txt has been successfuly submitted by Sumanth Channabasappa and posted to the IETF repository.

Filename:	 draft-ietf-sipping-config-framework
Revision:	 13
Title:		 A Framework for Session Initiation Protocol User Agent Profile Delivery
Creation_date:	 2007-10-25
WG ID:		 sipping
Number_of_pages: 56

Abstract:
This document specifies a framework to enable configuration of
Session Initiation Protocol (SIP) User Agents in SIP deployments.
The framework provides a means to deliver profile data that User
Agents need to be functional, automatically and with minimal or no
User and Administrative intervention.  The framework describes how
SIP User Agents can discover sources, request profiles and receive
notifications related to profile modifications.  As part of this
framework, a new SIP event package is defined for notification of
profile changes.  The framework provides minimal data retrieval
options to ensure interoperability.  The framework does not include
specification of the profile data within its scope.

The IETF Secretariat.

_______________________________________________
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

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 26 Oct 2007 09:59:27 -0600

Folks,

A new version (-13) of the SIP Configuration Framework is now available.

http://tools.ietf.org/html/draft-ietf-sipping-config-framework-13.txt

This includes comments and suggestions from various folks (John Elwell,
Shida Schubert, Dave Robbins, Roni Even, Markus Isomaki, and Peter
Blatherwick come to mind - thanks to everyone else as well). As a note,
I did not include changes that were already agreed upon in previous IETF
meetings (esp. layout). Other changes are a result of discussions
between Josh, Dan and myself.

To summarize the changes:

(Mostly) Technical Changes:
- Added clarification on the use of Outbound based on discussions with
Rohan, Cullen and Peter. This was raised by Markus at the last IETF
since it was unclear as to how Outbound is used for the initial SIP
SUBSCRIBE (prior to registration).
- Removed the term 'device AoR' within the device profile. (We still
allow for configured AoRs to override discovered AoRs.)
- Clarified a few areas in the Security section
- Added clarification regarding user profile retrieval

Editorial Changes:
- Removed Section on "Executive Summary", minimized repetition in the
initial sections (e.g., Overview)
- Added clarification of new terms, such as profile data, early on
- Affected various editorial changes 

- S

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 26 Oct 2007 11:07:47 -0500

Folks,

This email is to announce a two week post-WGLC review of the changes
made to this document. The diff is available at:
http://tools.ietf.org/wg/sipping/draft-ietf-sipping-config-framework/dra
ft-ietf-sipping-config-framework-13-from-12.diff.html

Please review the changes and post any comments on those changes to the
list on or before November 9th, 2007.   If you think the doc is "Ready",
please post a comment to the list as well. 

Regards,
Mary.
SIPPING WG co-chair

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Friday, October 26, 2007 10:59 AM
To: [email-masked]
Subject: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Folks,

Editorial Changes:

- S

_______________________________________________
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

---

From: Josh Littlefield <[email-masked]>
Date: Fri, 26 Oct 2007 13:14:16 -0400

I have reviewed the document and think it is finished.  I think it is
"ready", and I support publication.

Josh Littlefield

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sat, 27 Oct 2007 07:34:28 -0500

I think it is ready. 

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, October 26, 2007 12:08 PM
To: [email-masked]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Folks,

Regards,
Mary.
SIPPING WG co-chair

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Mon, 29 Oct 2007 10:25:07 -0400

I have looked over the document again in its current form and I believe
it is ready to go.  IMHO it should be published now.

Sam

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Friday, October 26, 2007 12:08 PM
To: [email-masked]
Subject: RE: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Folks,

Regards,
Mary.
SIPPING WG co-chair

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]]
Sent: Friday, October 26, 2007 10:59 AM
To: [email-masked]
Subject: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Folks,

Editorial Changes:

- S

---

From: [email-masked]
Date: Mon, 29 Oct 2007 16:58:59 -0400

Hi,
Good to see this update finally posted.  Thanks for all the hard work 
Sumanth! 

I have reviewed all the changes, and see no technical or major editorial 
issues.  I believe the I-D is now complete, and has addressed the comments 
received.  "READY". 

I have only a few very minor editorial nits, which I will pass along 
off-list, for what they are worth. 

-- Peter Blatherwick

"Mary Barnes" <[email-masked]>
26.10.07 12:07
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: [Sipping] Summary: 
draft-ietf-sipping-config-framework-13

Folks,

Regards,
Mary.
SIPPING WG co-chair

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]] 
Sent: Friday, October 26, 2007 10:59 AM
To: [email-masked]
Subject: [Sipping] Summary: draft-ietf-sipping-config-framework-13

Folks,

Editorial Changes:

- S

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 30 Oct 2007 10:45:42 +0200

Hi,

I have read all the draft again, and I think in its current form it is
extremely clear and I see no technical or major editorial issue.
IMHO it is ready to be published.

/Sal

>         To:
>  <[email-masked]>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 31 Oct 2007 17:44:48 +0000

Sumanth,

This is a big improvement on the previous draft - thanks. However, I do
still have lots of comments. In particular, I think there are security
and other holes concerning the case where there is a proxy between the
UA and the PDS. My review record is below:

Draft: drat-ietf-sipping-config-framework-13 
Reviewer: John Elwell
Review Date: 2007-10-30
Review Deadline: N/A
Status: Interim review

Summary: This draft is on the right track but has open issues, described
in the review.

1. "PDSs and devices will implement all the three profile types.  Unless
   configured otherwise, a device will try to obtain all the three
   profile types"
Shouldn't there be a means by which the first profile downloaded can
indicate if there is no need to fetch additional profiles? This would
avoid pre-configuration.

2. "There are no proxies in the network"
This assumption for the Simple Deployment Scenario seems to suggest a
P2P network, which should be outside the scope of this document (a
matter for the P2PSIP group). Does it mean that UAs can contact the PDS
without going through a proxy? If so, say so. However, I am not sure how
typical this case would be. Once configured with an outbound proxy
(which is the norm), future SIP requests, including any SUBSCRIBE or
re-SUBSCRIBE requests to this package, will go through the outbound
proxy according to normal RFC 3261 rules. We shouldn't specify anything
in contradication.

3. "   (A)  Upon initialization, the device obtains IP configuration
        parameters using DHCP.
   (B)  The device performs Profile Enrollment for the device profile ;
        the device profile data is contained in the enrollment
        notification."
Why the device profile? Since the local-network profile is normally
gathered before the device profile, wouldn't the local network profile
be more suitable for this Simple Deployment Scenario?

4. "o  The device MUST use the device identifier and the device
      provider's domain name to form the Request URI."
It should say exactly how the URI is formed from these two components.

5. "Option 1: Devices that support DHCP MUST attempt to obtain the
      hostname of the outbound proxy during the DHCP process, using the
      DHCP option for SIP servers defined in [RFC3361] or [RFC3319] (for
      IPv4 and IPv6 respectively)."
Presumably this domain name must then be used in forming the
Request-URI. Needs more explanation.

6. "Option 2: Devices that support DHCP MUST attempt to obtain the
      local IP network domain"
Presumably this domain is used in the domain part of the AoR. Needs more
explanation.

7. "The device MUST set the Request URI to the user AoR".
I can't figure out how this will work if the SUBSCRIBE request gets
routed via a standard proxy. It seems it would get routed to any
registered contacts for that AoR. Of course, if the user profile PDS is
a registered contact, it will get sent there too. Without looking at the
Event header field, it is impossible for a proxy to determine that such
a SUBSCRIBE request requires special treatment.

8. "In the absence of a Server Identity authenticated TLS session with
   the next-hop SIP entity:
   o  the device MUST NOT respond to any authentication challenges"
The requirement to use TLS is only SHOULD, so if you don't use TLS, you
can never respond to an authentication challenge. This doesn't make
sense.

9. "the device MUST ignore any notifications containing sensitive
      profile data"
How does the device know which data is sensitive? Is this something that
has to be defined with each profile? If so, we need some statement.

10. "Once enrolled, the device obtains the initial notification.  This
is
   authenticated using two methods.  If this initial notification was
   transmitted on the mutually authenticated TLS session established for
   enrollment requests, then it is considered authenticated"
This only works if the TLS session is end-to-end, i.e., no proxy between
the UA and the PDS. If there is a proxy, it is only the proxy that is
authenticated, not the PDS.

11. "If the
   SIP Identity header is absent or the device cannot validate it"
If the profile needs to be downloaded in order to install the CA
certificate, the device will be unable to validate the server and we
have a deadlock situation.

12. "If the
   SIP Identity header is absent or the device cannot validate it , the
   device MUST reject any sensitive profile data "
Same comment about how sensitive profile data is identified.

13. "If the SIP Identity
   header is present, and the device cannot validate it, then it MUST
   reject the profile data and retry enrollment"
This seems to contradict the previous sentence - two conficting actions
for the case where cannot validate.

14. "or those in deployments where communication with
   the PDS in the absence of a mutually authenticated TLS is
disallowed."
Which hop are we talking about - device-to-proxy, inter-proxy,
proxy-to-PDS? I guess there could be closed environments where it is
known that all hops use TLS, or SIPS could be used to ensure this is the
case. Seems to require more explanation.

15. "the PDS MUST set the host
   portion of the AoR in the 'From' header to the Provider's domain"
What does it put in the user-info part?

16. "If known by
   the PDS and the notification will result in data specific to the user
   AoR, the PDS MUST challenge the request using Digest authentication
   specified in [RFC3261]"
There needs to be some discussion about realm. Does the PDS necessarily
use the same realm that the device uses with its domain proxy/registrar?

17. "If the device established TLS with the next-hop entity then any
such
   notifications SHOULD be sent over the same TLS session by the PDS."
We should not preclude multiple TLS sessions (in accordance with
SIP-outbound) and should not preclude a TLS session having been
re-established following loss of an earlier session.
Furthermore, sending over the same TLS session from PDS to proxy does
not guarantee it will be sent over the same TLS session from proxy to
UA. Therefore what do we achieve by recommending it be sent over the
same TLS session?

18. "If no such TLS session exists, the
   device MUST NOT accept any sensitive profile data without verifying
   the presence of, and validating, a SIP Identity header."
The use of TLS is not necessarily a substitute for this, unless the TLS
session is end-to-end, not via a proxy.

19. "Profile data that allows the end-user to communicate with the
         device or SIP service provider."
It would be helpful to say "Profile data that allows the end-user to
communicate by non-SIP means with the device provider or SIP service
provider."

20. "*  Profile data that redirects the device to an entity, such as
         the PCC, that can provide identity data."
Where is this redirection mechanism specified? Or is it simply content
indirection, as defined in this spec, in which case isn't this bullet
redundant (because it is covered by the last bullet)?

21. "                     + If profile enrollment fails due to an
explicit
                       failure or a timeout as specified in RFC3261
                       = Continue with this function()"
It is unclear what "continue with this function() means. Does it mean
continue the inner loop (i.e., the next next-hop SIP entity?

22. "If a PDS wants
   to invalidate a profile it may do so by transmitting a NOTIFY with an
   'empty profile' (not to be confused with an empty NOTIFY)."
What is the syntax of an empty profile? Is it a requirement that each
profile type must define a syntax that means the profile is empty?

23. "and add the "ob" parameter as specified
   in [I-D.ietf-sip-outbound] within the SIP SUBSCRIBE for profile
   enrollment."
In sip-outbound, I can only find reference to use of "ob" in REGISTER
requests. It appears to have no meaning in a SUBSCRIBE request.

24. "The "effective-by"
   parameter MAY be provided in the NOTIFY request for any of the
   profile types."
What is required behaviour if this is omitted?

25. "The
   SUBSCRIBE SHOULD be either authenticated, or transmitted over an
   integrity protected SIP communications channel."
An integrity protected SIP communications channel is not a substitute
for authentication of the UA.

26. "If the specific user or device is unknown, the Notifier MAY
   either accept or reject the subscription."
Do we wish to specify a response in the case of rejection, e.g., 403?

27. "the
   Notifier MAY either respond with profile data (e.g., default profile
   data) or provide no profile information (i.e. no body or content
   indirection)."
Is "no profile information" the same as an "empty NOTIFY", as mentioned
earlier? Use consistent terminology.

28. "   If the URI in the SUBSCRIBE request is a known identity and the
   requested profile information is available (i.e. as specified in the
   profile-type parameter of the Event header),"
Which URI in the SUBSCRIBE request are we talking about - the
Request-URI, the From header field URI?

29. "   If the SUBSCRIBE was received over an integrity protected SIP
   communications channel, the Notifier SHOULD send the NOTIFY over the
   same channel."
This seems to violate RFC 3261 procedures, where a request to the dialog
initiator should be routed to the first entry in the route set. So if
the last proxy through which the SUBSCRIBE request passed does not
record route, the NOTIFY request will not necessarily need to be routed
to that proxy, and thus use of the same TLS connection will not be
possible. Instead, normal RFC 3263 procedures should be used to route to
the first element in the route set or, if no proxy has record-routed,
directly to the remote UA.

30. "The subscription
   dialog MUST NOT be terminated by a NOTIFY with no body."
Is "NOTIFY with no body" the same as an "empty NOTIFY", as mentioned
earlier? Use consistent terminology.

31. "Both the examples are derived from a
   snapshot of Section 4.1"
The word "snapshot" does not seem appropriate here (nor "snapshots" a
little further one).

32. "The examples are purely informative and in case of
   conflicts with the framework or protocols used for illustration, the
   latter should be deemed normative."
I cannot parse this. What does "the latter" refer to? There are three
items: "the examples", the "framework" and "protocols used for
illustration". If it refers to the last of these ("the protocols used
for illustration"), the meaning is still unclear.

33. "
                                      +----------------------+
    +--------+                        | SIP Service Provider |
    | Device |                        |                      |
    |(SIP UA)|                        |  SIP     PDS   HTTP  |
    +--------+                        | PROXY         Server |
                                      |                      |
                                      +----------------------+"
The PDS here is a device profile PDS (because the example shows a
subscription to the device profile). Why is device profile PDS part of
SSP? It could happen to be, but it doesn't seem a very good example.
Better just to show the PDS, HTTP server and SIP proxy in separate
boxes.

34. "    |                                |       |      |
         |                                |       |      |
         |          SUBSCRIBE             |       |      |
   (SReq)|--------device profile--------->|       |      |
         |                                |------>|      |"
Why us device profile, rather than local-network profile, shown as the
first subscription?

35. "   Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
            @example.com"
The Contact URI and Request URI are the same. Doesn't make sense.

36. " NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
        @192.0.2.44 SIP/2.0"
Presumably this is the URI that should have appeared in the contact
header field of the SUBSCRIBE request.

37. "It then transmits the request, after
   establishing a TLS session if required.  If obtained via a SIP proxy,
   the Request-URI is used to route it to a PDS (via an authoritative
   SIP proxy, if required)."
What is "obtained via a SIP proxy"?

38. "When a PDS receives the enrollment request, it can either challenge
   the presented identity (if any) or admit the enrollment."
What is the "presented identity"?

39. "The use of SIP Identity is useful in cases when TLS is not used but
   the device still obtains a profile (e.g., the local-network
profile)."
Identity is useful even when TLS is used, particularly if there is more
than one TLS hop.

40. "In such cases the device provider, or the user, can use the SIP
   Identity header to verify the source of the local-network profile."
The section concerned is to do with local-network profile, not device
profile.

41. "Thus the framework requires that devices supporting
   any sensitive device profiles establish next-hop authenticated TLS
   connections prior to device enrollment."
Next hop authenticated TLS is insufficient - some other means is needed
to authenticate the PDS.

42. "If the user AoR is a SIPS URI then the device is required
   to establish a next-hop authenticated TLS session.  This framework
   requires this for profiles with sensitive data".
Requires SIPS, or requires next hop authenticate TLS? I can't find any
MUST statements relating to this and sensitive data. You can still
subscribe without TLS, but the device MUST ignore notifications with
sensitive data.

John

> Sent: 26 October 2007 16:59
> To: [email-masked]