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
