Subject: RE: [Speermint] Policy Definition

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 17 Oct 2006 07:38:37 -0600

Brian wrote:
> While I think this definition is good, I think it is not sufficient.
The main goal is to have a rough definition we feel comfortable with. If
we try to get all the properties of a policy in the definition at this
point, it may be difficult to.

> I think we need to break policy up into several buckets and give each
> a name.
Could we achieve this by providing examples of policy properties in a
couple of sentences? This was the goal of breaking the definition in a
first short sentence, then add to it with a few additional sentences. 

> There is policy expressed statically (possibly by a contract, a web
> page, or some other thing that is human understandable).
Whether it can be exchanged statically or dynamically, I'm not sure the
basic definition of 'policy' differs here.

> 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.
These policy parameters could fit in the SIPPING terminology of session
policies.

> 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.
Yes, I don't think we are implying that session-independent policy
parameters are distinct from session-dependent ones: when instantiated,
a policy param could be updated based on both static & dynamic
constraints.

> 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
> >
> >
> > 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: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 17 Oct 2006 07:52:55 -0600

Reinaldo wrote:
> 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.

Yes for helping distinguish between the things that are
session-dependent vs. session independent. But there are 2 points we are
trying to clarify here and capture in our common understanding that are
not addressed in the SIPPING drafts:

	a) the policy definitions in
draft-ietf-sipping-session-policy-framework-01.txt do not actually
define what a policy is other than by using examples of policy
parameters in areas which have been declared out of scope such as codec,
and QoS.

==> we should keep the basic sentence Brian originally proposed:
"the set of parameters and other information needed by one VSP/ASP to
connect to another."

	b) the SIPPING drafts are geared towards *intra*-domain policies
applicable to UAs of a given domain (UA <-> Policy Server) whereas much
of what we are discussing here is *inter*-domain,  stuff between Policy
Servers or PFs. This may be obvious but it needs to be clear in our
definition.

Jean-Francois. 

> 
> 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
> >
> > > "In the context of session peering, a policy is defined as
> > the set of
> > 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: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 17 Oct 2006 07:59:50 -0600

Brian wrote:
> Sent: Monday, October 16, 2006 11:51 AM
> To: 'Reinaldo Penno'; Jean-Francois Mule; 'Daryl Malas'; 'David
> Schwartz'
> Cc: [email-masked]
> 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
To me, that kind of static parameters for UAs are handled in the
configuration framework and associated protocol toolkit: SIPPING
CONFIG-XCAP, etc.
I think we are loosing focus here: we seem to be bogged down by how to
categorize policy stuff (and the behavioral aspects of discovering and
exchanging policies) instead of just mentioning that yeah, some policy
parameters may be static or dynamic, and then discuss what those may be.

> 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.

As *you* proposed during the interim meeting, and most everyone seemed
to be ok, I thought we going to table the dynamic exchange of policies
for later.

Jean-Francois.

---

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

Jean-Francois.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 18 Oct 2006 08:58:32 -0600

Michael,

   Sure. To be clear, I'm all for having more dynamism - this is not the
point. The point is to try to describe what folks believe should be
exchanged between 2 domains to do L5 peering: discuss the "what" first,
not the "how".
   This is what Omar and I discussed live this week. 
Whether you extract some VSP/ASP domain policy params from a web page, a
contract agreement, an EULA contained in a soft app, a SIP
subscribe/notify exchange, or a DNS DDDS app, it seems that we should
grasp what that 'thing' is.
This will lead to requirement discussions that could feed protocol
mechanisms (right now, it seems reversed).

Jean-Francois.

> From: Michael Haberler [mailto:[email-masked]]
> Sent: Wednesday, October 18, 2006 1:48 AM
> To: Jean-Francois Mule
> Cc: Brian Rosen; [email-masked]
> Subject: Re: [Speermint] Policy Definition
> 
> Jean-Francois -
> >> defined in
> yes, Brian proposed this.
> 
> However, consensus in Philadelphia was to follow dynamic and static in
> parallel. So let's stick with that - especially since it's an option
> to
> go either route, and federation concepts and terminology are used
> throughout this WG.
> 
> Frankly, I suggest we do aim a bit higher than just codifying the
> status
> quo. The static route is extinct in the backbone since the mid-
> nineties
> for good reason and  telcos will eventually come around to that fact
> also in peering space.
> 
> It would be most helpful if people actually try to weigh the effort
> needed to implement something along the lines of the dynamic peering
> drafts, visavis the ongoing operations nightmare of "static peering",
> OPEX, routing loops and all. And it would be also helpful to keep in
> mind that the results of this group are for operator use, yes, but not
> exclusively.
> 
> I feel we're heading the "increasing success by lowering expectations"
> route here.
> 
> -Michael
> 
> ps: http://www.despair.com/viewall.html :-)

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 19 Oct 2006 10:52:26 -0400

OK, so any call signaling related stuff goes into the
session-independent area and these are modulo the timing
variant/invariant stuff.

Ok, I'll go with the flow.

Mike

> Sent: Wednesday, October 18, 2006 2:13 PM
> To: Michael Hammer (mhammer); 'Jean-Francois Mule'; 'Reinaldo Penno'
> Cc: [email-masked]
> I don't see the signaling/media variable being useful.
> Of course you have session dependent/independent Peer 
> Independent policy.
> The Federation may assert session dependent policy, as 
> opposed to a peer asserting one.
> 
> So I think the tree is
> 
> Peer Independent
>     Session dependent
>     Session independent
> Peer Dependent
>     Session dependent
>     Session independent
> 
> That's assuming my "addressing related" axis is subsumed.
> 
> Brian
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Wednesday, October 18, 2006 1:47 PM
> > To: Jean-Francois Mule; Reinaldo Penno
> > Cc: [email-masked]
> > Still chasing down this thread, but a couple comments:
> > 
> > Agree with the fact that we are defining NNI versus the 
> UNI-oriented 
> > stuff SIPPING defined.
> > 
> > Agree that static v. dynamic and session v. session-independent are 
> > two different dimensions:
> > 
> >             "Dynamic" "Static"
> >              Time-    Time-
> >              Variant  Non-Variant
> >             +--------+--------+
> > Session-    |        |        |
> > Variant     |        |        |
> >             +--------+--------+
> > Session-    |        |        |
> > Non-variant |        |        |
> >             +--------+--------+
> > 
> > BTW, the term "session" is sometimes used to mean media and 
> sometimes 
> > used to mean signaling or dialog, which creates lots of confusion.
> > Also, if there are restrictions on what can be put into an 
> SDP body, I 
> > assume that is lumped with the media (session) stuff.
> > 
> > I would prefer using terms like "signaling" for SIP constraints and 
> > "media" for SDP/RTP constraints.
> > 
> > Are there signaling-dependent and signaling-independent 
> aspects also?
> > We may be struggling with a branch of the tree but not 
> discovered the 
> > root yet:
> > 
> > Root
> > +--PeerIndependent
> > +--PeerDependent
> >     +--Call/Signaling Independent
> >     +--Call/Signaling Dependent
> >         +--Session/Media Independent
> >         +--Session/Media Dependent
> > 
> > Mix and match to get all branches.  Thoughts?
> > 
> > Mike
> > 
> > 
> > > Sent: Tuesday, October 17, 2006 9:53 AM
> > > To: Reinaldo Penno
> > > Cc: [email-masked]
> > > session-dependent vs. session independent. But there are 
> 2 points we 
> > > are trying to clarify here and capture in our common 
> understanding 
> > > that are not addressed in the SIPPING drafts:
> > >
> > > parameters in areas which have been declared out of scope such as 
> > > codec, and QoS.
> > >
> > > "the set of parameters and other information needed by 
> one VSP/ASP 
> > > to connect to another."
> > >
> > > applicable to UAs of a given domain (UA <-> Policy
> > > Server) whereas much of what we are discussing here is 
> > > *inter*-domain,  stuff between Policy Servers or PFs. This may be 
> > > obvious but it needs to be clear in our definition.
> > >
> > > Jean-Francois.
> > >
> > > >
> > > > > I think we need to break policy up into several 
> buckets and give 
> > > > > each a name.
> > > > >
> > > > > which federations it belongs to or which transit networks it 
> > > > > connects to, or what ingress gateways it uses.
> > > > >
> > > > > 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.
> > > > >
> > > > > > integrate other types of session peering per the 
> comments that
> > > > this