Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Bfm-0001ek-QM; Tue, 11 Dec 2007 15:25:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Bfl-0001Xx-O8 for PEPPERMINT@ietf.org; Tue, 11 Dec 2007 15:25:45 -0500 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Bfk-00013M-UY for PEPPERMINT@ietf.org; Tue, 11 Dec 2007 15:25:45 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id lBBKHx7Z017917; Tue, 11 Dec 2007 15:17:59 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 15:25:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF Date: Tue, 11 Dec 2007 15:25:43 -0500 Message-ID: <046F43A8D79C794FA4733814869CDF070217AB7A@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <029c01c83c33$ac3ce610$04b6b230$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF Thread-Index: Acg4ZZlAlpjhSsCDSN6H2B+HQQjSxADzVy4gAAA4rEA= From: "Hollenbeck, Scott" To: "Richard Shockey" , X-OriginalArrivalTime: 11 Dec 2007 20:25:44.0320 (UTC) FILETIME=[019EA800:01C83C34] X-Spam-Score: -2.8 (--) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: Alexander Mayrhofer X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org 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:richard@shockey.us]=20 > Sent: Tuesday, December 11, 2007 3:23 PM > To: PEPPERMINT@ietf.org > Cc: 'Alexander Mayrhofer' > Subject: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF >=20 >=20 > Alexander graciously took some notes and I've added some=20 > recollections .. if there are any additional comments or=20 > notes to be included let me know. >=20 > ############## >=20 >=20 > IETF 70 PEPPERMINT BOF Minutes >=20 > Thursday December 6, 2007 >=20 > Chair(s): >=20 > Richard Shockey Tom Creighton =20 > >=20 >=20 > RAI Director(s): >=20 > Jon Peterson jon.peterson@neustar.biz > Cullen Jennings fluffy@cisco.com >=20 > Chair estimates appx 200 in attendence >=20 > Shockey Chair: Reminder - this is BoF, not a WG >=20 > The purpose of the BOF is to discuss the problem, not define=20 > the solution. > The purpose of this hour to see whether there is a problem,=20 > and if yes, whether we want to address that in the IETF >=20 > How many people read the proposed charter? (about half of=20 > them in the room) >=20 > Reminder that some of the issues here were part of RFC 4114=20 > in the ENUM working group for provisioning. >=20 >=20 > PRESENTATIONS: >=20 > David Schwartz - Peering relationships >=20 >=20 > Filename : draft-schwartz-speermint-provisioning-problem-00.txt=20 >=20 > Bilateral interconnection models evolving into federation scenarios.=20 >=20 > 3 kinds of interfaces identified on the provisioning side.=20 > Currently everybody currently rolls his own. >=20 > 1) provisioning the registry > 2) provisioning "down" to local registry (like currently ftp) > 3) registry to registry >=20 > Why do we need PEPPERMINT? >=20 > Operators want to use more than one registry.=20 >=20 > Richard: that's not carrier only, right? This could be used=20 > for various network elements like PBX's? >=20 > David: No, any network element could do that. >=20 > Provisioning data like national LNPs, non-LNPs, etc. >=20 > Changed from "among admin domains" to "within admin domains"=20 > in richard's statement. >=20 > list of various currently used provisioning protocols. >=20 > Rohan Mahy : you forgot FAX! >=20 >=20 > Henry Sinnreich: single or many registries? > David: I don't see a single registry. There will be will be=20 > many. We have the sequential nightmare today of provisioning=20 > several registries >=20 > PRESENTATIONS: >=20 > Ed Lewis >=20 > Jon Peterson noted that Ed Lewis was the chair of the WG that=20 > developed EPP. >=20 > Draft=20 >=20 > Filename : draft-lewis-peppermint-enum-reg-if-01.txt >=20 >=20 > This document was created as a placeholder for a more formal=20 > requirements draft, built from IETF as well as NeuStar=20 > internal experience. >=20 > Note section about EPP: obvious alternative, decided against it. >=20 >=20 > PRESENTATIONS: >=20 > Scott Hollenbeck > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Provisioning protocol and tech overview >=20 > EPP documents progressing towards draft standards.=20 >=20 > EPP developed for the unique needs of the Domain Name Registries >=20 > IMHO 4114 not really usable for the PEPPERMINT problem=20 > statement (ENUM extensions for that as well) >=20 > It is fair to look at other options. There are couple of them=20 > in the IETF > context: >=20 > other things: CAPWAP (4565) > COPS / COPS-PR >=20 > Obviously not what we need >=20 > Provisioning technologies? >=20 > SOAP over HTTP > (eg SOAP over BEEP) >=20 > REST (over HTTP) >=20 > Jonathan Rosenberg : xcap is REST style >=20 > XML-RPC > (XML-RPC in BEEP) >=20 > religious debates will drag you down forever >=20 > Korean experiences with 4114 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Richard Shockey proxying for Joonhyung Lim=20 >=20 > .kr infrastructure ENUM trial (+82) using 4114 >=20 > outcome: carriers have their own system. >=20 > LawrenceConroy : please not that they did a lot of work on=20 > this, don't be unfair :) they provided a lot of toolkits for carriers. >=20 > Richard Shockey: were they looking into a new provisioning=20 > protocol for the second trial? >=20 >=20 > Lawrence Conroy : yes, this doesn't seem to fit how carriers think. >=20 > Alexander : carriers don't move a single inch. Mobile NP in=20 > Austria took 5 years to agree on a Fax style process >=20 > Ted hardie: jabber: andy agrees with alex >=20 > Richard Shockey : andy did an awful lot of work to make this=20 > BoF happen >=20 > David: world is changing, they are moving to IP. There are a=20 > lot of RFPs out there from carriers >=20 > Alexander: difference "between" and "among" is a scope question >=20 > Richard: please come to the microphone to say whether there=20 > is or not a problem >=20 > James: is this defining what data we use, or only on a=20 > mechanism we agree on? >=20 > Richard Shockey : 1) what is the bits that move on the wire=20 > 2) what data sets. this is a scope question. >=20 > Hadriel Kaplan: between/within very distinct problems.=20 > Personally, wants to be "within". >=20 > Richard Shockey: Do the two problems need to be addressed=20 > separately? both to be solved? >=20 > Hadriel Kaplan: question whether solving on the short term or=20 > not? And title to be changed, too >=20 > David: it's like SNMP - data model. there's a lot more we can do.=20 >=20 > Tim Dwight: We (Verizon) think there is a problem, yes.=20 >=20 > Cullen Jennings (individual): there's always a problem about=20 > everything. > Need to narrow scope. >=20 > Dan York: I think that this is important work >=20 > Tim: we'd like to join only a subset of registries, and still=20 > resolve all numbers.=20 >=20 > Tom Creighton: Would you like to speak just one prov. protocol there? >=20 > Tim Dwight: if it's a small set, we're ok with different protocols >=20 > ??: would love to have a standard registry interface >=20 > Jim: query too? >=20 > Richard: downstream provisioning too. there are 2 registries=20 > in the US for routing, for example, NPAC and LERG and those=20 > are merged into a single view. > Multiple registries are a given. >=20 > Jason Livingood : agree, there is no query problem. if=20 > u/i-ENUM would exist, there would be one place. there is not=20 > in real world. provisioning group within a carrier is the=20 > hardest to work with. >=20 > Jean-Francois Mule: you assume ENUM, which needs phone=20 > numbers for the query interface? What about a mechanism for=20 > non-E.164 data? 2) there are other relations within where=20 > data exchange needs to happen. 3) bilateral transacitons? >=20 > Richard Shockey: We certainly don't want to exclude bilateral=20 > data exchanges >=20 >=20 > Tim Dwight: trust & authenticity information? Policy possible=20 > with most registries today, too. realizes that policy might=20 > extend the scope, but might useful.. >=20 > Jon Peterson : Ive eard a couple of people talking they want=20 > it? does anybody understand it? >=20 > ( A number of heads start to nod in agreement )=20 >=20 > Jon Peterson: Who thinks this is a problem? Who thinks we=20 > should work on this? who is willing to personally contribute to this? >=20 > Richard Shockey: A show of hands .. who thinks this is a=20 > problem the IETF needs to address? (maybe 1/3 of the=20 > attendees raise their hand) >=20 > Richard Shockey: Who thinks that the IETF should NOT work on=20 > this problem? ( two hands go up) >=20 > Richard Shockey: How many people would be willing to=20 > personally contribute to this process? ( approximately 30 ?) >=20 > Kenneth: Its not a question of ditching or not ditching the=20 > provisioning system, but rather improving it... >=20 > Jon Peterson : Charter should be crisp and clear. >=20 >=20 >=20 >=20 > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www1.ietf.org/mailman/listinfo/peppermint >=20 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Bdi-0006nG-Kj; Tue, 11 Dec 2007 15:23:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Bdh-0006lp-Oz for PEPPERMINT@ietf.org; Tue, 11 Dec 2007 15:23:37 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Bdg-00010Q-Sj for PEPPERMINT@ietf.org; Tue, 11 Dec 2007 15:23:37 -0500 Received: from rshockeyPC (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lBBKN42Z008965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Dec 2007 12:23:08 -0800 From: "Richard Shockey" To: References: <8BC845943058D844ABFC73D2220D466506E71AB3@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D466506E71AB3@nics-mail.sbg.nic.at> Date: Tue, 11 Dec 2007 15:23:17 -0500 Message-ID: <029c01c83c33$ac3ce610$04b6b230$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4ZZlAlpjhSsCDSN6H2B+HQQjSxADzVy4g Content-Language: en-us X-Spam-Score: 0.2 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: 'Alexander Mayrhofer' Subject: [PEPPERMINT] PRELIMINARY meeting minutes from PEPPERMINT BOF X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org 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 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 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 PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Nvm-0003z5-GZ; Thu, 06 Dec 2007 16:06:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Nvl-0003rm-9o for PEPPERMINT@ietf.org; Thu, 06 Dec 2007 16:06:49 -0500 Received: from osprey.verisign.com ([216.168.239.75]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0Nvk-0007NH-OU for PEPPERMINT@ietf.org; Thu, 06 Dec 2007 16:06:49 -0500 Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id lB6KxUJZ017413 for ; Thu, 6 Dec 2007 15:59:30 -0500 Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 16:06:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PEPPERMINT] Few thoughts for tomorrow. Date: Thu, 6 Dec 2007 16:05:30 -0500 Message-ID: In-Reply-To: <0b3301c83832$b3512920$19f37b60$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Few thoughts for tomorrow. Thread-Index: Acg34xPMrrto9rnpSRmWPlUPPXP4NwAT4zEAAAY7uwA= From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 06 Dec 2007 21:06:48.0446 (UTC) FILETIME=[EA49B1E0:01C8384B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org My typo: This... b. Problem Statement that defines the overall problems that SPEERMINT must solve Should have read like this... b. Problem Statement that defines the overall problems that PAPPERMINT must solve -----Original Message----- From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Thursday, December 06, 2007 1:06 PM To: Cartwright, Kenneth; PEPPERMINT@ietf.org Subject: RE: [PEPPERMINT] Few thoughts for tomorrow. Thanks for your note. Its precisely this kind of support we need. > -----Original Message----- > From: Cartwright, Kenneth [mailto:kcartwright@verisign.com] > Sent: Thursday, December 06, 2007 3:36 AM > To: PEPPERMINT@ietf.org > Subject: [PEPPERMINT] Few thoughts for tomorrow. > =20 > Tom, Richard, et.al. > =20 > Not surprisingly, since this is in early stages, the four good docs > that > exist so far (two problem statements, Newton and Schwartz, the > requirements doc, Lewis, and the data set doc Schwartz) are good and > valuable but are also disjoint in their perspectives, terminology, and > the presumed underlying architecture. A suggestion to help rectify > this > is to follow the approach applied by the SPEERMINT group, which seemed > very effective to me. That would be the following: > =20 > 1) Create a block diagram like the one in SPEERMINT that illustrated > the > initial document set that will be produced (one doc per block), the > dependency flow from the first doc(s) on down. This creates a clear > picture for everyone on the documents that will be produced in what > order and for what reason. > 2) Imho the docs that we need are: > a. Architecture Document, that creates a clear picture and > responsibilities of the logical components within the provisioning > flow. > This probably should include the Registry(s), the Addressing Server > Master(s), and, optionally, the Addressing Server Slaves/Replicas. > This > document will also create a common terminology set for the logical > aspects of the architecture that can then be used in the problem > statement and the requirements doc(s). > b. Problem Statement that defines the overall problems that > SPEERMINT must solve relative to the logical components identified in > the Architecture Document, without delving into specific data items or > solution schemes. The Newton document was a good start at this, imho, > as it clearly laid out the high level problem statement to define an > API/protocol between the VSP and the Registry, and between the > Registry > and the addressing servers. The Schwatz document is also good, Id > does > however seem to mash the logical entity of the Registry and the ENUM > Addressing Server in together (assuming I interpreted the document > correctly). The Schwartz document moves past the higher level Problem > Statement and directly into Data Model items that, imho, are more > appropriate for a requirements document. But it is certainly a good > document as well. > c. Requirements Document that defines the data elements/objects > that > must provisionable (is that a word) via the interfaces identified in > the > Problem Statement, the operations that must be supported for this data > elements/objects, the performance and scalability requirements, > security > requirements, etc. But it is also important that this document not > attempt to specify the solution. I see in the current requirements > document that there is a lot of "solution" (e.g. use zone files, or > use > SOAP) in there but not enough requirements details. But it is a good > start. > d. Also, in one of these documents we need to make sure all the > terminology is defined and kept consistent, but we may not need a > separate doc for that. > 3) Lastly, in the BOF notification you asked if some can volunteer to > work on these documents. I'm volunteering to do so. I can be a > reviewer of all of these documents and also co-author them as > necessary. > =20 > Ken > =20 > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www1.ietf.org/mailman/listinfo/peppermint _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LDL-0004tj-0v; Thu, 06 Dec 2007 13:12:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LDK-0004te-Hy for PEPPERMINT@ietf.org; Thu, 06 Dec 2007 13:12:46 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0LDK-000483-2J for PEPPERMINT@ietf.org; Thu, 06 Dec 2007 13:12:46 -0500 Received: from rshockeyPC (dhcp-15f8.ietf70.org [130.129.21.248]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB6ICIGQ015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Dec 2007 10:12:18 -0800 From: "Richard Shockey" To: Date: Thu, 6 Dec 2007 13:12:39 -0500 Message-ID: <100b01c83833$96b2b1c0$c4181540$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg4M5ZRfEBs7m9hS4WmTz6zyrPrsg== Content-Language: en-us X-Spam-Score: -1.0 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [PEPPERMINT] PEPPERMINT MEETING MATERIALS for this afternoon X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org https://datatracker.ietf.org/meeting/70/materials.html Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0L79-0007qj-V2; Thu, 06 Dec 2007 13:06:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0L78-0007oi-FP for PEPPERMINT@ietf.org; Thu, 06 Dec 2007 13:06:22 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0L77-0001so-QZ for PEPPERMINT@ietf.org; Thu, 06 Dec 2007 13:06:22 -0500 Received: from rshockeyPC (dhcp-15f8.ietf70.org [130.129.21.248]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB6I5t2E013497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Dec 2007 10:05:56 -0800 From: "Richard Shockey" To: "'Cartwright, Kenneth'" , References: In-Reply-To: Subject: RE: [PEPPERMINT] Few thoughts for tomorrow. Date: Thu, 6 Dec 2007 13:06:17 -0500 Message-ID: <0b3301c83832$b3512920$19f37b60$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg34xPMrrto9rnpSRmWPlUPPXP4NwAT4zEA Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org Thanks for your note. Its precisely this kind of support we need. > -----Original Message----- > From: Cartwright, Kenneth [mailto:kcartwright@verisign.com] > Sent: Thursday, December 06, 2007 3:36 AM > To: PEPPERMINT@ietf.org > Subject: [PEPPERMINT] Few thoughts for tomorrow. > > Tom, Richard, et.al. > > Not surprisingly, since this is in early stages, the four good docs > that > exist so far (two problem statements, Newton and Schwartz, the > requirements doc, Lewis, and the data set doc Schwartz) are good and > valuable but are also disjoint in their perspectives, terminology, and > the presumed underlying architecture. A suggestion to help rectify > this > is to follow the approach applied by the SPEERMINT group, which seemed > very effective to me. That would be the following: > > 1) Create a block diagram like the one in SPEERMINT that illustrated > the > initial document set that will be produced (one doc per block), the > dependency flow from the first doc(s) on down. This creates a clear > picture for everyone on the documents that will be produced in what > order and for what reason. > 2) Imho the docs that we need are: > a. Architecture Document, that creates a clear picture and > responsibilities of the logical components within the provisioning > flow. > This probably should include the Registry(s), the Addressing Server > Master(s), and, optionally, the Addressing Server Slaves/Replicas. > This > document will also create a common terminology set for the logical > aspects of the architecture that can then be used in the problem > statement and the requirements doc(s). > b. Problem Statement that defines the overall problems that > SPEERMINT must solve relative to the logical components identified in > the Architecture Document, without delving into specific data items or > solution schemes. The Newton document was a good start at this, imho, > as it clearly laid out the high level problem statement to define an > API/protocol between the VSP and the Registry, and between the > Registry > and the addressing servers. The Schwatz document is also good, Id > does > however seem to mash the logical entity of the Registry and the ENUM > Addressing Server in together (assuming I interpreted the document > correctly). The Schwartz document moves past the higher level Problem > Statement and directly into Data Model items that, imho, are more > appropriate for a requirements document. But it is certainly a good > document as well. > c. Requirements Document that defines the data elements/objects > that > must provisionable (is that a word) via the interfaces identified in > the > Problem Statement, the operations that must be supported for this data > elements/objects, the performance and scalability requirements, > security > requirements, etc. But it is also important that this document not > attempt to specify the solution. I see in the current requirements > document that there is a lot of "solution" (e.g. use zone files, or > use > SOAP) in there but not enough requirements details. But it is a good > start. > d. Also, in one of these documents we need to make sure all the > terminology is defined and kept consistent, but we may not need a > separate doc for that. > 3) Lastly, in the BOF notification you asked if some can volunteer to > work on these documents. I'm volunteering to do so. I can be a > reviewer of all of these documents and also co-author them as > necessary. > > Ken > > _______________________________________________ > PEPPERMINT mailing list > PEPPERMINT@ietf.org > https://www1.ietf.org/mailman/listinfo/peppermint _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0CEx-0008Sl-4T; Thu, 06 Dec 2007 03:37:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0CEu-0008SH-Md for PEPPERMINT@ietf.org; Thu, 06 Dec 2007 03:37:49 -0500 Received: from peregrine.verisign.com ([216.168.239.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0CEr-00024J-Dy for PEPPERMINT@ietf.org; Thu, 06 Dec 2007 03:37:48 -0500 Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id lB68UASB008625 for ; Thu, 6 Dec 2007 03:30:10 -0500 Received: from DUL1WNEXMB05.vcorp.ad.vrsn.com ([10.170.12.240]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 03:36:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [PEPPERMINT] Few thoughts for tomorrow. Date: Thu, 6 Dec 2007 03:36:20 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PEPPERMINT] Few thoughts for tomorrow. Thread-Index: Acg34xPMrrto9rnpSRmWPlUPPXP4Nw== From: "Cartwright, Kenneth" To: X-OriginalArrivalTime: 06 Dec 2007 08:36:28.0805 (UTC) FILETIME=[187DA350:01C837E3] X-Spam-Score: -4.0 (----) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org Tom, Richard, et.al. Not surprisingly, since this is in early stages, the four good docs that exist so far (two problem statements, Newton and Schwartz, the requirements doc, Lewis, and the data set doc Schwartz) are good and valuable but are also disjoint in their perspectives, terminology, and the presumed underlying architecture. A suggestion to help rectify this is to follow the approach applied by the SPEERMINT group, which seemed very effective to me. That would be the following: 1) Create a block diagram like the one in SPEERMINT that illustrated the initial document set that will be produced (one doc per block), the dependency flow from the first doc(s) on down. This creates a clear picture for everyone on the documents that will be produced in what order and for what reason. 2) Imho the docs that we need are: a. Architecture Document, that creates a clear picture and responsibilities of the logical components within the provisioning flow. This probably should include the Registry(s), the Addressing Server Master(s), and, optionally, the Addressing Server Slaves/Replicas. This document will also create a common terminology set for the logical aspects of the architecture that can then be used in the problem statement and the requirements doc(s). b. Problem Statement that defines the overall problems that SPEERMINT must solve relative to the logical components identified in the Architecture Document, without delving into specific data items or solution schemes. The Newton document was a good start at this, imho, as it clearly laid out the high level problem statement to define an API/protocol between the VSP and the Registry, and between the Registry and the addressing servers. The Schwatz document is also good, Id does however seem to mash the logical entity of the Registry and the ENUM Addressing Server in together (assuming I interpreted the document correctly). The Schwartz document moves past the higher level Problem Statement and directly into Data Model items that, imho, are more appropriate for a requirements document. But it is certainly a good document as well. c. Requirements Document that defines the data elements/objects that must provisionable (is that a word) via the interfaces identified in the Problem Statement, the operations that must be supported for this data elements/objects, the performance and scalability requirements, security requirements, etc. But it is also important that this document not attempt to specify the solution. I see in the current requirements document that there is a lot of "solution" (e.g. use zone files, or use SOAP) in there but not enough requirements details. But it is a good start. d. Also, in one of these documents we need to make sure all the terminology is defined and kept consistent, but we may not need a separate doc for that. 3) Lastly, in the BOF notification you asked if some can volunteer to work on these documents. I'm volunteering to do so. I can be a reviewer of all of these documents and also co-author them as necessary. Ken _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01jp-00053S-AS; Wed, 05 Dec 2007 16:25:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J01jn-00051L-QV for peppermint@ietf.org; Wed, 05 Dec 2007 16:24:59 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J01jn-0000vo-EG for peppermint@ietf.org; Wed, 05 Dec 2007 16:24:59 -0500 Received: from rshockeyPC (dhcp-3172.ietf70.org [130.129.49.114]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB5LONWK019854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Dec 2007 13:24:28 -0800 From: "Richard Shockey" To: Date: Wed, 5 Dec 2007 16:24:46 -0500 Message-ID: <012301c83785$49806b30$dc814190$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acg3hPLqjOdcOLTrSuWP2EdSJs1Rsw== Content-Language: en-us X-Spam-Score: -1.0 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [PEPPERMINT] If you have slides for the BOF tommrrow please send them to me ASAP. X-BeenThere: peppermint@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: peppermint-bounces@ietf.org So I can get them posted on the IETF web site etc. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 _______________________________________________ PEPPERMINT mailing list PEPPERMINT@ietf.org https://www1.ietf.org/mailman/listinfo/peppermint