Subject: RE: [Speermint] Policies...policies...policies

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 25 Jan 2007 16:33:24 -0500

Sounds good & your suggestion is accepted.  I applaud you for saying you
don't think work is needed as well, that is not always the case.  I
think we will end up owing you a beer in Prague given the time you put
into it.  ;-)

Jason 

> -----Original Message-----
> From: Daryl Malas [mailto:[email-masked]] 
> Sent: Monday, January 22, 2007 5:05 PM
> To: [email-masked]
> Subject: [Speermint] Policies...policies...policies
> 
> Okay, so in San Diego, I was asked, again, to put together a 
> draft on policies, more specifically, the Policy Function.  
> Since, I introduced the Policy Function in the original 
> architecture, I heartily agreed.
> Recently, I decided to spend some time seriously putting this 
> draft together.  First, I spent several hours attempting to 
> identify the problem I was going to solve by writing this 
> draft....then several more hours...then a couple more.  I 
> re-wrote the abstract several times over, and made it about 
> as far as the introduction.
> 
> To be honest, I think the Policy Function is still a 
> reasonable idea; however, I do not think there are currently 
> any problems, which can be solved by it.  Instead of trying 
> to create a problem, and then write a solution to that 
> problem; I would like to suggest this idea is put on hold.
> 
> Through my toiling over potential problems, I came up with a 
> list of policies that might be necessarily solved by some 
> dynamic mechanism:
> 
> Session limits - A peer may want to notify another peer of 
> the number of sessions compared with a limit defined by a 
> policy; in the same way, a peer may request an update as to 
> the number of sessions compared to the limit.  Assuming this 
> truly is a problem (which I can debate with myself on), I 
> think this is a potential general SIP issue, and an event 
> package should possibly be introduced in relation to the 
> Overload work being done in SIPPING.  ...this should not be 
> addressed here.
> 
> LF Route changes - A peer may want to update IP addresses 
> associated with it's AoR for peering on an LF.  The LF would 
> subscribe to the PF for a "route-modify" event package.  
> First, I don't think this is
> necessary.    The only SIP case would be while utilizing a redirect
> server, so this would be potentially introduced as a SIP 
> event package and not a SPEERMINT issue.  Since, the 
> preferred routing mechanism is ENUM (or other), I think this 
> would be solving a "maybe" problem on a "yesterday" routing 
> method.  Second, utilizing ENUM, this would be a DNS change 
> and completely outside the scope of SIP.
> 
> All other policy cases, would almost always be resolved 
> through "paper"
> negotiations and have nothing to do with SPEERMINT 
> introducing any new functions or dynamic methodologies.  
> Also, I couldn't think of any specific peering policies, 
> which aren't already negotiated by every SIP/telecom vendor 
> when setting up a new service agreement.  So, this would be 
> restating the obvious...is that necessary.
> 
> So, my thought is....I came up with the idea of a Policy 
> Function, and right now; I think it is a dumb idea.  At some 
> point down the road, it may be necessary...and if/when we 
> come to that, maybe I'll write a draft on it.  Until then, I 
> agree with the WG chairs, this simply is unnecessary.
> 
> Thoughts?
> 
> --Daryl 
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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