Subject: RE: [Speermint] Policy Definition

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 17 Oct 2006 07:59:50 -0600

Brian wrote:
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Monday, October 16, 2006 11:51 AM
> To: 'Reinaldo Penno'; Jean-Francois Mule; 'Daryl Malas'; 'David
> Schwartz'
> Cc: [email-masked]
> Subject: RE: [Speermint] Policy Definition
> 
> The problem I have with these definitions is that they don't map into
> what
> we are talking about, although I can believe that what I called
> "dynamic
> policy" could have two sub-policies: session dependent and session
> independent.
> 
> Sipping's definitions don't meet "static" policies; the mechanism
To me, that kind of static parameters for UAs are handled in the
configuration framework and associated protocol toolkit: SIPPING
CONFIG-XCAP, etc.
I think we are loosing focus here: we seem to be bogged down by how to
categorize policy stuff (and the behavioral aspects of discovering and
exchanging policies) instead of just mentioning that yeah, some policy
parameters may be static or dynamic, and then discuss what those may be.

> defined in
> the draft is for session dependent policy, but there is also a
> mechanism for
> session-independent policy that is also automated.  I was after the
> distinction of something that needed a contract vs something that
> needed a protocol.

As *you* proposed during the interim meeting, and most everyone seemed
to be ok, I thought we going to table the dynamic exchange of policies
for later.

Jean-Francois.

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

---

From: Michael Haberler <[email-masked]>
Date: Wed, 18 Oct 2006 09:48:28 +0200

Jean-Francois -
> to be ok, I thought we going to table the dynamic exchange of policies
yes, Brian proposed this.

However, consensus in Philadelphia was to follow dynamic and static in
parallel. So let's stick with that - especially since it's an option to
go either route, and federation concepts and terminology are used
throughout this WG.

Frankly, I suggest we do aim a bit higher than just codifying the status
quo. The static route is extinct in the backbone since the mid-nineties
for good reason and  telcos will eventually come around to that fact
also in peering space.

It would be most helpful if people actually try to weigh the effort
needed to implement something along the lines of the dynamic peering
drafts, visavis the ongoing operations nightmare of "static peering",
OPEX, routing loops and all. And it would be also helpful to keep in
mind that the results of this group are for operator use, yes, but not
exclusively.

I feel we're heading the "increasing success by lowering expectations"
route here.

-Michael

ps: http://www.despair.com/viewall.html :-)