Hi, Dan, I wouldn't want the router/NAT/firewall/SBC to enforce application-specific policies. I think that is actually the root cause of the problem and that box needs to be made transparent.
I read through the policy framework that you linked to, and I understand the motivation of some service providers to attempt to control attached endpoints. I happen to think it is misguided to attempt to do so. -Pete Dan Petrie wrote: > Hi Peter: > > I think that Gonzalo covered this, but here is my view on the > local-network profile. > > The whole point of the local-network profile is so that the SIP UA > can figure out how to make things work. Sure a > router/NAT/firewall/SBC can enforce policies, but that does not help > the UA make things work or figure out what is allowed or preferred. > How does it get out to the big I Internet? A SIP UA is not so > interesting if it can only make local calls. The point is to figure > out the recommended technology to traverse the NAT/firewall, what > media types and/or bandwidth is preferred in the local network. > > Basically session independent policy is dependent upon the > local-network profile > (http://www.ietf.org/id/draft-ietf-sip-session-policy-framework-06.txt). > I expect there is some good text rationale in some of the policy > discussion threads on the email list as well as in the policy draft > for this. There is also an old expired policy requirements draft > that may reiterate the rationale. > > Cheers, > Dan > > > --- On Tue, 12/22/09, McCann Peter-A001034 <[email protected]> > wrote: > >> From: McCann Peter-A001034 <[email protected]> >> Subject: Gen-ART review of draft-ietf-sipping-config-framework-16 >> To: [email protected], >> [email protected] >> Date: Tuesday, December 22, 2009, 5:30 PM 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
