Hi, Gonzalo, I agree completely that local networks shouldn't modify the end-to-end SIP messages. However, I would go even further and say that they shouldn't be imposing these "policies" against certain codecs in the first place. One of the fruits of the end-to-end principle of system design is that end users can deploy whatever applications they want without asking permission from the network. Do we really want to give intervening networks the tools to control these applications?
-Pete Gonzalo Camarillo wrote: > Hi Peter, > > local networks enforce these types of policies anyway. Currently, > they do it using SBCs (Session Border Controllers) that rewrite the > SIP signalling and open and close firewalls. This mechanism allows > the local network to inform the UA about the policy so that the UA > can comply with it. In this way, the local network does not need to > break the SIP signalling and modify the end-to-end messages between > the endusers (these modifications cause a lot of problems in SIP > networks). Therefore, what this mechanism does it preserving the > end-to-end communication between the endpoints. > > Cheers, > > Gonzalo > > McCann Peter-A001034 wrote: >> 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
