Subject: [Gen-art] Gen-ART review of draft-ietf-sipping-config-framework-16

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 22 Dec 2009 17:30:08 -0500

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 23 Dec 2009 11:58:26 +0200

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:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 29 Dec 2009 16:39:45 -0500

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
> 
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> 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? 
>> 
>> 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:
>> critical operation. 
>>    The framework specified in this documents SHOULD BE:

---

From: Sumanth Channabasappa <[email-masked]>
Date: Tue, 29 Dec 2009 15:03:41 -0700

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