Subject: [Speermint] Policy Definition

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 10:01:51 -0400

Policy: The set of information needed by one VSP to connect to another that
is agreed to or specified (by some explicit protocol mechanism or contract)
by the Federation, and is not a per-call protocol negotiated value (athough
policy may specify the range of such values).

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

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 18 Sep 2006 17:06:52 +0300

Why is endpoint policy not included in the definition? Isn't it really
the AND'ing of federation and endpoint information?

________________________________

From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, September 18, 2006 5:02 PM
To: [email-masked]
Subject: [Speermint] Policy Definition

Policy: The set of information needed by one VSP to connect to another
that is agreed to or specified (by some explicit protocol mechanism or
contract) by the Federation, and is not a per-call protocol negotiated
value (athough policy may specify the range of such values).

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 10:13:52 -0400

Because the notion of peering in SPEERMINT is between VSPs (and I include
any individual who wants to run his own proxy server in "VSP").  The VSP is
responsible for making sure that the calls meet the policy.  It may do so by
constraining its endpoints, but it could also provide/insert various
functions to meet the policy independent of the endpoint.  An example
function is a transcoder.

Brian

________________________________________
From: David Schwartz [mailto:[email-masked]] 
Sent: Monday, September 18, 2006 10:07 AM
To: Brian Rosen; [email-masked]
Subject: RE: [Speermint] Policy Definition

Why is endpoint policy not included in the definition? Isn't it really the
AND'ing of federation and endpoint information?

________________________________________
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, September 18, 2006 5:02 PM
To: [email-masked]
Subject: [Speermint] Policy Definition

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 10:13:52 -0400

Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 18 Sep 2006 16:10:02 +0200

IMO you do not need the federation for definition, a policyy may also be agreed bi-lateral
Later you may define a federation as a club of VSPs using a common policy
 
Richard

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Mo 18.09.2006 16:01
An: [email-masked]
Betreff: [Speermint] Policy Definition

Policy: The set of information needed by one VSP to connect to another that is agreed to or specified (by some explicit protocol mechanism or contract) by the Federation, and is not a per-call protocol negotiated value (athough policy may specify the range of such values).

 2006 10:13:54 -0400
Content-class: urn:content-classes:message
Subject: Re: [Speermint] Policy Definition
Date: Mon, 18 Sep 2006 16:10:02 +0200
From: "Stastny Richard" <[email-masked]>
To: "Brian Rosen" <[email-masked]>,
	<[email-masked]>
Cc: 

IMO you do not need the federation for definition, a policyy may also be agreed bi-lateral
Later you may define a federation as a club of VSPs using a common policy
 
Richard

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Mo 18.09.2006 16:01
An: [email-masked]
Betreff: [Speermint] Policy Definition

Policy: The set of information needed by one VSP to connect to another that is agreed to or specified (by some explicit protocol mechanism or contract) by the Federation, and is not a per-call protocol negotiated value (athough policy may specify the range of such values).

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 10:16:10 -0400

For the sake of simplicity, a bi-lateral agreement is a small federation.

Brian

> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Monday, September 18, 2006 10:10 AM

---

From: Daryl Malas <[email-masked]>
Date: Mon, 18 Sep 2006 08:18:51 -0600

> value (athough policy may specify the range of such values).
Brian, I think this is good.  Although, I would add one aspect: "...is
agreed to or specified by the Peer and/or Federation, and is...."

--Daryl

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 10:23:05 -0400

I think that things specified by the peer independent of the federation is
out of scope.  I think that is standard SIP, and if we need anything else,
that's sipping/sip work.  I think the scope of SPEERMINT should be limited
to what the federation (including a bi-lat as a small federation) specifies.

Brian

> From: Daryl Malas [mailto:[email-masked]]
> Sent: Monday, September 18, 2006 10:19 AM
> To: Brian Rosen
> Cc: [email-masked]

---

From: "David Schwartz" <[email-masked]>
Date: Mon, 18 Sep 2006 17:26:59 +0300

So we rule out policy nesting?  I think that this definition is too
simplistic.

David

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, September 18, 2006 5:23 PM
To: 'Daryl Malas'
Cc: [email-masked]
Subject: RE: [Speermint] Policy Definition

I think that things specified by the peer independent of the federation
is
out of scope.  I think that is standard SIP, and if we need anything
else,
that's sipping/sip work.  I think the scope of SPEERMINT should be
limited
to what the federation (including a bi-lat as a small federation)
specifies.

Brian

---

From: Daryl Malas <[email-masked]>
Date: Mon, 18 Sep 2006 08:33:23 -0600

The issue is, architecture functions (LF, PF, SF, MF, etc.) can be
located within the peer's networks or hosted by the federation;
therefore, inherently the policy may be local to a peer and NOT hosted
by the federation.  We specified within the architecture draft these
functions may be local to a peer's network or hosted.  In this case,
even though 2 or more peers make a federation, the policy function is
located in each of the peer's networks.

Two distinct differences:

1.  2 Peers make up a federation.  They each host their own policy
function, which is queried by each of the peers as part of the session
establishment process.

2.  2 Peers make up a federation.  They utilize a single hosted policy
function, which is managed by a 3rd party operator (for example).

That's where I was going with this.

--Daryl

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 10:43:53 -0400

Does SPEERMINT scope include the capability to define a new policy mechanism
for endpoints?  I do not think so.  

"Nested policy" may or may not be something we consider in scope.  

Brian

> Sent: Monday, September 18, 2006 10:27 AM
> To: Brian Rosen; Daryl Malas
> Cc: [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Sep 2006 10:53:30 -0400

I don't see where the location of the policy matters.

I think the differentiation you were heading for was a bi-lat may exist in
the context of a federation, in which case policy is "nested".  The bi-lat
may say "we agree to exchange traffic at the XYZ exchange, and our policy at
that exchange is ...".  

Brian

> Sent: Monday, September 18, 2006 10:33 AM
> To: Brian Rosen
> Cc: [email-masked]