Subject: [PEPPERMINT] First pass at PEPPERMINT BOF #2 Agenda.

From: "Richard Shockey" <[email-masked]>
Date: Thu, 21 Feb 2008 15:48:17 -0500

Comments Please!

#########

IETF 71 PEPPERMINT BOF Agenda

1510-1610 Afternoon Session II 

WEDNESDAY, March 12, 2008

Breakout Room	RAI	peppermint	Provisioning Extensions in Peering
Registries for Multimedia INTerconnection BOF

Chair(s):

Richard Shockey <[email-masked]>
Tom Creighton  <[email-masked]>

RAI Director(s):

Jon Peterson [email-masked]
Cullen Jennings [email-masked]

Agenda Bashing. 

Presentation of the proposed charter.  <Shockey> 10 min ( see below) 

1. 
	Title		: Consolidated Provisioning Problem Statement
	Author(s)	: D. Schwartz, R. Mahy, A. Duric, E. Lewis
	Filename	:
draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00.txt
	Pages		: 12
	Date		: 2008-2-11
	
This document describes the type of data provisioned among Voice
   Service Providers and underscores the need for clearly defined
   structures and interfaces to facilitate this provisioning.  This work is
in support of the service provider peering as defined by the
   SPEERMINT WG.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schwartz-peppermint-consolidated-p
rovisioning-problem-statement-00.txt

2. 	
	Title           : A Provisioning Protocol for ENUM-SIP Addressing
Servers
	Author(s)       : K. Cartwright, et al.
	Filename        : draft-mule-peppermint-espp-protocol-00.txt
	Pages           : 117
	Date            : 2008-02-18

This document defines a provisioning protocol for ENUM-SIP addressing
servers.  This protocol has been recently published as part of
CableLabs(r) PacketCable(tm) specifications.  It allows SIP service
providers to provision and manage session establishment data used by SIP
network elements to route SIP sessions to the target destinations which may
be served by the operator's own internal network or by a session peering
partner.  The data provisioned into an ENUM-SIP addressing server is queried
by SIP entities using ENUM or SIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-protocol-00.t
xt

3. A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Provisioning Protocol Requirements for ENUM-SIP
Addressing Servers
	Author(s)       : T. Creighton, J. Mule
	Filename        : draft-mule-peppermint-espp-requirements-00.txt
	Pages           : 16
	Date            : 2008-02-18

This document presents use cases and protocol requirements for provisioning
ENUM-SIP addressing servers.  The provisioned data is used by an addressing
server to return part of the session establishment data to SIP entities so
that they can route SIP sessions to the target destinations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-requirements-
00.txt

General Discussion

The Usual Questions.

A. Is this a problem that the IETF needs to work on?

B. Who wants to work on this problem?

************

Peppermint Proposed Charter 

Provisioning Extensions in Peering Registries for Multimedia
Interconnection.

Mailing Lists: 

[email-masked]

General information about the mailing list is at:

https://www1.ietf.org/mailman/listinfo/peppermint

Temporary Area Directorate: Real Time Applications (RAI)

Ultimate Area Directorate: TBD

Chairs: TBD

PROPOSED CHARTER FOR PEPPERMINT

The IETF has been working on various aspects of session-based Multimedia
Interconnection among administrative domains. In addition, the IETF has done
significant work on data exchanges among various network elements. 

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

The PEPPERMINT work group is chartered to define what data needs to be
exchanged among Multimedia administrative domains, and how that data should
be structured provisioned and propagated. These protocols would be outside
the normal scope of establishing various forms of a SIP session. These
administrative domains are of any practical size and could be service
providers or enterprise SIP proxy's, such as PBX's.

Data exchanges to facilitate session-based Multimedia Interconnection are
typically between various Client User Agents and Registries or bilateral or
multilateral Registry to Registry.  Data exchanges could include bulk data
as well as real time updates. Typical data include mappings of phone numbers
to URIs, policies surrounding admission to various points of network
interconnection and various types of trunk data.  In addition, there is a
specific need for redistribution of such Registry data to various types of
network databases.  

The working group will draw upon expert advice and ongoing consultation from
the ENUM, SPEERMINT and PROVREG working groups. The working group may also
reuse elements of RFC 4114, if possible.

The final work product(s) from this working group will utilize and be based
on XML documents and XML document exchanges.

PROPOSED GOALS AND MILESTONES

Requirements for Interconnection data exchanges.         Sept 08 

Provisioning of Interconnection data registries.         Nov 08

Provisioning of Interconnection data caches.             Feb 09 

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

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 22 Feb 2008 12:48:34 -0500

Hi Richard,
I have only been at a few BOFs at the stage where a new WG is about to be formed in RAI, so could you clarify a couple things for me?

1) What are the remaining questions to be asked and answered at this BOF in order for a WG to be formed/approved?  Just the charter?

2) I see some items on the agenda which I would consider topics for the WG, not BOF.  Specifically, potential solutions to some of the problems outlined in the charter.  Are they being discussed now to help provide examples that the charter items are solvable, or to make sure the charter is written correctly, or are we expected to actually agree on a solution before the WG is formed?

3) With regard to David's consolidated problem statement draft, what would the ultimate outcome of that draft be?  Would it be a one-and-only-one requirements document for the WG, or would it just be for one particular problem the WG addresses? (I ask because the scope of the charter is broader than the problem draft)

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Shockey
> Sent: Thursday, February 21, 2008 3:48 PM
> To: [email-masked]
> Subject: [PEPPERMINT] First pass at PEPPERMINT BOF #2 Agenda.
>
>
> Comments Please!
>
> #########
>

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 22 Feb 2008 13:27:28 -0500

>  From: Hadriel Kaplan [mailto:[email-masked]]
>  Sent: Friday, February 22, 2008 12:49 PM
>  To: Richard Shockey; [email-masked]
>  Subject: RE: [PEPPERMINT] First pass at PEPPERMINT BOF #2 Agenda.
>  
>  
>  Hi Richard,
>  I have only been at a few BOFs at the stage where a new WG is about to
>  be formed in RAI, so could you clarify a couple things for me?
>  
>  1) What are the remaining questions to be asked and answered at this
>  BOF in order for a WG to be formed/approved?  Just the charter?

A. First task for a 2nd BOF is a re-demonstration of interest and support
within the community for doing the work. The IESG needs to see that it is a
"doable problem" and no one is going to go off and try to boil the ocean or
something like trying to put certs into a e164 number based DNS tree, for
instance.  We need to reask the usual questions and a nose count. Good
attendance obviously helps but, alas, beer will not be served.

B. Consensus on the charter is the next order of business. Though the
charter is ultimately negotiated between the AD's, chairs and BOF consensus.
We've had some input on that we need to finalize rough consensus on scope
and deliverables etc.

>  2) I see some items on the agenda which I would consider topics for
>  the WG, not BOF.  Specifically, potential solutions to some of the
>  problems outlined in the charter.  Are they being discussed now to
>  help provide examples that the charter items are solvable, or to make
>  sure the charter is written correctly, or are we expected to actually
>  agree on a solution before the WG is formed?

The Mule drafts to which you obviously refer are IMHO a demonstration that
the charter items are eminently solvable. The drafts to on the agenda are
not "the solution" only an example of solutions already out there. We only
need to agree on the scope of the solution before the WG is formed. These
drafts, however IMHO are an excellent insight into how the problem might be
solved, once its defined. First the WG will define the requirements then
move to the solution like every other WG. This proposed WG does have the
advantage of having a great deal of thought and work already put into it as
evidenced by these ID's.

>  
>  3) With regard to David's consolidated problem statement draft, what
>  would the ultimate outcome of that draft be?  Would it be a one-and-
>  only-one requirements document for the WG, or would it just be for one
>  particular problem the WG addresses? 

I could be either. That is a charter scope issue. Davids draft tends to deal
with issues surrounding service providers while the charter leaves open the
use of "the solution" for enterprise PBX's etc. There is no reason a group
of enterprises could multi-laterally federate on their own through private
data exchanges. This as we all know has already been done in certain
industry specific market segments.

As much as AD's want narrowly defined charters its clear from comments
already received that the use for such PBX to PBX data exchanges could
occur.

(I ask because the scope of the
>  charter is broader than the problem draft)

Excellent points ...

>  > draft-schwartz-peppermint-consolidated-provisioning-problem-
>  statement-
>  > 00.txt
>  >         Pages           : 12
>  >         Date            : 2008-2-11
>  >
>  >    structures and interfaces to facilitate this provisioning.  This
>  work
>  > is
>  > network elements to route SIP sessions to the target destinations
>  which
>  > may
>  > http://www.ietf.org/internet-drafts/draft-mule-peppermint-espp-
>  protocol-
>  > 00.t
>  > xt
>  >
>  >
>  >
>  > Interconnection among administrative domains. In addition, the IETF
>  has
>  > done
>  > typically between various Client User Agents and Registries or
>  bilateral
>  > or
>  > The working group will draw upon expert advice and ongoing
>  consultation
>  > from
>  > The final work product(s) from this working group will utilize and
>  be
>  > based