Subject: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF

From: "Richard Shockey" <[email-masked]>
Date: Tue, 11 Dec 2007 15:23:17 -0500

Alexander graciously took some notes and I've added some recollections .. if
there are any additional comments or notes to be included let me know.

##############

IETF 70 PEPPERMINT BOF Minutes

Thursday December 6, 2007

Chair(s):

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

RAI Director(s):

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

Chair estimates appx 200 in attendence

Shockey Chair: Reminder - this is BoF, not a WG

The purpose of the BOF is to discuss the problem, not define the solution.
The purpose of this hour to see whether there is a problem, and if yes,
whether we want to address that in the IETF

How many people read the proposed charter? (about half of them in the room)

Reminder that some of the issues here were part of RFC 4114 in the ENUM
working group for provisioning.

PRESENTATIONS:

David Schwartz - Peering relationships

Filename	: draft-schwartz-speermint-provisioning-problem-00.txt 

Bilateral interconnection models evolving into federation scenarios. 

3 kinds of interfaces identified on the provisioning side. Currently
everybody currently rolls his own.

1) provisioning the registry
2) provisioning "down" to local registry (like currently ftp)
3) registry to registry

Why do we need PEPPERMINT?

Operators want to use more than one registry. 

Richard: that's not carrier only, right? This could be used for various
network elements like PBX's?

David: No, any network element could do that.

Provisioning data like national LNPs, non-LNPs, etc.

Changed from "among admin domains" to "within admin domains" in richard's
statement.

list of various currently used provisioning protocols.

Rohan Mahy : you forgot FAX!

Henry Sinnreich: single or many registries?
David: I don't see a single registry. There will be will be many. We have
the sequential nightmare today of provisioning several registries

PRESENTATIONS:

Ed Lewis

Jon Peterson noted that Ed Lewis was the chair of the WG that developed EPP.

Draft 

Filename	: draft-lewis-peppermint-enum-reg-if-01.txt

This document was created as a placeholder for a more formal requirements
draft, built from IETF as well as NeuStar internal experience.

Note section about EPP: obvious alternative, decided against it.

PRESENTATIONS:

Scott Hollenbeck
================

Provisioning protocol and tech overview

EPP documents progressing towards draft standards. 

EPP developed for the unique needs of the Domain Name Registries

IMHO 4114 not really usable for the PEPPERMINT problem statement (ENUM
extensions for that as well)

It is fair to look at other options. There are couple of them in the IETF
context:

other things: CAPWAP (4565)
COPS / COPS-PR

Obviously not what we need

Provisioning technologies?

SOAP over HTTP
 (eg SOAP over BEEP)

REST (over HTTP)

 Jonathan Rosenberg : xcap is REST style

XML-RPC
 (XML-RPC in BEEP)

religious debates will drag you down forever

Korean experiences with 4114
============================

Richard Shockey proxying for Joonhyung Lim 

.kr infrastructure ENUM trial (+82) using 4114

outcome: carriers have their own system.

LawrenceConroy : please not that they did a lot of work on this, don't be
unfair :) they provided a lot of toolkits for carriers.

Richard Shockey: were they looking into a new provisioning protocol for the
second trial?

Lawrence Conroy : yes, this doesn't seem to fit how carriers think.

Alexander : carriers don't move a single inch. Mobile NP in Austria took 5
years to agree on a Fax style process

Ted hardie: jabber: andy agrees with alex

Richard Shockey : andy did an awful lot of work to make this BoF happen

David: world is changing, they are moving to IP. There are a lot of RFPs out
there from carriers

Alexander: difference "between" and "among" is a scope question

Richard: please come to the microphone to say whether there is or not a
problem

James: is this defining what data we use, or only on a mechanism we agree
on?

Richard Shockey : 1) what is the bits that move on the wire 2) what data
sets. this is a scope question.

Hadriel Kaplan: between/within very distinct problems. Personally, wants to
be "within".

Richard Shockey: Do the two problems need to be addressed separately? both
to be solved?

Hadriel Kaplan: question whether solving on the short term or not? And title
to be changed, too

David: it's like SNMP - data model. there's a lot more we can do. 

Tim Dwight: We (Verizon) think there is a problem, yes. 

Cullen Jennings (individual): there's always a problem about everything.
Need to narrow scope.

Dan York: I think that this is important work

Tim: we'd like to join only a subset of registries, and still resolve all
numbers. 

Tom Creighton: Would you like to speak just one prov. protocol there?

Tim Dwight: if it's a small set, we're ok with different protocols

??: would love to have a standard registry interface

Jim: query too?

Richard: downstream provisioning too. there are 2 registries in the US for
routing, for example, NPAC and LERG and those are merged into a single view.
Multiple registries are a given.

Jason Livingood : agree, there is no query problem. if u/i-ENUM would exist,
there would be one place. there is not in real world. provisioning group
within a carrier is the hardest to work with.

Jean-Francois Mule: you assume ENUM, which needs phone numbers for the query
interface? What about a mechanism for non-E.164 data? 2) there are other
relations within where data exchange needs
to happen. 3) bilateral transacitons?

Richard Shockey: We certainly don't want to exclude bilateral data exchanges

Tim Dwight: trust & authenticity information? Policy possible with most
registries today, too. realizes that policy might extend the scope, but
might useful..

Jon Peterson : Ive eard a couple of people talking they want it? does
anybody understand it?

( A number of heads start to nod in agreement ) 

Jon Peterson: Who thinks this is a problem? Who thinks we should work on
this? who is willing to personally contribute to this?

Richard Shockey: A show of hands .. who thinks this is a problem the IETF
needs to address? (maybe 1/3 of the attendees raise their hand)

Richard Shockey: Who thinks that the IETF should NOT work on this problem? (
two hands go up)

Richard Shockey: How many people would be willing to personally contribute
to this process?  ( approximately 30 ?)

Kenneth: Its not a question of ditching or not ditching the provisioning
system, but rather improving it...

Jon Peterson : Charter should be crisp and clear.

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 11 Dec 2007 15:25:43 -0500

One correction on the five EPP RFCs I described (excluding 4114):
they're not "progressing towards draft standards", they *are* draft
standards.

-Scott-

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Tuesday, December 11, 2007 3:23 PM
> To: [email-masked]
> Cc: 'Alexander Mayrhofer'
> Subject: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF
> 
> 
> Alexander graciously took some notes and I've added some 
> recollections .. if there are any additional comments or 
> notes to be included let me know.
> 
> ##############
> 
> 
> Richard Shockey <[email-masked]> Tom Creighton  
> <[email-masked]>
> 
> 
> RAI Director(s):
> 
> The purpose of this hour to see whether there is a problem, 
> and if yes, whether we want to address that in the IETF
> 
> Reminder that some of the issues here were part of RFC 4114 
> in the ENUM working group for provisioning.
> 
> 
> PRESENTATIONS:
> 
> 3 kinds of interfaces identified on the provisioning side. 
> Currently everybody currently rolls his own.
> 
> Richard: that's not carrier only, right? This could be used 
> for various network elements like PBX's?
> 
> Changed from "among admin domains" to "within admin domains" 
> in richard's statement.
> 
> David: I don't see a single registry. There will be will be 
> many. We have the sequential nightmare today of provisioning 
> several registries
> 
> PRESENTATIONS:
> 
> Ed Lewis
> 
> This document was created as a placeholder for a more formal 
> requirements draft, built from IETF as well as NeuStar 
> internal experience.
> 
> IMHO 4114 not really usable for the PEPPERMINT problem 
> statement (ENUM extensions for that as well)
> 
> LawrenceConroy : please not that they did a lot of work on 
> this, don't be unfair :) they provided a lot of toolkits for carriers.
> 
> Richard Shockey: were they looking into a new provisioning 
> protocol for the second trial?
> 
> 
> Alexander : carriers don't move a single inch. Mobile NP in 
> Austria took 5 years to agree on a Fax style process
> 
> David: world is changing, they are moving to IP. There are a 
> lot of RFPs out there from carriers
> 
> Richard: please come to the microphone to say whether there 
> is or not a problem
> 
> James: is this defining what data we use, or only on a 
> mechanism we agree on?
> 
> Richard Shockey : 1) what is the bits that move on the wire 
> 2) what data sets. this is a scope question.
> 
> Hadriel Kaplan: between/within very distinct problems. 
> Personally, wants to be "within".
> 
> Richard Shockey: Do the two problems need to be addressed 
> separately? both to be solved?
> 
> Hadriel Kaplan: question whether solving on the short term or 
> not? And title to be changed, too
> 
> Tim: we'd like to join only a subset of registries, and still 
> resolve all numbers. 
> 
> Richard: downstream provisioning too. there are 2 registries 
> in the US for routing, for example, NPAC and LERG and those 
> are merged into a single view.
> Jason Livingood : agree, there is no query problem. if 
> u/i-ENUM would exist, there would be one place. there is not 
> in real world. provisioning group within a carrier is the 
> hardest to work with.
> 
> Jean-Francois Mule: you assume ENUM, which needs phone 
> numbers for the query interface? What about a mechanism for 
> non-E.164 data? 2) there are other relations within where 
> data exchange needs to happen. 3) bilateral transacitons?
> 
> Tim Dwight: trust & authenticity information? Policy possible 
> with most registries today, too. realizes that policy might 
> extend the scope, but might useful..
> 
> Jon Peterson : Ive eard a couple of people talking they want 
> it? does anybody understand it?
> 
> Jon Peterson: Who thinks this is a problem? Who thinks we 
> should work on this? who is willing to personally contribute to this?
> 
> Richard Shockey: A show of hands .. who thinks this is a 
> problem the IETF needs to address? (maybe 1/3 of the 
> attendees raise their hand)
> 
> Richard Shockey: Who thinks that the IETF should NOT work on 
> this problem? ( two hands go up)
> 
> Richard Shockey: How many people would be willing to 
> personally contribute to this process?  ( approximately 30 ?)
> 
> Kenneth: Its not a question of ditching or not ditching the 
> provisioning system, but rather improving it...
>