Subject: RE: [Speermint] Policy Definition

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 16 Oct 2006 04:14:58 -0600

Here is my read of the thread on the 'policy' definition:
"In the context of session peering, a policy is defined as the set of
parameters and other information needed by one VSP to connect to
another. A policy may be agreed to by Peers, or specified by some
explicit protocol mechanism, or defined by a contract in a Federation. A
policy is typically applicable to multiple sessions: it is not a
per-call specific."

Notes:
	- VSP or VSP/ASP to re-use the ecrit terminology in order to
integrate other types of session peering per the comments that this
should not be voice-specific;
	- it incorporates the comments received on the fact that how a
policy is agreed to, or specify by is open to various models (Daryl's
"agreed to by Peers" and Richard's comment on the fact that the
reference to federation in this definition is not needed)
	- it does not prevent a VSP from including endpoint-related
parameters as long as those are representing what the VSP think is
required to 'connect' (per David's question)

Jean-Francois.

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Oct 2006 08:27:58 -0400

While I think this definition is good, I think it is not sufficient.

I think we need to break policy up into several buckets and give each a
name.

There is policy expressed statically (possibly by a contract, a web page, or
some other thing that is human understandable).  

There is policy that has to do with addressing and routing, such as which
federations it belongs to or which transit networks it connects to, or what
ingress gateways it uses.  

There is dynamically discoverable policy that governs things beyond
addressing.  At any point in time, or maybe variable with federations, the
this and static policy may have the same items in them, that is, we may
start with, say, a static policy on how many calls per second we accept, and
later come up with an automated way to discover it.

I propose: "static policy" "addressing (or routing) policy" and "dynamic
policy"

Brian

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 6:15 AM
> To: Brian Rosen; Daryl Malas; David Schwartz
> Cc: [email-masked]
> Subject: RE: [Speermint] Policy Definition
> 
>

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 16 Oct 2006 13:21:25 -0400

I suggest we just we use the terms already defined by the SIPPING WG.
These are session-dependent and session-independent policies. This was
what Jon P. mentioned in the interim meeting.

You can find it here  draft-ietf-sipping-policy-package-01

I leveraged these definitions in thse drafts:

draft-ietf-speermint-architecture-02 (to be submiited soon)
draft-penno-sipping-peering-package-00

If that does not make everybody happy, we can try to map Brian's
suggestions into the SIPPING definitions and make a sub-hierarchy if
needed.

Let me know your thoughts.

Thanks,

Reinaldo

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Monday, October 16, 2006 5:28 AM
> To: 'Jean-Francois Mule'; 'Daryl Malas'; 'David Schwartz'
> Cc: [email-masked]
> I think we need to break policy up into several buckets and 
> give each a name.
> 
> There is policy expressed statically (possibly by a contract, 
> a web page, or some other thing that is human understandable).  
> 
> There is policy that has to do with addressing and routing, 
> such as which federations it belongs to or which transit 
> networks it connects to, or what ingress gateways it uses.  
> 
> There is dynamically discoverable policy that governs things 
> beyond addressing.  At any point in time, or maybe variable 
> with federations, the this and static policy may have the 
> same items in them, that is, we may start with, say, a static 
> policy on how many calls per second we accept, and later come 
> up with an automated way to discover it.
> 
> I propose: "static policy" "addressing (or routing) policy" 
> and "dynamic policy"
> 
> Brian
> 
> > explicit protocol mechanism, or defined by a contract in a 
> Federation. 
> > A policy is typically applicable to multiple sessions: it is not a 
> > per-call specific."
> > 
> > Notes:
> > 	- it incorporates the comments received on the fact 
> that how a policy 
> > is agreed to, or specify by is open to various models 
> (Daryl's "agreed 
> > to by Peers" and Richard's comment on the fact that the 
> reference to 
> > federation in this definition is not needed)

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 16 Oct 2006 13:51:23 -0400

The problem I have with these definitions is that they don't map into what
we are talking about, although I can believe that what I called "dynamic
policy" could have two sub-policies: session dependent and session
independent.

Sipping's definitions don't meet "static" policies; the mechanism defined in
the draft is for session dependent policy, but there is also a mechanism for
session-independent policy that is also automated.  I was after the
distinction of something that needed a contract vs something that needed a
protocol.

It's a little harder to decide we need a term for the addressing related
"policies".  I suggested we do, primarily because they are not really policy
decisions in the classical sense, but routing decisions, although we have
been tending to call them "policy".  Again, you can imagine session
independent as well as session dependent versions of these.  Consider the
effect of congestion on a choice, or "buy 3 get one free" charging.  Those
would be "session dependent", even though normally, routing of voice traffic
is more classically session independent.

Brian

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 1:21 PM
> To: Brian Rosen; Jean-Francois Mule; Daryl Malas; David Schwartz
> Cc: [email-masked]