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

From: Daryl Malas <[email-masked]>
Date: Mon, 22 Jan 2007 15:04:47 -0700

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