Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

[Otmar Lendl <[e-mail]>]

On 2006/06/02 02:06, Andrew Newton <[e-mail]> wrote:
> On Jun 1, 2006, at 6:14 PM, Stastny Richard wrote:

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

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 ([e-mail]) | nic.at Systems Engineer >

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