Hi, Gonzalo, I understand that the spec is the result of long discussion in the WG to which I am coming late. My apologies. One of the purposes of the Gen-ART review is to bring up questions that relate to whether the document is a good idea for the Internet as a whole.
I share your concerns about SBCs modifying SIP messages. That shouldn't happen. If an access network does this they are not providing true Internet service. However, I think it is the actual imposition of the kinds of policies discussed in the draft, rather than the actual mechanism, that is the violation of the end-to-end principle that will lead to more fragile, less flexible architectures. I.e., adding explicit signaling to a middlebox so it doesn't have to modify the SIP messages does little to address the larger architectural question. While I understand that some access networks might want to limit the bandwidth consumed by a user under congestion conditions, it seems to me that more generic mechanisms, that apply to all applications instead of just SIP applications, would be more appropriate. I don't understand at all why an access network would care about the codec used by a particular application. That seems strictly a matter for end-to-end negotiation between the participants in a call. I'll let Russ decide whether he wants to bring the issues I've raised to the attention of the IESG. -Pete Gonzalo Camarillo wrote: > Hi Peter, > > this is something the WG discussed at great length and the conclusion > was to have local policies. Note that local policies are also used by > the policy framework: > > http://www.ietf.org/id/draft-ietf-sip-session-policy-framework-06.txt > > In the WG there were people that, like you, thought SIP entities > should not be concerned with media level stuff such as bandwidth, > codecs, etc. > However, the fact is that in real-life deployments SIP operators > implement these policies, whether we like it or not, using SBCs. > Having local policies provides them with a way to implement these > policies without violating the end-to-end principle in SIP. That is, > they can implement these policies without having an SBC modify > messages between the user agents. > > The bottom line is that your concerns were shared by some people in > the WG and, thus, were discussed at length when this spec was > written. > Therefore, at this point, I do not think we should revisit that > discussion since the arguments for and against are the same as they > were at the time of writing the spec. > > Cheers, > > Gonzalo > > > > McCann Peter-A001034 wrote: >> Sumanth Channabasappa wrote: >> Hi, Sumanth, >> >>> Peter, >>> >>> Regarding the local network profile, the intent was to provide a >>> mechanism for local networks (which can be a end-user's local >>> network or a Service Provider's network) to provide any information >>> that can help the end-device operate efficiently. While bandwidth >>> is one example, others include outbound proxy to reach the external >>> world. >> >> I thought the outbound proxy was already configured with a DHCP >> option. (not that you should need one anyway). I should be able to >> reach the external world over raw IP, without having to implement >> particular application protocols. >> >>> Can this be used abusively, e.g., to exercise control? Potentially. >>> However, the end-device may be configured to not request or use such >>> information when it does not feel the need. >> >> If we can't justify it maybe we should remove the option. >> >> -Pete >> >>> - S >>> >>> >>> On 12/29/09 2:39 PM, "McCann Peter-A001034" >>> <[email protected]> >>> wrote: >>> >>>> 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
