Subject: [Sipping] WGLC Review: draft-ietf-sipping-media-policy-dataset-04

From: "Mary Barnes" <[email-masked]>
Date: Fri, 8 Jun 2007 15:26:47 -0500

Draft:  draft-ietf-sipping-media-policy-dataset-04
Reviewer: Mary Barnes
Review Date: 8 June 2007
Review Deadline: 11 June 2007
Status: WGLC

Summary: This draft is on the right track for publication and has nits
that need to be fixed before publication. 

Comments:
---------
I had previously reviewed the -01 version and there's been too many
changes for the rfcdiff to be useful or for my previous comments to
apply. 

- The big comment is that section 8 needs to be reviewed by a Relax NG
Expert per the Note.  Do we have someone in the SIPPING WG that can
review that section?  

Nits:
------
- Header: Need to add "Intended Status:" (i.e., category="std" in the
<rfc> field)  

- General: "media types" vs "media-types" (use one or the other
consistently - i.e., the former is used in the Abstract, the latter in
the 1st paragraph - I'm not sure where else)

- Section 6.1, 3rd paragraph: "attribute" -> "attributes"

- Section 8.10.1: 2nd paragraph: should read the "<domain> element is
only defined inside a <session-policy> element" ( rather than
<session-info> )

- References:
- [2] 3555 has been replaced by 4855 and 4856. 
- [5] has been published as RFC 3688.

_______________________________________________
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: "Mary Barnes" <[email-masked]>
Date: Fri, 8 Jun 2007 15:28:43 -0500

Draft:  draft-ietf-sipping-policy-package-03
Reviewer: Mary Barnes
Review Date: 8 June 2007
Review Deadline: 11 June 2007
Status: WGLC

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication. 

Comments:
----------
I reviewed the diff for this document as compared to the version 
I previously reviewed:
http://www.softarmor.com/sipping/process/wg-review/reviews/draft-ietf-si
pping-policy-package-01-barnes.txt

And, I believe all my previous concerns have been addressed.  There are
a 
few nits that I noticed that should be fixed.

Nits:
------

- Section 3.9, 3rd paragraph, 1st sentence: "SUBSCRIBER" should be
changed to
"SUBSCRIBE" or lower case "subscriber"

- Section 4, 3rd, paragraph, 3rd list item: "an confidentiality-assured"
-> 
"a confidentiality-assured"

- References:
- [2]: TLS reference should likely be changed from RFC 2246 to RFC 4346.
- [9]: SDP reference should likely be changed from RFC 2327 to RFC 4566.

---

From: Volker Hilt <[email-masked]>
Date: Mon, 11 Jun 2007 09:48:50 -0400

Christian,
> 
> one short comment to the media-policy-dataet, concerning creation of session info document, based on offer and answer SDP information (section 4.2):
> - What are the use case for this?

A use case for this are session-specific policies.

> - What would be the related message flow?
> . UA sends A-side SDP description to Policy Server
> . Policy Server returns reviewed and sometimes changed document
> . UA INVITES B-Side
> . UA Receive SDP from B-Side
> . UA sends B-side SDP description to Policy Server
> . Policy Server returns reviewed and perhaps changed document
> . What should the UA A-Side do with this information? RE-INVITE?
> 
The call flows are described in:
http://www.ietf.org/internet-drafts/draft-ietf-sip-session-policy-framework-01.txt
> 
> PS: What about call setup delay in this case?
>  
A policy lookup is usually one round trip time to a server in the local 
network. This lookup should be short and it can be run in parallel to 
other operations (e.g. DNS lookup) so that the actual time contributed 
should be small.

An alternative to session-specific policies are session-independent 
policies, which do not require any messaging at the time a call is set up.

Volker

> 
> -----Ursprüngliche Nachricht-----
> Von: Mary Barnes [mailto:[email-masked]] 
> Gesendet: Montag, 21. Mai 2007 22:56
> An: [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: [Sipping] WGLC: draft-ietf-sipping-media-policy-dataset-04 anddraft-ietf-sipping-policy-package-03
> 
> Hi all,
> 
> This is to announce Working Group Last Call on the following documents:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-media-policy-data
> set-04.txt  (Recently updated to address the merging issue discussed on
> the mailing list)
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-policy-package-03
> .txt (Unchanged since prior to IETF-68)
> 
> This WGLC will end on 11 June 2007.
> 
> Since the WG has previously reviewed these documents, the plan is to
> keep the same set of reviewers that previously volunteered: 
>      Bob Penfield, Shida Schubert, Flemming Andreasen, Roni Even  
> However, anyone additional that would like to volunteer would be
> appreciated to get a fresh set of eyes on the document. 
> 
> Feedback should be sent to the authors' email addresses (which is cc'ed
> using the tools alias in the above for your convenience) and please copy
> the SIPPING mailing list.  
> 
> Note: the original plan was to WGLC this set of documents along with the
> framework document that moved to SIP.  So, stay tuned for an
> announcement on the SIP list of the WGLC plans for that document. 
> 
> Thanks, 
> Mary 
> SIPPING WG co-chair
> 
> 
>

---

From: "Schmidt, Christian" <[email-masked]>
Date: Tue, 12 Jun 2007 09:56:46 +0200

Volker,

thank you for the hint to the policy framework draft.
But there are still doubts, concerning the usage of B-side policy decision for A-side Policy server.
Lets talk about figure 3 (4.3.1) framework draft.

A-side perform policy negotiation (3,4).
INVITE
B-Side perform policy negotiation (6.7). 
OK (possible subset in session parameters)
What could be the interest of User A, to repeat policy negotiation? He can not improve policy results for the planned session.
- Best case could be the same result as within the first negotiation?
- Possible reduction of session policy (e.g. due to the fact, that b-side currently disallow video transmission)

Regards
Christian Schmidt

-----Ursprüngliche Nachricht-----
Von: Volker Hilt [mailto:[email-masked]] 
Gesendet: Montag, 11. Juni 2007 15:49
An: Schmidt, Christian
Cc: [email-masked]; Mary Barnes
Betreff: Re: AW: [Sipping] WGLC: draft-ietf-sipping-media-policy-dataset-04anddraft-ietf-sipping-policy-package-03

Christian,

Volker

---

From: "Schmidt, Christian" <[email-masked]>
Date: Mon, 11 Jun 2007 15:26:20 +0200

Hi Volker,

Please clarify
Regards
Christian Schmidt

-----Ursprüngliche Nachricht-----
Von: Mary Barnes [mailto:[email-masked]] 
Gesendet: Montag, 21. Mai 2007 22:56
An: [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: [Sipping] WGLC: draft-ietf-sipping-media-policy-dataset-04 anddraft-ietf-sipping-policy-package-03

Hi all,

Thanks, 
Mary 
SIPPING WG co-chair

---

From: Volker Hilt <[email-masked]>
Date: Tue, 12 Jun 2007 09:28:30 -0400

Christian,

thanks for your comments!
> 
> thank you for the hint to the policy framework draft. But there are
> still doubts, concerning the usage of B-side policy
decision for A-side Policy server.
> A-side perform policy negotiation (3,4). INVITE B-Side perform policy
> negotiation (6.7). OK (possible subset in session parameters) What
> could be the interest of User A, to repeat policy negotiation? He
> can not improve policy results for the planned session.
> - Possible reduction of session policy (e.g. due to the fact, that
> b-side currently disallow video transmission)
> 
Sending the offer only to the policy server (i.e. steps (3)/(4) and 
(6)/(7)) may indeed sufficient in many cases. This is supported by the 
policy framework and the policy event package.

However, some policies require that the policy server also receives the 
answer. For example, if the policy server wants to insert a media 
intermediary by modifying the media addresses in the SDP announcement, 
it needs to get the answer (containing the remote media address) and 
return a modified answer that contains the addresses of the intermediary.

Thanks,

Volker