Subject: [PEPPERMINT] First pass at a BoF proposal

From: Andrew Newton <[email-masked]>
Date: Fri, 5 Jan 2007 12:39:16 -0500

FYI... this is the preliminary BoF proposal that has been submitted.

Peppermint BOF

Provisioning Extensions in Peering Registries for Multimedia
INTerconnection.

Mailing Lists:

BOF chairs:

Andrew Newton [[email-masked]]

Richard Shockey [[email-masked]]

Temporary Area Directorate: Real Time Applications (RAI)

Ultimate Area Directorate: TBD

BOF Purpose.

The ENUM and SPEERMINT working groups are working on various aspects of
Multi Media Interconnection. ENUM is specifically chartered to develop
protocols that involve the translation of E.164 numbers to URI's.  
SPEERMINT
has been chartered to develop best current practices among real-time
application service providers and how such services interconnect across
domain boundaries.

It is clear from discussions in both working groups that Multi-Media
Interconnection will require various forms of data to be exchanged among
administrative domains outside the normal scope of establishing a SIP
session.

Such data exchanges might be provisioning of various forms of Registries
containing mappings of phone numbers to URI, policies surrounding the
admission to points of network interconnection and the distribution of
Registry data to various types of databases.

The purpose of the BOF is to determine the need and scope for such data
exchanges, what existing protocols need to be adapted to meet those  
needs
and the appropriate schema and queries are needed to facilitate such
exchanges.

The IETF has in the past done significant work on data exchanges among
various administrative entities. In particular the PROVREG working group
developed various schema and query mechanisms to facilitate the  
exchange of
data among domain name registries and registrars.

The ENUM Working group has adapted PROVREG working group protocols to
develop RFC 4114, which facilitates the provisioning of ENUM data in  
the DNS
tree.  However, there has been little adoption of RFC 4114, and many  
of the
participants of the SPEERMINT working group require both data models and
protocol features not found in RFC 4114.

The proposed PEPPERMINT working group will build upon the knowledge  
gained
from those efforts, and the intent of this proposed working group is  
to find
a provisioning solution for peering as defined by SPEERMINT. The  
final work
product(s) from this working group will be based upon XML.   
Additionally,
bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-RPC, or
HTTP/SOAP.

Proposed Deliverables

Requirements for SPEERMINT data exchange.

Provisioning of SPEERMINT data registries.

Provisioning of SPEERMINT/ENUM data caches.

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

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 8 Jan 2007 10:55:58 +0100

A question regarding the charter:

> Registry data to various types of databases.

Do I read this correctly that you want to include?

* Carriers provisioning numbers into a peering fabric's DB (the "registry") 

* Redistribution of that DB into each carrier's real-time routing DB

Do you also envision direct carrier<->carrier interactions without
a third party acting as the registry? 

Or do you think that this will just be a special case?

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

---

From: Andrew Newton <[email-masked]>
Date: Mon, 8 Jan 2007 07:26:52 -0500

> * Carriers provisioning numbers into a peering fabric's DB (the  

Yes.

> * Redistribution of that DB into each carrier's real-time routing DB

This work could be used for this, but the primary motivation is  
different from my understanding.  Peering fabrics tend to offer their  
members local cache's of the DB.  Today, the syncing of that cache  
requires custom protocols and software.

> Or do you think that this will just be a special case?

I do, as this happens today.  And I'm not sure it is much different  
than the other interactions.  In SPEERMINT terms, this is direct  
peering.

-andy