Subject: RE: [PEPPERMINT] new BoF proposal
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: "Andrew Newton" <[email-masked]>, <[email-masked]>
Cc: Andy Bierman <[email-masked]>
Date: Tue, 30 Jan 2007 08:19:54 +0200
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 

> The final work
> product(s) from this working group will be based upon XML.   
> Additionally,
> bias will be given to re-using either EPP, HTTP/REST, 
> HTTP/XML-RPC, or HTTP/SOAP.
> 

I would suggest that we add NETCONF to the list of possible technologies
to consider for re-use. 

Dan

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 29 Jan 2007 16:15:00 -0500
Cc: 
Subject: [PEPPERMINT] FYI - -D ACTION:draft-newton-peppermint-problem-statement-00.txt
Reply-To: [email-masked]

This is a multi-part message in MIME format.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, January 29, 2007 3:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-newton-peppermint-problem-statement-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Provisioning Extensions in Peering Registries for
> Multimedia Interconnection (PEPPERMINT) Problem Statement
> 	Author(s)	: A. Newton
> 	Filename	: draft-newton-peppermint-problem-statement-00.txt
> 	Pages		: 13
> 	Date		: 2007-1-29
> 
>    This document contains descriptions of the problems faced by
>    operators and participants of multimedia interconnection (i.e.  SIP)
>    peering registries with respect to identity provisioning.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-newton-peppermint-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-newton-peppermint-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-newton-peppermint-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.

------=_NextPart_000_0111_01C743C0.A47DACF0
Content-Type: Message/External-body;
	name="ATT00146.dat"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00146.dat"

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

ENCODING mime
FILE /internet-drafts/draft-newton-peppermint-problem-statement-00.txt

------=_NextPart_000_0111_01C743C0.A47DACF0
Content-Type: Message/External-body;
	name="draft-newton-peppermint-problem-statement-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-newton-peppermint-problem-statement-00.txt"

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

------=_NextPart_000_0111_01C743C0.A47DACF0
Content-Type: text/plain;
	name="ATT00149.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00149.txt"

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

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

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

------=_NextPart_000_0111_01C743C0.A47DACF0--

To: [email-masked]
From: Andrew Newton <[email-masked]>
Date: Sun, 28 Jan 2007 13:36:29 -0500
Subject: [PEPPERMINT] new BoF proposal

All,

A tightened up version of the PEPPERMINT BoF proposal has been  
formulated.  The major changes since the last version are: 1) some  
language has been changed or eliminated that was construed to give  
PEPPERMINT a larger scope than intended, and 2) the input documents  
are listed.

The text is below.  Comments, questions, and suggestions welcomed.

-andy

Peppermint BOF

Provisioning Extensions in Peering Registries for Multimedia
INTerconnection.

Mailing Lists:

BOF chairs:

Andrew Newton [[email-masked]]

Richard Shockey [[email-masked]]

Temporary Area Directorate: Real Time Applications (RAI)

Ultimate Area Directorate: TBD

BOF Purpose.

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

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

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

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

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

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

Proposed Deliverables:

1) Requirements for SPEERMINT data exchange.
2) Provisioning of SPEERMINT data registries.
3) Provisioning of SPEERMINT/ENUM data caches.

Input Documents:

1) PEPPERMINT Problem Statement
draft-newton-peppermint-problem-statement-00.txt

2) E.164 Number Provisioning Requirements - Data Set Requirements
draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

3) ENUM Registry Interface Requirements
draft-lewis-peppermint-enum-reg-if-00.txt

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

To: [email-masked]
From: Andrew Newton <[email-masked]>
Date: Sun, 28 Jan 2007 13:31:12 -0500
Subject: [PEPPERMINT] draft-newton-peppermint-problem-statement-00

All,

I've written a draft describing the problem to which PEPPERMINT is to  
be applied.  Of course, this is simply my opinion and holds no more  
weight than the opinion of others.  But I had received several  
private inquiries about the nature of PEPPERMINT, so I decided to  
write a draft to explain things to those not in the SIP peering  
community.  And for those of us in the SIP peering community,  
hopefully this will help align our goals.

Since the draft won't show up in the repository until Monday  
afternoon at best, I've posted the HTML version on-line: http:// 
ecotroph.net/~anewton/draft-newton-peppermint-problem-statement-00.html

-andy

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

From: "Richard Shockey" <[email-masked]>
To: "'Drage, Keith \(Keith\)'" <[email-masked]>, "'Creighton, Tom'" <[email-masked]>, <[email-masked]>
Subject: RE: [PEPPERMINT] PEPPERMINT BoF?
Date: Sat, 27 Jan 2007 22:20:58 -0500
Cc: 
Reply-To: [email-masked]

To my knowledge the IESG has not yet met to approve the BOF schedules yet.

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:[email-masked]]
> Sent: Friday, January 26, 2007 6:50 PM
> To: Creighton, Tom; [email-masked]
> Subject: RE: [PEPPERMINT] PEPPERMINT BoF?
> 
> The information on all deadline dates for IETF#68 is here.
> 
> http://www.ietf.org/meetings/68-cutoff_dates.html
> 
> We have not yet reached the date when the draft agenda is published, and
> even then it is still subject to change up to the last minute.
> 
> 
> Regards
> 
> Keith
> 
> > -----Original Message-----
> > From: Creighton, Tom [mailto:[email-masked]]
> > Sent: 26 January 2007 19:03
> > To: [email-masked]
> > Subject: [PEPPERMINT] PEPPERMINT BoF?
> >
> > Has a tentative date been set for the PEPPERMINT BoF?
> >
> > Regards,
> >
> > Tom
> >
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/peppermint
> >
> 
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/peppermint

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

Content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] PEPPERMINT BoF?
Date: Sat, 27 Jan 2007 00:50:07 +0100
From: "Drage, Keith \(Keith\)" <[email-masked]>
To: "Creighton, Tom" <[email-masked]>, <[email-masked]>
Cc: 

The information on all deadline dates for IETF#68 is here.

http://www.ietf.org/meetings/68-cutoff_dates.html

We have not yet reached the date when the draft agenda is published, and
even then it is still subject to change up to the last minute.

Regards

Keith 

> -----Original Message-----
> From: Creighton, Tom [mailto:[email-masked]] 
> Sent: 26 January 2007 19:03
> To: [email-masked]
> Subject: [PEPPERMINT] PEPPERMINT BoF?
> 
> Has a tentative date been set for the PEPPERMINT BoF?
> 
> Regards,
> 
> Tom
> 
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/peppermint
> 

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

Content-class: urn:content-classes:message
Date: Fri, 26 Jan 2007 14:02:42 -0500
From: "Creighton, Tom" <[email-masked]>
To: <[email-masked]>
Cc: 
Subject: [PEPPERMINT] PEPPERMINT BoF?

Has a tentative date been set for the PEPPERMINT BoF?

Regards,

Tom

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

Date: Thu, 25 Jan 2007 07:45:07 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Cc: [email-masked], Edward Lewis <[email-masked]>

At 7:22 -0500 1/25/07, Hollenbeck, Scott wrote:

>One concrete suggestion, Ed: right now the draft reads like a
>requirements document.  If you're trying to describe your own
>implementation experience, you should change the title and text to
>reflect that goal.  Taken in that context there's a lot of information
>in the document that could help us avoid "has anyone tried?" questions.

What I want to do is present a requirements document.   I'm saying 
that it is based on our experiences to help explain away why it may 
not be all encompassing, i.e., why it may not have requirements that 
others have stumbled across in their experience.

I don't really want to describe our experience, but base a 
requirements document on it for starters.  There's a sensitive issue 
in the IETF of people coming to a WG with an assembled solution and 
being perceived as asking for rubber stamp approval.  I think the 
document would get along better as being based on a broader set of 
experience than we have at an "individual -00" (i.e., just ours) but 
I had to start somewhere.

I think raising up "has anyone tried?" questions would be good.  I 
think that would help in vetting the final solution, for what ever 
value of $final is used.

Referring to my pat answer...if this work gets a WG and the 
requirements document I've submitted gets adopted, it will no longer 
be merely a reflection of just our experience.  Until then though, I 
want to ground it only in the reality of our experience as opposed to 
supplementing our experience with hypothetical issues.

I should add that our implementation probably fails to meet at least 
one of the requirements.  I picked one requirement up from reading 
mail exchanged after we were in the testing phase for what we have.

If there is other experience to draw from, great.  We just haven't 
gone seeking other opinions because our project goal was more of 
"solving a need" we see at hand than "creating a standard."  In the 
sense that "creating a standard" for the exercise of "creating a 
standard" is more or less a waste of time, I think that the "need" 
has to precede the "standard."

BTW - when I flip between "we" and "I" here I am differentiating 
between me as the author of the document and we as in the team of 
developers doing the work.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

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

Content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Date: Thu, 25 Jan 2007 07:22:57 -0500
From: "Hollenbeck, Scott" <[email-masked]>
To: "Edward Lewis" <[email-masked]>
Cc: [email-masked]

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]] 
> Sent: Wednesday, January 24, 2007 3:43 PM
> To: Hollenbeck, Scott
> Cc: Andrew Newton; [email-masked]
> Subject: RE: [PEPPERMINT] comments on 
> draft-lewis-peppermint-enum-ref-if-00
> 
> At 7:37 -0500 1/24/07, Hollenbeck, Scott wrote:
> 
> >Disclaimer: I'm the author of EPP.  I have a bias.
> 
> Disclaimer: I was one of the co-chairs of provreg.  "Shooting down" 
> the product of your erstwhile WG isn't that delightful.  (I should 
> add that Scott did all the work in the group.)
> 
> >Indeed.  It's already being used in ENUM contexts.  The 
> country code 1
> >user ENUM trial, for example, is using EPP.
> >
> >I'd like to see any analysis of data wrapping protocol to include a
> >discussion of the issues associated with tunneling data re-using HTTP
> >and port 80.  The Security Considerations section would be a 
> good place
> >to add text.  Let's discuss the software engineering and deployment
> >issues associated with adding HTTP and SOAP software layers, 
> too.  It's
> >not as simple as "build on top of SOAP", folks.
> 
> Before writing this draft, we had an internal meeting/discussion on 
> this debate.

[snip]

One concrete suggestion, Ed: right now the draft reads like a
requirements document.  If you're trying to describe your own
implementation experience, you should change the title and text to
reflect that goal.  Taken in that context there's a lot of information
in the document that could help us avoid "has anyone tried?" questions.

-Scott-

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

Content-class: urn:content-classes:message
Subject: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00 
Date: Thu, 25 Jan 2007 00:11:41 +0200
From: "David Schwartz" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

--======= 77582780=
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C74004.A1BA6428"

This is a multi-part message in MIME format.

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

I am curious.

If ENUM is the mechanism of choice (as opposed to redirect) how can the
querying party pass information in the query as to who he is? What is I
want to present different information depending on "who is asking"? 

Surely the answer is not "Check which IP the request originated from",
since this forces end user querying as opposed to VSP querying. 

David

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

<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle18
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>I am curious.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>If ENUM is the mechanism of choice (as opposed to redirect)
how can the querying party pass information in the query as to who he is? What
is I want to present different information depending on &#8220;who is asking&#8221;?
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Surely the answer is not &#8220;Check which IP the request
originated from&#8221;, since this forces end user querying as opposed to VSP
querying. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>David<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C74004.A1BA6428--

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

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

--======= 77582780=--

Date: Wed, 24 Jan 2007 15:43:27 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Cc: [email-masked]

At 7:37 -0500 1/24/07, Hollenbeck, Scott wrote:

>Disclaimer: I'm the author of EPP.  I have a bias.

Disclaimer: I was one of the co-chairs of provreg.  "Shooting down" 
the product of your erstwhile WG isn't that delightful.  (I should 
add that Scott did all the work in the group.)

>Indeed.  It's already being used in ENUM contexts.  The country code 1
>user ENUM trial, for example, is using EPP.
>
>I'd like to see any analysis of data wrapping protocol to include a
>discussion of the issues associated with tunneling data re-using HTTP
>and port 80.  The Security Considerations section would be a good place
>to add text.  Let's discuss the software engineering and deployment
>issues associated with adding HTTP and SOAP software layers, too.  It's
>not as simple as "build on top of SOAP", folks.

Before writing this draft, we had an internal meeting/discussion on 
this debate.

The reason our implementors eschewed EPP was the experience of having 
to build and maintain client tool kits for our EPP-using customers. 
That was a big factor to them.  (The implementors have experience in 
both EPP and SOAP.)  Also, the customers for the ENUM work had no 
real familiarity with EPP but did know SOAP.

In going over the discussion and knowing I would have to commit this 
to paper, my verbal summary was that the separating factors are 
factors not usually important in IETF discussions.  Our preference 
for SOAP over EPP was based on software engineering and software 
management workload.  Not just in-house but also what was either 
reported by or sensed from our client partners.

There isn't a major protocol-engineering detail that differentiates 
the two approaches, and sure, you could use XML schema extensions 
over EPP.  And if you look at the protocol aspects, you could more or 
less call it a draw.  Depending on your metrics, you could decide in 
favor of EPP.  (Or SOAP.)

As far as the tunneling over HTTP, etc., that was considered.  In 
this context, there was no fear of it and in fact a familiarity with 
it.  I don't think it would be productive to be too detailed on this 
item until we get a bit more steam on being a WG.

I'll leave it as is at this point.  The -00 of the document reflects 
our experience in getting our hands dirty on this.  Once we go "WG" 
our experience is just one opinion to cover.  For the time being, we 
can only truthfully document from our own experience.

>This isn't as simple as "EPP vs. SOAP".  You could, for example, carry
>the EPP data structures in SOAP instead of streaming them over TCP as
>described in RFC 3734.  Not that I'm advocating that, but it illustrates
>my point.

And I wanted this to be the next point after my response.  The draft 
picks on the EPP vs. SOAP angle because that is the one "debate" we 
see looming, and it is one we obviously choose a side on when 
building our implementation and conducted our testing.

I am agreeing that is isn't that simple a choice.  It's just that it 
was this choice was worth documenting.  As predicted, there's a 
discussion already rising on this.

>If this document is intended to describe interface requirements it
>shouldn't focus on one protocol or the other.  It should describe the
>*requirements* for the provisioning protocol interface.  We can debate
>which tools best meet the requirements when we get there.

The first line of section 5 should cue that in.  Up until section 5 
any bias is unintentional.  After that, we are talking about our 
experience and the one fairly significant design choice we made.

>We should also consider the possibility of obsoleting and replacing RFC
>4114 if it's proving to be inadequate.  Heck, it's only a *Proposed*
>standard.  If implementation experience demonstrates that it's
>inadequate, well, that's why we have a multi-stage standards track.

I don't think that there's any overt desire to make RFC 4114 sleep 
with the fishes.  For instance, there may be places where "legacy" 
favors EPP.  Perhaps if we go "WG" then a decision on what to do 
about RFC 4114's lack of adoption ought to be in the charter.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

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

Date: Wed, 24 Jan 2007 15:16:56 -0500
To: Andrew Newton <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Cc: [email-masked], Edward Lewis <[email-masked]>

At 12:07 -0500 1/24/07, Andrew Newton wrote:
>On Jan 24, 2007, at 11:51 AM, Edward Lewis wrote:

>>  But I don't really want to spend a long time trying to find 
>>something better just because we should.
>
>Wow!

I'm not sure if I need to clarify something...if we can cobble 
together a solution that meets the requirements from existing 
technologies we should do that.  I think trying to reinvent a 
technology (e.g., a means to convey bytes from one place to another) 
is waste of time unless the technology is truly in need of 
reinventing.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

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

From: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Date: Wed, 24 Jan 2007 12:07:37 -0500
To: Edward Lewis <[email-masked]>
Cc: [email-masked]

On Jan 24, 2007, at 11:51 AM, Edward Lewis wrote:
> Publication rules - I mean the ability to say "give this NAPTR set  
> to carrier A", "give this to B", and give this back to me when I  
> ask. Probably more simply put, "here's the NAPTR set for external  
> consumption and here's the NAPTR set I want to see in my own DNS."

Though in the end we will have to flesh this out some more, I now  
understand what you are talking about.  It is a very good consideration.

> But I don't really want to spend a long time trying to find  
> something better just because we should.

Wow!

-andy

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

Date: Wed, 24 Jan 2007 11:51:40 -0500
To: Andrew Newton <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Cc: [email-masked], Edward Lewis <[email-masked]>

The message quoting is all messed up here...so I'll resort to top posting.

I think it's pretty clear we want to convey what's in a NAPTR.  For 
what we don't have a NAPTR for, there's the (some would say 
"unenviable" but that is not for this argument) fallback of the TXT. 
 From our experience, that is all that we have seen the need to be 
able to convey.  Perhaps that is all we want to have, but I wasn't 
willing yet to say that we don't need to include, NS records.

Publication rules - I mean the ability to say "give this NAPTR set to 
carrier A", "give this to B", and give this back to me when I ask. 
Probably more simply put, "here's the NAPTR set for external 
consumption and here's the NAPTR set I want to see in my own DNS."

As far as a requirement for "expensive to operate" apparently you've 
not seen DNS. ;)  For the requirements that would lead to (or away 
from) XML, I can't think of any others.  We worked in XML because it 
was a standard and it wasn't ASN.1.  (Without trying to drag in too 
much context from other work, I'm thinking of the IRIS vs. LDAP bake 
off in the CRISP WG.  It took too long for the WG to finalize what 
seemed to be a snap of a decision.)

As far as "MUST support legacy systems that use SOAP" inferring "MUST 
use SOAP" I think the first observation is that if a revolutionary 
approach is developed that requires the tossing aside of all legacy 
systems then this work is in vain.  I think an explicit goal should 
be that this work builds on what's in place today. What's there now 
isn't the problem, the problem is what we want to interconnect them 
in a new way or ways.

I will admit that I unabashedly would support "just going with SOAP" 
towards a solution because it seems to be the easiest path to a 
solution.  If there is a better alternative, I'd be open to that, but 
if there is a ready and apparent one.  But I don't really want to 
spend a long time trying to find something better just because we 
should.

As I mentioned in the pat answer - other's experiences will be 
welcomed to the draft once the draft's "authorship" passes to a WG. 
As an individual submission it is based on our experiences.  As a WG 
document it would reflect a broader base of opinion.  Until then 
though, it would be foolhardy of me to try play down SOAP - that is 
until there is a compelling alternative.

I guess I am saying take this document for consideration as a 
reflection of our experiences.  I would be willing to accrete other 
lessons learned into the document.  What I don't want to do is write 
a document that is too general or too close to basic research.  If 
it's only the case that there might be something better than SOAP, 
how is that going to help a requirements document?

Section 5 is decidedly not "requirements" but a reflection on our 
experience in making the choice.  Maybe this gets dropped from a 
requirements document and finds it way into a document on 
implementation decisions - those kept and those discarded.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

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

From: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Date: Wed, 24 Jan 2007 11:11:43 -0500
To: Edward Lewis <[email-masked]>
Cc: [email-masked]

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=======72585503=
Content-Type: multipart/alternative;
	boundary="=_zeke.ecotroph.net-15880-1169655077-0001-2"

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zeke.ecotroph.net-15880-1169655077-0001-2
Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit

On Jan 24, 2007, at 10:50 AM, Edward Lewis wrote:

> >So, we need to be able to provision a list of 256 octet length  
> ASCII strings?  And since, conceivably, all DNS RR types can be  
> used in DDDS, this is probably overkill as requirements go.  Or way  
> to general.
> Answering the question, "no." As before "be able to convey" is not  
> the same as "convey."

The difference between MUST implement and MUST deploy is not the  
issue.  Since your requirement is that the protocol MUST be able to  
convey anything "conceivable", there is a large amount of room for  
subjective differences of opinion.

> >> 3.1.5 MUST be able to express the publication rules for any  
> registered
> >> data.
> >>
> >> o For data that differs upon the querier, such as the difference  
> between
> >> contacts and address-of-records in SIP.
> >
> >This needs a better explanation.
>
>  RFC 3764. - Does that help?

Well, it narrows the scope.  But I still don't know what you mean by  
"publication rules."

> >> 3.2.1 ...
> >> 3.2.2 ...
> >I have no problem with IRIs or dictating UTF-8 or XML.  None of us  
> wants to spend time sifting through obscure technologies.  But  
> wrapping this stuff in Mom & Apple Pie language just lends the  
> requirement to very subjective interpretations.
> I don't understand the comment, the latter part that is.

I doubt anybody will offer a proposal claiming to meet the  
requirements of "flimsy", "difficult to implement", and "expensive to  
operate".  Language like "robust" and "scalable" are highly  
subjective.  If your intent is to narrow the solution space, but  
forthcoming about it.

> >> 5 EPP Protocol
> >>
> >Stating that SOAP MUST be the mechanism of choice is wrong on a  
> few levels.
>
> I don't think that was ever said, "MUST" that is.

MUST support the "legacy" systems that use SOAP is an implication  
that SOAP MUST be used.  This is my basis of objection.  I'm not  
advocating against SOAP, but if the requirement is that we have to  
use it because certain people don't want to change any of their code,  
that is the equivalent of a rubber stamp.

-andy

--=_zeke.ecotroph.net-15880-1169655077-0001-2
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier
	0.53.3

<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jan 24, 2007, at 10:50 AM, Edward Lewis wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>&gt;So, we need to be able to provision a list of 256 octet length ASCII strings?  And since, conceivably, all DNS RR types can be used in DDDS, this is probably overkill as requirements go.  Or way to general.<BR></DIV><DIV>Answering the question, "no." As before "be able to convey" is not the same as "convey."</DIV></SPAN></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The difference between MUST implement and MUST deploy is not the issue.  Since your requirement is that the protocol MUST be able to convey anything "conceivable", there is a large amount of room for subjective differences of opinion.</DIV><BR><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV></DIV><DIV>&gt;&gt; 3.1.5 MUST be able to express the publication rules for any registered<BR>&gt;&gt; data.<BR>&gt;&gt;<BR>&gt;&gt; o For data that differs upon the querier, such as the difference between<BR>&gt;&gt; contacts and address-of-records in SIP.<BR>&gt;</DIV><DIV>&gt;This needs a better explanation.</DIV><DIV><BR></DIV><DIV> RFC 3764. - Does that help?</DIV></SPAN></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Well, it narrows the scope.  But I still don't know what you mean by "publication rules."</DIV><BR><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV></DIV><DIV>&gt;&gt; 3.2.1 ...</DIV><DIV>&gt;&gt; 3.2.2 ...</DIV><DIV>&gt;I have no problem with IRIs or dictating UTF-8 or XML.  None of us wants to spend time sifting through obscure technologies.  But wrapping this stuff in Mom &amp; Apple Pie language just lends the requirement to very subjective interpretations.<BR></DIV><DIV>I don't understand the comment, the latter part that is.</DIV></SPAN></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I doubt anybody will offer a proposal claiming to meet the requirements of "flimsy", "difficult to implement", and "expensive to operate".  Language like "robust" and "scalable" are highly subjective.  If your intent is to narrow the solution space, but forthcoming about it.</DIV><BR><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV></DIV><DIV>&gt;&gt; 5 EPP Protocol</DIV><DIV>&gt;&gt;</DIV><DIV>&gt;Stating that SOAP MUST be the mechanism of choice is wrong on a few levels.</DIV><DIV><BR></DIV><DIV>I don't think that was ever said, "MUST" that is.</DIV></SPAN></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>MUST support the "legacy" systems that use SOAP is an implication that SOAP MUST be used.  This is my basis of objection.  I'm not advocating against SOAP, but if the requirement is that we have to use it because certain people don't want to change any of their code, that is the equivalent of a rubber stamp.</DIV><BR><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV></DIV></SPAN></BLOCKQUOTE></DIV>-andy<BR></BODY></HTML>
--=_zeke.ecotroph.net-15880-1169655077-0001-2--

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

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

--=======72585503=--

Date: Wed, 24 Jan 2007 10:50:28 -0500
To: Andrew Newton <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Cc: [email-masked]

--=======18230690=
Content-Type: multipart/alternative;
	boundary="======_-1042468664=_ma======"

--======_-1042468664=_ma======
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 21:17 -0500 1/23/07, Andrew Newton wrote:

>Other comments in-line:
>>  3.1.1 ...

>Even if we are strictly talking about ENUM, I question the need for 
>this.  I would think the decisions for things like weight and 
>priority on NAPTR records should not be left up to every entity 
>provisioning into the registry.

The important phrase is "be able to."  This does not mean "MUST 
convey" the values.

>>  3.1.2 ...

>So, we need to be able to provision a list of 256 octet length ASCII 
>strings?  And since, conceivably, all DNS RR types can be used in 
>DDDS, this is probably overkill as requirements go.  Or way to 
>general.

Answering the question, "no." As before "be able to convey" is not 
the same as "convey."

>>  3.1.5 MUST be able to express the publication rules for any registered
>>  data.
>>
>>  o For data that differs upon the querier, such as the difference between
>>  contacts and address-of-records in SIP.
>
>This needs a better explanation.

  RFC 3764. - Does that help?

>>  3.1.6 ...
>
>Does this mean that each transaction must have unique identifier?

Yeah, well that is what was in mind.  But if there is another way it 
should/could be considered

>>  3.1.7 SHOULD follow any applicable standards.
>>
>>  o Public standards are hardier than internally developed solutions.
>
>Ummm....

Yeah, I know this sounds too basic to be written.  But this came up 
once in a call.  One group I talked to questioned the logic of 
including all the NAPTR information when all that was needed was an 
TN to URI mapping.  Once I mentioned "we want to follow standards" 
they quickly came to agree.

>>  3.2.1 ...
>>  3.2.2 ...
>I have no problem with IRIs or dictating UTF-8 or XML.  None of us 
>wants to spend time sifting through obscure technologies.  But 
>wrapping this stuff in Mom & Apple Pie language just lends the 
>requirement to very subjective interpretations.

I don't understand the comment, the latter part that is.

>If the intent is to replicate DNS AXFR or IXFR functionality, why 
>not just use DNS?

Not replicate, support and probably be optimized for.  The assumption 
for ENUM is that it be via DNS, but why limit options.

>>  5 EPP Protocol
>>
>Stating that SOAP MUST be the mechanism of choice is wrong on a few levels.

I don't think that was ever said, "MUST" that is.

>First, I've run into far more XML-over-FTP or CSV-over-FTP 
>provisioning systems than I have SOAP.  So, there are plenty of 
>"legacy" systems that aren't SOAP based.

I suppose then that I ought to add a requirement for an interactive 
(as opposed to batch-oriented file transfers.)

>Second, SOAP was not the first protocol with implementations that 
>did stub-method code generation.  It isn't magic, and saying "just 
>use SOAP" does not mean provisioning systems will write themselves.  
>
>There is always business logic and database interaction that must be 
>managed.  In my experience, getting the XML on and off the wire is a 
>very small part the software that must be written.
>
>Also, as has been mentioned, there is some adoption of EPP.

Here's my pat answer and then I'll explain:

"If a WG is formed and this document is accepted as WG document, I 
would be happy (if appointed editor) to include the experiences and 
trade-off analysis of others."

What I mean is that these requirements are based on our experience 
(that being me and developers here) in working with EPP and SOAP. 
(We do have some FTP based systems too, but they weren't part of the 
process.)  I hope that the requirements per se do not say "MUST be 
SOAP" but from our practical experience,  SOAP appears to us to be 
the way to go.  'Course, that's not a requirement but a statement on 
the solution.

For the record, when we tested a SOAP based solution to this with 
other organizations, no one objected or expressed any concern about 
the choice.  This doesn't mean that SOAP is necessarily the best 
solution, but based on our experience it seems to be the best choice.

The requirements are not meant to be stacked towards any solution. 
But if they are, I will plead it is an accident of history.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.
--======_-1042468664=_ma======
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [PEPPERMINT] comments on
draft-lewis-peppermint-enum-r</title></head><body>
<div>At 21:17 -0500 1/23/07, Andrew Newton wrote:</div>
<div><br></div>
<div>&gt;Other comments in-line:</div>
<div>&gt;&gt; 3.1.1 ...</div>
<div><br></div>
<div>&gt;Even if we are strictly talking about ENUM, I question the
need for this.&nbsp; I would think the decisions for things like
weight and priority on NAPTR records should not be left up to every
entity provisioning into the registry.<br>
</div>
<div>The important phrase is &quot;be able to.&quot;&nbsp; This does
not mean &quot;MUST convey&quot; the values.</div>
<div><br></div>
<div>&gt;&gt; 3.1.2 ...</div>
<div><br></div>
<div>&gt;So, we need to be able to provision a list of 256 octet
length ASCII strings?&nbsp; And since, conceivably, all DNS RR types
can be used in DDDS, this is probably overkill as requirements go.&nbsp;
Or way to general.<br>
</div>
<div>Answering the question, &quot;no.&quot; As before &quot;be able
to convey&quot; is not the same as &quot;convey.&quot;</div>
<div><br></div>
<div>&gt;&gt; 3.1.5 MUST be able to express the publication rules for
any registered<br>
&gt;&gt; data.<br>
&gt;&gt;<br>
&gt;&gt; o For data that differs upon the querier, such as the
difference between<br>
&gt;&gt; contacts and address-of-records in SIP.<br>
&gt;</div>
<div>&gt;This needs a better explanation.</div>
<div><br></div>
<div>&nbsp;RFC 3764. - Does that help?</div>
<div><br></div>
<div>&gt;&gt; 3.1.6 ...</div>
<div>&gt;</div>
<div>&gt;Does this mean that each transaction must have unique
identifier?</div>
<div><br></div>
<div>Yeah, well that is what was in mind.&nbsp; But if there is
another way it should/could be considered</div>
<div><br></div>
<div>&gt;&gt; 3.1.7 SHOULD follow any applicable standards.<br>
&gt;&gt;<br>
&gt;&gt; o Public standards are hardier than internally developed
solutions.<br>
&gt;</div>
<div>&gt;Ummm....</div>
<div><br></div>
<div>Yeah, I know this sounds too basic to be written.&nbsp; But this
came up once in a call.&nbsp; One group I talked to questioned the
logic of including all the NAPTR information when all that was needed
was an TN to URI mapping.&nbsp; Once I mentioned &quot;we want to
follow standards&quot; they quickly came to agree.</div>
<div><br></div>
<div>&gt;&gt; 3.2.1 ...</div>
<div>&gt;&gt; 3.2.2 ...</div>
<div>&gt;I have no problem with IRIs or dictating UTF-8 or XML.&nbsp;
None of us wants to spend time sifting through obscure technologies.&nbsp;
But wrapping this stuff in Mom &amp; Apple Pie language just lends the
requirement to very subjective interpretations.<br>
</div>
<div>I don't understand the comment, the latter part that is.</div>
<div><br></div>
<div>&gt;If the intent is to replicate DNS AXFR or IXFR functionality,
why not just use DNS?</div>
<div><br></div>
<div>Not replicate, support and probably be optimized for.&nbsp; The
assumption for ENUM is that it be via DNS, but why limit
options.</div>
<div><br></div>
<div>&gt;&gt; 5 EPP Protocol</div>
<div>&gt;&gt;</div>
<div>&gt;Stating that SOAP MUST be the mechanism of choice is wrong on
a few levels.</div>
<div><br></div>
<div>I don't think that was ever said, &quot;MUST&quot; that is.</div>
<div><br></div>
<div>&gt;First, I've run into far more XML-over-FTP or CSV-over-FTP
provisioning systems than I have SOAP.&nbsp; So, there are plenty of
&quot;legacy&quot; systems that aren't SOAP based.<br>
</div>
<div><br></div>
<div>I suppose then that I ought to add a requirement for an
interactive (as opposed to batch-oriented file transfers.)</div>
<div><br>
&gt;Second, SOAP was not the first protocol with implementations that
did stub-method code generation.&nbsp; It isn't magic, and saying
&quot;just use SOAP&quot; does not mean provisioning systems will
write themselves.&nbsp;&nbsp;<br>
&gt;</div>
<div>&gt;There is always business logic and database interaction that
must be managed.&nbsp; In my experience, getting the XML on and off
the wire is a very small part the software that must be written.<br>
&gt;</div>
<div>&gt;Also, as has been mentioned, there is some adoption of
EPP.</div>
<div><br></div>
<div>Here's my pat answer and then I'll explain:</div>
<div><br></div>
<div>&quot;If a WG is formed and this document is accepted as WG
document, I would be happy (if appointed editor) to include the
experiences and trade-off analysis of others.&quot;</div>
<div><br></div>
<div>What I mean is that these requirements are based on our
experience (that being me and developers here) in working with EPP and
SOAP.&nbsp; (We do have some FTP based systems too, but they weren't
part of the process.)&nbsp; I hope that the requirements per se do not
say &quot;MUST be SOAP&quot; but from our practical experience,&nbsp;
SOAP appears to us to be the way to go.&nbsp; 'Course, that's not a
requirement but a statement on the solution.</div>
<div><br></div>
<div>For the record, when we tested a SOAP based solution to this with
other organizations, no one objected or expressed any concern about
the choice.&nbsp; This doesn't mean that SOAP is necessarily the best
solution, but based on our experience it seems to be the best
choice.</div>
<div><br></div>
<div>The requirements are not meant to be stacked towards any
solution.&nbsp; But if they are, I will plead it is an accident of
history.</div>
<div><br></div>
<x-sigsep><pre>-- 
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-<br>
Edward
Lewis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp;&nbsp;&nbsp; +1-571-434-5468<br>
NeuStar</div>
<div><br></div>
<div>Dessert - aka Service Pack 1 for lunch.</div>
</body>
</html>
--======_-1042468664=_ma======--

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

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

--=======18230690=--

Content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00
Date: Wed, 24 Jan 2007 07:37:08 -0500
From: "Hollenbeck, Scott" <[email-masked]>
To: "Andrew Newton" <[email-masked]>, <[email-masked]>
Cc: 

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Tuesday, January 23, 2007 9:17 PM
> To: [email-masked]
> Subject: [PEPPERMINT] comments on 
> draft-lewis-peppermint-enum-ref-if-00

Disclaimer: I'm the author of EPP.  I have a bias.

[snip]

> > 5 EPP Protocol
> >
> > Breaking from requirements, there has been some consideration to EPP
> > extensions for ENUM [RFC4114], and why it has not been 
> adopted and why
> > a requirements document is now being produced to cover what would
> > seemingly be addressed by that solution.
> >
> > There are two reasons for EPP not being adopted.  One is 
> that it isn't
> > compatible with legacy participants.  The other reason is that it
> > requires more implementation work.
> >
> > Legacy participants have an existing base of software development  
> > built
> > around SOAP/XML and WSDL, and are familiar with TLS.  
> Approaches to  
> > ENUM
> > registry interfaces that use these tools will blend more easily into
> > the software products already in use to manage telephone numbers.
> >
> > The use of SOAP permits automatic generation of software to 
> handle the
> > client side of the exchange.  Domain name registries had to provide
> > software tool kits to give to registrars to match this 
> functionality.
> > When a change is made to EPP, there will be a lot of software  
> > exchanged.
> >
> > From experience with both EPP and SOAP based approaches to registry
> > software, the SOAP based approach is much easier on the software
> > engineering process.  The difference between the approaches is not  
> > seen
> > in a protocol analysis, but in an analysis of software engineering.
> 
> Stating that SOAP MUST be the mechanism of choice is wrong on a few  
> levels.
> 
> First, I've run into far more XML-over-FTP or CSV-over-FTP  
> provisioning systems than I have SOAP.  So, there are plenty of  
> "legacy" systems that aren't SOAP based.
> 
> Second, SOAP was not the first protocol with implementations 
> that did  
> stub-method code generation.  It isn't magic, and saying "just use  
> SOAP" does not mean provisioning systems will write themselves.   
> There is always business logic and database interaction that must be  
> managed.  In my experience, getting the XML on and off the wire is a  
> very small part the software that must be written.
> 
> Also, as has been mentioned, there is some adoption of EPP.

Indeed.  It's already being used in ENUM contexts.  The country code 1
user ENUM trial, for example, is using EPP.

I'd like to see any analysis of data wrapping protocol to include a
discussion of the issues associated with tunneling data re-using HTTP
and port 80.  The Security Considerations section would be a good place
to add text.  Let's discuss the software engineering and deployment
issues associated with adding HTTP and SOAP software layers, too.  It's
not as simple as "build on top of SOAP", folks.

This isn't as simple as "EPP vs. SOAP".  You could, for example, carry
the EPP data structures in SOAP instead of streaming them over TCP as
described in RFC 3734.  Not that I'm advocating that, but it illustrates
my point.

If this document is intended to describe interface requirements it
shouldn't focus on one protocol or the other.  It should describe the
*requirements* for the provisioning protocol interface.  We can debate
which tools best meet the requirements when we get there.

We should also consider the possibility of obsoleting and replacing RFC
4114 if it's proving to be inadequate.  Heck, it's only a *Proposed*
standard.  If implementation experience demonstrates that it's
inadequate, well, that's why we have a multi-stage standards track.

-Scott-

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

To: [email-masked]
From: Andrew Newton <[email-masked]>
Date: Tue, 23 Jan 2007 21:17:18 -0500
Subject: [PEPPERMINT] comments on draft-lewis-peppermint-enum-ref-if-00

I've reviewed this draft.  Though it touches on non-ENUM points, it  
is very centered on ENUM.  In general, I would like to see a  
consideration for a more general query mechanism.  Yes, ENUM will be  
used by many entities, but redirect servers are also quite common.

Other comments in-line:
> 3.1.1 MUST be able to covey all of the information required for a DNS
> NAPTR resource record.

Even if we are strictly talking about ENUM, I question the need for  
this.  I would think the decisions for things like weight and  
priority on NAPTR records should not be left up to every entity  
provisioning into the registry.

> 3.1.2 MUST be able to convey all of the information required for a  
> DNS TXT
> resource record or any other record type that can conceivably be  
> used in
> DDDS.

So, we need to be able to provision a list of 256 octet length ASCII  
strings?  And since, conceivably, all DNS RR types can be used in  
DDDS, this is probably overkill as requirements go.  Or way to general.

> 3.1.5 MUST be able to express the publication rules for any registered
> data.
>
> o For data that differs upon the querier, such as the difference  
> between
> contacts and address-of-records in SIP.

This needs a better explanation.

> 3.1.6 MUST provide a means of tracking individual commands.
>
> o Each command has to be identifiable for later actions.  The  
> interface is
> not involved in tracking.

Does this mean that each transaction must have unique identifier?

> 3.1.7 SHOULD follow any applicable standards.
>
> o Public standards are hardier than internally developed solutions.

Ummm....

> 3.2.1 MUST use an encoding method that is robust, easy to design and
> troubleshoot, and is capable of supporting IRI's.
>
> o Easy to design and troubleshoot lends itself to mechanisms that  
> are text
> based as opposed to binary or hexadecimal.  Internationalization is
> important, for now at least host names might be in non-ASCII and  
> sooner
> or later other parts of a URI may also be.
>
> 3.2.2 SHOULD use a widely recognized standard.
>
> o Avoiding specifically developed mechanisms.

I have no problem with IRIs or dictating UTF-8 or XML.  None of us  
wants to spend time sifting through obscure technologies.  But  
wrapping this stuff in Mom & Apple Pie language just lends the  
requirement to very subjective interpretations.

> 4.2 SHOULD be able to populate a DNS zone transfer message, once the
> SOA RR is included.
>
> o A DNS AXFR or IXFR consist of a zone's SOA resource record,  
> followed by
> a list of resource records, and followed by another copy of the SOA
> resource record.  The SOA resource record has parameters best set  
> by the
> resolution system, so that is left to the client-side of this  
> interface.
>   But all of the rest of the zone transfer data ought to be able to be
> pulled from the formats exchanged over this interface.

If the intent is to replicate DNS AXFR or IXFR functionality, why not  
just use DNS?

> 5 EPP Protocol
>
> Breaking from requirements, there has been some consideration to EPP
> extensions for ENUM [RFC4114], and why it has not been adopted and why
> a requirements document is now being produced to cover what would
> seemingly be addressed by that solution.
>
> There are two reasons for EPP not being adopted.  One is that it isn't
> compatible with legacy participants.  The other reason is that it
> requires more implementation work.
>
> Legacy participants have an existing base of software development  
> built
> around SOAP/XML and WSDL, and are familiar with TLS.  Approaches to  
> ENUM
> registry interfaces that use these tools will blend more easily into
> the software products already in use to manage telephone numbers.
>
> The use of SOAP permits automatic generation of software to handle the
> client side of the exchange.  Domain name registries had to provide
> software tool kits to give to registrars to match this functionality.
> When a change is made to EPP, there will be a lot of software  
> exchanged.
>
> From experience with both EPP and SOAP based approaches to registry
> software, the SOAP based approach is much easier on the software
> engineering process.  The difference between the approaches is not  
> seen
> in a protocol analysis, but in an analysis of software engineering.

Stating that SOAP MUST be the mechanism of choice is wrong on a few  
levels.

First, I've run into far more XML-over-FTP or CSV-over-FTP  
provisioning systems than I have SOAP.  So, there are plenty of  
"legacy" systems that aren't SOAP based.

Second, SOAP was not the first protocol with implementations that did  
stub-method code generation.  It isn't magic, and saying "just use  
SOAP" does not mean provisioning systems will write themselves.   
There is always business logic and database interaction that must be  
managed.  In my experience, getting the XML on and off the wire is a  
very small part the software that must be written.

Also, as has been mentioned, there is some adoption of EPP.

-andy

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

To: [email-masked]
From: Andrew Newton <[email-masked]>
Date: Tue, 23 Jan 2007 20:17:57 -0500
Subject: [PEPPERMINT] Fwd: I-D ACTION:draft-lewis-peppermint-enum-reg-if-00.txt 

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=======67838972=
Content-Type: multipart/alternative;
	boundary="=_zeke.ecotroph.net-26788-1169601447-0001-2"

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zeke.ecotroph.net-26788-1169601447-0001-2
Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit

FYI

Begin forwarded message:

> From: [email-masked]
> Date: January 23, 2007 3:50:01 PM EST
> To: [email-masked]
> Subject: I-D ACTION:draft-lewis-peppermint-enum-reg-if-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: ENUM Registry Interface Requirements
> 	Author(s)	: E. Lewis
> 	Filename	: draft-lewis-peppermint-enum-reg-if-00.txt
> 	Pages		:
> 	Date		: 2007-1-23
> 	
> An ENUM registry interacts with various elements to maintain what is
> essentially a telephone number to uniform (or a more modern version)
> resource identifier.  The interfaces needed are identified in this
> requirements document, as well as the requirements for the more  
> generic
> interfaces.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lewis-peppermint-enum-reg- 
> if-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-lewis-peppermint-enum-reg-if-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-lewis-peppermint-enum-reg-if-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.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

--=_zeke.ecotroph.net-26788-1169601447-0001-2
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier
	0.53.3

<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">FYI<BR><DIV><BR><DIV>Begin forwarded message:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><B>From: </B></FONT><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica"><A href="mailto:[email-masked]">[email-masked]</A></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><B>Date: </B></FONT><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">January 23, 2007 3:50:01 PM EST</FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><B>To: </B></FONT><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica"><A href="mailto:[email-masked]">[email-masked]</A></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><B>Subject: </B></FONT><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica"><B>I-D ACTION:draft-lewis-peppermint-enum-reg-if-00.txt<SPAN class="Apple-converted-space"> </SPAN></B></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><FONT face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><B>Reply-To: </B></FONT><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica"><A href="mailto:[email-masked]">[email-masked]</A></FONT></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">A New Internet-Draft is available from the on-line Internet-Drafts<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">directories.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>Title<SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>: ENUM Registry Interface Requirements</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>Author(s)<SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>: E. Lewis</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>Filename<SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>: draft-lewis-peppermint-enum-reg-if-00.txt</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>Pages<SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>:<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>Date<SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>: 2007-1-23</DIV><P style="margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN><BR class="khtml-block-placeholder"></P><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">An ENUM registry interacts with various elements to maintain what is</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">essentially a telephone number to uniform (or a more modern version)</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">resource identifier.<SPAN class="Apple-converted-space">  </SPAN>The interfaces needed are identified in this</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">requirements document, as well as the requirements for the more generic</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">interfaces.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">A URL for this Internet-Draft is:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://www.ietf.org/internet-drafts/draft-lewis-peppermint-enum-reg-if-00.txt">http://www.ietf.org/internet-drafts/draft-lewis-peppermint-enum-reg-if-00.txt</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">To remove yourself from the I-D Announcement list, send a message to<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="mailto:[email-masked]">[email-masked]</A> with the word unsubscribe in the body of<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">the message.<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">You can also visit <A href="https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1.ietf.org/mailman/listinfo/I-D-announce</A><SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to change your subscription settings.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Internet-Drafts are also available by anonymous FTP. Login with the<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">username "anonymous" and a password of your e-mail address. After<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">logging in, type "cd internet-drafts" and then<SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">"get draft-lewis-peppermint-enum-reg-if-00.txt".</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">A list of Internet-Drafts directories can be found in</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</A><SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">or <A href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Internet-Drafts can also be obtained by e-mail.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Send a message to:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN><A href="mailto:[email-masked]">[email-masked]</A>.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">In the body type:</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>"FILE /internet-drafts/draft-lewis-peppermint-enum-reg-if-00.txt".</DIV><P style="margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px"><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN><BR class="khtml-block-placeholder"></P><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">NOTE:<SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>The mail server at ietf.org can return the document in</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>MIME-encoded form by using the "mpack" utility.<SPAN class="Apple-converted-space">  </SPAN>To use this</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>feature, insert the command "ENCODING mime" before the "FILE"</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>command.<SPAN class="Apple-converted-space">  </SPAN>To decode the response(s), you will need "munpack" or</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>a MIME-compliant mail reader.<SPAN class="Apple-converted-space">  </SPAN>Different MIME-compliant mail readers</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>exhibit different behavior, especially when dealing with</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>"multipart" MIME messages (i.e. documents which have been split</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>up into multiple messages), so check your local documentation on</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre">	</SPAN>how to manipulate these messages.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Below is the data which will enable a MIME compliant mail reader</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">implementation to automatically retrieve the ASCII version of the</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Internet-Draft.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Content-Type: text/plain</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Content-ID: &lt;<A href="mailto:[email-masked]">[email-masked]</A>&gt;</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I-D-Announce mailing list</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="mailto:[email-masked]">[email-masked]</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1.ietf.org/mailman/listinfo/i-d-announce</A></DIV> </BLOCKQUOTE></DIV><BR></BODY></HTML>
--=_zeke.ecotroph.net-26788-1169601447-0001-2--

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

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

--=======67838972=--

Content-class: urn:content-classes:message
Date: Mon, 22 Jan 2007 15:07:44 +0200
From: "David Schwartz" <[email-masked]>
To: "Otmar Lendl" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [PEPPERMINT] RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

Hi Otmar

I think the problem is that of an unclear definition. The current
definition of length is "This field is used for expanding ranges to
individual unique numbers". The wording I would add is as follows...
"This value is an exact match and is used for expanding ranges to
complete number sets. In areas of the world where non NANP type
numbering plans exist there may be a need for multiple "exact" length
records to account for all possibilities:".

With that said I am not completely averse to exchanging "exact" length
with two alternate fields: minLength and maxLength. All I was trying to
say was that anything you can do with those two can be done with 1 exact
length field as well.

David

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Wednesday, January 10, 2007 8:12 PM
To: David Schwartz
Cc: Andrew Newton; Richard Shockey; [email-masked];
[email-masked]
Subject: Re: [Speermint]
draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

On 2007/01/09 16:01, David Schwartz <[email-masked]> wrote:
> Hi Otmar.

David,

> In general, the assumption I made in the draft was that ranges cover a
> factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6
> than the numbers provisioned are 123450, 123451, ... 123459. 

Sound fine as long as you can assume you know the length of the number.

> The problem
> you raise regarding the numbering plans in Germany is not new to me
and
> brings up the question that often arises in database architecture,
> namely that of width (or length) of a record Vs the depth or table
size.
> Specifically, how complicated do we want to make each provisioning
> record at the expense of not writing another record. 

Oh, I'm not even there yet. What bothers me is the implicit assumption
that
we're dealing with sets of numbers, and not sets of prefixes. 

In other words, I'd prefer to first get consensus on what a typical
database scheme of such a registry might look like.

Once we have that, we can start to talk about how to provision records
into that database. As you mention, a single provisioning record
might get expanded into multiple records in the database. On the
other hand, any rule we want to store in the DB must also be possible
to provision in some way.

> While at one extreme is the prospect of provisioning each number
> individually and not using ranges, it is possible using the mechanism
I
> proposed to combine individual numbers with ranges and take advantage
of
> "DeactivationDate" field that allows me to port individual values as
> well as sub-ranges out of larger 10X ranges and arrive at the
resolution
> we desire.

I think I understand your scheme and I think it is very reasonable
for sets of fixed-length numbers.

It's just that I don't think that "sets of fixed-length numbers" is
all we're going to need.

E.g. yes, you can use that scheme to announce a route to the
full NANP area with

Activate...
1,true,11 // equivalent to adding 1XXXXXXXXXX

but how do you do a route to Austria? This way?

43,true,15 // equivalent to adding 43XXXXXXXXXXXXXX

Is this record supposed to match 436624669 which is not 15 digits long?
Or do I also need to provision the following:

43,true,9

Or, to take the example from my last mail: What should Telekom Austria
provision into your system to announce that they serve +43 1 50564616
plus all set of possible extensions behind that number?

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

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

Content-class: urn:content-classes:message
Date: Mon, 22 Jan 2007 14:35:50 +0200
From: "David Schwartz" <[email-masked]>
To: "T. Martin" <[email-masked]>, "Andrew Newton" <[email-masked]>, "Richard Shockey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [PEPPERMINT] RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

Hi Terry

> I would suggest you qualify the definition of an E.164 number as
defined 
> by ITU E.123.  And indicate what will be included in the field number

> Were to get the correct notation information:
> http://www.itu.int/rec/T-REC-E.123-200102-I/E

> The definition should include:

> Each assigned number contains a country code (CC), a national
destination
> code (NDC), and a subscriber number (SN). There can be up to 15 digits
in 
> an E.164 number. The E.164 plan was originally developed by the 
> International Telecommunication Union (ITU).

Agreed.

> I have another question: 

> Where do you get the time and date information?

So the only field where this is really an issue is "CreationDatetime".
If no value is entered the provisioning server enters the current time,
otherwise the provisioning client needs to enter the value for this.
Specifically, one thing this draft did not address was the data set for
the provisioning response (which will hopefully be included in the next
version). One of the fields that must be returned is the creation date
time field. When provisioning a number for the first time, the
provisioning client leaves the "CreationDatetime" field empty and the
server enters the current time. This time is returned to the client and
upon any subsequent modification of this record this date time should be
used.

David

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

To: [email-masked]
From: Andrew Newton <[email-masked]>
Date: Wed, 17 Jan 2007 16:36:17 -0500
Subject: [PEPPERMINT] test

pls ignore

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

Date: Tue, 16 Jan 2007 17:27:38 +0000
From: Paul Erkkila <[email-masked]>
To: Otmar Lendl <[email-masked]>, David Schwartz <[email-masked]>, Andrew Newton <[email-masked]>, Richard Shockey <[email-masked]>, [email-masked]
Cc: 
Subject: [PEPPERMINT] Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

   My thoughts on this discussion.

- Adapting this data to fit the "common" database case *may* be very 
difficult . I think separating communication of the data and using it 
should be left separate.

- The "extreme" case as David named it where a fully expanded route list 
is transmitted is actually the easiest to adopt case. It can be 
converted to pretty much any format. (This is covered by the Range flag 
in the draft).

- Any format compression such as the range flag and length field as 
proposed really needs to cover the entire namespace. As much as I love 
the NANP ignoring the requirements of variable plan implementors like 
Austria (no kangaroos) seems like a bad idea.

   Would it be horribly evil to allow regular expression like syntax in 
the value field? Expansions would be bounded by E164, and the rules 
allowed can be modified to reduce complexity errors that David is 
concerned about, purely for example:
     - Matches and expansions on numbers only (E164)
     - Expansion just inside the E164 space (E164: no 17 digit numbers)
     - Can make all values here inclusive (positive) and not allow 
negation operations. (complexity)
     - All expansion is done on the right side (complexity)

The answer to Telecom Austria announcing "+43 1 50564616" could then be 
4315056461[6][0-9]* (pick a favorite syntax).

A value with no syntax sugar would just be the standard value.

This seems to cover the number/prefix issue, as well as the length 
variation issue (inside of e164).

-pee

Otmar Lendl wrote:
> On 2007/01/09 16:01, David Schwartz <[email-masked]> wrote:
>> Hi Otmar.
> 
> David,
> 
>> In general, the assumption I made in the draft was that ranges cover a
>> factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6
>> than the numbers provisioned are 123450, 123451, ... 123459. 
> 
> Sound fine as long as you can assume you know the length of the number.
> 
>> The problem
>> you raise regarding the numbering plans in Germany is not new to me and
>> brings up the question that often arises in database architecture,
>> namely that of width (or length) of a record Vs the depth or table size.
>> Specifically, how complicated do we want to make each provisioning
>> record at the expense of not writing another record. 
> 
> Oh, I'm not even there yet. What bothers me is the implicit assumption that
> we're dealing with sets of numbers, and not sets of prefixes. 
> 
> In other words, I'd prefer to first get consensus on what a typical
> database scheme of such a registry might look like.
> 
> Once we have that, we can start to talk about how to provision records
> into that database. As you mention, a single provisioning record
> might get expanded into multiple records in the database. On the
> other hand, any rule we want to store in the DB must also be possible
> to provision in some way.
> 
>> While at one extreme is the prospect of provisioning each number
>> individually and not using ranges, it is possible using the mechanism I
>> proposed to combine individual numbers with ranges and take advantage of
>> "DeactivationDate" field that allows me to port individual values as
>> well as sub-ranges out of larger 10X ranges and arrive at the resolution
>> we desire.
> 
> I think I understand your scheme and I think it is very reasonable
> for sets of fixed-length numbers.
> 
> It's just that I don't think that "sets of fixed-length numbers" is
> all we're going to need.
> 
> E.g. yes, you can use that scheme to announce a route to the
> full NANP area with
> 
> Activate...
> 1,true,11 // equivalent to adding 1XXXXXXXXXX
> 
> but how do you do a route to Austria? This way?
> 
> 43,true,15 // equivalent to adding 43XXXXXXXXXXXXXX
> 
> Is this record supposed to match 436624669 which is not 15 digits long?
> Or do I also need to provision the following:
> 
> 43,true,9
> 
> Or, to take the example from my last mail: What should Telekom Austria
> provision into your system to announce that they serve +43 1 50564616
> plus all set of possible extensions behind that number?
> 
> /ol

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

Date: Wed, 10 Jan 2007 19:12:22 +0100
From: Otmar Lendl <[email-masked]>
To: David Schwartz <[email-masked]>
Mail-Followup-To: Otmar Lendl <[email-masked]>, David Schwartz <[email-masked]>, Andrew Newton <[email-masked]>, Richard Shockey <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: [PEPPERMINT] Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

On 2007/01/09 16:01, David Schwartz <[email-masked]> wrote:
> Hi Otmar.

David,

> In general, the assumption I made in the draft was that ranges cover a
> factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6
> than the numbers provisioned are 123450, 123451, ... 123459. 

Sound fine as long as you can assume you know the length of the number.

> The problem
> you raise regarding the numbering plans in Germany is not new to me and
> brings up the question that often arises in database architecture,
> namely that of width (or length) of a record Vs the depth or table size.
> Specifically, how complicated do we want to make each provisioning
> record at the expense of not writing another record. 

Oh, I'm not even there yet. What bothers me is the implicit assumption that
we're dealing with sets of numbers, and not sets of prefixes. 

In other words, I'd prefer to first get consensus on what a typical
database scheme of such a registry might look like.

Once we have that, we can start to talk about how to provision records
into that database. As you mention, a single provisioning record
might get expanded into multiple records in the database. On the
other hand, any rule we want to store in the DB must also be possible
to provision in some way.

> While at one extreme is the prospect of provisioning each number
> individually and not using ranges, it is possible using the mechanism I
> proposed to combine individual numbers with ranges and take advantage of
> "DeactivationDate" field that allows me to port individual values as
> well as sub-ranges out of larger 10X ranges and arrive at the resolution
> we desire.

I think I understand your scheme and I think it is very reasonable
for sets of fixed-length numbers.

It's just that I don't think that "sets of fixed-length numbers" is
all we're going to need.

E.g. yes, you can use that scheme to announce a route to the
full NANP area with

Activate...
1,true,11 // equivalent to adding 1XXXXXXXXXX

but how do you do a route to Austria? This way?

43,true,15 // equivalent to adding 43XXXXXXXXXXXXXX

Is this record supposed to match 436624669 which is not 15 digits long?
Or do I also need to provision the following:

43,true,9

Or, to take the example from my last mail: What should Telekom Austria
provision into your system to announce that they serve +43 1 50564616
plus all set of possible extensions behind that number?

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

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Tue, 9 Jan 2007 16:16:26 -0500
Subject: [PEPPERMINT] FW: I-D ACTION:draft-schwartz-peppermint-e164-provisioning-data-set-00.txt
Reply-To: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0115_01C73409.870C51B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2007 3:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-schwartz-peppermint-e164-provisioning-data-set-
> 00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: E.164 Number Provisioning - Data Set Requirements
> 	Author(s)	: D. Schwartz, E. Katz
> 	Filename	:
draft-schwartz-peppermint-e164-provisioning-data-set-
> 00.txt
> 	Pages		:
> 	Date		: 2007-1-9
> 
>    This document outlines which information should be captured when
>    E.164 numbers are provisioned within a central registry.  This
>    document is not a specification but rather a set of information
>    which, when associated with an addressable entity can assist in
>    applying policy to subsequent queries.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-schwartz-peppermint-e164-
> provisioning-data-set-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-e164-provisioning-data-set-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-e164-provisioning-
> data-set-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_0115_01C73409.870C51B0
Content-Type: Message/External-body;
	name="draft-schwartz-peppermint-e164-provisioning-data-set-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-schwartz-peppermint-e164-provisioning-data-set-00.txt"

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

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

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

------=_NextPart_000_0115_01C73409.870C51B0--

Content-class: urn:content-classes:message
Date: Tue, 9 Jan 2007 17:09:41 +0200
From: "David Schwartz" <[email-masked]>
To: "Otmar Lendl" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [PEPPERMINT] RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

Hi Otmar.

In general, the assumption I made in the draft was that ranges cover a
factor of 10 numbers, i.e. if the pattern is 12345 and the length is 6
than the numbers provisioned are 123450, 123451, ... 123459. The problem
you raise regarding the numbering plans in Germany is not new to me and
brings up the question that often arises in database architecture,
namely that of width (or length) of a record Vs the depth or table size.
Specifically, how complicated do we want to make each provisioning
record at the expense of not writing another record. 

I contend and I may be wrong that while it is possible to add minLength,
maxLength, numberOfValuesInRange, etc, to cover ALL possible scenarios,
this obfuscates and complicates the processing of each record to the
point where it is more prone to errors. 

If on the other hand we simplify the record at the expense of adding
more records, while the upload time is perhaps increased (negligible)
the complexity is reduced and the errors that creep in to the system are
reduced as well.

While at one extreme is the prospect of provisioning each number
individually and not using ranges, it is possible using the mechanism I
proposed to combine individual numbers with ranges and take advantage of
"DeactivationDate" field that allows me to port individual values as
well as sub-ranges out of larger 10X ranges and arrive at the resolution
we desire.

If we take Germany as an example, suppose the number range I want to
provision is the 257 numbers starting with +4936628411 and going to
+493662841257. The way I would accomplish this with the mechanism
proposed in the draft using the "pattern|range|length" tuple is as
follows.

Activate...
493662841,true,12 // equivalent to adding 493662841XXX

Deactivate...
4936628413,true,12 // equivalent to removing 4936628413XX
4936628414,true,12 // equivalent to removing 4936628414XX
4936628415,true,12 // equivalent to removing 4936628415XX
4936628416,true,12 // equivalent to removing 4936628416XX
4936628417,true,12 // equivalent to removing 4936628417XX
4936628418,true,12 // equivalent to removing 4936628418XX
4936628419,true,12 // equivalent to removing 4936628419XX
4936628410,true,12 // equivalent to removing 4936628410XX

49366284126,true,12 // equivalent to removing 49366284126X
49366284127,true,12 // equivalent to removing 49366284127X
49366284128,true,12 // equivalent to removing 49366284128X
49366284129,true,12 // equivalent to removing 49366284129X

493662841258,false,12 // equivalent to removing 493662841258
493662841259,false,12 // equivalent to removing 493662841259

While I may have left out a record or two you get the point. 15 records
and you have clearly defined the range. While I could come up with a
scheme to do this in one record I felt that in light of the amount of
provisioning errors that we have seen in the field (with an even simpler
data set) I prefer to make porting in and out of ranges explicit and
thus reduce the chance of error.

Cheers,

D.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, January 09, 2007 1:23 PM
To: David Schwartz
Cc: Andrew Newton; Richard Shockey; [email-masked];
[email-masked]
Subject: Re: [Speermint]
draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

On 2007/01/08 23:01, David Schwartz <[email-masked]> wrote:
> 
> I just submitted a 00 draft on provisioning data sets.

Thanks for the input, here is the first question:

> 
>    o  Static Information
> 
>       The data in this category relates to the identification,
ownership
>       and general validity of the number.
> 
>       1.  Value
> 
>           The value is the resource that is being sought.  This value
>           may be a fully qualified E.164 number (e.g. 12127775555), or
>           alternatively, the value may be a number representing a
range
>           of numbers (e.g. 1212777).  In this latter case the "length"
>           field defined below is needed to establish the limits of the
>           number range.
> 
>       2.  Range
> 
>           This and the next field are used to assist in resolving
ranges
>           into individual and unique valid E.164 numbers.  The Range
>           field is a Boolean value, which indicates whether the
resource
>           specified in the "Value" field is a range that needs to be
>           expanded out to the "length" number of digits, or
>           alternatively, an individual number that does not require
>           further manipulation.
> 
>       3.  Length
> 
>           This field is used for expanding ranges to individual unique
>           numbers.

I can see how this works for blocks of numbers in countries with 
closed numbering plans. How this is supposed to work in Germany or
Austria, I don't know.

The problem is that "expanding ranges to individual unique numbers" is
a fool's errand in the context of open numbering plans. There are no
"ranges" assigned to corporate PBXs, they get prefixes (=pilot numbers,
"Kopfnummern") to which the PBX admin appends extensions according to
their own taste.

e.g.: the enum.at office in Vienna has +4315056416 (= 10 digits). We're
completely free to use the remaining 5 digits of the E.164 standard
as we wish. We don't even need to use a fixed length, we could use
-0, -1X, -2XX, -3XXX, -4XXXX, or any other scheme.

Thus: 

 * "Length" needs to be a range.

 * Expanding such a "block" into individual numbers turns a simple
   ISDN BRI customer into more than 100,000 DB entries.

--

In a more generic sense, you want to handle prefix-based in any case,
e.g. how else are you going to communicate that you offer termination
to London numbers, other than by saying route to +4420XXXXXXXX ? 
In that case, too, you don't want to translate that single route into
10^8 = 100 million individual routes.

Summary: Do we want to provision individual numbers, or are we aiming at
generalized prefix-based routes (with numbers as special cases)?

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

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

From: "T. Martin" <[email-masked]>
To: "'David Schwartz'" <[email-masked]>, "'Andrew Newton'" <[email-masked]>, "'Richard Shockey'" <[email-masked]>
Date: Tue, 9 Jan 2007 06:28:01 -0800
Importance: Normal
Z-USANET-MsgId: XID932LaiodE0143X38
Cc: [email-masked], [email-masked]
Subject: [PEPPERMINT] RE: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

Dave

I would suggest you qualify the definition of an E.164 number as defined by
ITU E.123.  And indicate what will be included in the field number

Were to get the correct notation information:
http://www.itu.int/rec/T-REC-E.123-200102-I/E

The definition should include:

Each assigned number contains a country code (CC), a national destination
code (NDC), and a subscriber number (SN). There can be up to 15 digits in an
E.164 number. The E.164 plan was originally developed by the International
Telecommunication Union (ITU).

I have another question: 

Where do you get the time and date information?

Terry Martin 
GVNW Consulting Inc
Senior Consultant
phone:503.612.4400
fax 503.612.4401
cell 503.318.8909

-----Original Message-----
From: David Schwartz [mailto:[email-masked]] 
Sent: Monday, January 08, 2007 2:27 PM
To: Andrew Newton; Richard Shockey
Cc: [email-masked]; [email-masked]
Subject: [Speermint]
draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

Hi

I just submitted a 00 draft on provisioning data sets.

Until it shows up on the ID tracker you can use this version.

Cheers,

David 

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

Date: Tue, 9 Jan 2007 12:22:37 +0100
From: Otmar Lendl <[email-masked]>
To: David Schwartz <[email-masked]>
Mail-Followup-To: Otmar Lendl <[email-masked]>, David Schwartz <[email-masked]>, Andrew Newton <[email-masked]>, Richard Shockey <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: [PEPPERMINT] Re: [Speermint] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

On 2007/01/08 23:01, David Schwartz <[email-masked]> wrote:
> 
> I just submitted a 00 draft on provisioning data sets.

Thanks for the input, here is the first question:

> 
>    o  Static Information
> 
>       The data in this category relates to the identification, ownership
>       and general validity of the number.
> 
>       1.  Value
> 
>           The value is the resource that is being sought.  This value
>           may be a fully qualified E.164 number (e.g. 12127775555), or
>           alternatively, the value may be a number representing a range
>           of numbers (e.g. 1212777).  In this latter case the "length"
>           field defined below is needed to establish the limits of the
>           number range.
> 
>       2.  Range
> 
>           This and the next field are used to assist in resolving ranges
>           into individual and unique valid E.164 numbers.  The Range
>           field is a Boolean value, which indicates whether the resource
>           specified in the "Value" field is a range that needs to be
>           expanded out to the "length" number of digits, or
>           alternatively, an individual number that does not require
>           further manipulation.
> 
>       3.  Length
> 
>           This field is used for expanding ranges to individual unique
>           numbers.

I can see how this works for blocks of numbers in countries with 
closed numbering plans. How this is supposed to work in Germany or
Austria, I don't know.

The problem is that "expanding ranges to individual unique numbers" is
a fool's errand in the context of open numbering plans. There are no
"ranges" assigned to corporate PBXs, they get prefixes (=pilot numbers,
"Kopfnummern") to which the PBX admin appends extensions according to
their own taste.

e.g.: the enum.at office in Vienna has +4315056416 (= 10 digits). We're
completely free to use the remaining 5 digits of the E.164 standard
as we wish. We don't even need to use a fixed length, we could use
-0, -1X, -2XX, -3XXX, -4XXXX, or any other scheme.

Thus: 

 * "Length" needs to be a range.

 * Expanding such a "block" into individual numbers turns a simple
   ISDN BRI customer into more than 100,000 DB entries.

--

In a more generic sense, you want to handle prefix-based in any case,
e.g. how else are you going to communicate that you offer termination
to London numbers, other than by saying route to +4420XXXXXXXX ? 
In that case, too, you don't want to translate that single route into
10^8 = 100 million individual routes.

Summary: Do we want to provision individual numbers, or are we aiming at
generalized prefix-based routes (with numbers as special cases)?

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

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

Content-class: urn:content-classes:message
Date: Tue, 9 Jan 2007 00:27:25 +0200
To: "Andrew Newton" <[email-masked]>, "Richard Shockey" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [PEPPERMINT] draft-schwartz-peppermint-e164-provisioning-data-set-00.txt

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73374.318D16EB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi

I just submitted a 00 draft on provisioning data sets.

Until it shows up on the ID tracker you can use this version.

Cheers,

David 

------_=_NextPart_001_01C73374.318D16EB
Content-Type: text/plain;
	name="Peppermint provisioning Version 00.txt"
Content-Transfer-Encoding: base64
Content-Description: Peppermint provisioning Version 00.txt
Content-Disposition: attachment;
	filename="Peppermint provisioning Version 00.txt"

------_=_NextPart_001_01C73374.318D16EB
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------_=_NextPart_001_01C73374.318D16EB--

From: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] First pass at a BoF proposal
Date: Mon, 8 Jan 2007 07:26:52 -0500
To: Otmar Lendl <[email-masked]>
Cc: [email-masked]

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=======17031720=
Content-Type: multipart/alternative;
	boundary="=_zeke.ecotroph.net-11300-1168259191-0001-2"

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zeke.ecotroph.net-11300-1168259191-0001-2
Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed
Content-Transfer-Encoding: 7bit

On Jan 8, 2007, at 4:55 AM, Otmar Lendl wrote:

> Do I read this correctly that you want to include?
>
> * Carriers provisioning numbers into a peering fabric's DB (the  
> "registry")

Yes.

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

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

> Do you also envision direct carrier<->carrier interactions without
> a third party acting as the registry?
>
> Or do you think that this will just be a special case?

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

-andy

--=_zeke.ecotroph.net-11300-1168259191-0001-2
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier
	0.53.3

<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Jan 8, 2007, at 4:55 AM, Otmar Lendl wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Do I read this correctly that you want to include?</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">* Carriers provisioning numbers into a peering fabric's DB (the "registry")<SPAN class="Apple-converted-space"> </SPAN></FONT></P> </BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Yes.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">* Redistribution of that DB into each carrier's real-time routing DB</FONT></P> </BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This work could be used for this, but the primary motivation is different from my understanding.  Peering fabrics tend to offer their members local cache's of the DB.  Today, the syncing of that cache requires custom protocols and software.</DIV><BR><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Do you also envision direct carrier&lt;-&gt;carrier interactions without</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">a third party acting as the registry?<SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Or do you think that this will just be a special case?</FONT></P> </BLOCKQUOTE></DIV><DIV><BR class="khtml-block-placeholder"></DIV>I do, as this happens today.  And I'm not sure it is much different than the other interactions.  In SPEERMINT terms, this is direct peering.<DIV><BR class="khtml-block-placeholder"></DIV><DIV>-andy<BR><DIV><BR class="khtml-block-placeholder"></DIV></DIV></BODY></HTML>
--=_zeke.ecotroph.net-11300-1168259191-0001-2--

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

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

--=======17031720=--

Date: Mon, 8 Jan 2007 12:17:25 +0100
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Subject: Re: [PEPPERMINT] While we wait on the drafts
Mail-Followup-To: Otmar Lendl <[email-masked]>, [email-masked]

On 2007/01/05 18:01, Andrew Newton <[email-masked]> wrote:
> 
> As I stated in the SPEERMINT meeting in San Diego, there seems to be  
> near zero deployment of RFC 4114.  And almost every single time I've  
> asked about it, the response has been "What is RFC 4114?"  In the  
> interest of understanding why RFC 4114 might not meet the  
> requirements for SIP peering provisioning, how many people have  
> implemented and/or deployed RFC 4114?

The Austrian I-ENUM trial as run by enum.at uses EPP + RFC4114 as
the provisioning interface.

Personally, my love for RFC4114 is limited. 

EPP is fine for incremental changes, and I think we found a decent
way to use EPP in the +43 user-ENUM provisioning.

I see three flaws with 4114:

* The key is the domain, not the number.

  IMHO the provisioning protocol should reflect the fact that
  we're dealing primarily with E.164 numbers. Yes, maybe
  the end-result of that provisioning is an ENUM-style domain,
  but that could just as well be a SIP redirect server or
  some other mechanism.

* Reliance on the NAPTR format.

  As above: If all you are ever going to produce is an ENUM zone,
  then yes: that may be ok and gives you full control over the
  resulting NAPTR record. Once again, if you consider other
  query protols other than DNS/ENUM, then 4114 is too specific.

* No simple way to specify number-ranges or prefixes.

  You can work-around using wildcard domain-names for prefixes,
  but things like +1 555 123 4444 -- +1 555 123 4532 can only
  be done by enumerating all numbers in that range.

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

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

Date: Mon, 8 Jan 2007 10:55:58 +0100
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Subject: Re: [PEPPERMINT] First pass at a BoF proposal
Mail-Followup-To: Otmar Lendl <[email-masked]>, [email-masked]

A question regarding the charter:

On 2007/01/05 18:01, Andrew Newton <[email-masked]> wrote:
> 
> It is clear from discussions in both working groups that Multi-Media
> Interconnection will require various forms of data to be exchanged among
> administrative domains outside the normal scope of establishing a SIP
> session.
> 
> Such data exchanges might be provisioning of various forms of Registries
> containing mappings of phone numbers to URI, policies surrounding the
> admission to points of network interconnection and the distribution of
> Registry data to various types of databases.

Do I read this correctly that you want to include?

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

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

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

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

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

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

From: "Richard Shockey" <[email-masked]>
To: "'Andrew Newton'" <[email-masked]>, "'Adam Uzelac'" <[email-masked]>
Subject: RE: [PEPPERMINT] While we wait on the drafts
Date: Fri, 5 Jan 2007 14:00:39 -0500
Cc: [email-masked], 'David Schwartz' <[email-masked]>
Reply-To: [email-masked]

> It is possible that both features could be achieved with the same
> mechanism.
> 
> >> What about a model that follows a "per query" methodology?  There
> >> would
> >> be some minor upfront provisioning that would ensure that a
> >> preexisting
> >> contractual or trust relationship exists, but then query the
> >> catalog of
> >> your peers for reachability of the intended target.  I realize
> >> there are
> >> scaling issues involved, but it's realistic that this model would
> >> exist,
> >> no?
> >
> > Of course .. some folks will not want to cache the catalog/registry
> > and
> > others will simply want a per dip model. The issue will be then
> > what are the
> > appropriate per dip query mechanisms and do we want to limit the
> > scope of
> > acceptable models limit discussion to just RFC 3761 (DNS) and SIP
> > Redirect?
> 
> I'd prefer we leave the actual mechanism for the query out of scope.

Its certainly a topic for discussion but in principal I agree with you.

> 
> -andy

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

From: Andrew Newton <[email-masked]>
Subject: Re: [PEPPERMINT] While we wait on the drafts
Date: Fri, 5 Jan 2007 13:17:45 -0500
To: Richard Shockey <[email-masked]>, Adam Uzelac <[email-masked]>
Cc: [email-masked], David Schwartz <[email-masked]>

In-line...

On Jan 5, 2007, at 12:42 PM, Richard Shockey wrote:

>
> NeuStar has not implemented 4114 for that matter though we have  
> implemented
> EPP in our normal domain name registry operations.
>
>
>> -----Original Message-----
>> From: Uzelac, Adam [mailto:[email-masked]]
>>
>> Andy - If you are asking for a show of hands as to who has or hasn't
>> implemented/deployed 4114 - you can put Global Crossing as a company
>> that has NOT.

I was.  Thanks for understanding the obtuseness of the request.  For  
the record, SunRocket has not implemented 4114 (we'd be doing client- 
side), but have given it consideration and would have implemented it  
if any of our partners had.

>> As for the provisioning models that you put forth, is
>> there not room for a hybrid environment?  I think there has to be a
>> combination of the 2 models to achieve a practical implementation.
>> There must be an "entire catalog" download/upload to start before any
>> delta model can be realized.  But to do a full download of the  
>> catalog
>> at a regular interval would be unruly.

Yes, there is room for a hybrid model.  But in Model 1, there is no  
exact need for a model 2 style start up.  Startup is simply a truck- 
load of additions.  However, I think it reasonable that normal  
operations would be model 1 and startup and checkpoints/resyncs would  
be model 2.

> We would assume a incremental update of changes to the entire  
> cached catalog
> " aka registry" would be a MUST.

So why doesn't 4114 meet your needs?

As far as MUST/SHOULD language goes, I'd like to see both models (and  
their hybrid) be a MUST implement.  Must deploy is a different matter.

And while I'm reciting my wish list, I'd like to see a couple of  
protocol features:

Model 1 Transactions) It would be nice to group the deltas into  
discrete transactions, similar to SQL transactions.  If one fails,  
they all fail.

Model 2 Chunking) With a reasonably sized catalog, the number of  
octets in the catalog (especially if it uses XML) can get quite  
cumbersome.  Typical octet counting mechanisms (such as EPP or plain  
HTTP POST) would then require an enormous buffer.  It would be better  
if the catalog could be sent in chunks or different, sequential  
messages.

It is possible that both features could be achieved with the same  
mechanism.

>> What about a model that follows a "per query" methodology?  There  
>> would
>> be some minor upfront provisioning that would ensure that a  
>> preexisting
>> contractual or trust relationship exists, but then query the  
>> catalog of
>> your peers for reachability of the intended target.  I realize  
>> there are
>> scaling issues involved, but it's realistic that this model would  
>> exist,
>> no?
>
> Of course .. some folks will not want to cache the catalog/registry  
> and
> others will simply want a per dip model. The issue will be then  
> what are the
> appropriate per dip query mechanisms and do we want to limit the  
> scope of
> acceptable models limit discussion to just RFC 3761 (DNS) and SIP  
> Redirect?

I'd prefer we leave the actual mechanism for the query out of scope.

-andy

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

From: "Richard Shockey" <[email-masked]>
To: "'Uzelac, Adam'" <[email-masked]>, "'Andrew Newton'" <[email-masked]>, <[email-masked]>
Subject: RE: [PEPPERMINT] While we wait on the drafts
Date: Fri, 5 Jan 2007 12:42:01 -0500
Cc: 'David Schwartz' <[email-masked]>
Reply-To: [email-masked]

NeuStar has not implemented 4114 for that matter though we have implemented
EPP in our normal domain name registry operations.

> -----Original Message-----
> From: Uzelac, Adam [mailto:[email-masked]]
> Sent: Friday, January 05, 2007 12:22 PM
> To: Andrew Newton; [email-masked]
> Cc: David Schwartz
> Subject: RE: [PEPPERMINT] While we wait on the drafts
> 
> Andy - If you are asking for a show of hands as to who has or hasn't
> implemented/deployed 4114 - you can put Global Crossing as a company
> that has NOT.  As for the provisioning models that you put forth, is
> there not room for a hybrid environment?  I think there has to be a
> combination of the 2 models to achieve a practical implementation.
> There must be an "entire catalog" download/upload to start before any
> delta model can be realized.  But to do a full download of the catalog
> at a regular interval would be unruly.

We would assume a incremental update of changes to the entire cached catalog
" aka registry" would be a MUST.

> 
> What about a model that follows a "per query" methodology?  There would
> be some minor upfront provisioning that would ensure that a preexisting
> contractual or trust relationship exists, but then query the catalog of
> your peers for reachability of the intended target.  I realize there are
> scaling issues involved, but it's realistic that this model would exist,
> no?

Of course .. some folks will not want to cache the catalog/registry and
others will simply want a per dip model. The issue will be then what are the
appropriate per dip query mechanisms and do we want to limit the scope of
acceptable models limit discussion to just RFC 3761 (DNS) and SIP Redirect? 

> 
> -AU
> 
> > -----Original Message-----
> > From: Andrew Newton [mailto:[email-masked]]
> > Sent: Friday, January 05, 2007 12:04 PM
> > To: [email-masked]
> > Cc: David Schwartz
> > Subject: [PEPPERMINT] While we wait on the drafts
> >
> > David Schwartz is producing an I-D with his take on
> > requirements for a SIP peering provisioning protocol.  And
> > I've been told privately of one other in the works.  But to
> > get the discussions started, I'd like to share my
> > observations in this space.
> >
> > As I stated in the SPEERMINT meeting in San Diego, there
> > seems to be near zero deployment of RFC 4114.  And almost
> > every single time I've asked about it, the response has been
> > "What is RFC 4114?"  In the interest of understanding why RFC
> > 4114 might not meet the requirements for SIP peering
> > provisioning, how many people have implemented and/or
> > deployed RFC 4114?
> >
> >  From what I've seen with the proprietary solutions, there
> > appear to be two different models used in the industry:
> >
> > Model 1) This is very similar to how RFC 4114 and EPP work,
> > though the mechanisms differ (usually they are flat files
> > sent using FTP).
> > The exchange is all about deltas, any additions or deletions
> > since the last transaction.
> >
> > Model 2) This is the "entire catalog" approach.  In each
> > transaction, every "address" (e.g. telephone # or SIP URI) is given.
> >
> >  From a client perspective (or a provisioner's perspective...
> > we need a term for that), model 2 is easier even though it
> > obviously consumes more bandwidth.  However, from the server
> > perspective (or the provisionee's perspective... again, we
> > need a term), I would think this is cumbersome, as the
> > tracking of the changes occurs on that side of the
> > transaction.  When you extract the business considerations,
> > tracking the changes may not be important... but we have to
> > work within the confines of the real world here where
> > charging, customer service, etc. do exist.
> >
> > The opposite is true for Model 1.  More processing and
> > attention must be paid by the client.
> >
> > And though Model 1 is similar in operation to EPP, EPP's
> > genesis in the domain name space doesn't exactly make it a
> > perfect fit for VSPs with multiple peers.  In the
> > registrar/registry domain name world of EPP, a registrar will
> > only have one registry with which to provision any one
> > instance of a domain name.  In other words, a registry only
> > ever deals with one registry when it must do something with
> > "example.org".
> >
> > But for VSPs peered with multiple partners, this breaks down.
> >  Each "address" (again, a phone # or SIP URI or whatever)
> > could be provisioned with each partner.  This means deltas
> > for each relationship must be tracked.
> >
> > Comments and opinions welcome....
> >
> > -andy
> >
> > _______________________________________________
> > PEPPERMINT mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/peppermint
> >
> 
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/peppermint

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

To: [email-masked]
From: Andrew Newton <[email-masked]>
Date: Fri, 5 Jan 2007 12:39:16 -0500
Subject: [PEPPERMINT] First pass at a BoF proposal

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

Peppermint BOF

Provisioning Extensions in Peering Registries for Multimedia
INTerconnection.

Mailing Lists:

BOF chairs:

Andrew Newton [[email-masked]]

Richard Shockey [[email-masked]]

Temporary Area Directorate: Real Time Applications (RAI)

Ultimate Area Directorate: TBD

BOF Purpose.

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

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

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

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

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

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

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

Proposed Deliverables

Requirements for SPEERMINT data exchange.

Provisioning of SPEERMINT data registries.

Provisioning of SPEERMINT/ENUM data caches.

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

Content-class: urn:content-classes:message
Subject: RE: [PEPPERMINT] While we wait on the drafts
Date: Fri, 5 Jan 2007 12:22:27 -0500
From: "Uzelac, Adam" <[email-masked]>
To: "Andrew Newton" <[email-masked]>, <[email-masked]>
Cc: David Schwartz <[email-masked]>

Andy - If you are asking for a show of hands as to who has or hasn't
implemented/deployed 4114 - you can put Global Crossing as a company
that has NOT.  As for the provisioning models that you put forth, is
there not room for a hybrid environment?  I think there has to be a
combination of the 2 models to achieve a practical implementation.
There must be an "entire catalog" download/upload to start before any
delta model can be realized.  But to do a full download of the catalog
at a regular interval would be unruly.  

What about a model that follows a "per query" methodology?  There would
be some minor upfront provisioning that would ensure that a preexisting
contractual or trust relationship exists, but then query the catalog of
your peers for reachability of the intended target.  I realize there are
scaling issues involved, but it's realistic that this model would exist,
no?

-AU

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Friday, January 05, 2007 12:04 PM
> To: [email-masked]
> Cc: David Schwartz
> Subject: [PEPPERMINT] While we wait on the drafts
> 
> David Schwartz is producing an I-D with his take on 
> requirements for a SIP peering provisioning protocol.  And 
> I've been told privately of one other in the works.  But to 
> get the discussions started, I'd like to share my 
> observations in this space.
> 
> As I stated in the SPEERMINT meeting in San Diego, there 
> seems to be near zero deployment of RFC 4114.  And almost 
> every single time I've asked about it, the response has been 
> "What is RFC 4114?"  In the interest of understanding why RFC 
> 4114 might not meet the requirements for SIP peering 
> provisioning, how many people have implemented and/or 
> deployed RFC 4114?
> 
>  From what I've seen with the proprietary solutions, there 
> appear to be two different models used in the industry:
> 
> Model 1) This is very similar to how RFC 4114 and EPP work, 
> though the mechanisms differ (usually they are flat files 
> sent using FTP).  
> The exchange is all about deltas, any additions or deletions 
> since the last transaction.
> 
> Model 2) This is the "entire catalog" approach.  In each 
> transaction, every "address" (e.g. telephone # or SIP URI) is given.
> 
>  From a client perspective (or a provisioner's perspective... 
> we need a term for that), model 2 is easier even though it 
> obviously consumes more bandwidth.  However, from the server 
> perspective (or the provisionee's perspective... again, we 
> need a term), I would think this is cumbersome, as the 
> tracking of the changes occurs on that side of the 
> transaction.  When you extract the business considerations, 
> tracking the changes may not be important... but we have to 
> work within the confines of the real world here where 
> charging, customer service, etc. do exist.
> 
> The opposite is true for Model 1.  More processing and 
> attention must be paid by the client.
> 
> And though Model 1 is similar in operation to EPP, EPP's 
> genesis in the domain name space doesn't exactly make it a 
> perfect fit for VSPs with multiple peers.  In the 
> registrar/registry domain name world of EPP, a registrar will 
> only have one registry with which to provision any one 
> instance of a domain name.  In other words, a registry only 
> ever deals with one registry when it must do something with 
> "example.org".
> 
> But for VSPs peered with multiple partners, this breaks down. 
>  Each "address" (again, a phone # or SIP URI or whatever) 
> could be provisioned with each partner.  This means deltas 
> for each relationship must be tracked.
> 
> Comments and opinions welcome....
> 
> -andy
> 
> _______________________________________________
> PEPPERMINT mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/peppermint
> 

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

From: Andrew Newton <[email-masked]>
Date: Fri, 5 Jan 2007 12:03:47 -0500
To: [email-masked]
Cc: David Schwartz <[email-masked]>
Subject: [PEPPERMINT] While we wait on the drafts

David Schwartz is producing an I-D with his take on requirements for  
a SIP peering provisioning protocol.  And I've been told privately of  
one other in the works.  But to get the discussions started, I'd like  
to share my observations in this space.

As I stated in the SPEERMINT meeting in San Diego, there seems to be  
near zero deployment of RFC 4114.  And almost every single time I've  
asked about it, the response has been "What is RFC 4114?"  In the  
interest of understanding why RFC 4114 might not meet the  
requirements for SIP peering provisioning, how many people have  
implemented and/or deployed RFC 4114?

 From what I've seen with the proprietary solutions, there appear to  
be two different models used in the industry:

Model 1) This is very similar to how RFC 4114 and EPP work, though  
the mechanisms differ (usually they are flat files sent using FTP).  
The exchange is all about deltas, any additions or deletions since  
the last transaction.

Model 2) This is the "entire catalog" approach.  In each transaction,  
every "address" (e.g. telephone # or SIP URI) is given.

 From a client perspective (or a provisioner's perspective... we need  
a term for that), model 2 is easier even though it obviously consumes  
more bandwidth.  However, from the server perspective (or the  
provisionee's perspective... again, we need a term), I would think  
this is cumbersome, as the tracking of the changes occurs on that  
side of the transaction.  When you extract the business  
considerations, tracking the changes may not be important... but we  
have to work within the confines of the real world here where  
charging, customer service, etc. do exist.

The opposite is true for Model 1.  More processing and attention must  
be paid by the client.

And though Model 1 is similar in operation to EPP, EPP's genesis in  
the domain name space doesn't exactly make it a perfect fit for VSPs  
with multiple peers.  In the registrar/registry domain name world of  
EPP, a registrar will only have one registry with which to provision  
any one instance of a domain name.  In other words, a registry only  
ever deals with one registry when it must do something with  
"example.org".

But for VSPs peered with multiple partners, this breaks down.  Each  
"address" (again, a phone # or SIP URI or whatever) could be  
provisioned with each partner.  This means deltas for each  
relationship must be tracked.

Comments and opinions welcome....

-andy

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

From: "Richard Shockey" <[email-masked]>
To: <[email-masked]>
Date: Wed, 3 Jan 2007 20:08:16 -0500
Subject: [PEPPERMINT] test
Reply-To: [email-masked]

test

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
sip:5651(at)neustarlab.biz
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]
https://www1.ietf.org/mailman/listinfo/peppermint