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
