Subject: [Sipping] Comments on config-framework-11

From: "Elwell, John" <[email-masked]>
Date: Sun, 01 Apr 2007 16:28:45 +0100

Sumanth,

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).

John

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Sun, 1 Apr 2007 14:18:50 -0400

I strongly share the concern that we don't arrive at a situation  
where we need either pre-configuration or devices that are "class A",  
"class B" and "class C". All devices, in all situations, should try a  
small number of configuration options, without human intervention. We  
really don't want manual meta-configuration and the draft needs to  
make this patently clear. Judging from bad experience, software  
writers will make things configurable that shouldn't be, unless told  
otherwise.

If, for efficiency reasons, you want to avoid that a device tries the  
same non-existing service at every reboot, one might imagine some  
kind of negative caching mechanism that stores the non-existence of a  
certain method. I suspect this won't be necessary since DNS already  
supports negative caching and DHCP-induced options are observable as  
to whether they exist or not, but the design team needs to consider  
this issue, as not doing so will lead exactly to the "provide option  
to turn off configuration method X" we don't want. Naturally, this  
also argues for a minimalist approach to configuration. The more  
options, the more temptation there is to "profile".

Henning

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 19 Apr 2007 09:07:12 +0300

Hi,

the draft states that a device identifier "should be based on MAC
address or UUID". 
I was wondering why don't include also IMEI (International Mobile
Equipment Identity) or at least mention it as a possible alternate
representation auto-generated by devices.  

thanks
Sal