Subject: [PEPPERMINT] FW: I-D ACTION:draft-schwartz-speermint-provisioning-problem-00.txt

From: "Richard Shockey" <[email-masked]>
Date: Tue, 13 Nov 2007 15:21:09 -0500

I believe this is a document we will be discussing in Vancouver at the BOF.
The references to spearmint was, I'm told somewhat inadvertent on the part
of the authors.

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

	Title		: Managing Client Voice Peering Provisioning
	Author(s)	: D. Schwartz, et al.
	Filename	:
draft-schwartz-speermint-provisioning-problem-00.txt
	Pages		: 8
	Date		: 2007-11-13
	
   This document describes the type of data provisioned among Voice
   Service Providers.  This 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-speermint-provisioning-pr
oblem-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-speermint-provisioning-problem-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-speermint-provisioning-problem-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]
https://www1.ietf.org/mailman/listinfo/peppermint

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Nov 2007 17:02:45 +0000

David,

>From an initial read, I am rather confused. There is a clearly defined
split between SPEERMINT work and ENUM work, with ENUM converting a
telephone number into a SIP URI, and SPEERMINT finding a SIP server,
policy, etc. for the domain indicated in the SIP URI. However, the draft
seems to approach provisioning without due regard for that split, i.e.,
it seems to tackle provisioning in a way that allows a VSP to take a
phone number as input and directly obtain the information it needs to
route to an appropriate terminating VSP. Shouldn't we try to keep the
two stages separate? Or have I misunderstood something?

John

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: 13 November 2007 20:21
> To: [email-masked]
> Subject: [PEPPERMINT] FW: 
> I-DACTION:draft-schwartz-speermint-provisioning-problem-00.txt
> 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: David Schwartz <[email-masked]>
Date: Sun, 25 Nov 2007 00:26:33 +0200

Hi john.

inline...

On Nov 21, 2007, at 7:02 PM, Elwell, John wrote:

> telephone number into a SIP URI,

DS: The draft is trying among other to point out that the exact  
meaning of the SIP URI returned in the response is vague and open to  
interpretation. Defining the meaning and context of data that is  
passed using the ENUM protocol is an open issue and one may argue  
that this belongs in the ENUM group. I am not convinced. As to  
whether or not this should be in the SPEERMINT group, this too is an  
open issue and it was my understanding that the BOF was formed to  
discuss this.

As a side point, using a SIP 302 redirect mechanism for said  
resolution is completely valid approach (in fact used quite often in  
practice) and has nothing to do with ENUM or NAPTR records so the  
relevance of ENUM is somewhat unclear.

> and SPEERMINT finding a SIP server, policy, etc.
> for the domain indicated in the SIP URI.

DS: I would like to quote from the charter as there seems to be some  
confusion. "... More specifically, SPEERMINT focuses on real-time  
session routing architectures and their associated use cases.  
Deliverables here include the specification of the various types of  
application flows, such as signaling and media flows, in such  
networks, and includes both trunking and peer-to-peer flows... The  
most focused deliverables of SPEERMINT are best current practices  
regarding exchange of real-time sessions among VoIP and other real- 
time application service providers and, in particular, how such calls  
are routed...  While the the ENUM Working Group is primarily  
concerned with the structure and lookup of data for the translation  
of E.164 numbers into URIs (RFC3761), SPEERMINT is concerned with the  
use of the resulting URI data, as well as non-ENUM-derived URI data,  
for use in signaling and routing of real-time sessions. "

While the charter does mention that SPEERMINT is concerned with "the  
use of the resulting URI data" none of the work to date has addressed  
this issue and it is unclear when and if it will. While I fully  
understand and support the current efforts with SPEERMINT to define  
the architectures and use cases as a foundation for future peering  
work I feel that the context, meaning and data model of the E.164  
resolution data as well as the provisioning of this data may well be  
out of scope for SPEERMINT.

> However, the draft