I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> ).
Please resolve these comments along with any other Last Call comments you may receive. 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
