Subject: [Speermint] Policy Function

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 19 Sep 2006 14:39:08 -0400

So,

The audio quality in the afternoon wasn't so great so I did not want to
interrupt. But my take on integrating the PF into other functions is the
following.

1) As soon as we removed the PF term it seems the room started striving
to find what to call these "things". Policy mechanims? Policy
procedures?

2) It seemed to me the only thing missing in the PF description was
mentioning that it could be used at each step independently. Version 01
covers that. Just like security that permeates several layers and can be
used at every stage, so does policies.

3) It seems to me that instead of having a single section that defines
the policy function: what it is, what it provides and its scope; we are
going to repeat that in every section describing each function. This
seems a prime example of something that should be constructed into a
different function (at least programatically)

So, I'm not sold on the idea to have it embedded into other functions.
It seems actually simpler to have it separate. 

Now, if we are going to use DNS, SIP SUBSCRIBE/NOTIFY, Proprietary
methods, a phone call to your peering partner, etc that's another matter
should not obfuscate the issue that having a separate function actually
helps frame and describe things.

Thanks,

Reinaldo

Ps: I did not catch the decision of having a separate policy draft. 

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

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Thu, 21 Sep 2006 14:47:45 -0500

I think creating policy specific document is a good idea.
I support your intention. 

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 3:01 PM
To: Reinaldo Penno
Cc: [email-masked]; Uzelac, Adam
Subject: RE: [Speermint] Policy Function

Through all of the discussions, I do not think policy exchange or the policy function is a baseline requirement for peering (This does not mean it is excluded from the Terminology draft).  I assert we take all of the work we have done and create two documents based on policies.
First, we create a document detailing the creation, exchange, and best practice use of policies (obviously for peering).  Second, we continue to develop Reinaldo's policy event package draft based on the "First".

I volunteered to compile the first version of the policy document and then I will remain as the editor, as I know many of you would like to contribute to this document.

Let me know what the mailing list thinks.

Thanks...--Daryl

On Tue, 2006-09-19 at 17:26 -0400, Reinaldo Penno wrote:
>  
> 
> ________________________________
> 
> 	From: Uzelac, Adam [mailto:[email-masked]] 
> 	Sent: Tuesday, September 19, 2006 1:54 PM
> 	To: Reinaldo Penno; [email-masked]
> 	Subject: RE: [Speermint] Policy Function
> 	
> 	
> 
> 	The general feeling in the room was one of ambiguity in general 
> around the term "policy". I believe that Brian Rosen was given the 
> task to help construct either a better term or better define what 
> policy means in the context of speermint.
> 	
> 	For the exact reason that a separate 'security function' is not 
> defined, PF should be generalized and understood to be a sub-category 
> of the main functions, with the main functions being LF, SF, & MF.
> 
> [Reinaldo]
> 
> I belive the argument still applies. In security we have a set of 
> common procedures that are the same for all protocols (shared key 
> crypto, private, symmatric keys, sha-1, AES, etc). All we specify 
> within each layer is how TLS, Ipsec and others use such 
> infrastructure. I'm not sure we have such groundwork for SIP Policies. 
> This is the common part I'm talking about.
> 
> In any case, whenever we have it, we should specifiy how each component
> can use policies.   
> 
> 
> 	
> 	During the discussion at least 5 different definitions were 
> presented, and few of the definitions overlapped the different 
> functions.
> 	
> 	I propose that we at least make the attempt to sub-categorize the PF 
> to determine if it flows appropriately.  The PF section was simply too 
> ambiguous and difficult to comprehend - IMHO.
> 	
> 	-AU
> 	
> 	 -----Original Message-----
> 	From:   Reinaldo Penno [mailto:[email-masked]]
> 	Sent:   Tue Sep 19 14:40:37 2006
> 	To:     [email-masked]
> 	Subject:        [Speermint] Policy Function
> 	
> 	So,
>