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.
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. - 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
