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

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

Roni,

thanks much for reviewing the draft!
> 
> In section 3.3 on the open issue, I think that XML is good direction,
> using it will enable to define media policy not in terms of SDP
> architecture. Still there is a need to be able to map from SDP to
> XML.  The mapping should allow specifying per session and per media
> policy.
> 
I agree. The mapping probably needs to be defined in the XML format 
definition.

> In section 3.6 on the open issue, I think that there should be a
> basic set at least the media and bandwidth. The subscriber may update
> this information, for example, if the peer sends a re-invite. This
> can be very useful for bandwidth management and even provide a tool
> for resource scheduling application that will work also with the non
> session specific policy.
> 
Please see my comments in response Mary's feedback. She had raised the
same issues.

> In section 3.9 why SHOULD is used and not SHALL, if a session policy
> is in place and a UA subscribed to the policy server then it must
> work according to the policy.
> 
Yes, this needs clarification. I'll clarify the application of policies 
to a session in section 3.9 and other places in the draft.

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

ce.

> Section 3.6:
> - OPEN ISSUE: This is a really good and important question.  My initial
> reaction is yes, we should be able to define at least some basic default
> examples to justify and validate why this functionaltiy is even useful
> or needed.  There used to be a scenarios document and I'm wondering if
> it wouldn't be useful to revamp that.  Overall, I found this document to
> be extremely abstract and feel that there's a need for some more
> concrete examples in this document in general.  
> 
Yes, looking at the examples we had in the scenarios draft should be a
good start for determining which kind of information is needed in such a
document. I'll see if I can submit a revamped version of the scenarios 
draft for the next meeting.

In general, I think the general rule should be disclose what you have.
I.e. a UA should essentially encode what it has in the SDP announcement
and a few extra fields (e.g. request URI, session ID). I really would
not want a situation where policy server and UA start to negotiate what
should be disclosed and what not.

Regarding the more general comment having too few examples, I've added a
number of examples in various place of the draft. Hope this helps to
address this concern.

> Section 3.7: 
> - 3rd paragraph, 1st sentence: "Responding timely..." -> "A timely
> response..."
Done.

> - 3rd paragraph, last sentence: break out that parenthetical statement
> into its own sentence. 
> 
Done.

> Section 3.8:
> - 1st paragraph, last sentence: Here's where a more concrete example
> would be really useful. 

Added two specific examples.

> - 3rd paragraph, 3rd sentence: How would the determination be made as to
> whether a notifier would "expect that the session can be admitted at a
> later point in time"?  
> 
I've added an example for that.

> Section 3.9: 
> - 3rd paragraph, 2nd sentence: Could that SHOULD be a MUST?  If not,
> there should be a statement about the consequences of the subscriber not
> applying the new policy decision to this session, or least an example of
> when a subscriber might not want to. 

It should be a MUST. I've also added some text clarifying this.

> - 3rd paragraph, 3rd sentence: It's not clear to me why a subscriber
> would ever need to terminate a session based upon an updated policy.
> Could you add an example here?  
> 
Done.

> Section 3.13:
> - 1st paragraph, last sentence: insert "a" between "on" and "transport".
> 
Done.

> - Example Flow.  It would be really informative to show the detailed XML
> in terms of understanding the changes that might happen between the
> SUBSCRIBE and NOTIFY. And also, example for the local and remote.  I
> know it's tedious, but despite not being normative, examples tend to be
> really useful for developers to really "get it".  You could borrow the
> example that is given in section 7 of the media policy dataset document
> and build from there.   
> 
Yes, I agree. Since the XML format still needs some work to enable its 
use in SUBSCRIBE bodies, I probably won't be able to add an example for 
this revision but will put this on my to do list.

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:26 -0400

Roni,

Thanks!

Volker

-o) with ESMTP id k9K4CRch015084;
	Thu, 19 Oct 2006 23:12:27 -0500 (CDT)
Date: Fri, 20 Oct 2006 00:12:26 -0400
From: Volker Hilt <[email-masked]>
To: "Even, Roni" <[email-masked]>
Cc: [email-masked], Mary Barnes <[email-masked]>,
	[email-masked]
Subject: [Sipping] Re: Review of draft-ietf-sipping-policy-package-01

Roni,

Thanks!

Volker

-o) with ESMTP id k9K4CRch015084;
	Thu, 19 Oct 2006 23:12:27 -0500 (CDT)
Date: Fri, 20 Oct 2006 00:12:26 -0400
From: Volker Hilt <[email-masked]>
To: "Even, Roni" <[email-masked]>
Cc: [email-masked], Mary Barnes <[email-masked]>,
	[email-masked]
Subject: [Sipping] Re: Review of draft-ietf-sipping-policy-package-01

Roni,

Thanks!

Volker