From provreg@contact.dotandco.com Sat Jul 2 08:35:02 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66D811E8136 for ; Sat, 2 Jul 2011 08:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKXmxaoID8wA for ; Sat, 2 Jul 2011 08:35:02 -0700 (PDT) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1E62511E8129 for ; Sat, 2 Jul 2011 08:34:58 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p62FWq0b008913 for ; Sat, 2 Jul 2011 17:32:53 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id p62FWqkk008911 for provreg@ietf.org; Sat, 2 Jul 2011 17:32:52 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Sat, 2 Jul 2011 17:32:50 +0200 From: Patrick Mevzek To: provreg@ietf.org Message-ID: <20110702153250.GE4081@home.patoche.org> References: <201106092208.p59M8p2k070964@nic-naa.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201106092208.p59M8p2k070964@nic-naa.net> Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Sat, 02 Jul 2011 17:32:53 +0200 (CEST) Subject: Re: [provreg] Why must there be one solution? was Re: Lists and EPP X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 15:35:02 -0000 brunner@nic-naa.net 2011-06-10 02:08 > At the Paris ICANN meeting I asked the Registrar Constituency members > present which would be doing new gTLDs -- as registrars. > > No hands were raised. Which probably does not reflect what happens in reality... just see the rate of adoption of .XXX among registrars... (almost 100% already during a month of accreditations, if I take your own account of 60 "true" registrars below) > The Vertial Integration Botch (tm) now means that we've 600+600 as > a design space. 600 registries (legacy ex-RRP-speakers, 2001+2004 > EPP-speakers, a "bigger N" number of 3166 registries, and ICANN's > 500 (or whatever) of 201x registries, AND the same 60 registrars > (ignoring the 600+ shell registrars that exist only for the 3pm > race), the same "+N0" registrars pursuing local geo markets, AND > each registry-as-a-registrar. However there are not 600+60 registry back-end providers, software and solutions. And I do not believe that each registrar wanting to be a gTLD operator will create from scratch a registry system. There are maybe 30 or 50 commercial provider providing parts or all of a registry solution (including current gTLD operators), a few open source software and companies building on them. You can even add all current ccTLDs operators (since some will be gTLD operators), you are still far from 600. So, in my view, there is still hope of some factorization of EPP extensions. Hence my attempt at a draft more than 2 years ago. -- Patrick Mevzek From provreg@contact.dotandco.com Sat Jul 2 08:45:23 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9E11E8144 for ; Sat, 2 Jul 2011 08:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G9GbU8oex1c for ; Sat, 2 Jul 2011 08:45:22 -0700 (PDT) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id 64A7711E8146 for ; Sat, 2 Jul 2011 08:45:22 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p62FhKvV011650 for ; Sat, 2 Jul 2011 17:43:20 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id p62FhJJN011647 for provreg@ietf.org; Sat, 2 Jul 2011 17:43:19 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Sat, 2 Jul 2011 17:43:17 +0200 From: Patrick Mevzek To: provreg@ietf.org Message-ID: <20110702154317.GF4081@home.patoche.org> References: <1308058382.22854.27.camel@scimitar.gb.zmg.lon.uk.centralnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Sat, 02 Jul 2011 17:43:21 +0200 (CEST) Subject: Re: [provreg] Another look at the data model for launch phase registrations X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 15:45:23 -0000 Wil Tan 2011-06-16 15:47 > > * MUST have 1 or more codes from the set: [pending, > > validated, invalid, cancelled, allocated] (Q: possibly others?) > > I'm ambivalent about allowing the status field to be extended. These status > values suited our use case fine, but others may have a need for a different > set of values. I would prefer to have the extension being as extensible itself as possible. Fixed list of status code in EPP is one of the most visible problems, as nearly all registry need to extend that list in some way. So I would argue: provide a set of "sensible" (aka currently known) status codes, but make the schema in such a way that other status could be added. Extended statuses could be mandatory to follow a specific form (to separate them from standard ones, and from one registry to another), such as the often used "X-" prefix, or following the contact srids having some sort of registry id being prepended or appended to the status, or available along it. Also, allowing a free text to be attached to a status is useful for providing extra information. > > > * MUST have a from the set [SR, LR] (Q: should we let > > servers define further phases?) > > > > I think should be optional, and it should just be free form. I can > definitely see use cases for mini launch phases such as "2char-release". Same comment as previously: I would prefer not free form but instead a list of current sensible values (but without the need to compress them to 2 chars, "sunrise" is ok and better in my view than SR), and a way to easily extend them without having to redefine the extension. -- Patrick Mevzek From provreg@contact.dotandco.com Sat Jul 2 09:03:43 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4197E21F864D for ; Sat, 2 Jul 2011 09:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhxZ6GR+F+vc for ; Sat, 2 Jul 2011 09:03:42 -0700 (PDT) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCB821F864F for ; Sat, 2 Jul 2011 09:03:41 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p62G1bIF017063 for ; Sat, 2 Jul 2011 18:01:37 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id p62G1bAG017061 for provreg@ietf.org; Sat, 2 Jul 2011 18:01:37 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Sat, 2 Jul 2011 18:01:35 +0200 From: Patrick Mevzek To: provreg@ietf.org Message-ID: <20110702160135.GG4081@home.patoche.org> References: <4DFA358B.5090605@blacknight.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DFA358B.5090605@blacknight.com> Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Sat, 02 Jul 2011 18:01:37 +0200 (CEST) Subject: Re: [provreg] Proposal: A method in EPP for registry policy discovery X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 16:03:43 -0000 Keith Gaughan 2011-06-16 18:56 > This proposal comes out of the comments Jothan has been making recently, which > I agree wholeheartedly with. > > As a registrar, one of our great problems registry policy discovery. This is > of particular importance with it comes to ccTLDs, whose policies can vary > drastically. For instance: > > * what commands does the registry support with particular objects, > * what is the lifecycle of a domain in a particular zone, > * does removing a domain from redemption incur a cost to the registrar, > * how long after registration, transfer, and renewal must it be before a > domain can be transferred or renewed, > * what periods does a registry support for registrations, transfers, and > renewals, > * does the registry support the poll command, > * for contacts, which types does the element support (this is a > crapshoot and registries, in my experience, never document this), > * does the registry support registrant modification, > * are there per-command limits. > > These are just the ones I could think of off the top of my head. If not done already, I believe you can find other examples/ideas in section 4.4 of my draft at http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt However, I fear to have the same opinion than Klaus, meaning that it would be hard to specify clearly all details for everyone. For example, pricing components would be probably better left out of such scope. There was however, I believe in some past CENTR meeting, a ccTLD registry explaining they have all of their EPP business rules encoded in an XML document which is parsed and used by their EPP server as is, or during tests maybe, sorry I do not remember details. Also something else that is true for all new possible extension that would be useful in all EPP servers: if you can not have support of current registries, starting with gTLDs, then the extension even if very useful in itself, would be practically not useful if not used by enough registry operators. So there would be probably a lot of non technical work there, to convince operators to adhere. I do however completely agree with you that for registrars the current situation is difficult, since registry policies are not often clear nor clearly available, even less in a kind of standard fashion. I'm not sure however the IETF could do anything in that aspect, maybe something would be better to conduct among ccTLDs organizations such as CENTR, or inside ICANN Registrars/Registries consistuencies. However if interested, please find below some quick ideas: > > > It would be useful then to know DAC is prefered, so something should still be provided there. > Can the registrar do a domain:info on a domain it manages ? With or without the associated authInfo? Is the content retrieved different? In what manner? > What are the minimum/maximum years allowed? Which contacts are mandatory, which are optional, in what cardinality, etc. > > Yes, but I'm not sure it's orthogonal with the list you provide above. For example, in one zone, domain:delete may be possible, and not in another. So probably everything should be per zone. -- Patrick Mevzek From ebw@nic-naa.net Sat Jul 2 09:09:17 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7AE21F8671 for ; Sat, 2 Jul 2011 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnMfggNjByD2 for ; Sat, 2 Jul 2011 09:09:16 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9B75621F866F for ; Sat, 2 Jul 2011 09:09:16 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p62E50dm077502; Sat, 2 Jul 2011 10:05:01 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201107021405.p62E50dm077502@nic-naa.net> From: brunner@nic-naa.net To: provreg@contact.dotandco.com Date: Sat, 02 Jul 2011 10:05:00 -0400 Sender: ebw@nic-naa.net Cc: provreg@ietf.org Subject: Re: [provreg] Why must there be one solution? was Re: Lists and EPP X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 16:09:17 -0000 > brunner@nic-naa.net 2011-06-10 02:08 > > > At the Paris ICANN meeting I asked the Registrar Constituency members > > > present which would be doing new gTLDs -- as registrars. > > > > > > No hands were raised. > > Which probably does not reflect what happens in reality... just see > the rate of adoption of .XXX among registrars... a 2004 round applicant, with some non-trival lead-time. the .post trajectory should be similar, whenever it gets to delegation. my question -- in 2008 -- was about registrar interest in a vastly larger number, with vastly different inter-availability waits. > (almost 100% already during a month of accreditations, > if I take your own account of 60 "true" registrars below) i really don't care what you take into account, given the substitution of many-in-a-year with one-in-a-decade, as the registrar problem statement, above. > > > The Vertial Integration Botch (tm) now means that we've 600+600 as > > > a design space. 600 registries (legacy ex-RRP-speakers, 2001+2004 > > > EPP-speakers, a "bigger N" number of 3166 registries, and ICANN's > > > 500 (or whatever) of 201x registries, AND the same 60 registrars > > > (ignoring the 600+ shell registrars that exist only for the 3pm > > > race), the same "+N0" registrars pursuing local geo markets, AND > > > each registry-as-a-registrar. > However there are not 600+60 registry back-end providers, software and > solutions. > And I do not believe that each registrar wanting to be a gTLD > operator will create from scratch a registry system. > There are maybe > 30 or 50 commercial provider providing parts or all of a registry > solution (including current gTLD operators), a few open source software and companies > building on them. You can even add all current ccTLDs operators > (since some will be gTLD operators), you are still far from 600. each registry operator enjoys the assumption that it acts independently of all others, and is free to dork as it sees fit, as the 2001-to-present variation shows. the smaller number of mature platform operators, all of whom support two or more variations, line previous, may not reduce that registrar-harming freedom of registry non-interdependence, and all self hosting operators are limited only by the technology they license, or build, and operate independently. > So, in my view, there is still hope of some factorization of EPP > extensions. Hence my attempt at a draft more than 2 years ago. solving the 2004 problem has some utility. -e From provreg@contact.dotandco.com Sat Jul 2 09:46:32 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008DF11E8073 for ; Sat, 2 Jul 2011 09:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1si-cbIifiR for ; Sat, 2 Jul 2011 09:46:31 -0700 (PDT) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4462C228016 for ; Sat, 2 Jul 2011 09:46:31 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p62GiTBb005753 for ; Sat, 2 Jul 2011 18:44:29 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id p62GiSmf005730 for provreg@ietf.org; Sat, 2 Jul 2011 18:44:28 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Sat, 2 Jul 2011 18:44:26 +0200 From: Patrick Mevzek To: provreg@ietf.org Message-ID: <20110702164426.GA27741@home.patoche.org> References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Sat, 02 Jul 2011 18:44:29 +0200 (CEST) Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 16:46:32 -0000 Patrik Fältström 2011-06-17 12:10 > When you do transfer of a domain, what happens with the host and contact objects that are bound to the domain? What notifications are sent, and what actions have to be taken? > > I think, even though we have 200+ different business models, I claim those can be implemented with only say 3-5 different ways of doing transfer. I mostly agree with this. > > It might be better to approach this from a different direction. How about defining a standard set of registry transactions -- create/delete/modify objects, renew and transfer a domain name, etc -- and writing this up as a BCP? Once that's done, the BCP could be encoded in a standard test suite. In other words, document what it is that's to be tested before developing a test suite. Some tests might be optional (for instance IDN and DNSSEC might not be deployed in places) while others are mandatory. > > I fully support this. And is implicitly what I am asking for. That registries try to, before they invent their own epp architecture, look carefully at if they can not reuse what someone else is doing. I would suggest before that to make sure that each registry document and publish (eventually up to an IETF Informative RFC) their extensions. So that we would have a "catalogue" of what is happening on the field. However this purely technical hope is severly constrained by an economic one: each registry taken independantly has no financial/economical/technical interest in redoing things that work today but using another extension (so the current fragmentation has little hope to be resolved), and even documenting it clearly and publishing it outside of their registrars circle (and this is indeed one example of response I got when I query registries for their technical details as an EPP implementor but not an accredited registrar with them). And I do not see, since it is not a purely technical issue in the hands of IETF, how to "convince" people to correct this situation. So, Patrick, I agree with you, registries should "try to" see what exists already before reinventing the wheel, but how to achieve that? I honestly have no idea while still believing it is a worthwile goal. Maybe registrars (as a group) + independant implementors should try to raise their voice together... As for the new ones with the new gTLDs, the smartest ones (those having read Michele excellent recent post on CircleID for example) will make sure to lower the technical differences as much as possible, and reuse existing extensions (but back to square one: they have to be published and well known beforehand). Others will either need anyway to create new extension based on their own needs (and there it could go wrong in many ways... I'm not sure there are many prospective gTLDs operators being here, but I hope being wrong), or would argue they can do things better/differently and then create a new extension for something already done by some current registries. -- Patrick Mevzek From provreg@contact.dotandco.com Sat Jul 2 09:54:28 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFF821F85B0 for ; Sat, 2 Jul 2011 09:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKMJHRccDW4v for ; Sat, 2 Jul 2011 09:54:27 -0700 (PDT) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id 56A0421F85AE for ; Sat, 2 Jul 2011 09:54:26 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p62GqQKe010975 for ; Sat, 2 Jul 2011 18:52:26 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id p62GqQF6010973 for provreg@ietf.org; Sat, 2 Jul 2011 18:52:26 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Sat, 2 Jul 2011 18:52:25 +0200 From: Patrick Mevzek To: provreg@ietf.org Message-ID: <20110702165225.GB27741@home.patoche.org> References: <4DFA2E85.1010607@blacknight.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DFA2E85.1010607@blacknight.com> Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Sat, 02 Jul 2011 18:52:26 +0200 (CEST) Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 16:54:28 -0000 Hello Keith, Keith Gaughan 2011-06-16 18:26 > This is the first in a series of suggestions from a registrar's point of view > improvements that can be made to and around EPP to make the life of registrars > easier. Consider them food for thought if nothing else. At least personnally I welcome your initiative and wish that other registrars participate here and do the same. > A standard EPP test suite from OT&E would, I think, serve two important > purposes. Firstly, it would be an immense help to registrar who are > developing their domain management systems for the first time as not all of > us use Net::DRI for Perl or EPP-RTK for Java and C++. Ours, for instance, is > written in a combination of Python and PHP. Secondly, it would mean that > registrars would only need to run through the test suite *once*, which would > greatly reduce the management overhead for both registrars and registries > during accreditation. A central registry, likely maintained by ICANN, listing > whether a registrar has successfully completed a particular part of the test > suite, would also be useful. I'm not sure this suits ICANN mandate or role. I even fear it would complicate the system. However, I also agree with Klaus and Wil: current accreditation tests are *worthless* and I would say even *dangerous*. They mandate to do things specifically forbidden in EPP (such as syntax of some elements outside accepted values), and seem to concentrate in detail with some arcane parts that almost never appear in production. Obviously, not all registry certification tests are equal, some are more worthless than others :-) End results (and it's not an hypothesis, I have direct personal proof of that): registrars build (or buy) a quick custom script that send to the registries the rubbish they wait for, and pass the accreditation test without problems. It has no bearing on what they will really use in production, meaning it would be something completely different. So the tests in that case do not verify anything... except maybe the registry own systems :-) There are also some registries that also accepts tests even if not 100% passed. So I'm not against certification tests per se, as I believe they could fulfill an useful role of making sure that registrars technical team EPP knowledge level is raised up an acceptable level, before having it in production, and through the support channel. Again, as a personal direct observation, many calls to registry support people are tied with some very basic questions such as "how to do a connection from language X" (when X is not included in registries SDK) or "how to setup my SSL certificate". But technical tests as they are done today are a burden without actual benefits. Back in ICANN 2010 Brussels, I've proposed the idea of having a cross-registry EPP test suite ( http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-icann-brussels-ccnso-techday-201006/index.html#slide19 ) that could be done in such a way that it works for both directions, and may also solve part of the problem raised here by Keith in another thread, such as the registry policies for various operations. And following Jim's idea there, it could be done as a BCP. What also seems to me more important is mandating the registries to have a working OT&E system well used during upgrades with enough advance warnings and documentations on new/changed extensions. I would also suppose that the first registrars of the new gTLDs will be current registrars, meaning they obviously already have a working EPP implementation. Forcing them to pass new certification tests would be a loss of time, except if they are limited to each registry specific parts and new extensions. -- Patrick Mevzek From pfaltstr@cisco.com Sat Jul 2 20:53:08 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE3911E813D for ; Sat, 2 Jul 2011 20:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yLwiSyJBYzB for ; Sat, 2 Jul 2011 20:53:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5BC11E811C for ; Sat, 2 Jul 2011 20:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pfaltstr@cisco.com; l=769; q=dns/txt; s=iport; t=1309665187; x=1310874787; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=0uLNSxbVjms5QeyXnRKQsprygC+/HQNnWKjwkwgOJuQ=; b=fB2RV1Tu2usv+LBGubDe8AZfEiUbEw+Dz9YWtVv7KGjuNYeNWt6FoUSc wOyoCvumpdTCe/zkozipzLvrOtnDKlGbPL9GT/puwFsKvgmw2oekNIsYh WZKqICl7q5+p3oGuyu2kBCGNUV5c4NFdxZ7gdVeRt4Eju621BoQhsn58O w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEHAAfnD06Q/khM/2dsb2JhbABSiQueCWwCd4h6onScfIY2BJI2hQGLNw X-IronPort-AV: E=Sophos;i="4.65,466,1304294400"; d="scan'208";a="99354796" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Jul 2011 03:53:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p633r5DQ012643; Sun, 3 Jul 2011 03:53:05 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jul 2011 05:53:04 +0200 Received: from 72.163.62.136 ([72.163.62.136]) by XMB-AMS-106.cisco.com ([144.254.74.81]) with Microsoft Exchange Server HTTP-DAV ; Sun, 3 Jul 2011 03:53:04 +0000 References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> <20110702164426.GA27741@home.patoche.org> Content-Transfer-Encoding: quoted-printable From: "Patrik Faltstrom (pfaltstr)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <20110702164426.GA27741@home.patoche.org> Thread-Topic: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type Thread-Index: Acw5NLXxWfcChAxbT+6epfPJmqgYgg== Message-ID: Date: Sun, 3 Jul 2011 05:51:19 +0200 To: "Patrick Mevzek" MIME-Version: 1.0 (iPhone Mail 8J2) X-OriginalArrivalTime: 03 Jul 2011 03:53:04.0951 (UTC) FILETIME=[B67B2C70:01CC3934] X-Mailman-Approved-At: Sun, 03 Jul 2011 01:48:36 -0700 Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:53:08 -0000 On 2 jul 2011, at 18:46, "Patrick Mevzek" wro= te: > So, Patrick, I agree with you, registries should "try to" see what exists > already before reinventing the wheel, but how to achieve that? I > honestly have no idea while still believing it is a worthwile goal. We can not police, but IETF can help by "stop being so nice" and ack that tw= o registries that require ANY change in the registrar epp implementation are= NOT interoperable. If just that is known, we are in a better situation. > Maybe registrars (as a group) + independant implementors should try to > raise their voice together... I think/hope that is what is now happening? ;-) Patrik - tired of all non-interoperable registry inventions in epp From ebw@nic-naa.net Sun Jul 3 07:30:11 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E02621F87D5 for ; Sun, 3 Jul 2011 07:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b90BbZ-uTAu8 for ; Sun, 3 Jul 2011 07:30:10 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8194821F8723 for ; Sun, 3 Jul 2011 07:30:10 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p63CPixj083520; Sun, 3 Jul 2011 08:25:44 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201107031225.p63CPixj083520@nic-naa.net> From: ebw@abenaki.wabanaki.net To: pfaltstr@cisco.com Date: Sun, 03 Jul 2011 08:25:44 -0400 Sender: ebw@nic-naa.net X-Mailman-Approved-At: Sun, 03 Jul 2011 08:14:50 -0700 Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 14:30:11 -0000 patrik, If you, or anyone else with an interest in the implementation consequences of the post-2004 scaling properties of new icann contracts for registries, had been engaged in the vertical integreation policy area, from the point in time when icann staff, sui sponte, included the continuation of the '01 and '04 structural separation with the more general question of economic utility analysis [1], you would have witnessed two salient meta-requiements expressed by the majority involved in the policy area: o registrars generally had no interest in restrictions upon their behavior as registries, though a few significant exceptions did exist, e.g., core and godaddy, o non-registrars had no interest in restrictions upon their behavior as registries. if you go back to the final vi report and see how many participants (note also their business, or their academic/ideological affiliation) rejected continuity of the basic '01 and '04 separation requirement. the ec and doj letters of last month deal with the existing competition policy problem of allowing an entity with an 83% market share, or entities with a 100% market share, compete with external registrar functional units, though it is expressed as a market power analysis, allowing integration where market power is absent. what the ec and doj letters do not deal with is nacent competition policy problem of 500 registries, each able to express a distinct business model, through its registration policy, and each able to operate as a registrar for its own registry. your milage, and others, will vary, but after i reflected on the problem i came to the conclusion that the 15% cap on registry ownership in registrars was the better structural policy choice which allowed any cross-ownership, as it, as an implementation detail, requires at least 7 registries which do not share ownership or control (e.g., no "seven puppets") to agree to form a cross-ownership restriction compliant registrar. this reduces the diversity problem by almost an order of magnitude, see "scale", above, as the co-owners of, and co-channel dependent registries have a criticial material interest in -- interoperation. a lower cross-ownership threshold is even better, 5% means 20 registries have a criticial material interest in their common registrar's ability to operate over 20 inventories, 20 policy models, on a tractible implementation platform, possibly implemented as a single code base with 20, but no fewer, ugly little #ifdefs. since i don't recall anyone involved in epp, past or present, other than myself being involved with the icann vi wg, the straight-registrar interest in the issue of requirements diversity is a ship that sailed, steered mostly by the stars of independent fortunes for independent registries. a ship that has not yet sailed is that of 2012 applicants who apply for a form of assistance arising from the icann boards' policy resolution 20 at nairobi, and implemented by the joint applicant support (jas) working group. for qualified (for support under the guidelines recommended by the jas) applicants, is cooperation on one or more areas of qualified applicant common interest recommended, required, or included? if support is available to 20% of the 2012 applicants, and if cooperation takes the form of a criticial material interest in -- interoperation, then this reduces the diversity problem by two orders of magnitude, see "scale", above. i'm writing this now (well, today i'm working on a law school project with a "now" deadline). if you want to find a way to pursuade enom to play nice with netsol, where both (and many others) are platform owners and hold one or (many) more registry contracts and are registrars for their proper new gtld registries, feel free. i suspect you'll need to make your arguement to the board (ok, you can try the fatally disfunctional gnso first) that diversity without restriction leads to cartels of registrar controlled registries, harming non-affiliated registrars (and registrants), and when that doesn't work, making the same competition policy claim to the ec and doj as competition authorities. the straight registrar has a criticial material interest in interoperability, this interest is not shared by registries, or any other policy advocacy entity with standing, under the current regulatory policy model and practice. one reasonable answer is monopoly, follow com/net, with a few forks for org and the next big thing. we took that path in 2000, dropping xrp and all its bells and whistles. another is changing the problem constraints, see above. implementers need only inform investors that interoperability with existing competitors, and surrendering plan of record competitive advantage in the new gtld market is a wicked good idea to find redirection or other employment opportunities. which leaves a lot of non-interoperability, and some interoperability, based on a criticial material interest. -e [1] 2008, the "economic analysis" having been claimed as a necessity prior by parties advocating no, or few, new registries, generally due to the cost to marks portfolio managers to execute dilution defense via systematic defensive buys -- the covert "first million in revenu" in the price-cap with no material policy based registration restriction registry business plans. From pawal@blipp.com Mon Jul 4 03:07:29 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580D421F8613 for ; Mon, 4 Jul 2011 03:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE+nnPDE9Mal for ; Mon, 4 Jul 2011 03:07:29 -0700 (PDT) Received: from vic20.blipp.com (cl-682.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:2a9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA9B21F860C for ; Mon, 4 Jul 2011 03:07:28 -0700 (PDT) Received: from [IPv6:2001:16d8:cc4f:1001:21f:f3ff:fe54:eb8a] (unknown [IPv6:2001:16d8:cc4f:1001:21f:f3ff:fe54:eb8a]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id 02F6E3809A; Mon, 4 Jul 2011 12:07:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Patrik Wallstrom In-Reply-To: Date: Mon, 4 Jul 2011 12:07:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8EE23D8C-B986-4FEF-96C2-4EADB65CFE98@blipp.com> References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> <20110702164426.GA27741@home.patoche.org> To: Patrik Faltstrom (pfaltstr) X-Mailer: Apple Mail (2.1084) Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 10:07:29 -0000 On Jul 3, 2011, at 5:51 AM, Patrik Faltstrom (pfaltstr) wrote: > On 2 jul 2011, at 18:46, "Patrick Mevzek" = wrote: >=20 >> So, Patrick, I agree with you, registries should "try to" see what = exists >> already before reinventing the wheel, but how to achieve that? I >> honestly have no idea while still believing it is a worthwile goal. >=20 > We can not police, but IETF can help by "stop being so nice" and ack = that two registries that require ANY change in the registrar epp = implementation are NOT interoperable. If just that is known, we are in a = better situation. That would be very hard for the IETF to do for a protocol that the IETF = claims to be extensible, right? If you want protocols that can be = policed like that, at least that word should not be in the name of the = standard. :) From pfaltstr@cisco.com Mon Jul 4 03:21:00 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60921F8623 for ; Mon, 4 Jul 2011 03:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwZ0AVd666Xq for ; Mon, 4 Jul 2011 03:20:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1321F861E for ; Mon, 4 Jul 2011 03:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pfaltstr@cisco.com; l=756; q=dns/txt; s=iport; t=1309774859; x=1310984459; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=L/ED2/EwGX2r1IZUvv+mDXfbyVdq38vJWLZY8ThApWY=; b=VadaU8t/Rr7VyCvBv6559oAzj226EgBIM8npB7FL/tyPSLK8u7z6fLQX o4G6zutJDF+uole09k1fBwKK8VO66DEeW4C+zIo5eKuBNVoWbAJ5odn5K BZJAqEv65W07EWgcbx1RA4GEUDIzYcPGXwuxfrvoZMil3YYI9eJZ95Kfe 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0IAMCSEU6Q/khN/2dsb2JhbABSpxBrAneIeqQ1nTOGNgSSNoUBh0CDdw X-IronPort-AV: E=Sophos;i="4.65,471,1304294400"; d="scan'208";a="99509556" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 04 Jul 2011 10:20:55 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p64AKtlW004569; Mon, 4 Jul 2011 10:20:55 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jul 2011 12:20:55 +0200 Received: from 144.254.231.96 ([144.254.231.96]) by XMB-AMS-106.cisco.com ([144.254.74.81]) with Microsoft Exchange Server HTTP-DAV ; Mon, 4 Jul 2011 10:20:54 +0000 References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> <20110702164426.GA27741@home.patoche.org> <8EE23D8C-B986-4FEF-96C2-4EADB65CFE98@blipp.com> Content-Transfer-Encoding: quoted-printable From: "Patrik Faltstrom (pfaltstr)" Content-Type: text/plain; charset="us-ascii" Thread-Topic: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type Thread-Index: Acw6NA7IQ5FJQsNCR5mo8FCZLJiMfw== In-Reply-To: <8EE23D8C-B986-4FEF-96C2-4EADB65CFE98@blipp.com> Message-ID: Date: Mon, 4 Jul 2011 12:20:03 +0200 To: "Patrik Wallstrom" MIME-Version: 1.0 (iPhone Mail 8J2) X-OriginalArrivalTime: 04 Jul 2011 10:20:55.0153 (UTC) FILETIME=[0F03F610:01CC3A34] X-Mailman-Approved-At: Mon, 04 Jul 2011 03:43:38 -0700 Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 10:21:00 -0000 On 4 jul 2011, at 12:07, "Patrik Wallstrom" wrote: >> We can not police, but IETF can help by "stop being so nice" and ack that= two registries that require ANY change in the registrar epp implementation a= re NOT interoperable. If just that is known, we are in a better situation. >=20 > That would be very hard for the IETF to do for a protocol that the IETF cl= aims to be extensible, right? If you want protocols that can be policed like= that, at least that word should not be in the name of the standard. :) Absolutely correct! As I have said before, I was the area director and because of that somewhat r= esponsible when epp was standardized. I did then not envision what problems w= ould arise. Patrik= From theo@flame.co.za Mon Jul 4 04:41:40 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE31F0C40 for ; Mon, 4 Jul 2011 04:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSSdND4qViXC for ; Mon, 4 Jul 2011 04:41:40 -0700 (PDT) Received: from flame.co.za (conficker5.flame.co.za [160.124.170.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321A01F0C36 for ; Mon, 4 Jul 2011 04:41:40 -0700 (PDT) Received: from theo-kramers-macbook-pro.int.coza.net.za (unknown [41.160.185.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTPSA id 7490E8005C for ; Mon, 4 Jul 2011 13:41:36 +0200 (SAST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Theo Kramer In-Reply-To: Date: Mon, 4 Jul 2011 13:41:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DFA2E85.1010607@blacknight.com> <4DFAF92E.90104@knipp.de> <4DFAFE39.1010602@internetx.de> <94C1FF5C-4155-4FBF-81DC-56E37A2240DF@rfc1035.com> <20110702164426.GA27741@home.patoche.org> To: provreg@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 11:41:40 -0000 On 03 Jul 2011, at 5:51 AM, Patrik Faltstrom (pfaltstr) wrote: > On 2 jul 2011, at 18:46, "Patrick Mevzek" = wrote: >=20 >> So, Patrick, I agree with you, registries should "try to" see what = exists >> already before reinventing the wheel, but how to achieve that? I >> honestly have no idea while still believing it is a worthwile goal. >=20 > We can not police, but IETF can help by "stop being so nice" and ack = that two registries that require ANY change in the registrar epp = implementation are NOT interoperable. If just that is known, we are in a = better situation. >=20 >> Maybe registrars (as a group) + independant implementors should try = to >> raise their voice together... >=20 > I think/hope that is what is now happening? ;-) >=20 > Patrik - tired of all non-interoperable registry inventions in epp The OASIS ebCPPA protocol defines a mechanism for trading partners to = implement a collaborative business process by defining a collaboration = profile. Perhaps such an approach could be investigated for EPP = Registries and Registrars to formalize interoperability with the formal = collaboration profiles registered with ICANN or IETF ... --=20 Regards Theo From ebw@nic-naa.net Mon Jul 4 08:05:04 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647121F0C92 for ; Mon, 4 Jul 2011 08:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nkv9K4cIoa96 for ; Mon, 4 Jul 2011 08:05:04 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 3065C1F0C90 for ; Mon, 4 Jul 2011 08:05:03 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p64D0Nkl089720; Mon, 4 Jul 2011 09:00:23 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201107041300.p64D0Nkl089720@nic-naa.net> From: brunner@nic-naa.net To: pfaltstr@cisco.com Date: Mon, 04 Jul 2011 09:00:23 -0400 Sender: ebw@nic-naa.net Cc: provreg@ietf.org Subject: Re: [provreg] Proposal: A standard EPP OT&E test suite for each object type and extension type X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 15:05:04 -0000 paf, it is now useful for one or more epp specification and implemention interested parties to opine, or make a recommendation on the utility of common syntax and semantics to a class of registry applicants. i, and possibly one or more other contributors to the joint applicant support working group (jointness from the generic name supporting organization and the at large advisory committee, as participating bylaws entities of the internet corporation for assigned names and numbers), will be making recommendations that are intended to reduce new gtld applicant cost and risk, for qualified applicants. cost includes more than the application fee, and risk includes risk of entering "continuity", which includes a failure of the registry as a cost-recovery economic unit, which includes interoperability, as a cost barrier to its acquisition of sales channels (external registrars), and therefore the provisioning protocol. a contribution on the subject, from parties knowledgable about the current practice of provisioning protocol implementors and users, and the choices available to specification authors for a given set of user requirements, something offering more salient guidance than "tired of all non-interoperable registry inventions in epp", could be useful. non-contribution means i co-author the text, which i suspect is sufficient, but asking is prudent. more formal requests from the jas-wg to the board and it's ietf liaison, and on through the magic of delegation, eventually to this very mailing list, are possible. -e From nkong.cnnic@gmail.com Thu Jul 14 00:06:33 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69E221F87AF for ; Thu, 14 Jul 2011 00:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCpqWKvf7cZi for ; Thu, 14 Jul 2011 00:06:29 -0700 (PDT) Received: from mail-pv0-f194.google.com (mail-pv0-f194.google.com [74.125.83.194]) by ietfa.amsl.com (Postfix) with ESMTP id C0EBE21F8797 for ; Thu, 14 Jul 2011 00:06:26 -0700 (PDT) Received: by pvg11 with SMTP id 11so1729305pvg.1 for ; Thu, 14 Jul 2011 00:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=vvTcwRXX/8eGEM6sLqqp3a9cVK3xZ2EE8L2fA69BjNQ=; b=l/2teCkr30XWi6/J5lhnV02DLDA1fswr9xHcUoS45yWrXcvhdppWuBHO3z7oA8GAP8 wPpY/v0O++1PCqh7jgwcUFy5UCvskBs0GQtGxjIIy1Yt8X7WEDd+QhqyQMnQKdgK/ogS 6O3tWxKbl4psqHJHDqdKWQ04QqTtS+Wtbs11k= MIME-Version: 1.0 Received: by 10.68.60.65 with SMTP id f1mr2571279pbr.67.1310627186210; Thu, 14 Jul 2011 00:06:26 -0700 (PDT) Received: by 10.68.63.230 with HTTP; Thu, 14 Jul 2011 00:06:26 -0700 (PDT) Date: Thu, 14 Jul 2011 15:06:26 +0800 Message-ID: From: Ning Kong To: provreg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [provreg] draft-kong-epp-cdn-mapping-00 Submitted for Review X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 07:14:57 -0000 Hi folks, I submitted http://www.ietf.org/id/draft-kong-epp-cdn-mapping-00.txt which describes an extension of Extensible Provisioning Protocol (EPP) domain name mapping for the provisioning and management of Chinese Domain Names (CDNs), especially for variant CDNs. Any comments on this draft are welcomed. Thanks, Ning From ebw@nic-naa.net Fri Jul 22 10:45:45 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B39521F8B3E for ; Fri, 22 Jul 2011 10:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH4rq9EvkHVm for ; Fri, 22 Jul 2011 10:45:44 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8515A21F8B3C for ; Fri, 22 Jul 2011 10:45:44 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p6MFmCNB053797 for ; Fri, 22 Jul 2011 11:48:12 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201107221548.p6MFmCNB053797@nic-naa.net> From: brunner@nic-naa.net To: provreg@ietf.org Date: Fri, 22 Jul 2011 11:48:12 -0400 Sender: ebw@nic-naa.net Subject: [provreg] Fwd: registry software availability X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 17:45:45 -0000 Colleagues, I'm looking for pointers to licensing terms and conditions for some or all the components of a registry and registrar system, which uses EPP as the provisioning protocol. I will summarize for the Joint Application Support Working Group, and the consumers of its work product, and this mailing list. I've updated the note forwarded, and will annotate a table of source bases, licensing terms, and things I think useful, and make it available. Thanks in advance, Eric ------- Forwarded Message From: ebw@abenaki.wabanaki.net To: soac-newgtldapsup-wg@icann.org Subject: Re: [soac-newgtldapsup-wg] registry software availability Date: Fri, 22 Jul 2011 06:40:50 -0400 Sender: ebw@nic-naa.net Colleagues, The following, from the "There exists some similar programs" link from the http://codev-nic.generic-nic.net/ site is what I'd in mind when suggesting that the JAS-WG inquire into registry implementation sources and their licensing conditions. OpenReg of ISC http://www.isc.org/index.pl?/sw/openreg/ SRS of .nz http://sourceforge.net/projects/dnrs/ mod_epp of .at http://sourceforge.net/projects/aepps/ FRED of .cz http://fred.nic.cz/ CoCCA of .cx http://trac.cocca.org.au/ (dead link pointed out by Michele Neylon, alt: https://downloads.coccaregistry.net/ in follow-up mail to the JAS-WG mailing list) registro of .br http://www.registro.br/ tinyReg of NSRC http://nsrc.org/tinyReg/ And of course, as Fabien helpfully pointed out, there is CODEC-NIC. (at http://codev-nic.generic-nic.net/ ) Eric ------- End of Forwarded Message From michele@blacknight.ie Fri Jul 22 11:26:01 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C1321F8AD8 for ; Fri, 22 Jul 2011 11:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjYMhII3nDRC for ; Fri, 22 Jul 2011 11:26:00 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7D21F8A71 for ; Fri, 22 Jul 2011 11:25:59 -0700 (PDT) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.01.0323.000; Fri, 22 Jul 2011 19:25:58 +0100 From: "Michele Neylon :: Blacknight" To: " " Thread-Topic: [provreg] registry software availability Thread-Index: AQHMSJzN5xNFDYvQ7k2id2ojs7iXEQ== Date: Fri, 22 Jul 2011 18:25:57 +0000 Message-ID: References: <201107221548.p6MFmCNB053797@nic-naa.net> In-Reply-To: <201107221548.p6MFmCNB053797@nic-naa.net> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [87.198.196.25] Content-Type: text/plain; charset="us-ascii" Content-ID: <19E27FBD7FFE564F95EE21CC4A2FD19F@blacknight.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [provreg] registry software availability X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 18:26:01 -0000 On 22 Jul 2011, at 16:48, wrote: > Colleagues, >=20 > I'm looking for pointers to licensing terms and conditions for some or > all the components of a registry and registrar system, which uses EPP > as the provisioning protocol. Eric I haven't come across much in the way of "registrar" software for EPP. Ther= e are a few libraries floating around, but I don't recall ever seeing anyth= ing that was an actual "full" solution that you could deploy "out of the bo= x". There are commercial services available from a growing number of compan= ies, but they're pretty much all "hosted" services. Regards Michele Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection ICANN Accredited Registrar http://www.blacknight.com/ http://blog.blacknight.com/ http://blacknight.mobi/ http://mneylon.tel Intl. +353 (0) 59 9183072 US: 213-233-1612=20 UK: 0844 484 9361 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From patrik@frobbit.se Fri Jul 22 23:36:01 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B67721F87FA for ; Fri, 22 Jul 2011 23:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipEAY8AhZCBw for ; Fri, 22 Jul 2011 23:36:00 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 8E75D21F87AF for ; Fri, 22 Jul 2011 23:35:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id EEB6A118B9817; Sat, 23 Jul 2011 08:35:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWX8kLOrtOCJ; Sat, 23 Jul 2011 08:35:52 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 9DE1F118B9814; Sat, 23 Jul 2011 08:35:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Sat, 23 Jul 2011 08:35:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107221548.p6MFmCNB053797@nic-naa.net> To: "Michele Neylon :: Blacknight" X-Mailer: Apple Mail (2.1084) Cc: "" Subject: Re: [provreg] registry software availability X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 06:36:01 -0000 On 22 jul 2011, at 20.25, Michele Neylon :: Blacknight wrote: >> I'm looking for pointers to licensing terms and conditions for some = or >> all the components of a registry and registrar system, which uses EPP >> as the provisioning protocol. >=20 > Eric >=20 > I haven't come across much in the way of "registrar" software for EPP. = There are a few libraries floating around, but I don't recall ever = seeing anything that was an actual "full" solution that you could deploy = "out of the box". There are commercial services available from a growing = number of companies, but they're pretty much all "hosted" services. I do not know of any either, as the registries have so much different = implementations of epp. So if you want to support more than one = registry, you (from my point of view) must do your own hack. Yes, as Michele says, one can of course use one of the existing epp = libraries. I think Net::DRI in perl is one of the ones that is the one = that covers the various epp implementations the best. http://www.dotandco.com/services/software/Net-DRI/ Myself, I did choose to not use Net::DRI, but instead implement from = ground up. No, not open source. But I am very interested in the result of the investigation as I, as you = see, have not seen around what I want to see. Patrik From ebw@nic-naa.net Sat Jul 23 15:07:53 2011 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688E321F8C1C for ; Sat, 23 Jul 2011 15:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgXrtuPgWfhd for ; Sat, 23 Jul 2011 15:07:52 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id BBBD921F8B6C for ; Sat, 23 Jul 2011 15:07:52 -0700 (PDT) Received: from nic-naa.net (localhost [127.0.0.1]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id p6NKAueh036455; Sat, 23 Jul 2011 16:10:56 -0400 (EDT) (envelope-from ebw@nic-naa.net) Message-Id: <201107232010.p6NKAueh036455@nic-naa.net> From: brunner@nic-naa.net To: patrik@frobbit.se, michele@blacknight.ie Date: Sat, 23 Jul 2011 16:10:56 -0400 Sender: ebw@nic-naa.net Cc: provreg@ietf.org Subject: Re: [provreg] registry software availability X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 22:07:53 -0000 Paf, Michele, Thank you both for taking the time to read my note and responding. The point of my queries is to determine what choices are available to one or more hypothetical JAS-Qualified [1] applicants should the (or these) applicant(s) choose to implement one or more Registry Services Platforms (RSPs). This portion of the query covers the implementations of, and licensing terms and conditions, of registry implementations. Related, in part through the "Vertical Integration" (VI) PDP outcome, which I personally view as disasterous, though the US DoJ and EC letters may cure, are the implementations of, and licensing terms and conditions, of registrar implementations. Given the 6 quarters or more before operational deployment in the "Transition to Delegation" phase of ICANN's new gTLD plan of record, and my predilections as a coder, however marginal, the lack of some feature identified in the (untested and still somewhat speculative) ICANN Final Applicant Guidebook is not determinative. The ability of the hypothetical JAS-Qualified applicant(s) to modify one or more source bases to meet their immediate ends -- some several years of operations with no significant additional investment -- is determinative. Similarly, given the opportunity to generate revenues in the existing, and continuous COM/NET/ORG/INFO prior to supporting the as yet undefined business logic and EPP extensions (see prior notes on non-uniqueness) of registries not available for the next 6 quarters of more, the utility is in the openness of a COM and others currently existing client, not in a closed, complete, and dead-end "solution", though these too have a use cases. The motivations are in two part. First, the ICANN BoD voted to allocate $2m to assist JAS-Qualified applicants. This money could be sprinkled as pixie dust on all of them, or it could fund one or more RSPs, with more beneficial side effects [2]. Second, next to zero registrars exist in several ICANN regions, and under both the VI rational, and a regional capacity building rational, this is reasonable to alter, with, or without, new gTLDs, some of which may be JAS-Qualified. This in response to a public comment at Singapore. That's it in a nutshell. Data to me please PROVREG'ers if you want me to know it. Existing vendors that aren't going to be making their source available under useful terms and conditions needn't bother with this. Summary will go to the JAS WG for publication, by one, or more, of the ALAC, GNSO and Board/Staff, or to any query. A related query activity by another JAS WG contributor focuses on the availability of in-kind services, which isn't quite the same question. Eric [1] for the moment let's assume that this term will acquire some degree of rigor in the proximal future. "needy" or "useful" for some definition of "need" or "use" are gestures towards that end.