Draft: draft-ietf-sipping-config-framework-11.txt Reviewer: Elwell, John [john.elwell@siemens.com] Review Date: 4/1/2007 Review Deadline: Status: Interim Review Summary: Needs work. Comments: --------- As promised, I have reviewed sections 1-5 of draft-11. While this is heading in the right direction, it took me two passes to understand it (even though I had read earlier versions). So I think there is still considerable scope for improving the readability, not least in the area of terminology. Also some technical comments. Specific comments: 1. "The devices are required to support all the three profile types, unless configured otherwise (at a minimum they need to support the device profile )" Presumably this should say that devices are required to implement all three profile types, but in a given deployment they might use only a subset, this being determined by discovery or pre-configuration. Whether the device profile should be a necessary part of that subset, I am not sure - see later comment. 2. "The deployments are required to support the device profile" It is more important to say what has to be implemented in a PDS, rather than what has to be deployed in a given situation. 3. "The life cycle is initiated when the device enrolls for profile data" I have a real problem with this. This is supposed to be a "profile life cycle". I think a profile exists before a device attempts to subscribe to it and continues to exist even after that subscription expires or is cancelled. Furthermore, multiple devices can be subscribed to the same profile at different times or at the same time. Are you really talking about the life cycle of a subscription instead? 4. "Profile Enrollment : the process by which a device requests, and if successful, enrolls with a PDS capable of providing a profile" This seems to correspond very precisely to the concept of subscription in RFC 3265. On the other hand, the term "subscription" is used in some places with apparently a different meaning, which I find confusing. Can't we use "subscription" instead of "enrollment" for an RFC 3265 subscription and avoid its use for other concepts? 5. "configuration management server" This is not defined. 6. "The device is pre-configured to only request the device profile" Why does the device have to be pre-configured? For example, the device profile could indicate that no user profile is needed? 7. "The device performs Profile Enrollment for the device profile ; the device profile data is contained in the enrollment notification" We should say something about how it discovers the PDS for the device profile. I know procedures are rather complicated, but at least mention that it can be by pre-configuration or discovery. 8. Section 4.2, figure. This figure shows a SIP proxy, but the corresponding figure in 4.1 does not. We should either be consistent or explain the reason for the difference. 9. "This also provides the local domain information to help with local-network profile enrollment" Say more precisely how this helps, i.e., by enabling the device to determine where to send the subscription request to. 10. "The device then requests profile enrollment for the device profile" Again we should say something about how the device discovers the PDS for the device profile. 11. "the device and the PDS MUST follow the Profile Life Cycle requirements stated in this section for all supported profile types." We need to understand better what is required to be supported (implemented). Can a single PDS support more than one profile type, or just one? If more than one can be supported, is it mandatory to implement all (even though a given deployment might not use them all)? 12. " | | NO; attempt | | Profile Request | | in specified order" Make it clear that this is specified later in this document (rather than at implementation or deployment time). 13. Second figure in section 5. I don't find this figure intuitive. For example, what happens after the boxes "Profile Change Operation" and "Profile Content Retrieval"? What if both the initial notification and the change notification require content indirection? 14. "The Profile Life Cycle is initiated when the device transmits an enrollment request for a specific profile" See earlier comment on about life cycle. Also we need to say something about how the device discovers where to send the request to. 15. "This framework defines three profile types and an order that MUST be followed by the device in requesting them (when it retrieves two or more of the defined profile types), as follows: o local-network o device o user" This order might apply to initial configuration, but not to change notifications. For example, a device could receive notification of a change of user profile without necessarily needing to go get the local-network and device profiles again first. 16. "creating a profile enrollment subscription" I think what is meant here is a "subscription request" rather than an "enrollment subscription". 17. "Profile Notification Component (PNC), responsible for enrolling devices in Profile event subscriptions" I find this wording odd. Presumably it should say something like "responsible for acting as the notifier for profile event subscriptions". 18. "5.1.1.1. SIP SUBSCRIBE for the Local-Network profile type Before attempting to create a SIP SUBSCRIBE" This is the first mention of a SIP SUBSCRIBE request. It should probably say something like "In order to subscribe to receive the local-network profile, the device MUST send a SIP SUBSCRIBE request. Before it can do this , the device MUST have...." 19. "Alice may have a prior arrangement with the local network operator giving her special privileges.)" Who is Alice in this context? We are talking about the local-network profile, so the user should be irrelevant. 20. "the uniqueness of the "device-id" event header provides an important capability" We should say what this important capability is. 21. "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 and port allocation." Should this be talking about the device-id in the Event header field (relating to my comment above) rather than the From header field? 22. "Devices MUST follow the procedures specified below in the order presented, unless exceptions are made by device manufacturers or Device Providers who may provide an option for the user to choose the order (to suit specific deployment models, for example)." Frankly there are just too many options specified in the text that follows. Can't we eliminate some? 23. " The device MAY be pre-configured with information that can be utilized to identify the host and port of the Request URI. The information can be provided - as examples - when the device is manufactured, by using Service Provider entities (flash card, SIM card)" Normally SIM cards and flash cards tend relate to users rather than devices. I can move them between devices. 24. " If pre-configuration is not an option, or not available, IP configuration" What is "IP configuration" in this context? Is it specifically DHCP? Of auto-discovery in general? 25. "This is based on the user's identity that is usually known in the network (for example, associated with a subscription)" Here is an example where I think "subscription" might be used in a way that is not consistent with the RFC 3265 meaning of the term. 26. "for example, users belonging to the same subscription" And another example - the statement does not make sense in the context of an RFC 3265 subscription. 27. "an example of an exception would be the re-use of devices across Service Providers" This seems to be quite an important exception - the way it is written sounds like it is a corner case, however. 28. " The SIP infrastructure receiving such requests is expected to relay and process profile enrollment requests." In the case of subscription to the user profile, the Request-URI is just the AoR, so normal proxy behaviour will be to send it to any UAs registered as contacts for that AoR. How do we ensure it goes only to the PDS? 29. " Any changes to a Profile as a result of Profile Change Operation MUST result in a Profile Notification to all enrolled devices for that Profile, if any." In the case of the device profile there can be only one device. 30. " At a minimum, a device requires the device profile to be able to function effectively." Why? I could argue that the local network profile should be the "must use" one? First, it is easier to discover, assuming the device has discovered a SIP proxy in the local network. Second, a device could be designed with default settings for that particular device type, which would need to be overridden only as a consequence of attaching to a different local-network or supporting a particular user. 31. Throughout sections 1 to 5 there are numerous uses of the word "service" or "services". This has always been a contentious issue as to exactly what it means. So find a better term or explain exactly what is meant (e.g, SIP registrar/proxy functions).