Document: draft-ietf-sipping-config-framework-16
Reviewer: Pete McCann
Review Date: 2009-12-22
IETF LC End Date: 2009-12-24
IESG Telechat date: unknown 

Summary: One big issue to discuss.

Major issues: 

I don't understand why the local network needs to be involved
in SIP provisioning.  The end-to-end principle should dictate 
that SIP is an application that runs transparently over intervening
networks.

From Section 3.2:
   In such cases, local
   network providers may wish to provide local network information such
   as bandwidth constraints to the devices.
Why should the bandwidth constraints applicable to SIP be any different
from the bandwidth constraints applied to any other application?

I suggest dropping the local-network profile type.

Minor issues: 

Figure 5 is confusing: it shows user A obtaining service before
user A's profile is downloaded.  Similar for user B.  Shouldn't
the profile be downloaded to the kiosk before service is provided?

Section 5.2.1:
   Additionally, the device MUST authenticate the PDS
   to ensure that it is obtaining sensitive profile data from a valid
   PDS, except in the bootstrapping scenario.
Why not in the bootstrapping scenario?  That seems to be the most
critical
operation.

Nits/editorial comments: 

Section 5.1.4.2:
   it MUST be
   use
SHOULD BE:
   it MUST use

Section 9:
   The framework specified in this documents 
SHOULD BE:
   The framework specified in this document

Section 9.1:
   in the absence TLS 
SHOULD BE:
   in the absence of TLS