From info at arin.net Fri Dec 19 11:43:37 2008 From: info at arin.net (Member Services) Date: Fri, 19 Dec 2008 11:43:37 -0500 Subject: [ARIN-consult] Call for Community Consultation - Automated Template Submission and Testing Message-ID: <494BCF39.4030106@arin.net> In response to Suggestion 2008.5: Testbed for Checking ARIN Template Syntax, ARIN would like additional community input regarding expectations for format/delivery and test/validation of automated templates. ARIN is creating a new provisioning system for its customers as part of the Secure Login initiative. In upcoming releases, many of the templates that are currently submitted via e-mail will be available for online submission. However, there are a few templates that are currently delivered to ARIN via e-mail in an automated fashion. These forms do not lend themselves easily to manual web-based template submission system. As ARIN is updating our provisioning systems, we would like community feedback on alternative methods and/or formats for delivery templates that are automated by our customers. There are several options under consideration: maintaining the current submission format for automated forms; providing a secure, authenticated conduit for these same forms; offering an XML format using a RESTFUL interface; or some other option, like using EPP. For example LACNIC is in the development stages of creating an EPP interface for their customers. ARIN would also like input on what the community wants in terms of testing and validation. Connection-oriented solutions such as RESTFUL HTTP and EPP are more readily integrated into test frameworks and validation suites than e-mail templates. ARIN would know your expectations for both format/delivery and test/validation for automated templates. Discussion on this list will close at 5:00 PM ET 30 January 2009. ARIN may decide to conduct a poll on the topic during the following week depending on the volume and diversity of the discussion. Participation in the poll will be limited to arin-consult mail list subscribers who are registered at the time the poll opens. The ARIN Consultation and Suggestion Process documentation is available at: http://www.arin.net/about_us/corp_docs/acsp.html. We welcome community-wide participation. Please address any process questions to info at arin.net. Regards, Member Services American Registry for Internet Numbers (ARIN) 2008.5 Submitted 4 February 2008 ARIN should deploy a testbed for checking the syntax in ARIN templates. This would allow users to test the template before submitting it. It would allow new users to practice in a non-production environement. It would allow organizations who automate template generation to test changes, before putting them into production. RIPE has a tool that could be used as an example: http://www.ripe.net/tools/ From michael.dillon at bt.com Fri Dec 19 13:47:45 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 19 Dec 2008 18:47:45 -0000 Subject: [ARIN-consult] Automated templates Message-ID: I believe that XML templates submitted through a RESTful API are the best overall solution. EPP may be useable in part but there could well be gaps and rather than try to update/influence EPP, I think ARIN is better off going it alone. On the client side, it is minimal effort to generate a special ARIN XML format once you have set up what you need to create filled-in XML templates. I wouldn't want to see delays caused by problems with EPP. At its heart, the REST architectural style is about leveraging a hypermedia and a representation of the resources in an application. XML addresses the resource aspects, but the hypermedia part is a bit more subtle and many tools/systems claiming to be RESTful, are not really what they claim. Because of this, I think that the planned interface specification should be made public for discussion *BEFORE* development work is invested into building it. More info on this issue is available at Also, since it will be a REST API, it doesn't need to be narrowly focused on just template submissions. Since you will be giving URLs to resources (e.g. a template) there is no reason that the URL used to address the template could not be a permanent reference to the address block that was then allocated. In this way, you would end up with most of a REST API for the whois directory. --Michael Dillon From owen at delong.com Fri Dec 19 13:59:24 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Dec 2008 10:59:24 -0800 Subject: [ARIN-consult] Automated templates In-Reply-To: References: Message-ID: <12428AA9-94E0-4369-9519-235CB0063009@delong.com> I really don't see a need to make this overly complicated with XML when for what ARIN templates require a simple attribute/value pairing and RFC-822 style plain text is quite adequate to the task. attribute: value What more do we need? Owen On Dec 19, 2008, at 10:47 AM, wrote: > > I believe that XML templates submitted through a RESTful API are the > best overall solution. EPP may be useable in part but there could well > be gaps and rather than try to update/influence EPP, I think ARIN is > better off going it alone. On the client side, it is minimal effort to > generate a special ARIN XML format once you have set up what you > need to > create filled-in XML templates. I wouldn't want to see delays caused > by > problems with EPP. > > At its heart, the REST architectural style is about leveraging a > hypermedia and a representation of the resources in an application. > XML > addresses the resource aspects, but the hypermedia part is a bit more > subtle and many tools/systems claiming to be RESTful, are not really > what they claim. Because of this, I think that the planned interface > specification should be made public for discussion *BEFORE* > development > work is invested into building it. More info on this issue is > available > at > driven> > > Also, since it will be a REST API, it doesn't need to be narrowly > focused on just template submissions. Since you will be giving URLs to > resources (e.g. a template) there is no reason that the URL used to > address the template could not be a permanent reference to the address > block that was then allocated. In this way, you would end up with most > of a REST API for the whois directory. > > --Michael Dillon > _______________________________________________ > ARIN-Consult > You are receiving this message because you are subscribed to the > ARIN Consult Mailing > List (ARIN-consult at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-consult Please contact > the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. From michael.dillon at bt.com Fri Dec 19 16:20:53 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 19 Dec 2008 21:20:53 -0000 Subject: [ARIN-consult] Automated templates In-Reply-To: <12428AA9-94E0-4369-9519-235CB0063009@delong.com> Message-ID: > I really don't see a need to make this overly complicated > with XML when for what ARIN templates require a simple > attribute/value pairing and > RFC-822 style plain text is quite adequate to the task. > > attribute: value > > What more do we need? How do you correctly represent the name of one of Canada's two largest cities, Montr?al in plain text? I suppose you could use some non-ASCII encoding, but which one? XML solves that and a host of other parsing problems. The toolkits that people use to build REST clients and servers already have XML handling baked into them. No need to worry about whether or not a comma will cause things to go into the wrong db field. Since the API under discussion is about communication between a client application and a server application, there is nothing simple about RFC 822 format and it is not adequate to the task. Let's face it, nowadays XML is COTS (Common Off-The-Shelf) technology, and wrestling with RFC 822 objects is uncommon, and generally requires customized coding. --Michael Dillon From owen at delong.com Fri Dec 19 17:47:40 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Dec 2008 14:47:40 -0800 Subject: [ARIN-consult] Automated templates In-Reply-To: References: Message-ID: <4EEBDD3A-51A4-4B77-A79F-88CDF100F19D@delong.com> On Dec 19, 2008, at 1:20 PM, wrote: >> I really don't see a need to make this overly complicated >> with XML when for what ARIN templates require a simple >> attribute/value pairing and >> RFC-822 style plain text is quite adequate to the task. >> >> attribute: value >> >> What more do we need? > > How do you correctly represent the name of one of Canada's > two largest cities, Montr?al in plain text? I suppose > you could use some non-ASCII encoding, but which one? > XML solves that and a host of other parsing problems. > The toolkits that people use to build REST clients > and servers already have XML handling baked into them. > No need to worry about whether or not a comma will cause > things to go into the wrong db field. > Actually, there is a LATIN-1 ASCII encoding which includes all the characters necessary to represent any of the city names in the region that I am aware of. While I don't want to be culturally insensitive, the reality is that today, the WHOIS and other ARIN databases use Montreal to represent the name of the city and I am not aware of any substantial portion of the ARIN constituency finding tremendous fault with that representation. > Since the API under discussion is about communication > between a client application and a server application, > there is nothing simple about RFC 822 format and it > is not adequate to the task. Let's face it, nowadays > XML is COTS (Common Off-The-Shelf) technology, and > wrestling with RFC 822 objects is uncommon, and generally > requires customized coding. > Some templates will be automated, some will be hand generated. Having one parser that can automate the handling of both circumstances is, in my opinion, desirable. Having a human-readable template format that can be used for error reporting and human-based corrected resubmission is also desirable. RFC822 parsing is pretty simple, and, there are toolkits for it available in PERL, Python, and several other languages. RFC822 attribute-value pairs are commonly used in one of your favorite tools, afterall... LDIF uses an RFC822 style attribute-value pairing syntax. Owen From heather.schiller at verizonbusiness.com Mon Dec 22 11:41:33 2008 From: heather.schiller at verizonbusiness.com (Heather Schiller) Date: Mon, 22 Dec 2008 11:41:33 -0500 Subject: [ARIN-consult] Automated Template Submission and Testing Message-ID: <494FC33D.8010500@verizonbusiness.com> My original intent with this suggestion was that ARIN make available a second alias that behaves identically to hostmaster@ but does not trigger db changes in the production system. This way folks can test scripts that auto generate templates and individuals who have never use the system can get some practice. We have built in an automatic swip update function into our address provisioning system. When the templates change it would be nice to have a system to test it against before we release the change into production. Also, we have many customers who ask us how to submit templates to ARIN and would like us to check the templates for them before they submit. In some cases they would also like a way to have their folks 'practice' submitting templates as a training exercise. The consultation request seems to go beyond this to ask how we would like the new online system to work. (Which isn't bad.. I'm just not prepared to provide feedback on that at the moment!) --Heather -- ==================================================== Heather Schiller Verizon Business Customer Security 1.800.900.0241 IP Address Management help4u at verizonbusiness.com =====================================================