IETF 70 PEPPERMINT BOF Minutes Thursday December 6, 2007 Chair(s): Richard Shockey Tom Creighton RAI Director(s): Jon Peterson jon.peterson@neustar.biz Cullen Jennings fluffy@cisco.com 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 5 EPP RFCs *are* 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.