A Framework for Session Initiation Protocol User Agent Profile Delivery
draft-ietf-sipping-config-framework-18

[This was a part of my DISCUSS, but after discussing this on IESG call I am Ok (not happy, but Ok) that missing information about data model in a framework document is Ok]:

I have some major concerns about lack of data model definition in this document. Without that it is not possible to write 2 interoperable implementations. The document says that specific configuration formats are going to be specified in future documents. Are there any examples of such configuration formats?




6.2.3.  effective-by parameter

   Effective-By =  "effective-by" EQUAL 1*DIGIT

Does this value have an upper limit?


9.1.  Local-network profile

   Alternatively, certain deployments may require the entities - device
   and the PDS - to authenticate each other prior to successful profile
   enrollment.  Such networks may pre-configure user identities to the
   devices and allow user-specific local-network profiles.  In such
   networks the PDS will support digest, and the devices are configured

COMMENT: suggest changing "suport digest" to "support Digest authentication" or similar.

For what it is worth, I think the configuration model is overly
complicated and some of the design decisions do not IMO work well
in the Internet environment. For instance, I would prefer discovery
and probing of the local network conditions as opposed to expecting
there to be a SIP-specific configuration server that delivers such
information. For instance, for most networks there will not be
a reliable way to provide any information about available bandwidth,
due to inability to estimate number of concurrent users, radio
conditions, and so on.

Section 3.2., paragraph 5:
>    In more complex deployments, devices connect via a local network that
>    is not controlled by the SIP Service Provider, such as devices that
>    connect via available public WiFi hot spots.  In such cases, local
>    network providers may wish to provide local network information such
>    as bandwidth constraints to the devices.

  If by "bandwidth constraints" you mean *available* bandwidth, that'd
  be a bad example - it's clearly not configuration data. Is there a
  better example or a better way to phrase this?


Section 3.3., paragraph 5:
>    Additional profile types may also be specified.

  By whom? The IETF in future RFCs? Anyone out there deploying this
  framework? (Section 5.3.6 also doesn't make this clear.)


Section 6.2.2., paragraph 1:
>    The
>    implementer SHOULD use their DNS domain name (e.g., example.com) as
>    the value of the "vendor" parameter so that it is known to be unique.

  If you leave this a SHOULD, you cannot depend on it being unique.
  (Because two vendors may decide to not follow the SHOULD and pick
  conflicting values.)


Section 6.2.3., paragraph 1:
>    A value of 0 (zero) indicates that the subscribing
>    user agent must attempt to make the profiles effective immediately
>    (despite possible service interruptions).

  s/must attempt to/MUST/


Section 6.10., paragraph 1:
>    The rate of notifications for the profiles in this framework is
>    deployment specific, but expected to be infrequent.  Hence, the Event
>    Package specification does not specify a throttling or minimum period
>    between NOTIFY requests

  If its expected to be infrequent, you can easily specify a minimum
  period that won't interfere with operation and will prevent accidental
  bursts due to misconfiguration, etc. Please do so?

Section 2 uses the term "entity" inconsistently -- for example, a Device can "contain entities such as a DHCP client" but the term SIP Service Provider can "refer to ... "public entities". I suggest changing the first instance to "application" and the second to "services". 

Section 5.1.1 states:   

   The device needs certain data to create an enrollment request,
   form a Request-URI, and authenticate to the network.  This
   includes the profile provider's domain name, identities and
   credentials.

What are the provider's credentials here? Does this in fact mean the device's or user's credentials with the provider? If so, please express this more clearly.

Section 5.2 uses the term "privacy" when the term "data confidentiality" is meant.  See RFC 4949 for details (and if possible please align the usage of security terminology with RFC 4949).

Section 9.1 that "a PDS may not implement any authentication requirements or TLS". Does this mean that a PDS might happen to operate insecurely, or that it is allowed to (MAY) operate insecurely?

Section 11 includes organizational affiliations.  This information is not typically included in acknowledgements, since it goes against the IETF tradition of treating people as individuals, not as corporate representatives.  In any case, many of the affiliations are out of date.

1) 5.1.4.2: r/subscription URI/Subscription URI

2) 5.2: I noted the same thing as Peter did wrt the use of the term "privacy".

3) 5.2.1: I also noted the same thing Alexey did wrt to the use of Digest authentication over TLS.

4) 5.3.2: r/device must enroll/device MUST enroll

5) 5.3.2: I'd like to see some discussion about what happens when the device uses a cached device, user, and local network profile and it's no the same domain/local network which provided the cached data.

6) 5.3.4: r/This framework recommends the device profile to provide the identities and credentials due to a couple of reasons./This framework recommends the device profile provide the identities and credentials due to a couple of reasons.

7) 5.3.4: r/i.e., data that cannot be compromised/i.e., data that cannot be disclosed to unauthorized parties

8) 6.10: r/NOTIFY requests/NOTIFY requests.

9) 9: r/Compromise of sensitive data/Disclosure of sensitive data

10) 9: r/For sensitive data that should not be subject to snooping, privacy is also required./For sensitive data that should not be disclosed to unauthorized parties, privacy is also required.

11) 9.1: r/In such networks the PDS will support digest, and .../In such networks the PDS will support digest authentication, and ...

I support the discuss positions from Sean, Dan, Peter, and Alexey.