Draft: draft-ietf-sipping-config-framework-12.txt Reviewer: Elwell, John [john.elwell@siemens.com] Review Date: 7/3/2007 Review Deadline: 7/9/2007 (extended original WGLC date from 6/25/2007) Status: WGLC Summary: Needs work. Comments: --------- Well, I'm not sure I committed to do a full review, but I said I would look at it. Having spent a few hours trying to get to grips with it, I am afraid I have only been able to put together a few random comments and thoughts, which do not constitute a full review. 1. General I have in the past raised a concern about this document's complexity. I am not sure how much this is due just to the way the document is written (64 pages seems an awful lot to have to read and understand in order to implement this) and how much is due to unnecessary technical complexity. Certainly some of the complexity comes from having 3 profiles that potentially are obtained from different sources. In the enterprise environment, which concerns me mostly, I don't see this being a likely situation. Also, is an authority responsible for the network and/or the device but not VoIP likely to support a SIP event package as a means of making policy available? Furthermore, before enrolment can take place for any of the profiles, the device already has to be configured with certain SIP information, e.g., the address of the outbound proxy, a CA certificate for verifying the identity of the proxy during TLS handshake. I think there is a requirement for a non-SIP means of bootstrapping the configuration. SIP undoubtedly has a role later on for providing notifications of changes, but I sense that too much pre-configuration is needed (or perhaps that is just my perception, since the whole draft is too complex for me to take in the complete picture). I believe another Internet Draft will appear shortly, proposing a much simpler solution, and I would like to hear what the community thinks about that. However, putting those thoughts aside, I still think this draft needs more work. 2. Basically I don't find it an easy document to read. Some examples (in no particular order): - "6. Profile Delivery Framework This section presents the profile delivery framework, the subject of this document." I get quite a number of pages into the document before I get to this statement. I would expect the subject of the document to be presented right up front. - "The section starts by explaining the framework via the profile delivery stages. It then explains how the framework secures the profile data propagation. It ends with considerations such as back-off and retry mechanisms and profile data." However, mixed into this section 6 are a lot of normative statements. I don't think we should be mixing explanation and normative statements like this. - Section 6.1 explains about the three profile delivery stages, yet that is already explained to some extent in section 4.3. - Section 5 gives some use cases, yet these same two use cases are described (but in less detail) in section 4.1. Furthermore there are extended examples in section 8. - In section 1 there is the statement "This framework also addresses change notifications when profiles change" This is the first mention of profile - I would expect to be told what a profile is before being told about profile changes. Expecting the reader to look ahead to section 2 is not very satisfactory. - Section 3 has the title "Executive Summary". While this new section does provide a concise overview of the solution, I don't think we normally use the title "Executive Summary" for such things. - Section 4.2 has the title "Data Model and Profile Types", yet the contents of the section talk only about profile types. - There are two terms Profile Delivery Server and Profile Delivery Stages (both capitalised). Although the acronym PDS is used only for the former, it is rather confusing. - "Profile enrolment is initiated when the device transmits an enrolment request using a SIP SUBSCRIBE request [RFC3265] for the event package specified in Section 7.2." and much later in the same section: "To enroll, the device needs to request enrollment. This is done via a SIP SUBSCRIBE message." We should try to keep everything to do with device behaviour on enrollment together and avoid repetition. I would like to see a clear separation into: - Introduction - Motivation - Overview of solution - Normative part - Examples with avoidance of repetition. Furthermore, the normative part should be sub-structured to make it clear what are the requirements for devices, what are the requirements for PDSs, and what (if any) are the requirements for proxies. 3. Other comments - "If a SIP infrastructure element receives the request, it will relay it to the authoritative proxy for the domain indicated in the Request-URI. The authoritative proxy is required to examine the request (e.g., event package) and transmit it to a PDS capable of addressing the profile enrollment request." This seems to be imposing special requirements on proxies - this seems undesirable. - "The device MUST set the host and port of the Request URI to the concatenation of "_sipuaconfig" and the local network domain/port." This is not backed up by the examples. For example, the example in section 8.1 has the following Request-URI: "sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB @example.com" - "the profile provider's domain name, identities and credentials. Such data can be "configured" during device manufacturing, by the user prior to network connectivity, or via profile data retrieval." This last (profile data retrieval) seems to suggest some sort of recursion. I think we need more explanation. For example, can a given profile provide data that causes a further version of that same profile to be retrieved? Or does one profile provide data on where to retrieve a different profile? What exactly are the requirements on a device in order to support this? - "The From field is populated with the user AoR, if available. This allows the local network provider to propagate user-specific profile data, if available. The "+sip.instance" parameter is set to the device identifier or specifically, the SIP UA instance. Even though every device may get the same (or similar) local-network Profile, the uniqueness of the "+sip.instance" parameter provides an important capability. Having unique From fields allows the management of the local network to track devices present in the network and consequently also manage resources such as bandwidth allocation." I was not aware that a From header field could contain such a parameter. Also this is not reflected in the example in section 8.1. - Section 6.1.4.2. This represents a very complex procedure for forming a SUBSCRIBE request for the device profile. I had great difficulty understanding it. In particular, I don't understand the concept of "device AoR". Is there one value for a class of devices, and all devices of that class send the SUBSCRIBE request to that AoR? Or does each individual device have a different value of device AoR? - Then it goes on to say "If the device does not have a configured or cached Subscription URI, then it can use the device AoR." But earlier it said that the device AoR is configured, so something is wrong. - And then: "When the device needs to present its device identifier it MUST use the UUID-based URN representation for the user portion of the Request-URI, as specified in [RFC4122]." But this seems to be in conflict with the use of a device AoR, if available. - Sections 6.2.1 and 6.2.2 talk about TLS on the first hope. Section 6.2.2 states requirements for the PDS to have an X.509 certificate. However, this is of no relevance when going via a proxy. - Also in 6.2.2: "PDSs that are configured with X.509 certificates (as described above) SHOULD implement SIP Identity as specified in [RFC4474]. When the SIP Identify header is included, the PDS MUST set the host portion of the AoR in the 'From' header to the local network domain." According to my understanding, the PDS acts as the UAS for the SUBSCRIBE request, so its only involvement in RFC 4474 would be as a verifier. The statement above does not make sense. Or are we talking about NOTIFY requests here? If so, are we using the capabilities of RFC 4916 to allow modification of a From header field URI within a dialog? - "A PDS that does not support TLS MUST use content indirection to a PCC that supports authentication and integrity protection for conveying sensitive profile data". Even if the PDS supports TLS and TLS is indeed used on the last hop to the PDS, there is no guarantee that it is used on all hops. So should there be a requirement for content indirection in such cases? - "If the device established next-hop authentication TLS then any such notifications SHOULD be sent over the same TLS session. If the TLS session exists, the device MUST ignore any notifications sent outside the TLS session." Isn't this in conflict with sip-outbound, which allows different TLS connections to be used (different flows) or which allows a TLS connection to be rebuilt if the connectivity check fails? 4. NITS - In sub-section 6.1 it states "Devices and PDSs MUST comply with the requirements as specified in this section." Does this mean sub-section 6.1 or section 6? - "for the event package specified in Section 7.2." The event package is specified in 7, not just 7.2.