Subject: RE: [Speermint] Policy Definition

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 18 Oct 2006 13:46:57 -0400

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

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: Tuesday, October 17, 2006 9:53 AM
> To: Reinaldo Penno
> Cc: [email-masked]
> Subject: RE: [Speermint] Policy Definition
> 
> 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
> > 
> > 
> > > -----Original Message-----
> > > 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]
> > > Subject: RE: [Speermint] Policy Definition
> > >
> > > 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
> > > >
> > > >
> > > > 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
> > >
> 
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Oct 2006 14:12:59 -0400

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]

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 18 Oct 2006 18:31:47 -0400

> Sent: Wednesday, October 18, 2006 11:13 AM
> To: 'Michael Hammer (mhammer)'; 'Jean-Francois Mule'; Reinaldo Penno
> Cc: [email-masked]

I tend to agree with Brian here. The policy entry/rule/whatever itself
should be enough to tell to whom apply it.

> The Federation may assert session dependent policy, as 
> opposed to a peer asserting one.
> 
> So I think the tree is

This approach is reasonable. 

> That's assuming my "addressing related" axis is subsumed.

Addressing related? 

> > 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 |        |        |
> >             +--------+--------+
> > 
> > > 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:
> > >
> 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.
> > >
> > > "the set of parameters and other information needed by 
> one VSP/ASP 
> > > to connect to another."
> > >
> policies 
> > > applicable to UAs of a given domain (UA <-> Policy
> > > *inter*-domain,  stuff between Policy Servers or PFs. This may be 
> > > obvious but it needs to be clear in our definition.
> > >
> > > Jean-Francois.
> > >
> > > >

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Oct 2006 20:21:53 -0400

In my email starting this discussion I said:
>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.  

I broke out addressing policy (and wanted a term) because it really is the
fundamental part of peering, whereas the other stuff is more secondary.  We
don't really NEED to break out the addressing/routing part, but I thought it
made some sense to.

Brian