Subject: RE: [Speermint] Policy Definition

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 17 Oct 2006 09:55:13 -0600

Here is another try based on yesterday's dialogs: 

--- Session peering 'policy' definition:
"In the context of session peering, a policy is globally defined as the
set of parameters and other information needed by one VSP/ASP to connect
to another.
Some of the session policy parameters may be statically exchanged and
set throughout the lifetime of the peering relationship. Others
parameters may be discovered and updated dynamically using by some
explicit protocol mechanisms. These dynamic parameters may also relate
to a VSP/ASP's session-dependent or session independent policies as
defined in [ID-sipping-policy].

Notes:
 - this revised text injects the notions of 'static' vs. dynamic policy
params Brian proposed; the addressing/routing is part of the
session-dependent and session-independent policies of a domain (as you
proposed Brian).
 - it links speermint's policy def (focused on inter-domain) with the
sipping's def (focused on intra-domain) per Reinaldo's proposal.

Thoughts? Good enough for now or not?

Jean-Francois.

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

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 17 Oct 2006 12:37:13 -0400

I believe when the SIPPING folks defined session-dependent and
session-independent polcies they knew that static policies existed. When
you sign a VoIP contract with a Cable providers there are static
policies in place and when two VSPs peer they also sign a contract. It
is no different, the question we need to ask is how much text real
estate we need to give to static policies. Does a IETF WG need to care
if there are policies driven by a contract? I wonder if there are
similar considerations in Inter Domain Routing WG.

Anyway, I just want to make it consistent with other IETF work.

As far as the definition below, I do not believe it is "globally"
defined. Not even static policies might be global. Many dynamic policies
(whether session dependent or independent) are local to a specific
peering point (assuming VSPs peer at more than one location) and/or even
a proxy (calls per second, bw, etc).

Thanks,

Reinaldo

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: Tuesday, October 17, 2006 8:55 AM
> To: Brian Rosen; Reinaldo Penno; Daryl Malas; David Schwartz
> Cc: [email-masked]
> Subject: RE: [Speermint] Policy Definition
> 
> "In the context of session peering, a policy is globally 
> defined as the set of parameters and other information needed 
> by one VSP/ASP to connect to another.
> Some of the session policy parameters may be statically 
> exchanged and set throughout the lifetime of the peering 
> relationship. Others parameters may be discovered and updated 
> dynamically using by some explicit protocol mechanisms. These 
> dynamic parameters may also relate to a VSP/ASP's 
> session-dependent or session independent policies as defined 
> in [ID-sipping-policy].
> 
> Notes:
>  - this revised text injects the notions of 'static' vs. 
> dynamic policy params Brian proposed; the addressing/routing 
> is part of the session-dependent and session-independent 
> policies of a domain (as you proposed Brian).
>  - it links speermint's policy def (focused on inter-domain) 
> with the sipping's def (focused on intra-domain) per 
> Reinaldo's proposal.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Oct 2006 11:09:18 -0400

I can live with this.  I do think we are probably at the point where more
fine grained chopping of language is not going to help.

I would like to ask, though, about scope.  There is often the problem of
scope creep, and I'd like to limit scope whenever possible.

Consider the notion of dynamic policies, and the session dependent.

Is session dependent in scope?  Do we really want to consider, in this
charter incarnation, the idea that from call to call, policies change?

I DO want to consider policy that changes (i.e. dynamic), albeit I'm pretty
sure we want to do a "Version 1" that doesn't do that first.  The question
is whether we literally want to have policies that change per session.

I can see some use of that.  For example, use THIS gateway if you need >256K
of bandwidth, and THAT gateway if you need less.  However, I think we get a
whole lot done before those kinds of issues come up.

So, I can see a policy changing between two calls, so that one call uses the
old policy and the next one uses the new policy.  What I don't see in scope
is the session dependent policy the sipping work discusses, at least within
our current work.

That doesn't mean a change in definition.  Actually, the definition helps,
because I precisely want to say that session-dependent policy is out of
scope for now.

Brian

> Sent: Tuesday, October 17, 2006 11:55 AM

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Oct 2006 11:09:18 -0400

Brian