Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Stastny Richard" <[email-masked]>
Date: Fri, 2 Jun 2006 00:14:56 +0200

>I was using the term to mean a peering exchange (or federation or
>whatever you want to call them) that can be joined dynamically.

On what terms? I still do nor understand. Joining a federation
always involves some legal negotiotions.
 
In addition, a "federation" to do ENUM (i.e. E.164 to URI mapping =
finding out the Carrier-of-Record) and The "federation" to peer VoIP
traffic may be identical, but need not to be.

As I already pointed out on this list, it is still the choice of the
originating service provider to select the peering fabric
 
-sta

________________________________

Von: Andrew Newton [mailto:[email-masked]]
Gesendet: Fr 02.06.2006 00:00
An: Stastny Richard
Cc: [email-masked]; [email-masked]
Betreff: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Stastny Richard wrote:
> 
> I am not quite sure what you mean with "opportunistic"
> peering exchanges

I was using the term to mean a peering exchange (or federation or
whatever you want to call them) that can be joined dynamically.

-andy

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 1 Jun 2006 20:24:11 -0400

> always involves some legal negotiotions.

Well, they require an agreement.  The legality of that agreement is  
another matter.

If the execution of that agreement requires signed contracts, etc...  
all the configuration information for joining that federation does  
not need to be in machine readable form.  Indeed, much of it will not  
be given until an NDA is signed or a service contract is signed, so  
it won't even be available on the web.

If, however, there is intention to have the policies on which the  
peering federation agreement operates to be machine readable, such as  
in the DDDS application proposed by Otmar, then this seems to imply  
that joining the federation is more opportunistic in nature.

> traffic may be identical, but need not to be.

I guess that is one way to look at it.  I've always thought that an  
ENUM service was just a feature or service of a particular  
federation.  After all, many of the commercial ones today have  
mechanisms other than ENUM to convert E.164 numbers to URIs.  And it  
is possible that a federation may have multiple namespace management  
services as E.164 is but just one type of namespace.  A federation  
may decide to offer namespace management for ICQ numbers -- in  
addition to E.164.

> originating service provider to select the peering fabric

Yes.  And to do it today requires no new protocols or work.

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 2 Jun 2006 11:44:34 +0200

> that joining the federation is more opportunistic in nature.

My DDDS proposal allows both:

draft-lendl-speermint-federations-00 is targetted at the former
type of federation (we call it "named federation"). All the DNS
contains is the federation ID. Nothing else is required. From this
the draft (highlighted with !!):

-=-=-=-
3.  Federations

   The proposed method is based upon the concept of a "Federation".  A
   federation in this context is defined as follows:

      A Federation is a group of VoIP service providers which
      *  agree to receive calls from each other via SIP,
      *  agree on a set of administrative rules for such calls
         (settlement, abuse-handling, ...), and
      *  agree on specific rules for the technical details of the
         interconnection.

!! This document does not define what these rules can be and how they
!! are communicated to all members of a federation.  There is no
!! requirement to make those rules public.

   Federations shall use URIs as their identifiers.  It is RECOMMENDED
   that federations use URLs as identifiers which point to documents
   describing the federation.
-=-=-=-

The draft describing the overall algorithm (draft-lendl-domain-policy-ddds-00)
contains an "Examples" section which uses "ad-hoc" federations based
on references to standards. That section contains the following
warning:

-=-=-=-
5.  Examples

   In order to give meaningful examples, we need to define a few types
   of rules.  The definitions here are purely meant to illustrate the
   possibilities.  They MUST NOT be considered as valid examples of real
   entries.

...

   o  The policy-type "std" shall indicate that the URI indicates a
      standard the sender has to fulfill.

-=-=-=-

I haven't written an I-D defining the exact semantics of these
ad-hoc federations.

Our assumption is that named federation (which can hide their
internals from the public) are well suited for peerings between
service providers. 

For the Austrian I-ENUM trial, we're going to start with named
federations only.

Ad-hoc federations are IMHO more suitable for enterprise
environments.

Questions to the group:

* Is there interest in an I-D which defines the semantic of 
  policy rules which can be used to form ad-hoc federations?

* Is there interest in another presentation regarding my 
  domain policy DDDS proposal at the upcoming IETF meeting?

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >