http://blog.gmane.org/gmane.ietf.provreg hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.provreg/2967 <pre>In the case of a registry operator who operates multiple TLDs in a single database, are the escrow deposit files intended to be per-TLD? Or per-registry operator? My suspicion is that it should be the latter. The entire reason for the escrow deposit to exist is to transition to an EBERO in the event that a registry operator is unable to perform its duties. That could happen on a per-TLD basis, but it would be a lot more efficient to do it for *all* TLDs that are managed by that registry operator. So if that is the case, what are we to make of the escrow deposit file naming convention? Files will be named according to the following convention: If there is a single escrow file with multiple TLDs embedded in it, what would you use for "{gTLD}"? Is the assumption that all TLDs will be stored in totally separate databases? Or that they should be written to separate files, even if stored in the same database? That would mean that shared objects (e.g. contacts, hosts, etc.) would have to be written multiple </pre> Seth Goldman 2013-06-18T20:42:13 http://comments.gmane.org/gmane.ietf.provreg/2967 <pre>In the case of a registry operator who operates multiple TLDs in a single database, are the escrow deposit files intended to be per-TLD? Or per-registry operator? My suspicion is that it should be the latter. The entire reason for the escrow deposit to exist is to transition to an EBERO in the event that a registry operator is unable to perform its duties. That could happen on a per-TLD basis, but it would be a lot more efficient to do it for *all* TLDs that are managed by that registry operator. So if that is the case, what are we to make of the escrow deposit file naming convention? Files will be named according to the following convention: If there is a single escrow file with multiple TLDs embedded in it, what would you use for "{gTLD}"? Is the assumption that all TLDs will be stored in totally separate databases? Or that they should be written to separate files, even if stored in the same database? That would mean that shared objects (e.g. contacts, hosts, etc.) would have to be written multiple </pre> Seth Goldman 2013-06-18T20:42:13 http://comments.gmane.org/gmane.ietf.provreg/2961 <pre>Hello! I'm new to EPP, and am currently working on an implementation. While implementing the check and info commands against the Verisign OT&amp;E server, I discovered that they require the namestoreExt-1.1 extension to be implemented, which basically means adding something like this to each command frame: &lt;extension&gt; &lt;namestoreExt:namestoreExt xmlns:namestoreExt="http://www.verisign-grs.com/epp/namestoreExt-1.1"&gt; &lt;namestoreExt:subProduct&gt;dotCOM&lt;/namestoreExt:subProduct&gt; &lt;/namestoreExt:namestoreExt&gt; &lt;/extension&gt; However, the docs (http://www.verisigninc.com/assets/namestore-extension.pdf) do not mention the purpose of this block, or the valid values. I've guessed from using Verisign's epptool (https://epptool-ctld.verisign-grs.com/epptool/) that the valid values are 'dotCOM', 'dotNET', and 'dotEDU', though I get an authorization error when using 'dotEDU'. However, I'm still confused as to the correct usage. For example, the check command allows you to specify multiple domain names in</pre> Ofer Nave 2013-06-14T16:10:56 http://comments.gmane.org/gmane.ietf.provreg/2958 <pre>Hi Everybody, We've run into a condition during development and are seeking feedback/guidance from the group. This case is specific to First Come, First Served Sunrises, and the delete/update commands. When we read this in the spec: 2.2. Launch Phases The server MAY support multiple launch phases sequentially or simultaneously. The &lt;launch:phase&gt; element MUST be included by the client to define the target launch phase of the command. We interpreted that to mean that the launch:phase was mandatory, and would come in with each command in the extension. Currently, the XSD for the delete/update commands do not support the application id being optional. And of course, for a FCFS registration, the application id is not needed/used. &lt;element name="update" type="launch:idContainerType"/&gt; &lt;element name="delete" type="launch:idContainerType"/&gt; &lt;!-- Common container of id (identifier) element --&gt; &lt;complexType name="idContainerType"&gt; &lt;sequence&gt; </pre> Wodjenski, Sharon 2013-06-03T18:05:21 http://comments.gmane.org/gmane.ietf.provreg/2957 <pre>Verisign has released the fourth release of a preview version of the Launch EPP SDK, named Launch EPP SDK 2.2.0.0. This SDK fully implements draft-tan-epp-launchphase-11 ( http://tools.ietf.org/html/draft-tan-epp-launchphase-11 ) and draft-lozano-tmch-smd-02 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-02 ), referred to simply as 11/02, and includes the following features that can be of use to multiple stakeholders: 1. Packet encoder / decoder (CODEC) that will encode the XML from objects and decode the objects from XML. 2. Creation and validation code for signed marks (SMD) using an XML signed mark or a base64 encoded signed mark that complies with draft-lozano-tmch-smd-02. 3. Use of a test CA issued certificate that is included in the signed mark or base64 encoded signed mark that is chained to the test CA certificate by the EPP Stub Server. A test certificate in a test Certificate Revocation List (CRL) is also validated by the EPP Stub Server. 4. Sample of poll messaging compliant wi</pre> Gould, James 2013-05-31T20:34:43 http://comments.gmane.org/gmane.ietf.provreg/2953 <pre>All, looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft currently doesn't seem to restrict the set of XML Signature parameters to be used. The signature and normalization algorithm examples look surprisingly similar to RFC5105 (written by my colleague Otmar Lendl back in 2006/2007). During his journey to implement the signature technoloy in our ENUM registry software, he found out that some options in XML DSIG (particularly the normalization options) are rather cumbersome and error-prone (AFAIR whitespace changes created by the validating XML parser triggering validation errors, etc.). Based on this practical experience, he restricted the parameter range for XML DSIG in http://tools.ietf.org/html/rfc5105#section-3 of RFC5105, in order to increase interopability. The concept described in RFC5105 has since been validated in implementations of a few ENUM registry installations (servers), as well as their ENUM registrars (clients). Since SMD essentially uses the same technology, i'm </pre> Alexander Mayrhofer 2013-05-27T14:39:53 http://comments.gmane.org/gmane.ietf.provreg/2952 <pre>Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 11. You can find the draft at the URL http://tools.ietf.org/html/draft-tan-epp-launchphase-11. This version includes the following change: 1. Moved the claims check response &lt;launch:chkData&gt; element under the &lt;extension&gt; element instead of the &lt;resData&gt; element based on the request from Francisco Obispo. Thanks, JG James F. Gould Verisign "This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately."</pre> Gould, James 2013-05-17T19:40:44 http://comments.gmane.org/gmane.ietf.provreg/2951 <pre>Colleagues, This is to let you know that we are launching a public, open mailing list for technical discussions regarding gTLD registries and registrars. The intention is to provide a forum for discussion of issues that may appear during ongoing operation and particularly with the upcoming launch of new gTLDs. You can subscribe to the list at: https://mm.icann.org/mailman/listinfo/gtld-tech Regards, </pre> Francisco Arias 2013-05-16T23:29:40 http://comments.gmane.org/gmane.ietf.provreg/2949 <pre>Jim, You have long been a proponent for having clients provide "claims" and "landrush" in the phase element (to my disagreement). Since you require clients specify both, how would you represent a "custom" phase that requires claims processing given the "name" attribute cannot be used to specify the sub-phase? My preference is to remove "claims" as a phase as it provides _zero_ value to the protocol, and retire the need to provide sub-phase information during claims. Claims information may be provided with other phases (landrush, open) without explicitly providing a "claims" phase value, and servers have to code for missing claims information regardless (e.g. It is possible to provide "sunrise" with claims information, and "claims" with mark information). I also dislike the use of the term "custom" - registries will operate sunrises differently; those different sunrises are by definition custom. IMO the schema-level restriction on phase values provides no value to the protocol itself. I would like to see </pre> James Mitchell 2013-05-16T05:23:05 http://comments.gmane.org/gmane.ietf.provreg/2944 <pre>How are we going to pursue standardization of the Launchphase and IDN drafts? I'm in the process of registering the namespace for the IDN extension, but I'm thinking about how to make sure it all stays "current" after the draft expires. Can someone explain what is the process? Francisco Obispo Director of Applications and Services - ISC email: fobispo&lt; at &gt;isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE _______________________________________________ provreg mailing list provreg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/provreg </pre> Francisco Obispo 2013-05-11T15:44:34 http://comments.gmane.org/gmane.ietf.provreg/2942 <pre>We're currently implementing the launchphase extentension. In my opinion the Claims Check system should use the &lt;extension&gt; section and not the &lt;resData&gt; The reason for my reasoning has to do with RFC5730 and: 2.9.2.1. EPP &lt;check&gt; Command The EPP &lt;check&gt; command is used to determine if an object can be provisioned within a repository. It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the &lt;create&gt; command as object-provisioning requirements are ultimately a matter of server policy. Referring to "Objects", however launch-1.0 is an extension, or at least is handled in EPP like one, so my belief is that the response should go into the &lt;extension&gt; section: S:&lt;?xml version="1.0" encoding="UTF-8" standalone="no"?&gt; S:&lt;epp xmlns="urn:ietf:params:xml:ns:epp-1.0"&gt; S: &lt;response&gt; S: &lt;result code="1000"&gt; S: &lt;msg&gt;Command completed successfully&lt;/msg&gt; S: &lt;/result&gt; S: &lt;resData&gt; S: &lt;launch:chkData S:</pre> Francisco Obispo 2013-05-10T05:07:25 http://comments.gmane.org/gmane.ietf.provreg/2940 <pre>Verisign has released the third release of a preview version of the Launch EPP SDK, named Launch EPP SDK 2.1.0.0. This SDK fully implements draft-tan-epp-launchphase-10 ( http://tools.ietf.org/html/draft-tan-epp-launchphase-10 ) and draft-lozano-tmch-smd-02 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-02 ), referred to simply as 10/02, and includes the following features that can be of use to multiple stakeholders: 1. Packet encoder / decoder (CODEC) that will encode the XML from objects and decode the objects from XML. 2. Creation and validation code for signed marks (SMD) using an XML signed mark or a base64 encoded signed mark that complies with draft-lozano-tmch-smd-02. 3. Use of a test CA issued certificate that is included in the signed mark or base64 encoded signed mark that is chained to the test CA certificate by the EPP Stub Server. A test certificate in a test Certificate Revocation List (CRL) is also validated by the EPP Stub Server. 4. Sample of poll messaging compliant wit</pre> Gould, James 2013-05-08T14:43:51 http://comments.gmane.org/gmane.ietf.provreg/2930 <pre>All, Please share your thoughts regarding the implementation of the Contact AuthInfo for the approval of initiated contact updates. Our current process looks to have the registrant provide the code as an indication of approval regarding the update of their information, completing the update instantly. Updates that are not provided with the code will not execute. Further to this, we are looking to implement the Domain AuthInfo code as a definite measure for approving registrant changes to a linked domain. In this instance the current registrant must provide the Domain AuthInfo code as approval of the registrant change. Regards, Vlad Dinculescu -------------------------------- Domain Name Services _______________________________________________ provreg mailing list provreg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/provreg </pre> Vlad Dinculescu 2013-05-07T06:23:37 http://comments.gmane.org/gmane.ietf.provreg/2924 <pre>Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 10. You can find the draft at the URL http://tools.ietf.org/html/draft-tan-epp-launchphase-10. This version includes the following changes: 1. Changed noticeIDType from base64Binary to token to be compatible with draft-lozano-tmch-func-spec-05&lt;http://tools.ietf.org/html/draft-lozano-tmch-func-spec-05&gt;. 2. Changed codeType from base64Binary to token to be more generic. 3. Updated based on feedback from Alexander Mayrhofer, which include: 1. Changed "extension to the domain name extension" to "extension to the domain name mapping". 2. Changed use of 2004 return code to 2306 return code when phase passed mismatches active phase and sub-phase. 3. Changed description of "allocated" and "rejected" statuses. 4. Moved sentence on a synchronous &lt;domain:create&gt; command without the use of an intermediate application, then an </pre> Gould, James 2013-05-01T12:32:56 http://comments.gmane.org/gmane.ietf.provreg/2920 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:27:16 http://comments.gmane.org/gmane.ietf.provreg/2913 <pre>Hi, i've reviewed draft-lozano-tmch-func-spec, here are my comments: - Abstract: The text contains "Domain Name Registry" as well as "domain name Registry" - is this intentional? - Introduction: Why is "Data Formats" capitalized? - 5.2.1 / 5.2.2 (Sunrise domain registration): I understand that "registration" in the sense of executing a sunrise "create" command could either be direct "Allocation", or the creation of an "Application". Some text that clarifies these options would be good, because "registration" could be mis-interpreted as "direct, immediate allocation". - page 27 (5.2.3): Theres a broken literal "xref" in bullet 4. - 6.1 (DNL List): I understand that the DNL is always a "full" list, containing all DNLs that match a PRM? Clarifying text would be appreciated here. - 6.2 (SMD revocation): I do assume it would always include all revoked SMDs. Also "Version 1 MUST always be present" could maybe be changed to "MUST be set to '1' for this version of the specification".. Same in Section 6.3 a</pre> Alexander Mayrhofer 2013-04-23T11:54:33 http://comments.gmane.org/gmane.ietf.provreg/2912 <pre>Hi, i've done a more thorough review of the current version of the launchphase documents. Generally, i think the draft is pretty mature, and that the document could proceed to publication, i haven't found any *really* major issues that would prevent implementation - thanks for the great work so far. The few issues that i found are listed below (disclaimer: Some of them might have been discussed in past conf calls or mailing list discussions that i have missed - if that is the case, please disregard them). I also haven't looked at the schema definition itself, but i assume that would be done during a final NITS review. Here we go: - Introduction: The last paragraph says "extension to the domain name extension" - i suppose that should read "extension to the domain name mapping". - Section 2.2: I think that 2004 is an inappropriate response code for this case, since the value might not be "outside the range of values specified by the protocol" - it actually *is* a valid value, just not appropriate at that</pre> Alexander Mayrhofer 2013-04-22T20:45:47 http://comments.gmane.org/gmane.ietf.provreg/2908 <pre>Wil Tan, Gavin Brown and I have updated the Launch Phase EPP Extension Mapping to Version 09. You can find the draft at the URL http://tools.ietf.org/html/draft-tan-epp-launchphase-09. This version includes the following changes: 1. Made &lt;choice&gt; element optional in &lt;launch:create&gt; to allow passing just the &lt;launch:phase&gt; in &lt;launch:create&gt; per request from Ben Levac. 2. Added optional "type" attribute in &lt;launch:create&gt; to enable the client to explicitly define the desired type of object (application or registration) to create to all forms of the create extension. 3. Added text that the server SHOULD validate the &lt;launch:phase&gt; element in the Launch Phases section. 4. Add the "General Create Form" to the create command extension to support the request from Ben Levac. 5. Updated the text for the Poll Messaging section based on feedback from Klaus Malorny. 6. Replaced the "claims1" and "claims2" phases with th</pre> Gould, James 2013-04-17T12:48:08 http://comments.gmane.org/gmane.ietf.provreg/2899 <pre>Jim et al, The check command text should be updated to allow for checking availability of names available to a particular phase. One example is the phased-launch of an IDN table post general registration, where registrars can provide a phase, e.g. ZH-release, and the list of names they require availability for. The registrar would feed this information back to the registrant prior to their selection of names for submission in create commands. This should not require any change to the schema. I can provide text if required. Regards, James _______________________________________________ provreg mailing list provreg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/provreg </pre> James Mitchell 2013-04-09T15:28:15 http://comments.gmane.org/gmane.ietf.provreg/2898 <pre>Jim et al, It is my opinion that claims and name availability information should be available in one command/response. Registrars may want to know claims information at the time of availability (register a new domain search page) to 1) indicate a different price if claims is present or 2) indicate the name is subject to claims acknowledgement/extra processing, or 3) withhold the name from their name spinner because they have chosen not support claims. I suggest the claims check command be extended to include an "standalone" attribute with boolean value true indicating availability information is not required, and false indicating that availability information is desired in addition to claims. Servers may choose to support only standalone=true, servers that support standalone=false must support standalone=true. I'm not too keen on the "standalone" name, so please make other suggestions. I can contribute text if required. Regards, James _______________________________________________ provreg mailing list p</pre> James Mitchell 2013-04-09T15:16:14 http://comments.gmane.org/gmane.ietf.provreg/2889 <pre>We are currently working on the draft-tan-epp-launchphase-09 updates and wanted to know what the list felt about replacing the "claims1" and "claims2" phases with simply the "claims" phase. The split of "claims" to "claims1" and "claims2" occurred after the LA meeting in the 04 draft. Since draft-lozano-tmch-func-spec doesn't reference claims2, it doesn't seem to make sense to continue to reference it within draft-tan-epp-launchphase and recombine "claims1" and "claims2" into "claims". Please post your thoughts to the list or privately on this potential change. Thanks, -- JG [cid:E9E1A0E2-F675-4A16-8884-13946BB85239] James Gould Principal Software Engineer jgould&lt; at &gt;verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com "This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable </pre> Gould, James 2013-04-08T19:28:52 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.provreg