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
