Subject: [Speermint] I'd like to guage interest in restarting a BOF on the subject of Peppermint.

From: "Richard Shockey" <[email-masked]>
Date: Thu, 4 Oct 2007 21:31:44 -0400

This time last year I tried to start up a BOF on some of the ongoing
provisioning issues between various forms of ENUM registries and network
entities. I've had a few folks ask what ever happened to that. I still think
there is a strong need to do this and the work could have relevance if the
scope were expanded not to be just service provider to registry but also PBX
to registries as well.

I'd like to test the water to see if there is any interest in doing this in
Vancouver.

The original BOF proposal was this:

Comments as usual are welcome

Peppermint BOF

Provisioning Extensions in Peering Registries for Multimedia
Intererconnection.

Mailing Lists:

BOF chairs:

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.

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>

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

---

From: "Eli Katz" <[email-masked]>
Date: Wed, 10 Oct 2007 17:16:42 +0100

I concur with Rich, in that any efforts to help standardisation of SP
Registry Provisioning will be useful to the telecom industry. 

The lack of a commonly used (standards based or other) methodology is
currently hindering take up of industry-demanded registry-based
interconnection.

Eli

Eli Katz
Founder & CEO
XConnect - Bridging the VoIP Islands

T : +44 (0) 870 794 1100
F : +44 (0) 870 794 1101
M : +44 (0) 7973 632 364
[email-masked]
www.xconnect.net 

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: 05 October 2007 02:32
To: [email-masked]; [email-masked]
Subject: [Speermint] I'd like to guage interest in restarting a BOF on
thesubject of Peppermint.

This time last year I tried to start up a BOF on some of the ongoing
provisioning issues between various forms of ENUM registries and network
entities. I've had a few folks ask what ever happened to that. I still
think there is a strong need to do this and the work could have
relevance if the scope were expanded not to be just service provider to
registry but also PBX to registries as well.

I'd like to test the water to see if there is any interest in doing this
in Vancouver.

Peppermint BOF

Mailing Lists:

BOF chairs:

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.

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,

Proposed Deliverables

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> <mailto:richard.shockey(at)neustar.biz>

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

---

From: Daryl Malas <[email-masked]>
Date: Thu, 11 Oct 2007 08:51:50 -0600

IMO, I believe this is warranted, but I do not think we are ready for it
yet.  I suspect this will be of a lot more interest in this BOF in about
1 year, after several of the SPEERMINT milestones are completed.

Daryl

---

From: "Creighton, Tom" <[email-masked]>
Date: Fri, 12 Oct 2007 08:45:57 -0400

I disagree.  This work needs to begin immediately so that in a year from
now we might actually have working code.

Tom

> From: Daryl Malas [mailto:[email-masked]]
> Sent: Thursday, October 11, 2007 10:52
> To: Richard Shockey
> Cc: [email-masked]; [email-masked]
> Subject: [Enum] Re: [Speermint] I'd like to guage interest in
restarting
> aBOF on the subject of Peppermint.
> 
> think
> > there is a strong need to do this and the work could have relevance
if
> the
> > scope were expanded not to be just service provider to registry but
also
> PBX
> in
> needs
> of
> DNS
> > tree.  However, there has been little adoption of RFC 4114, and many
of
> the
> 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
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 12 Oct 2007 13:15:46 -0400

Don't you think the work can proceed in parallel? 

Provisioning is the Achillies heel of interconnection ..

>  Sent: Thursday, October 11, 2007 10:52 AM
>  To: Richard Shockey
>  restarting a BOF on the subject of Peppermint.
>  
>  if the
>  also PBX
>  of the
>  to find
>  final work

---

From: Daryl Malas <[email-masked]>
Date: Tue, 16 Oct 2007 15:47:44 -0600

>From my perspective, we are just, finally, nearing completion of the
terminology draft.  Since, we have not completed drafts, such as
"Requirements" and "Architecture", I would be concerned the PEPPERMINT
group/BOF understands exactly what the requirements of the
interconnection would look like in order to provision it appropriately.

IMO, continued discussion around this topic is warranted, but I think
the PEPPERMINT BOF should wait until near or after the following
SPEERMINT milestone is met:

Feb 2008 Submit SPEERMINT minimum requirements for SIP-based VoIP
interconnection. (BCP)

Based on this, I would recommend a BOF in the spring (likely Summer) and
perhaps the need for a WG at the fall 2008 IETF conference.

This way the PEPPERMINT group will fully understand the requirements,
and will be able to appropriately define a charter.

--Daryl

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 16 Oct 2007 21:53:01 -0400

Clearly I don't agree. I think there are time to market issues that require
a parallel effort. The deployment of ENUM in its various forms specifically
private instantiations as well as federations surrounding cable and mobile
networks indicate that if action is not taken anarchy will occur.

Provisioning as I have stated countless times is the Achilles' Heel of the
entire federation process. There are multiple issues in provisioning, not
just the location of various points of interconnection but internal
provisioning of highly cached ENUM servers, what I refer to as IP-SCP's that
are rapidly becoming core network elements of NGN.

For instance discovery of points of interconnection may require separate
internal trunking decisions on how the traffic is to be routed based on
internal policy on how Layer1-3 connections are made.

It is my intention to have a new ENUM ID ready shortly that will outline how
to create a new ENUMservice based on RFC 4904.

>  Sent: Tuesday, October 16, 2007 5:48 PM
>  To: Richard Shockey
>  Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest in
>  > >  IMO, I believe this is warranted, but I do not think we are ready
>  for
>  > >  it
>  > >  yet.  I suspect this will be of a lot more interest in this BOF
>  in
>  > >  about
>  > >  > provisioning issues between various forms of ENUM registries
>  and
>  > >  network
>  > >  > entities. I've had a few folks ask what ever happened to that.
>  I
>  > >  still think
>  > >  > I'd like to test the water to see if there is any interest in
>  doing
>  > >  this in
>  > >  > Vancouver.
>  > >  >
>  > >  >
>  > >  > The ENUM and SPEERMINT working groups are working on various
>  aspects
>  > >  of
>  > >  > Interconnection will require various forms of data to be
>  exchanged
>  > >  among
>  > >  > administrative domains outside the normal scope of establishing
>  a
>  > >  SIP
>  > >  > session.
>  > >  >
>  > >  > containing mappings of phone numbers to URI, policies
>  surrounding
>  > >  the
>  > >  > admission to points of network interconnection and the
>  distribution
>  > >  of
>  > >  > The purpose of the BOF is to determine the need and scope for
>  such
>  > >  data
>  > >  > The IETF has in the past done significant work on data
>  exchanges
>  > >  among
>  > >  > various administrative entities. In particular the PROVREG
>  working
>  > >  group
>  > >  > The ENUM Working group has adapted PROVREG working group
>  protocols
>  > >  to
>  > >  > develop RFC 4114, which facilitates the provisioning of ENUM
>  data in
>  > >  the DNS
>  > >  > participants of the SPEERMINT working group require both data
>  models
>  > >  and
>  > >  > bias will be given to re-using either EPP, HTTP/REST, HTTP/XML-
>  RPC,
>  > >  or
>  > >  > HTTP/SOAP.
>  > >  >
>  > >  > Proposed Deliverables
>  > >  >

---

From: "Creighton, Tom" <[email-masked]>
Date: Wed, 17 Oct 2007 15:11:02 -0400

Daryl:

I understand your concern that we might be placing the cart before the
horse; but have you considered that the cart might actually be a horse?
SPEERMINT, as we all know, was designed to take a collection of
protocols and provide a set of recommendations as to how they should be
used. PEPPERMINT, however, would need to define a set of protocols that
could be used to exchange provisioning data in support of efforts such
as SPEERMINT.  These standards would need to support a myriad of use
cases within the IETF which could then be the basis of a SPEERMINT BCP.

There is a DIRE need for standardization in this area today because the
current standard of exchanging provisioning data (such as call routing
tables) using Excel is not acceptable.

Tom

> Sent: Tuesday, October 16, 2007 17:48
> To: Richard Shockey
> Subject: RE: [Enum] Re: [Speermint] I'd like to guage interest
> inrestarting a BOF on the subject of Peppermint.
> 
for
in
and
I
doing
exchanged
a
surrounding
distribution
such
exchanges
working
protocols
data
> > >  > from those efforts, and the intent of this proposed working
group
> is
> > >  > bias will be given to re-using either EPP, HTTP/REST,
HTTP/XML-RPC,

---

From: Daryl Malas <[email-masked]>
Date: Thu, 18 Oct 2007 09:15:28 -0600

Tom/Richard,

I perceive you both are closer to an existing problem relative to this
than I am.

Let me know how I can support you from SPEERMINT aspects.

--Daryl

---

From: Paul Erkkila <[email-masked]>
Date: Tue, 23 Oct 2007 15:00:40 +0000

I would be interested in this BOF, as I believe there are significant
resources being expended towards solving this problem right now. The
sooner open dialog on issues and methods can be established the better.

-pee

(If it turns out to be a B2B interface for exchanging excel spreadsheets
I'm going to cry in public...)

> Provisioning Extensions in Peering Registries for Multimedia
<snip>