Subject: RE: [Speermint] Policy Function

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 19 Sep 2006 16:53:56 -0400

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.

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,

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
_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 19 Sep 2006 17:26:46 -0400

________________________________

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

---

From: Daryl Malas <[email-masked]>
Date: Wed, 20 Sep 2006 14:01:00 -0600

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