Subject: [Sipping] Re: Review of draft-ietf-sipping-policy-package-01

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Oct 2006 00:12:22 -0400

Shida,

thanks much for reviewing the draft!
> 
> I only have some technical concerns:
> 
> Section 3.6/3.9
> May be it belongs in the framework document but there is 
> no normative behavior in neither of documents for 
> UAC or UAS when policy server either returns an error 
> upon Subscription or when Notification does not arrivp inserting the remote session
>   description in SUBSCRIBE requests within this subscription.  It MAY
>   skip refreshing the subscription in order to convey information
>   about the remote session description to the notifier.
> 
> Being consistent with my prior comments, the subscriber SHOULD NOT
> include the remote description when the notifier has indicated that
> it is not needed. Suggest changing to:
> 
>   If the subscriber receives a NOTIFY that contains the "local-only"
>   event parameter, it SHOULD NOT include the remote session
>   description in subsequent SUBSCRIBE requests within this
>   subscription.
> 
I've used the proposed text.

> [Editorial] Introduction
> 
> The Intro seems a bit wordy and repetitive. For example, there are at
> least three places where it talks about a user agent disclosing the
> session information to the policy server. I think it needs to be more
> concise.
> 
I've streamlined the introduction.

> [Editorial] on page 8, in section 3.7, it says:
> 
>   However, subscriptions may also be established by applications and
>   automata (e.g. a conference server).
> 
> I don't think that "and automata" adds anything to this sentence. How
> is it different than "applications"?
> 
Removed automata.

> [Editorial] on page 8, in section 3.7, it says:
> 
>   Responding timely to a SUBSCRIBE request is crucial for this event
>   package.
> 
> Suggest "Responding in a timely manner to ..." or "Timely responses to ..."
> 
Done.

Thanks!

Volker

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Oct 2006 00:12:22 -0400

Shida,

Removed automata.

Done.

Thanks!

Volker

---

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Oct 2006 00:12:22 -0400

Shida,

Removed automata.

Done.

Thanks!

Volker

---

From: Volker Hilt <[email-masked]>
Date: Fri, 20 Oct 2006 00:12:22 -0400

Shida,

> upon Subscription or when Notification does not arrive 
> within reasonable time frame. 
> 
I've added some wording that describes this to Section 3.6.

> Section 3.7
>  -1st paragraph, 2nd sentence: Because remote policy server 
> may be contacted, the techniques listed in the draft might 
> not suffice the authentication/authorization. Mentioning 
> of P-A-ID/AIB/SIP-Identity as a potential way to 
> authenticate a client(subscriber) may be good.
> 
I've completely revised the security section, which should now better
describe the mutual authentication/authorization.

> Section 4
> All the security consideration focuses on UA but 
> with policy server possibly providing policy information 
> of the domain to an outside entity, there is a security 
> consideration surrounding the domain's security as well.
> 
> If no proper security is set for providing policy information 
> to an entity outside of the domain, malicious user can gain 
> access on potential attacking point such as IP/port to use 
> etc. Currently all you need is policy server's URI to gain 
> access to this, as there is no correlation between the request 
> that caused 488 and the SUBSCRIBE request.
> 

The policy server can authenticate and authorize the user agent (as
mentioned, I've overhauled the Security Section). After authenticating a
UA a network provider can decide which policy it wants to send to which
UA. It can, for example, have a policy for known/trusted UAs and
a more restrictive policy to unknown UAs. I'm not sure how correlating
the SUBSCRIBE to a 488 would help in this case.

Thanks!

Volker

---

From: Shida Schubert <[email-masked]>
Date: Thu, 19 Oct 2006 21:33:45 -0700

Hi Volker;

I probably need to see the new revised draft before
I can comment on the last two comments.

Thanks
Shida