Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
From: "Cartwright, Kenneth" <[email-masked]>
To: "Andrew Newton" <[email-masked]>
Cc: [email-masked]
Date: Tue, 26 Feb 2008 12:38:32 -0500
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>

Andy, one of the docs up for consideration at the BOF in Vancouver in
fact spoke to the use of zone files (and I'm not saying that that was
necessarily the right approach).  This is indicative of the point that
I'm making that the specifics of the problem(s) to be addressed by the
WG have not yet been defined by the group in a requirements doc.  So,
should a partial list of possible RFCs and technologies that should
underlie the solution(s) be pre-determined in the charter?  I do not
think so.  That's all.

Ken

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 10:14 AM
To: Cartwright, Kenneth
Cc: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17

On Feb 25, 2008, at 4:41 PM, Cartwright, Kenneth wrote:

> Should SSL, HTTP, TCP, Zone Files, HTTP Digest, WSDL, SOAP, etc, etc 
> all be added into the list?

Zone files and WSDL?  If the scope of the problem is so unknown that the
net has to be cast that wide, I do not think the IETF should charter
such a working group.

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Tue, 26 Feb 2008 11:06:58 -0500
Subject: [PEPPERMINT] presumed final peppermint agenda.
Sender: [email-masked]

I think this about does it unless someone has something to add..

IETF 71 PEPPERMINT BOF Agenda

Provisioning Extensions in Peering Registries for Multimedia INTerconnection

1510-1610 Afternoon Session II
Franklin 11/12	INT	dna	Detecting Network Attachment WG
Franklin 5	OPS	grow	Global Routing Operations WG
Franklin 3/4	RAI	peppermint	Provisioning Extensions in Peering
Registries for Multimedia INTerconnection BOF
Franklin 13	RTG	isis	IS-IS for IP Internets WG
Salon I	SEC	ltans	Long-Term Archive and Notary Services WG
Franklin 5	SEC	msec	Multicast Security WG

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-01.txt
	Pages           : 117
	Date            : 2008-02-25

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 SIP service provider'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-01.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: Andrew Newton <[email-masked]>
To: "Cartwright, Kenneth" <[email-masked]>
Date: Tue, 26 Feb 2008 10:13:52 -0500
Cc: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
Sender: [email-masked]

On Feb 25, 2008, at 4:41 PM, Cartwright, Kenneth wrote:

> Should SSL, HTTP, TCP, Zone Files, HTTP
> Digest, WSDL, SOAP, etc, etc all be added into the list?

Zone files and WSDL?  If the scope of the problem is so unknown that  
the net has to be cast that wide, I do not think the IETF should  
charter such a working group.

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

From: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 25 Feb 2008 22:30:53 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [PEPPERMINT] [Speermint] I-D Action:draft-lendl-speermint-background-01.txt
Sender: [email-masked]

Well... working for one of only two vendors who implemented it, afaict, it failed for multiple reasons.  None of them had to do with prefix aggregation or scalability, at least at the time.  BGP was definitely a poor choice, though more for marketing/perception reasons than technical, albeit there were some major technical issues with it too.  It was never tied to BGP for IP routing - it operated on a separate plane really, and even had a different protocol model for internal route distribution, but yes it inherited too much of BGP in terms of deployment model and some unnecessary baggage.  The big killer though, imho, was there was no real problem at the time that it solved.  It's moot though - I'm definitely not suggesting a TRIP down memory lane.
:)

-hadriel

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Monday, February 25, 2008 8:26 PM
> To: Hadriel Kaplan; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Speermint] I-D Action:draft-lendl-speermint-background-
> 01.txt
>
> >  Awesome draft. (I missed it the first time 'round)
> >
> >  I agree with your statement of "The obvious solution is to add an on-
> >  demand mapping step ahead of the routing protocol."  The trick will be
> >  how that works/scales, and how it interacts with a routing protocol.
> >  The easy case is the non-transit bilateral peering - the very hard
> >  case is transit.
> >
> >  One very minor nit: I don't think TRIP failed due to being prefix-
> >  based and thus needing aggregation.  I think it failed because the
> >  market wasn't ready for it (the problem didn't need to be fixed for
> >  most people yet), the idea of implementing/using BGP scared off voip
> >  vendors, and it didn't cover some of the routing selection models
> >  people need.
>
> IMHO TRIP failed because it was using a 120 mm howitzer to deal with a
> problem better dealt with a BB gun. There were enough issues with BGP as
> it
> was.

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Mon, 25 Feb 2008 20:33:23 -0500
Subject: [PEPPERMINT] FW: I-D Action:draft-mule-peppermint-espp-protocol-01.txt
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_03F1_01C877ED.AEEA14F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, February 25, 2008 1:15 PM
To: [email-masked]
Subject: I-D Action:draft-mule-peppermint-espp-protocol-01.txt

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

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

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 SIP service provider'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-01.t
xt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-mule-peppermint-espp-protocol-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-mule-peppermint-espp-protocol-01.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_03F1_01C877ED.AEEA14F0
Content-Type: Message/External-body;
	name="ATT00932.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00932.dat"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-mule-peppermint-espp-protocol-01.txt

------=_NextPart_000_03F1_01C877ED.AEEA14F0
Content-Type: Message/External-body;
	name="draft-mule-peppermint-espp-protocol-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-mule-peppermint-espp-protocol-01.txt"

Content-Type: text/plain
Content-ID: <2008-02-25100245.I-D\@ietf.org>

------=_NextPart_000_03F1_01C877ED.AEEA14F0
Content-Type: text/plain;
	name="ATT00935.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00935.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_03F1_01C877ED.AEEA14F0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_NextPart_000_03F1_01C877ED.AEEA14F0--

From: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, <[email-masked]>
Date: Mon, 25 Feb 2008 20:25:48 -0500
Cc: [email-masked], [email-masked]
Subject: Re: [PEPPERMINT] [Speermint] I-D Action:draft-lendl-speermint-background-01.txt
Sender: [email-masked]

>  Awesome draft. (I missed it the first time 'round)
>  
>  I agree with your statement of "The obvious solution is to add an on-
>  demand mapping step ahead of the routing protocol."  The trick will be
>  how that works/scales, and how it interacts with a routing protocol.
>  The easy case is the non-transit bilateral peering - the very hard
>  case is transit.
>  
>  One very minor nit: I don't think TRIP failed due to being prefix-
>  based and thus needing aggregation.  I think it failed because the
>  market wasn't ready for it (the problem didn't need to be fixed for
>  most people yet), the idea of implementing/using BGP scared off voip
>  vendors, and it didn't cover some of the routing selection models
>  people need.

IMHO TRIP failed because it was using a 120 mm howitzer to deal with a
problem better dealt with a BB gun. There were enough issues with BGP as it
was.

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

From: Hadriel Kaplan <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 25 Feb 2008 18:24:02 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [PEPPERMINT] I-D Action:draft-lendl-speermint-background-01.txt
Sender: [email-masked]

Awesome draft. (I missed it the first time 'round)

I agree with your statement of "The obvious solution is to add an on-demand mapping step ahead of the routing protocol."  The trick will be how that works/scales, and how it interacts with a routing protocol.  The easy case is the non-transit bilateral peering - the very hard case is transit.

One very minor nit: I don't think TRIP failed due to being prefix-based and thus needing aggregation.  I think it failed because the market wasn't ready for it (the problem didn't need to be fixed for most people yet), the idea of implementing/using BGP scared off voip vendors, and it didn't cover some of the routing selection models people need.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Monday, February 25, 2008 4:15 PM
> To: [email-masked]
> Subject: I-D Action:draft-lendl-speermint-background-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>         Title           : VoIP Peering: Background and Assumptions
>         Author(s)       : O. Lendl
>         Filename        : draft-lendl-speermint-background-01.txt
>         Pages           : 15
>         Date            : 2008-02-25
>
> This documents provides background for the work on VoIP peering and
> tries to provide guidance on what kind of work is needed to
> facilitate widespread SIP-based peering of telephony networks.  It is
> intended to spur discussion on the work about peering and should also
> serve as input to the ongoing discussions on reducing Spam for
> Internet Telephony (SPIT).
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lendl-speermint-background-
> 01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
>         "get draft-lendl-speermint-background-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-lendl-speermint-background-01.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
_______________________________________________
PEPPERMINT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/peppermint

Content-class: urn:content-classes:message
Date: Mon, 25 Feb 2008 16:41:01 -0500
From: "Cartwright, Kenneth" <[email-masked]>
To: "Andrew Newton" <[email-masked]>
Cc: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
Sender: [email-masked]

Hi Andy,
 
 1)  Ok.  We'll agree to disagree.
 2)  I did not say that it said that we MUST use 4114.  You are correct,
it certainly does not say that.
 3)  I guess we'll have to agree to disagree again.  Proposing a
possible and partial solution before the problem has even been defined
is not the best approach, imho.  Your proposal to add REST into the list
of possible partial solutions further bolsters my point.  It is not good
to start listing possible partial solutions in the charter before the
problem has been clearly defined.  Where do you stop adding items to the
list and how do you know that REST is good (or the best approach) for
the problem(s) to be solved?  Should SSL, HTTP, TCP, Zone Files, HTTP
Digest, WSDL, SOAP, etc, etc all be added into the list?  I think not.
It's best to leave that to the WG, imho.

But we've beaten this to death now and we may have to agree to disagree.
:-)

Ken

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 3:02 PM
To: Cartwright, Kenneth
Cc: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17

On Feb 25, 2008, at 1:50 PM, Cartwright, Kenneth wrote:

> Hi Andy,
>
> On the first point, I was there and listening intently and 
> participating as was appropriate, and the impression I came away with 
> was the one I communicated.  But obviously, this was my impression, 
> certainly not a formal position of the BOF.

Let's just agree to disagree on this point, especially since it might be
inconsequential.

> On the second point, the WG has not even fully agreed on the scope or 
> nature of the problem, so putting what could be part of the solution 
> in the charter is premature, imho.  Furthermore, the charter should 
> not suggest the solution, imho.

I do not believe the text of the charter is saying that 4114 MUST be
used.  It is simply pointing at a specification that already addresses
this space, and says a potential working group MAY use PARTS of 4114.

>  The charter should identify the broad scope of the problem and leave 
> the rest (e.g. the specific definition of the
> problem(s) and the corresponding solutions) up to the WG, imho.

I disagree. Some working group charters do specifically carve out scope
to better focus participants.  I think that would be appropriate here.
I'd even be in favor further limiting the solution space beyond the XML
limitation, such as saying that it will be an XML/REST solution.

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

From: Andrew Newton <[email-masked]>
To: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 25 Feb 2008 15:01:48 -0500
Cc: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
Sender: [email-masked]

On Feb 25, 2008, at 1:50 PM, Cartwright, Kenneth wrote:

> Hi Andy,
>
> On the first point, I was there and listening intently and  
> participating
> as was appropriate, and the impression I came away with was the one I
> communicated.  But obviously, this was my impression, certainly not a
> formal position of the BOF.

Let's just agree to disagree on this point, especially since it might  
be inconsequential.

> On the second point, the WG has not even fully agreed on the scope or
> nature of the problem, so putting what could be part of the solution  
> in
> the charter is premature, imho.  Furthermore, the charter should not
> suggest the solution, imho.

I do not believe the text of the charter is saying that 4114 MUST be  
used.  It is simply pointing at a specification that already addresses  
this space, and says a potential working group MAY use PARTS of 4114.

>  The charter should identify the broad scope
> of the problem and leave the rest (e.g. the specific definition of the
> problem(s) and the corresponding solutions) up to the WG, imho.

I disagree. Some working group charters do specifically carve out  
scope to better focus participants.  I think that would be appropriate  
here.  I'd even be in favor further limiting the solution space beyond  
the XML limitation, such as saying that it will be an XML/REST solution.

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

Content-class: urn:content-classes:message
Date: Mon, 25 Feb 2008 13:50:26 -0500
From: "Cartwright, Kenneth" <[email-masked]>
To: "Andrew Newton" <[email-masked]>
Cc: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
Sender: [email-masked]

Hi Andy,

On the first point, I was there and listening intently and participating
as was appropriate, and the impression I came away with was the one I
communicated.  But obviously, this was my impression, certainly not a
formal position of the BOF.

On the second point, the WG has not even fully agreed on the scope or
nature of the problem, so putting what could be part of the solution in
the charter is premature, imho.  Furthermore, the charter should not
suggest the solution, imho.  The charter should identify the broad scope
of the problem and leave the rest (e.g. the specific definition of the
problem(s) and the corresponding solutions) up to the WG, imho.
 
Ken

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 1:13 PM
To: Cartwright, Kenneth
Cc: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17

On Feb 21, 2008, at 4:04 PM, Cartwright, Kenneth wrote:

> Just curious what the thinking is behind this statement in the
> charter:
>
> "The working group may also reuse elements of RFC 4114, if possible."
>
> This subject was discussed at the last BOF and received little support

> (if any at all).  So while 4114 certainly need not be ruled out as an 
> option, singling it out for inclusion the charter of the WG seems (1) 
> un-necessary, (2) somewhat inappropriate detail for a charter because 
> it suggests a partial *solution* when the charter is designed to 
> define just the scope of the *problem(s)* to be analyzed and solved by

> the WG, and (3) possibly contradictory to a general opinion expressed 
> at the last BOF.  So it seems that the charter would not be harmed by 
> removing this statement, but would be improved by removing it.

First, I'm not sure about your first point regarding "little support".
While I was not in attendance, I did listen in via audio (and even made
a few statements via Jabber).  I do not remember any solution path
having support over others.  I was under the impression that the
available solution paths were being explored, and the feedback being
sought was about the necessary level of desire to solve the problem
through any of the solutions available.  Again, I was not there, so I
could be wrong.

Second, I think leaving the wording around 4114 in the text is a good
idea.  Given that EPP and 4114 solve some aspects of this problem, it is
reasonable for the IETF to ask why you/we are asking for a working group
to solve the same problem and why 4114 cannot be re-used.

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

From: Andrew Newton <[email-masked]>
To: "Cartwright, Kenneth" <[email-masked]>
Date: Mon, 25 Feb 2008 13:12:55 -0500
Cc: [email-masked]
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
Sender: [email-masked]

On Feb 21, 2008, at 4:04 PM, Cartwright, Kenneth wrote:

> Just curious what the thinking is behind this statement in the  
> charter:
>
> "The working group may also reuse elements of RFC 4114, if possible."
>
> This subject was discussed at the last BOF and received little support
> (if any at all).  So while 4114 certainly need not be ruled out as an
> option, singling it out for inclusion the charter of the WG seems (1)
> un-necessary, (2) somewhat inappropriate detail for a charter  
> because it
> suggests a partial *solution* when the charter is designed to define
> just the scope of the *problem(s)* to be analyzed and solved by the  
> WG,
> and (3) possibly contradictory to a general opinion expressed at the
> last BOF.  So it seems that the charter would not be harmed by  
> removing
> this statement, but would be improved by removing it.

First, I'm not sure about your first point regarding "little  
support".  While I was not in attendance, I did listen in via audio  
(and even made a few statements via Jabber).  I do not remember any  
solution path having support over others.  I was under the impression  
that the available solution paths were being explored, and the  
feedback being sought was about the necessary level of desire to solve  
the problem through any of the solutions available.  Again, I was not  
there, so I could be wrong.

Second, I think leaving the wording around 4114 in the text is a good  
idea.  Given that EPP and 4114 solve some aspects of this problem, it  
is reasonable for the IETF to ask why you/we are asking for a working  
group to solve the same problem and why 4114 cannot be re-used.

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Sun, 24 Feb 2008 17:10:39 -0500
Subject: [PEPPERMINT] FW: [CYBERTEL] The Future of IP Interconnection: Technical, Economic and Public Policy Aspects
Sender: [email-masked]

FYI from our friends at the Commission..

********

The following report, produced by WIK-Consult on behalf of the 
European Commission, has just been published on the European 
Commission's web site. I had the pleasure and honor of working with 
some very exceptional colleagues. Those of you who are familiar with 
my previous work on the subject will see that this is a deeper and 
more comprehensive treatment.

===============

The Future of IP Interconnection: Technical, Economic and Public 
Policy Aspects - prepared by WIK-Consult.
http://ec.europa.eu/information_society/policy/ecomm/library/ext_studies/ind
ex_en.htm#2008

Executive Summary only:
http://ec.europa.eu/information_society/policy/ecomm/doc/library/ext_studies
/future_ip_intercon/ip_intercon_study_exec_sum.pdf

Full Study:
http://ec.europa.eu/information_society/policy/ecomm/doc/library/ext_studies
/future_ip_intercon/ip_intercon_study_final.pdf

Cheers,
= Scott

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

From: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>, <[email-masked]>
Date: Fri, 22 Feb 2008 13:27:28 -0500
Subject: Re: [PEPPERMINT] First pass at PEPPERMINT BOF #2 Agenda.
Sender: [email-masked]

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

>  
>  
>  -hadriel
>  
>  
>  > -----Original Message-----
>  > From: [email-masked] [mailto:peppermint-
>  [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!
>  >
>  > #########
>  >
>  > 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

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

From: Hadriel Kaplan <[email-masked]>
To: Richard Shockey <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 22 Feb 2008 12:48:34 -0500
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [PEPPERMINT] First pass at PEPPERMINT BOF #2 Agenda.
Sender: [email-masked]

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!
>
> #########
>
> 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
_______________________________________________
PEPPERMINT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/peppermint

From: "Richard Shockey" <[email-masked]>
To: "'Cartwright, Kenneth'" <[email-masked]>, <[email-masked]>
Date: Thu, 21 Feb 2008 17:01:34 -0500
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
Sender: [email-masked]

4114 comprises many things, both data objects as well as transport protocols
EPP etc.

Elements might just be parts of 4114 like the XML objects etc .. and the
word MAY is just that _maybe_.

IETF likes to reuse things if possible,  but your point is well taken and
review of the charter would be the first order of business in Philadelphia.

Frankly I would not have any personal objections to removing the sentence.
Something we might hum on.

Your comment, in any event, is most welcome. 

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of Cartwright, Kenneth
>  Sent: Thursday, February 21, 2008 4:05 PM
>  To: [email-masked]
>  Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
>  
>  Just curious what the thinking is behind this statement in the
>  charter:
>  
>  "The working group may also reuse elements of RFC 4114, if possible."
>  
>  This subject was discussed at the last BOF and received little support
>  (if any at all).  So while 4114 certainly need not be ruled out as an
>  option, singling it out for inclusion the charter of the WG seems (1)
>  un-necessary, (2) somewhat inappropriate detail for a charter because
>  it
>  suggests a partial *solution* when the charter is designed to define
>  just the scope of the *problem(s)* to be analyzed and solved by the
>  WG,
>  and (3) possibly contradictory to a general opinion expressed at the
>  last BOF.  So it seems that the charter would not be harmed by
>  removing
>  this statement, but would be improved by removing it.
>  
>  Thank you for considering this.
>  
>  
>  
>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of [email-masked]
>  Sent: Friday, February 15, 2008 1:29 PM
>  To: [email-masked]
>  Subject: PEPPERMINT Digest, Vol 8, Issue 17
>  
>  Send PEPPERMINT mailing list submissions to
>  	[email-masked]
>  
>  To subscribe or unsubscribe via the World Wide Web, visit
>  	http://www.ietf.org/mailman/listinfo/peppermint
>  or, via email, send a message with subject or body 'help' to
>  	[email-masked]
>  
>  You can reach the person managing the list at
>  	[email-masked]
>  
>  When replying, please edit your Subject line so it is more specific
>  than
>  "Re: Contents of PEPPERMINT digest..."
>  
>  
>  Today's Topics:
>  
>     1.  Proposed charter V3 (Richard Shockey)
>  
>  
>  ----------------------------------------------------------------------
>  
>  Message: 1
>  Date: Fri, 15 Feb 2008 13:28:39 -0500
>  From: "Richard Shockey" <[email-masked]>
>  Subject: [PEPPERMINT] Proposed charter V3
>  To: <[email-masked]>
>  Message-ID: <017201c87000$964d7a30$c2e86e90$@us>
>  Content-Type: text/plain;	charset="us-ascii"
>  
>  Comments and flames always welcome.
>  
>  
>  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
>  
>  
>  End of PEPPERMINT Digest, Vol 8, Issue 17
>  *****************************************
>  _______________________________________________
>  PEPPERMINT mailing list
>  [email-masked]
>  http://www.ietf.org/mailman/listinfo/peppermint

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Thu, 21 Feb 2008 16:03:18 -0500
Subject: [PEPPERMINT] Remember Agenda times are PRELIMINARY.
Sender: [email-masked]

The final IETF agenda is still somewhat in flux so plan or don't plan
accordingly.

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

Content-class: urn:content-classes:message
Date: Thu, 21 Feb 2008 16:04:44 -0500
From: "Cartwright, Kenneth" <[email-masked]>
To: <[email-masked]>
Subject: Re: [PEPPERMINT] PEPPERMINT Digest, Vol 8, Issue 17
Sender: [email-masked]

Just curious what the thinking is behind this statement in the charter:

"The working group may also reuse elements of RFC 4114, if possible." 

This subject was discussed at the last BOF and received little support
(if any at all).  So while 4114 certainly need not be ruled out as an
option, singling it out for inclusion the charter of the WG seems (1)
un-necessary, (2) somewhat inappropriate detail for a charter because it
suggests a partial *solution* when the charter is designed to define
just the scope of the *problem(s)* to be analyzed and solved by the WG,
and (3) possibly contradictory to a general opinion expressed at the
last BOF.  So it seems that the charter would not be harmed by removing
this statement, but would be improved by removing it.

Thank you for considering this.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Friday, February 15, 2008 1:29 PM
To: [email-masked]
Subject: PEPPERMINT Digest, Vol 8, Issue 17

Send PEPPERMINT mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.ietf.org/mailman/listinfo/peppermint
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of PEPPERMINT digest..."

Today's Topics:

   1.  Proposed charter V3 (Richard Shockey)

----------------------------------------------------------------------

Message: 1
Date: Fri, 15 Feb 2008 13:28:39 -0500
From: "Richard Shockey" <[email-masked]>
Subject: [PEPPERMINT] Proposed charter V3
To: <[email-masked]>
Message-ID: <017201c87000$964d7a30$c2e86e90$@us>
Content-Type: text/plain;	charset="us-ascii"

Comments and flames always welcome.

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

End of PEPPERMINT Digest, Vol 8, Issue 17
*****************************************
_______________________________________________
PEPPERMINT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/peppermint

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Thu, 21 Feb 2008 15:48:17 -0500
Subject: [PEPPERMINT] First pass at PEPPERMINT BOF #2 Agenda.
Sender: [email-masked]

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: David Schwartz <[email-masked]>
To: Paul Erkkila <[email-masked]>
Date: Thu, 21 Feb 2008 12:20:00 +0200
Cc: [email-masked]
Subject: Re: [PEPPERMINT] small question on draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00.txt
Sender: [email-masked]

Hi Paul.

The goal was to have this consistent with public DNS - hence the  
requirement.

once some specific querier has responsibility data, it can use another  
service to further refine things.

D.

On Feb 19, 2008, at 5:48 AM, Paul Erkkila wrote:

>
> Section 4.ends with "It is important to note that the registry is
> expected to return the same responsibility data for all parties that
> query it."
>
> Was there any particular reason that language was in there. There  
> isn't
> any explanation around it so I was just curious. Possibly something I
> missed on speermint?
>
>
> -pee
>
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/peppermint

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

Date: Mon, 18 Feb 2008 22:48:09 -0500
From: Paul Erkkila <[email-masked]>
To: [email-masked]
Subject: [PEPPERMINT] small question on draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00.txt
Sender: [email-masked]

Section 4.ends with "It is important to note that the registry is 
expected to return the same responsibility data for all parties that 
query it."

Was there any particular reason that language was in there. There isn't 
any explanation around it so I was just curious. Possibly something I 
missed on speermint?

-pee

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 18 Feb 2008 17:36:37 -0500
Subject: [PEPPERMINT] FW: I-D Action:draft-mule-peppermint-espp-requirements-00.txt
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_1353_01C87254.D139E1F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, February 18, 2008 5:00 PM
To: [email-masked]
Subject: I-D Action:draft-mule-peppermint-espp-requirements-00.txt

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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-mule-peppermint-espp-requirements-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-mule-peppermint-espp-requirements-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_1353_01C87254.D139E1F0
Content-Type: Message/External-body;
	name="ATT04878.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT04878.dat"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-mule-peppermint-espp-requirements-00.txt

------=_NextPart_000_1353_01C87254.D139E1F0
Content-Type: Message/External-body;
	name="draft-mule-peppermint-espp-requirements-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-mule-peppermint-espp-requirements-00.txt"

Content-Type: text/plain
Content-ID: <2008-02-18135422.I-D\@ietf.org>

------=_NextPart_000_1353_01C87254.D139E1F0
Content-Type: text/plain;
	name="ATT04881.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT04881.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_1353_01C87254.D139E1F0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_NextPart_000_1353_01C87254.D139E1F0--

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 18 Feb 2008 17:36:22 -0500
Subject: [PEPPERMINT] FW: I-D Action:draft-mule-peppermint-espp-protocol-00.txt
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_134F_01C87254.C8E9E450
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, February 18, 2008 5:00 PM
To: [email-masked]
Subject: I-D Action:draft-mule-peppermint-espp-protocol-00.txt

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

	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

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in, type
"cd internet-drafts" and then
	"get draft-mule-peppermint-espp-protocol-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-mule-peppermint-espp-protocol-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_134F_01C87254.C8E9E450
Content-Type: Message/External-body;
	name="ATT04896.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT04896.dat"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-mule-peppermint-espp-protocol-00.txt

------=_NextPart_000_134F_01C87254.C8E9E450
Content-Type: Message/External-body;
	name="draft-mule-peppermint-espp-protocol-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-mule-peppermint-espp-protocol-00.txt"

Content-Type: text/plain
Content-ID: <2008-02-18135556.I-D\@ietf.org>

------=_NextPart_000_134F_01C87254.C8E9E450
Content-Type: text/plain;
	name="ATT04899.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT04899.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_134F_01C87254.C8E9E450
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_NextPart_000_134F_01C87254.C8E9E450--

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Sun, 17 Feb 2008 21:15:13 -0500
Cc: [email-masked]
Subject: [PEPPERMINT] FW: Correction: Internet-Drafts Submission Cutoff Deadline for the	71st IETF Meeting in Philadelphia, PA, USA
Sender: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexa Morris
Sent: Saturday, February 16, 2008 1:35 PM
To: [email-masked]
Subject: Correction: Internet-Drafts Submission Cutoff Deadline for the 71st
IETF Meeting in Philadelphia, PA, USA

On February 1st, an automated email reminder went to everyone on this email
list that contained incorrect deadline information for Internet-Draft
submissions. There are two (2) Internet-Draft cutoff dates for the 71st IETF
Meeting in Philadelphia, PA, USA:

All initial Internet-Drafts (version -00) must be submitted by this Monday,
February 18th at 5pm ET (22:00 UTC/GMT). The only exception is for
version -00 WG drafts that replace existing non-WG drafts.  Such drafts
may be submitted until the cutoff date for version -01 and higher
drafts.

All revised Internet-Drafts (version -01 and higher) must be submitted
by Monday, February 25th at 5pm ET (22:00 UTC/GMT). Version -00 WG drafts
that replace existing non-WG drafts must be submitted by this cutoff date as
well.

This information, as well as other significant dates for the 71st IETF
Meeting, can be found at http://www.ietf.org/meetings/71-cutoff_dates.html.

We apologize for any confusion this deadline discrepancy may have caused
you. If you have any questions or concerns, please feel free to send a
message to [email-masked]. You are also welcome to contact me
directly at any time.

Kind regards,
Alexa Morris

-----------
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: [email-masked]

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com <http://www.amsl.com/>

 

_______________________________________________
IETF-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf-announce

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Fri, 15 Feb 2008 13:28:39 -0500
Subject: [PEPPERMINT] Proposed charter V3
Sender: [email-masked]

Comments and flames always welcome.

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: "Richard Shockey" <[email-masked]>
To: "'Paul Erkkila'" <[email-masked]>
Date: Fri, 15 Feb 2008 13:26:56 -0500
Cc: [email-masked], "'Peterson, Jon'" <[email-masked]>
Subject: Re: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
Sender: [email-masked]

Apologies for the tardy reply .. in line ..

>  -----Original Message-----
>  From: Paul Erkkila [mailto:[email-masked]]
>  Sent: Tuesday, February 12, 2008 3:04 PM
>  To: Richard Shockey
>  Cc: [email-masked]; 'Peterson, Jon'
>  Subject: Re: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
>  
>  Richard Shockey wrote:
>  > PROPOSED CHARTER FOR PEPPERMINT
>  >
>  
>  >
>  > Data exchanges to facilitate session-based Multimedia
>  Interconnection are
>  > typically between various Client User Agents and Registries
>  containing
>  > 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.
>  >
>  
>  2 questions..
>  
>  1. Would a service provider be considered a registry in this case?
>  Making inter-provider data exchanges registry <=> registry as David
>  commented?

Yes .. data exchanges could be either bilateral or multilateral between administrative domains as well as centralized registries.. 

>  
>  2. Would the timing aspects of the exchange be important for the
>  charter? (I'm new to this). Many of the exchanges done today for
>  instance are "batch" mode file exchanges. Are we looking to cover that
>  scenario or more real time efforts (or both...)?

That is a well known issue and there will be more on this issue forthcoming. Bulk upload and realtime updates are presumed to be in scope. I have noted this in the next iteration of the charter.

>  
>  For example in the PSTN world I might be able to instantly tell you
>  that  a block of numbers you are trying to claim was refused for some reason
>  (it's mine for instance), that would be real time feedback. However
>  not  refusing a block of numbers would not be the same as me telling you
>  that  I've accepted it, and it is in fact now live and usable on my network.

Exactly .. 

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

Date: Tue, 12 Feb 2008 15:03:47 -0500
From: Paul Erkkila <[email-masked]>
To: Richard Shockey <[email-masked]>
Cc: [email-masked], "'Peterson, Jon'" <[email-masked]>
Subject: Re: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
Sender: [email-masked]

Richard Shockey wrote:
> PROPOSED CHARTER FOR PEPPERMINT
> 

> 
> Data exchanges to facilitate session-based Multimedia Interconnection are
> typically between various Client User Agents and Registries containing
> 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.  
> 

2 questions..

1. Would a service provider be considered a registry in this case? 
Making inter-provider data exchanges registry <=> registry as David 
commented?

2. Would the timing aspects of the exchange be important for the 
charter? (I'm new to this). Many of the exchanges done today for 
instance are "batch" mode file exchanges. Are we looking to cover that 
scenario or more real time efforts (or both...)?

For example in the PSTN world I might be able to instantly tell you that 
a block of numbers you are trying to claim was refused for some reason 
(it's mine for instance), that would be real time feedback. However not 
refusing a block of numbers would not be the same as me telling you that 
I've accepted it, and it is in fact now live and usable on my network.

-pee

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Tue, 12 Feb 2008 11:59:47 -0500
Cc: "'Peterson, Jon'" <[email-masked]>
Subject: [PEPPERMINT] Tentative slot assignment...request for Agenda Items
Sender: [email-masked]

We have a tentative 2nd BOF session scheduled in Philadelphia.

This is subject to change and or cancellation.

We have a first iteration of a combined problem statement draft ready to
discuss as well as a proposed WG charter.

I'd like to know what if any other documents people are planning on
submitting. Especially if they involve use cases etc. 

PEPPERMINT Session 1 (1 hour)
Tuesday, Afternoon Session IV 1850-1950
Room Name: Breakout Room
----------------------------------------------

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: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Tue, 12 Feb 2008 11:51:49 -0500
Cc: "'Peterson, Jon'" <[email-masked]>
Subject: [PEPPERMINT] FW: I-D ACTION:draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00.txt
Sender: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, February 11, 2008 7:30 PM
To: [email-masked]
Subject: I-D
ACTION:draft-schwartz-peppermint-consolidated-provisioning-problem-statement
-00.txt

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

	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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get
draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00.txt
".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-schwartz-peppermint-consolidated-provisioning-problem
-statement-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

From: "Richard Shockey" <[email-masked]>
To: "'DRAGE, Keith \(Keith\)'" <[email-masked]>, <[email-masked]>
Date: Fri, 8 Feb 2008 09:24:20 -0500
Cc: "'Peterson, Jon'" <[email-masked]>
Subject: Re: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
Sender: [email-masked]

Short answer YES... administrative domains are assumed to be of any
practical size ( which certainly include PBX systems ) so this provisioning
protocol could be used by PBX systems to provision ENUM systems with TN to
URI mappings, for instance either inter or intra domain or a service
provider or TN to URI peering relationships between service providers.

This is a excellent point and we can certainly clarify this in subsequent
charter iterations. 

>  -----Original Message-----
>  From: DRAGE, Keith (Keith) [mailto:[email-masked]]
>  Sent: Friday, February 08, 2008 6:03 AM
>  To: Richard Shockey; [email-masked]
>  Cc: Peterson, Jon
>  Subject: RE: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
>  
>  Question: Is this work meant to cover all "administrative domains" or
>  only those above a certain size?
>  
>  For example, will the results of this group be applicable to an
>  enterprise operator with a single IP-PBX with less than a 100 lines
>  (or
>  equivalent functionality) and their relationship with a service
>  provider?
>  
>  Regards
>  
>  Keith
>  
>  > -----Original Message-----
>  > From: [email-masked]
>  > [mailto:[email-masked]] On Behalf Of Richard Shockey
>  > Sent: Thursday, February 07, 2008 8:10 PM
>  > To: [email-masked]
>  > Cc: 'Peterson, Jon'
>  > Subject: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
>  >
>  > 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 charted 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.
>  >
>  > Data exchanges to facilitate session-based Multimedia
>  > Interconnection are typically between various Client User
>  > Agents and Registries containing 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
>  >

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

Content-class: urn:content-classes:message
Date: Fri, 8 Feb 2008 12:02:42 +0100
From: "DRAGE, Keith \(Keith\)" <[email-masked]>
To: "Richard Shockey" <[email-masked]>, <[email-masked]>
Cc: "Peterson, Jon" <[email-masked]>
Subject: Re: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
Sender: [email-masked]

Question: Is this work meant to cover all "administrative domains" or
only those above a certain size?

For example, will the results of this group be applicable to an
enterprise operator with a single IP-PBX with less than a 100 lines (or
equivalent functionality) and their relationship with a service
provider?

Regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Shockey
> Sent: Thursday, February 07, 2008 8:10 PM
> To: [email-masked]
> Cc: 'Peterson, Jon'
> Subject: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
> 
> 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 charted 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. 
> 
> Data exchanges to facilitate session-based Multimedia 
> Interconnection are typically between various Client User 
> Agents and Registries containing 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
> 
_______________________________________________
PEPPERMINT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/peppermint

From: David Schwartz <[email-masked]>
To: Richard Shockey <[email-masked]>
Date: Fri, 8 Feb 2008 03:35:42 +0200
Cc: [email-masked], "Peterson, Jon" <[email-masked]>
Subject: Re: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
Sender: [email-masked]

comments inline...

On Feb 7, 2008, at 10:10 PM, Richard Shockey wrote:

> 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 charted to define what data needs to be

Chartered not Charted
>
> 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.
>
> Data exchanges to facilitate session-based Multimedia  
> Interconnection are
> typically between various Client User Agents and Registries containing
> 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.

How about registry - registry (i.e registry data exchange/query)
>
>
> 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
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Thu, 7 Feb 2008 15:10:16 -0500
Cc: "'Peterson, Jon'" <[email-masked]>
Subject: [PEPPERMINT] 2nd pass on PEPPERMINT charter.
Sender: [email-masked]

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

Data exchanges to facilitate session-based Multimedia Interconnection are
typically between various Client User Agents and Registries containing
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: "Richard Shockey" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>
Date: Thu, 7 Feb 2008 11:16:25 -0500
Cc: "'Ersue, Mehmet \(NSN - DE/Muenich\)'" <[email-masked]>
Subject: Re: [PEPPERMINT] FW:  potenntial charter for PEPPERMINT
Sender: [email-masked]

This is a multipart message in MIME format.

--===============2021348796==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_098E_01C8697A.E18ADD80"
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_098E_01C8697A.E18ADD80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The sentence on the issue of NETCONF was only meant to be illustrative of
the fact that the IETF continues to work on issues involving the
provisioning of data in various network elements. I'm going to remove that
sentence since it is clearly causing confusion.

The issue the WG is dealing with (and was strongly confirmed in the first
BOF)  is that various aspects of RFC 4114 are insufficient or inappropriate
for the provisioning of various data sets required by multi media
interconnection databases. 

It is not as simple as ENUM/DNS registry provisioning. The relationships
between various provisioning entities like PBX systems, SIP CUA's,  carrier
OSS systems and network elements  such as SIP proxys and or Session border
controllers are more diverse and the relationships more complex.

The forthcoming requirements/problem statement ID make that clear.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, February 07, 2008 4:58 AM
To: [email-masked]
Cc: Ersue, Mehmet (NSN - DE/Muenich)
Subject: [PEPPERMINT] FW: potenntial charter for PEPPERMINT

One more comment about the charter proposal from Mehmet Ersue, co-chair of
the NETCONF WG. 

Please copy Mehmet on responses, as he is not subscribed to the peppermint
list. 

Dan

----------------------------------------------

 

Hi All,

I fully agree with Margaret that the choice of the technology needs 
to be a group consensus.

Since IETF and IESG are always interested to use already existing 
protocols if they are suitable to do the job I'm pretty much interested to 
hear the concrete arguments why the gateway configuration cannot be 
done with NETCONF over SOAP.

NETCONF is a suitable protocol for network element configuration and 
configuration data exchange. NETCONF is also reliable and supports 
notification and transaction mechanisms. BTW: NETCONF over SOAP 
is not heavy-weight.

NETCONF is already available as a standard and has been implemented 
many times. Already different companies are using it in their products.

You don't get all these functionalities for free. It takes usually many
years 
of hard work to develop the standard documents and get them stable based 
on implementations.

This is the reason why IESG is usually keen of using already existing IETF 
technologies instead of starting another overlapping work which takes years
to finalize.

So, please tell me, what are the hard-reasons for not using an existing 
technology?

Cheers, 
Mehmet Ersue

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Margaret 
> Wasserman
> Sent: Wednesday, February 06, 2008 4:29 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PEPPERMINT] potenntial charter for PEPPERMINT
> 
> 
> By "NETCFG", does Richard mean NETCONF?
> 
> I would prefer to see the line removed that states that "bias 
> will be  
> given" to particular solutions.  I think it is okay to charter a  
> group with restrictions on the solution space, such as "will 
> be based  
> on XML" if there is consensus to do so, but I'm not sure what it  
> would mean to charter a group and require that they be "biased"  
> towards certain solutions.  If there isn't consensus that the  
> solution must be based on one of the technologies listed, I think  
> that line should be removed and the choice of technology should be a  
> group consensus decision.
> 
> Margaret
> 

------=_NextPart_000_098E_01C8697A.E18ADD80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The sentence on the issue of NETCONF was only meant to be
illustrative of the fact that the IETF continues to work on issues =
involving
the provisioning of data in various network elements. I&#8217;m going to =
remove
that sentence since it is clearly causing =
confusion.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The issue the WG is dealing with (and was strongly =
confirmed in
the first BOF) &nbsp;is that various aspects of RFC 4114 are =
insufficient or
inappropriate for the provisioning of various data sets required by =
multi media
interconnection databases. <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>It is not as simple as ENUM/DNS registry provisioning. =
The
relationships between various provisioning entities like PBX systems, =
SIP CUA&#8217;s,
&nbsp;carrier OSS systems and network elements &nbsp;such as SIP proxys =
and or
Session border controllers are more diverse and the relationships more =
complex.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The forthcoming requirements/problem statement ID make =
that
clear.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b>On =
Behalf
Of </b>Romascanu, Dan (Dan)<br>
<b>Sent:</b> Thursday, February 07, 2008 4:58 AM<br>
<b>To:</b> [email-masked]<br>
<b>Cc:</b> Ersue, Mehmet (NSN - DE/Muenich)<br>
<b>Subject:</b> [PEPPERMINT] FW: potenntial charter for =
PEPPERMINT<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal><em><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>One more comment about the charter proposal from Mehmet =
Ersue,
co-chair of the NETCONF WG. </span></b></em><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><em><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Please copy Mehmet on responses, as he is not subscribed to =
the
peppermint list. </span></b></em><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><em><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>Dan</span></b></em><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><em><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:blue'>----------------------------------------------</span></b></em=
><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
</span><br>
&nbsp;<o:p></o:p></p>

</div>

<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>

<div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><br>
Hi All,<br>
<br>
I fully agree with Margaret that the choice of the technology needs <br>
to be a group consensus.<br>
<br>
Since IETF and IESG are always interested to use already existing <br>
protocols if they are suitable to do the job I'm pretty much interested =
to <br>
hear the concrete arguments why the gateway configuration cannot be <br>
done with NETCONF over SOAP.<br>
<br>
NETCONF is a suitable protocol for network element configuration and =
<br>
configuration data exchange. NETCONF is also reliable and supports <br>
notification and transaction mechanisms. BTW: NETCONF over SOAP <br>
is not heavy-weight.<br>
<br>
NETCONF is already available as a standard and has been implemented <br>
many times. Already different companies are using it in their =
products.<br>
<br>
You don't get all these functionalities for free. It takes usually many =
years <br>
of hard work to develop the standard documents and get them stable based =
<br>
on implementations.<br>
<br>
This is the reason why IESG is usually keen of using already existing =
IETF <br>
technologies instead of starting another overlapping work which takes =
years<br>
to finalize.<br>
<br>
So, please tell me, what are the hard-reasons for not using an existing =
<br>
technology?<br>
<br>
Cheers, <br>
Mehmet Ersue<br>
&nbsp;<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: [email-masked] <br>
&gt; [mailto:[email-masked]] On Behalf Of ext Margaret <br>
&gt; Wasserman<br>
&gt; Sent: Wednesday, February 06, 2008 4:29 PM<br>
&gt; To: Romascanu, Dan (Dan)<br>
&gt; Cc: [email-masked]; [email-masked]; [email-masked]<br>
&gt; Subject: Re: [PEPPERMINT] potenntial charter for PEPPERMINT<br>
&gt; <br>
&gt; <br>
&gt; By &quot;NETCFG&quot;, does Richard mean NETCONF?<br>
&gt; <br>
&gt; I would prefer to see the line removed that states that &quot;bias =
<br>
&gt; will be&nbsp; <br>
&gt; given&quot; to particular solutions.&nbsp; I think it is okay to =
charter
a&nbsp; <br>
&gt; group with restrictions on the solution space, such as &quot;will =
<br>
&gt; be based&nbsp; <br>
&gt; on XML&quot; if there is consensus to do so, but I'm not sure what
it&nbsp; <br>
&gt; would mean to charter a group and require that they be
&quot;biased&quot;&nbsp; <br>
&gt; towards certain solutions.&nbsp; If there isn't consensus that =
the&nbsp; <br>
&gt; solution must be based on one of the technologies listed, I =
think&nbsp; <br>
&gt; that line should be removed and the choice of technology should be =
a&nbsp;
<br>
&gt; group consensus decision.<br>
&gt; <br>
&gt; Margaret<br>
&gt; <o:p></o:p></span></p>

</div>

</div>

</blockquote>

</div>

</div>

</body>

</html>

------=_NextPart_000_098E_01C8697A.E18ADD80--

--===============2021348796==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2021348796==--

From: "Richard Shockey" <[email-masked]>
To: "'Romascanu, Dan \(Dan\)'" <[email-masked]>, <[email-masked]>
Date: Thu, 7 Feb 2008 11:01:45 -0500
Cc: [email-masked]
Subject: Re: [PEPPERMINT] FW:  potenntial charter for PEPPERMINT
Sender: [email-masked]

I meant NETCONF ..  a pure typo. 

The comment on the use of bias is also perfectly reasonable and I'll remove
that.

>  
>  -----Original Message-----
>  From: Margaret Wasserman [mailto:[email-masked]]
>  Sent: Wednesday, February 06, 2008 5:29 PM
>  To: Romascanu, Dan (Dan)
>  Cc: [email-masked]; [email-masked]; [email-masked]
>  Subject: Re: [PEPPERMINT] potenntial charter for PEPPERMINT
>  
>  
>  By "NETCFG", does Richard mean NETCONF?
>  
>  I would prefer to see the line removed that states that "bias will be
>  given" to particular solutions.  I think it is okay to charter a group
>  with restrictions on the solution space, such as "will be based on
>  XML"
>  if there is consensus to do so, but I'm not sure what it would mean to
>  charter a group and require that they be "biased"
>  towards certain solutions.  If there isn't consensus that the solution
>  must be based on one of the technologies listed, I think that line
>  should be removed and the choice of technology should be a group
>  consensus decision.
>  
>  Margaret
>  
>  
>  
>  On Feb 6, 2008, at 5:30 AM, Romascanu, Dan (Dan) wrote:
>  
>  >
>  > Comments are welcome.
>  >
>  > Dan
>  >
>  >
>  >
>  >
>  > -----Original Message-----
>  > From: [email-masked] [mailto:peppermint-
>  [email-masked]]
>  > On Behalf Of Richard Shockey
>  > Sent: Wednesday, February 06, 2008 2:06 AM
>  > To: [email-masked]
>  > Subject: [PEPPERMINT] potenntial charter for PEPPERMINT
>  >
>  >
>  > Folks ..we had a successful BOF in Vancouver in order to progress
>  the
>  > work towards a full charter by the IETF it is necessary to reach
>  > consensus on a charter.
>  >
>  > I have a proposal for a charter here below. I welcome comments
>  public
>  > private etc.
>  >
>  >
>  > PROPOSED CHARTER FOR PEPPERMINT
>  >
>  > The IETF has been working on various aspects of Multi-Media
>  > Interconnection among administrative domains.
>  >
>  > 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.
>  >
>  > These forms of interconnection will require various forms of data to
>  > be exchanged among administrative domains outside the normal scope
>  of
>  > establishing various SIP sessions.
>  >
>  > The IETF has, in the past done, significant work on data exchanges
>  > among various network elements. PROVREG and NETCFG being the most
>  > prominent recent examples.
>  >
>  > Data exchanges to facilitate Multi-Media Interconnection are
>  typically
>  
>  > between various Client User Agents and Registries containing
>  mappings
>  > of phone numbers to URI's, policies surrounding admission to points
>  of
>  
>  > network interconnection and various types of trunking data.  In
>  > addition there is a specific need for redistribution of Registry
>  data
>  > to various types of network databases.
>  >
>  > The proposed PEPPERMINT working group will build upon the knowledge
>  > and expertise of the PROVREG, ENUM and SPEERMINT working groups. The
>  > goal of the WG is to find a provisioning solution for
>  interconnection
>  > to be ultimately used by SPEERMINT. The working group may also reuse
>  > elements of RFC 4114 if possible.
>  >
>  > The final work product(s) from this working group will be based upon
>  > XML.
>  >
>  > Additionally, bias will be given to using, HTTP/REST, HTTP/XML-RPC,
>  or
>  
>  > HTTP/SOAP.
>  >
>  > The working group will draw upon expert advice and ongoing
>  > consultation from the ENUM, SPEERMINT and PROVREG working groups.
>  >
>  >
>  > PROPOSED GOALS AND MILESTONES
>  >
>  >
>  > Requirements for Interconnection data exchanges.       July 08
>  >
>  > Provisioning of Interconnection data registries.       Sep 08
>  >
>  > Provisioning of Interconnection data caches.           Dec 08
>  >
>  >
>  > 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
>  >
>  > --
>  > to unsubscribe send a message to [email-masked] with
>  > the word 'unsubscribe' in a single line as the message text body.
>  > archive: <http://ops.ietf.org/lists/netconf/>
>  
>  
>  This email was protected during delivery to Avaya with TLS encryption
>  
>  _______________________________________________
>  PEPPERMINT mailing list
>  [email-masked]
>  http://www.ietf.org/mailman/listinfo/peppermint

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

Content-class: urn:content-classes:message
Date: Thu, 7 Feb 2008 10:57:35 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: "Ersue, Mehmet \(NSN - DE/Muenich\)" <[email-masked]>
Subject: [PEPPERMINT] FW:  potenntial charter for PEPPERMINT
Sender: [email-masked]

This is a multi-part message in MIME format.

--===============0989597415==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8696F.DE2AA50E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8696F.DE2AA50E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

One more comment about the charter proposal from Mehmet Ersue, co-chair
of the NETCONF WG.=20
=20
Please copy Mehmet on responses, as he is not subscribed to the
peppermint list.=20
=20
Dan
=20
----------------------------------------------

=20

	Hi All,
=09
	I fully agree with Margaret that the choice of the technology
needs=20
	to be a group consensus.
=09
	Since IETF and IESG are always interested to use already
existing=20
	protocols if they are suitable to do the job I'm pretty much
interested to=20
	hear the concrete arguments why the gateway configuration cannot
be=20
	done with NETCONF over SOAP.
=09
	NETCONF is a suitable protocol for network element configuration
and=20
	configuration data exchange. NETCONF is also reliable and
supports=20
	notification and transaction mechanisms. BTW: NETCONF over SOAP=20
	is not heavy-weight.
=09
	NETCONF is already available as a standard and has been
implemented=20
	many times. Already different companies are using it in their
products.
=09
	You don't get all these functionalities for free. It takes
usually many years=20
	of hard work to develop the standard documents and get them
stable based=20
	on implementations.
=09
	This is the reason why IESG is usually keen of using already
existing IETF=20
	technologies instead of starting another overlapping work which
takes years
	to finalize.
=09
	So, please tell me, what are the hard-reasons for not using an
existing=20
	technology?
=09
	Cheers,=20
	Mehmet Ersue
	=20
=09
	> -----Original Message-----
	> From: [email-masked]=20
	> [mailto:[email-masked]] On Behalf Of ext Margaret=20
	> Wasserman
	> Sent: Wednesday, February 06, 2008 4:29 PM
	> To: Romascanu, Dan (Dan)
	> Cc: [email-masked]; [email-masked]; [email-masked]
	> Subject: Re: [PEPPERMINT] potenntial charter for PEPPERMINT
	>=20
	>=20
	> By "NETCFG", does Richard mean NETCONF?
	>=20
	> I would prefer to see the line removed that states that "bias=20
	> will be =20
	> given" to particular solutions.  I think it is okay to charter
a =20
	> group with restrictions on the solution space, such as "will=20
	> be based =20
	> on XML" if there is consensus to do so, but I'm not sure what
it =20
	> would mean to charter a group and require that they be
"biased" =20
	> towards certain solutions.  If there isn't consensus that the

	> solution must be based on one of the technologies listed, I
think =20
	> that line should be removed and the choice of technology
should be a =20
	> group consensus decision.
	>=20
	> Margaret
	>=20
=09

------_=_NextPart_001_01C8696F.DE2AA50E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE type=3Dtext/css>DIV {
	MARGIN: 0px
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D621355509-07022008>One more comment about the charter proposal =
from Mehmet=20
Ersue, co-chair of the NETCONF WG. </SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D621355509-07022008></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D621355509-07022008>Please copy Mehmet on responses, as he is not =

subscribed to the peppermint list. </SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D621355509-07022008></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D621355509-07022008>Dan</SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D621355509-07022008></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D621355509-07022008>----------------------------------------------=
</SPAN></FONT></EM></STRONG></DIV>
<DIV><FONT face=3DTahoma size=3D2><BR></FONT><BR>&nbsp;</DIV>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
arial,helvetica,sans-serif">
  <DIV><BR>Hi All,<BR><BR>I fully agree with Margaret that the choice of =
the=20
  technology needs <BR>to be a group consensus.<BR><BR>Since IETF and =
IESG are=20
  always interested to use already existing <BR>protocols if they are =
suitable=20
  to do the job I'm pretty much interested to <BR>hear the concrete =
arguments=20
  why the gateway configuration cannot be <BR>done with NETCONF over=20
  SOAP.<BR><BR>NETCONF is a suitable protocol for network element =
configuration=20
  and <BR>configuration data exchange. NETCONF is also reliable and =
supports=20
  <BR>notification and transaction mechanisms. BTW: NETCONF over SOAP =
<BR>is not=20
  heavy-weight.<BR><BR>NETCONF is already available as a standard and =
has been=20
  implemented <BR>many times. Already different companies are using it =
in their=20
  products.<BR><BR>You don't get all these functionalities for free. It =
takes=20
  usually many years <BR>of hard work to develop the standard documents =
and get=20
  them stable based <BR>on implementations.<BR><BR>This is the reason =
why IESG=20
  is usually keen of using already existing IETF <BR>technologies =
instead of=20
  starting another overlapping work which takes years<BR>to =
finalize.<BR><BR>So,=20
  please tell me, what are the hard-reasons for not using an existing=20
  <BR>technology?<BR><BR>Cheers, <BR>Mehmet Ersue<BR>&nbsp;<BR><BR>&gt;=20
  -----Original Message-----<BR>&gt; From: [email-masked] =
<BR>&gt;=20
  [mailto:[email-masked]] On Behalf Of ext Margaret <BR>&gt; =

  Wasserman<BR>&gt; Sent: Wednesday, February 06, 2008 4:29 PM<BR>&gt; =
To:=20
  Romascanu, Dan (Dan)<BR>&gt; Cc: [email-masked]; [email-masked];=20
  [email-masked]<BR>&gt; Subject: Re: [PEPPERMINT] potenntial =
charter for=20
  PEPPERMINT<BR>&gt; <BR>&gt; <BR>&gt; By "NETCFG", does Richard mean=20
  NETCONF?<BR>&gt; <BR>&gt; I would prefer to see the line removed that =
states=20
  that "bias <BR>&gt; will be&nbsp; <BR>&gt; given" to particular=20
  solutions.&nbsp; I think it is okay to charter a&nbsp; <BR>&gt; group =
with=20
  restrictions on the solution space, such as "will <BR>&gt; be =
based&nbsp;=20
  <BR>&gt; on XML" if there is consensus to do so, but I'm not sure what =

  it&nbsp; <BR>&gt; would mean to charter a group and require that they =
be=20
  "biased"&nbsp; <BR>&gt; towards certain solutions.&nbsp; If there =
isn't=20
  consensus that the&nbsp; <BR>&gt; solution must be based on one of the =

  technologies listed, I think&nbsp; <BR>&gt; that line should be =
removed and=20
  the choice of technology should be a&nbsp; <BR>&gt; group consensus=20
  decision.<BR>&gt; <BR>&gt; Margaret<BR>&gt;=20
<BR></DIV></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C8696F.DE2AA50E--

--===============0989597415==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0989597415==--

Content-class: urn:content-classes:message
Date: Thu, 7 Feb 2008 07:16:57 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: [email-masked]
Subject: [PEPPERMINT] FW:  potenntial charter for PEPPERMINT
Sender: [email-masked]

Please see below a comment from OPS-DIR member Margaret Wasserman. 

Dan

 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Wednesday, February 06, 2008 5:29 PM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PEPPERMINT] potenntial charter for PEPPERMINT

By "NETCFG", does Richard mean NETCONF?

I would prefer to see the line removed that states that "bias will be
given" to particular solutions.  I think it is okay to charter a group
with restrictions on the solution space, such as "will be based on XML"
if there is consensus to do so, but I'm not sure what it would mean to
charter a group and require that they be "biased"  
towards certain solutions.  If there isn't consensus that the solution
must be based on one of the technologies listed, I think that line
should be removed and the choice of technology should be a group
consensus decision.

Margaret

On Feb 6, 2008, at 5:30 AM, Romascanu, Dan (Dan) wrote:

>
> Comments are welcome.
>
> Dan
>
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Richard Shockey
> Sent: Wednesday, February 06, 2008 2:06 AM
> To: [email-masked]
> Subject: [PEPPERMINT] potenntial charter for PEPPERMINT
>
>
> Folks ..we had a successful BOF in Vancouver in order to progress the 
> work towards a full charter by the IETF it is necessary to reach 
> consensus on a charter.
>
> I have a proposal for a charter here below. I welcome comments public 
> private etc.
>
>
> PROPOSED CHARTER FOR PEPPERMINT
>
> The IETF has been working on various aspects of Multi-Media 
> Interconnection among administrative domains.
>
> 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.
>
> These forms of interconnection will require various forms of data to 
> be exchanged among administrative domains outside the normal scope of 
> establishing various SIP sessions.
>
> The IETF has, in the past done, significant work on data exchanges 
> among various network elements. PROVREG and NETCFG being the most 
> prominent recent examples.
>
> Data exchanges to facilitate Multi-Media Interconnection are typically

> between various Client User Agents and Registries containing mappings 
> of phone numbers to URI's, policies surrounding admission to points of

> network interconnection and various types of trunking data.  In 
> addition there is a specific need for redistribution of Registry data 
> to various types of network databases.
>
> The proposed PEPPERMINT working group will build upon the knowledge 
> and expertise of the PROVREG, ENUM and SPEERMINT working groups. The 
> goal of the WG is to find a provisioning solution for interconnection 
> to be ultimately used by SPEERMINT. The working group may also reuse 
> elements of RFC 4114 if possible.
>
> The final work product(s) from this working group will be based upon 
> XML.
>
> Additionally, bias will be given to using, HTTP/REST, HTTP/XML-RPC, or

> HTTP/SOAP.
>
> The working group will draw upon expert advice and ongoing 
> consultation from the ENUM, SPEERMINT and PROVREG working groups.
>
>
> PROPOSED GOALS AND MILESTONES
>
>
> Requirements for Interconnection data exchanges.       July 08
>
> Provisioning of Interconnection data registries.       Sep 08
>
> Provisioning of Interconnection data caches.           Dec 08
>
>
> 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
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>

This email was protected during delivery to Avaya with TLS encryption

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

Content-class: urn:content-classes:message
Date: Thu, 7 Feb 2008 07:14:16 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: David B Harrington <[email-masked]>
Subject: [PEPPERMINT] FW: [OPS-DIR]  potenntial charter for PEPPERMINT
Sender: [email-masked]

Please see below a comment from OPS-DIR member David Harrington. 

Regards,

Dan

 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Harrington
Sent: Wednesday, February 06, 2008 7:12 PM
To: 'Margaret Wasserman'; Romascanu, Dan (Dan)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [OPS-DIR] [PEPPERMINT] potenntial charter for PEPPERMINT

Hi,

A Google search shows NETCFG to be an open-source GUI-based application
for configuring networks. I would be very concerned if the charter calls
for a solution "biased" toward a vendor-specific offering, even if the
vendor uses open-source and the MIT license, since we are supposed to
develop vendor-neutral standards, and biased != neutral.

If the intention was to reference NETCONF, then I have a concern that
the expressed bias is to favor a non-mandatory-to-implement "transport"
for NETCONF. I agree that the line expressing a bias for certain
solutions should be removed.

I would not object to a line expressing a constraint for solutions that
leverage existing IETF standards for certain aspects, such as security.
But I'm not sure I know what is to be delivered well enough to know how
existing standards could be leveraged.

Overall, I find the charter wording to be too ambiguous to adequately
describe the scope of the work to be done. "find a provisioning solution
for interconnection" does not seem sufficiently focused to identify the
expected deliverables. Is this WG chartered to produce a protocol, some
data models, functionality to manage caches? I'm just not really sure
what is being proposed as deliverables, and would be hard pressed to
know when the WG drifted off-topic or completed their work.

I think the charter wording and scope needs to be tightened
significantly to make this engineering-ready.

David Harrington
[email-masked]
[email-masked]
[email-masked]

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