From fobispo@isc.org Mon Apr 1 17:37:28 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45F921F8F35 for ; Mon, 1 Apr 2013 17:37:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sjchGdnDHP4 for ; Mon, 1 Apr 2013 17:37:28 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id BE1EA21F844F for ; Mon, 1 Apr 2013 17:37:27 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id A612D5F997C; Tue, 2 Apr 2013 00:37:16 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1364863047; bh=HA5usEXfDYkP2D5bRgLMsPkXAZxJH3SnWO67/X0IqZc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ePC9VibxcCF/I+ao+MS140M+hWdOqUfziQvHU0RyujoC1TpKDP8ul8NnkXctAp08t mCiT9Rt0PXD760G4i0UFNzOV8ZhRJDIjlNC1p/f5Cka7c+DZTQF9u8nfH41xa6l7vB wC/4X9FEoj4gImaWh1WesPEiAD7tZdI8+ieEGJ6I= Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1604F216C47; Tue, 2 Apr 2013 00:37:15 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: <19F54F2956911544A32543B8A9BDE0750982F68A@NICS-EXCH.sbg.nic.at> Date: Mon, 1 Apr 2013 17:37:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A677006-518B-467A-B3C9-62481094A084@isc.org> References: <19F54F2956911544A32543B8A9BDE0750982F68A@NICS-EXCH.sbg.nic.at> To: Alexander Mayrhofer X-Mailer: Apple Mail (2.1503) Cc: Mark Hofstetter , "ire@ietf.org" Subject: Re: [ire] "resend" attribute in "deposit" element. X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 00:37:28 -0000 Hi Alexander, Well, if we have a detached signature that can be used to verify the = integrity of the file, why do we neep to record the 'retries'? I support the idea of removing the 'resend' attribute from the deposit, = and in fact, I would go further and remove it from the file name as = well. Francisco On Mar 29, 2013, at 7:27 AM, Alexander Mayrhofer = wrote: > Hi, >=20 > We're in the late stages of implementing our escrow export script, and = have discussed internally the purpose of the "resend" attribute in the = "deposit" element itself.=20 >=20 > Reading through the definition, this attribute is not related to the = *creation* of the escrow deposit, but rather to its *transport* (Our = understanding is that the id attribute is more related to the creation = of the file).=20 >=20 > More specifically, we don't see a reason why the "resend" attribute = should actually be contained in the file itself, because failure to = "send" the file to the Escrow provider is completely unrelated to the = contents of the file.=20 >=20 > If a transport attempt fails, a registry should simply be able to = rename the (successfully created, validated) escrow file, and just retry = the *transport*, rather than the *creation*. However, since the "resend" = attribute is included in the (compressed/encrypted/signed) file itself = (in addition to the file name!), a failed *transport* attempt (eg. a = interrupted upload) requires registries to essentially restart the = generation: modify the original escrow dump, and repeat the whole = split/compress/encrypt/sign steps.=20 >=20 > We hence believe that the "resend" attribute should be removed from = the definition of the "deposit" element. It is not only redundant (since = it's also included in the file name itself), but its inclusion in the = escrow content itself is actually misleading, and puts extra burden on = the escrow process. *If* ICANN's intent with the "resend" attribute was = to reflect whether a file has been re-*generated* (and not just = re-*sent*), we propose to change the current structure as follows: >=20 > - Keep the "resend" part of the file names, and provide clear = instructions that this number is to be increased when *transport* of the = deposit failed, and is repeated with the identical file contents = (retransmission). > - Remove the "resend" attribute from the "deposit" element. > - (Optionally) add a "revision" attribute to the "deposit" element, = and provide clear instructions that the number contained in that = attribute is to be increased when the *creation* of a deposit with an = identical "id" is performed (re-generation). >=20 > Feedback appreciated >=20 > Alex >=20 >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From james.mitchell@ausregistry.com.au Tue Apr 2 08:05:24 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8E721F8AB2 for ; Tue, 2 Apr 2013 08:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeMTxMxgfTFd for ; Tue, 2 Apr 2013 08:05:23 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDD621F86B1 for ; Tue, 2 Apr 2013 08:05:23 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 03 Apr 2013 02:05:22 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 3 Apr 2013 02:05:17 +1100 From: James Mitchell To: Gustavo Lozano , David Kipling , "ire@ietf.org" Date: Wed, 3 Apr 2013 02:05:17 +1100 Thread-Topic: [ire] Extended Verification Process - FQDN step Thread-Index: Ac4vs3txWmWQ5IkyRdeqomCCLE45bQ== Message-ID: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] Extended Verification Process - FQDN step X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 15:05:24 -0000 Registries may have a reserved list that contains wild-card characters, e.g. *profanity* (read: contains the term "profanity"). Assuming entries to be domain names will either result in validation failures, or registries will not escrow their reserved lists. Regardless, I do not understand why I would escrow the reserved list mandated by ICANN, or the reserved list at all for that matter. I thought the purpose of escrow was to make sure that we don't lose registration data (domains, hosts, contacts) and that a registry can be reconstituted quickly - to an EBERO that cannot accept registrations and thus has no need for a reserved names list. Regards, James On 27/03/13 12:17 PM, "Gustavo Lozano" wrote: >Hi David, > >Comments inline. > >Regards, >Gustavo > >On 3/22/13 5:34 AM, "David Kipling" wrote: > >>Hi Gustavo, >> >>At NCC Group we are working on the extended verification process and >>after speaking with some of our customers and registry backend providers >>it was unclear as to how the step below could be tested effectively: >> >>"An FQDN exists only as a domain name or NNDN." >> >>Is this literally that any values in the name element of the domain >>record should not exist as the value of the aName element of an NNDN >>record? >> >>e.g. >> >>example1.test means the value of example1.test >>should not exist as a value of the tag e.g. >>rdeNNDN:aName>example1.test and vice versa so if the >>element xn--exampl-gva.test exists then >>xn--exampl-gva.test should not exist in the >>deposit. > >You are correct. > >=20 >The NNDN object was created to support those registries that >use a reserved list of names that are not created as domain objects and >also to >support the use case of using a name (but not a domain object) to specify >granular policies regarding IDN variants handling. > >=20 >If a registry creates reserved names as domain objects with >an internal registrar for example, such registry may only use domain >objects. > >If a registry handle reserved names as a list of names, such >registry may use the NNDN object. > >If a registry creates variants in blocked or withheld >state, such registry may use the NNDN object instead of a creating a >domain >object. > >If a registry creates mirror variants algorithmically, such registry may >use >the NNDN to block variants that are not valid. >=20 > >The registry must choose if the use of a NNDN is appropriate >based on the design of its SRS. Basically a NNDN is like a light domain >object >with no registrar, registrant or NS servers associated to it. > > >Regards, >Gustavo > >> >>Regards >> >>David >>________________________________ >> >>David Kipling >>Solutions Architect >>NCC Group >>Manchester Technology Centre, >>Oxford Road >>Manchester, M1 7EF >> >>Telephone: +44 161 209 5430 >>Mobile: >>Fax: >>Website: www.nccgroup.com >>Email: David.Kipling@nccgroup.com >> [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] >> >>________________________________ >> >>This email is sent for and on behalf of NCC Group. NCC Group is the >>trading name of NCC Services Limited (Registered in England CRN: >>2802141). Registered Office: Manchester Technology Centre, Oxford Road, >>Manchester, M1 7EF. The ultimate holding company is NCC Group plc >>(Registered in England CRN: 4627044). >> >>Confidentiality: This e-mail contains proprietary information, some or >>all of which may be confidential and/or legally privileged. It is for the >>intended recipient only. If an addressing or transmission error has >>misdirected this e-mail, please notify the author by replying to this >>e-mail and then delete the original. If you are not the intended >>recipient you may not use, disclose, distribute, copy, print or rely on >>any information contained in this e-mail. You must not inform any other >>person other than NCC Group or the sender of its existence. >> >>For more information about NCC Group please visit >>www.nccgroup.com >> >>P Before you print think about the ENVIRONMENT >> >> >>For more information please visit >href=3D"http://www.mimecast.com">http://www.mimecast.com
>>This email message has been delivered safely and archived online by >>Mimecast. >> >> > >_______________________________________________ >ire mailing list >ire@ietf.org >https://www.ietf.org/mailman/listinfo/ire From gustavo.lozano@icann.org Thu Apr 4 12:19:35 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C90921F8D41 for ; Thu, 4 Apr 2013 12:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+SaA5Ug8HPi for ; Thu, 4 Apr 2013 12:19:34 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 029EA21F8D0D for ; Thu, 4 Apr 2013 12:19:34 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 4 Apr 2013 12:19:33 -0700 From: Gustavo Lozano To: "ire@ietf.org" Date: Thu, 4 Apr 2013 12:19:30 -0700 Thread-Topic: New versions of data escrow drafts Thread-Index: Ac4xaVZWs1jRwxxBTF2pKS1h4rpYDQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD832052F908gustavolozanoicannorg_" MIME-Version: 1.0 Subject: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 19:19:35 -0000 --_000_CD832052F908gustavolozanoicannorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Colleagues, New versions of the registry-data-escrow and dndrd-objects-mapping drafts h= ave been published to incorporate suggestions received in this list and by = private messages: http://www.ietf.org/internet-drafts/draft-arias-noguchi-registry-data-escro= w-06.txt http://www.ietf.org/internet-drafts/draft-arias-noguchi-dnrd-objects-mappin= g-03.txt As the merge of the CSV draft (dnrd-csv-mapping) with dndrd-object-mapping = continues, this minor updates of registry-data-escrow and dndrd-objects-ma= pping drafts should clarify some questions and incorporate suggestions rece= ived by private messages and in this list from registry operators and data = escrow agents. Main changes are as follows. draft-arias-noguchi-registry-data-escrow-06: * The resend attribute is now only used when the escrow deposit must be re-= generated by the registry operator because the escrow verification procedur= e failed at the receiving party. draft-arias-noguchi-dnrd-objects-mapping-03: * The resend attribute of the element is now an element ()= and contains the same value as the resend attribute. * Data Escrow Agents must send a notification by each successfully received= deposit regardless of the result of the verification process. * Added XPath attribute to policy object. * Removed optional from XML schemas since the escrow of that ele= ment is not required to be escrowed based on the suggestions received in th= e list. ----- * I have received questions regarding how the data escrow agent notifies IC= ANN the status of escrow deposits, as required in the base agreement of new= gTLDs. In the following link http://tools.ietf.org/html/draft-lozano-icann= -registry-interfaces-00, you will find the specification of the web service= s we are implementing for such purpose. This draft will be discussed in ano= ther forum. * I have received questions regarding data escrow extensions and new gTLDs.= The base agreement, Specification 2, 3.2 defines: " If a Registry Operator= offers additional Registry Services that require submission of additional = data, not included above, additional =93extension schemas=94 shall be defin= ed in a case by case base to represent that data. ... ICANN and the respect= ive Registry shall work together to agree on such new objects=92 data escro= w specifications.". In other words, we are going to validate/approve the da= ta escrow extensions in case of Registry Operators that offer additional Re= gistry Services. If no additional registry services are offered, the data escrow agent uses = this specification; if additional registry services are offered, the data e= scrow agent uses the extensions validated/approved by ICANN. ----- * I have received questions regarding the process for encrypting the escrow= deposits as required in the base agreement of new gTLDs. I attempt to prov= ide answers as follows: With the incorporation of CSV as an option for doing registry escrow, there= is the possibility of an escrow deposit being an XML file plus potentially= several CSV data files. Regardless of doing escrow XML only or with CSV, t= here is always a XML file generated as described in the registry-data-escro= w draft. This XML file is named following the procedure described in specification 2= of the applicant guidebook. The XML file and potentially the CSV files are= always aggregated in a tarball file. For example: gustavolozano$ ls -lh example_2009-08-02_full_S1_R0.xml 15M example_2009-08-02_full_S1_R0.xml gustavolozano$ tar -tvf example_2009-08-02_full_S1_R0.tar example_2009-08-02_full_S1_R0.xml The tarball is encrypted and optionally compressed by an OpenPGP utility th= at conforms to RFC4880: gustavolozano$ gpg --recipient dataescrowagent --output example_2009-08-02_= full_S1_R0.ryde --encrypt example_2009-08-02_full_S1_R0.tar gustavolozano$ ls -lh example_2009-08-02_full_S1_R0.ryde 16K example_2009-08-02_full_S1_R0.ryde A signature file for the .ryde file is generated: gustavolozano$ gpg --output example_2009-08-02_full_S1_R0.sig --detach-sig = example_2009-08-02_full_S1_R0.ryde The registry operator would then send the .ryde and .sig file to the data e= scrow agent. Questions are suggestions are welcome. Regards, Gustavo --_000_CD832052F908gustavolozanoicannorg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Colleagues,

 

New versions of the registry-data-escrow and dndrd-objects-mapping drafts have been published to incorporate suggestions received in this list and by private messages:

http://www.ietf.org/internet-drafts/draft-arias-nog= uchi-registry-data-escrow-06.txt

<= a href=3D"http://www.ietf.org/internet-drafts/draft-arias-noguchi-dnrd-obje= cts-mapping-03.txt">http://www.ietf.org/internet-drafts/draft-arias-noguchi= -dnrd-objects-mapping-03.txt

 = ;

As the merge of the CSV draft (dnrd-csv-mapping) wit= h dndrd-object-mapping continues, this minor updates of  registry-data-e= scrow and dndrd-objects-mapping drafts should clarify some questions and incorporate suggestions received by private messages and in this list from registry operators and data escrow agents.

 

Main changes are as follows.

 

draft-arias-noguchi-registry-data-escrow-06:

 

* The resend attribute is now only used when the esc= row deposit must be re-generated by the registry operator because the escrow verification procedure failed at the receiving party.

 

draft-arias-noguchi-dnrd-objects-mapping-03:

 

* The resend attribute of the <report> element is now an element (<resend>) and contains the same = value as the <rde:deposit> resend attribute.

&nb= sp;

* D= ata Escrow Agents must send a notification by each successfully received deposit regardless of the result of the verification process.

&nb= sp;

* A= dded XPath attribute to policy object.

&nb= sp;

* R= emoved optional <authinfo> from XML schemas since the escrow of that element= is not required to be escrowed based on the suggestions received in the list.

-----

 

* I have received questions regarding how the data escrow agent notifies ICANN = the status of escrow deposits, as required in the base agreement of new gTLDs. = In the following link http://tools.ietf.org/html/draft-lozano-icann-registry-i= nterfaces-00, you will find the specification of the web services we are im= plementing for such purpose. This draft will be discussed in another forum.

&nb= sp;

* I have received questions regarding data escrow extensions and new gTLDs. The base agreement, Specification 2, 3.2 defines: " If a Registry Operator offers additional Registry Services that require submission of additional d= ata, not included above, additional =93extension schemas=94 shall be defined in = a case by case base to represent that data. ... ICANN and the respective Registry shall work together to agree on such new objects=92 data escrow specifications.". In other words, we are going to validate/approve the data escrow extensions in case of Registry Operators that offer additional Registry Services.

If no additional registry services are offered, the data escrow agent uses thi= s specification; if additional registry services are offered, the data escrow agent uses the extensions validated/approved by ICANN.


-----


* I have received questions regarding the process for encrypting the escrow deposits as required in the base agreement of new gTLDs. I attempt to provi= de answers as follows:

&nb= sp;

Wit= h the incorporation of CSV as an option for doing registry escrow, there is t= he possibility of an escrow deposit being an XML file plus potentially several= CSV data files. Regardless of doing escrow XML only or with CSV, there is alway= s a XML file generated as described in the registry-data-escrow draft.

&nb= sp;

Thi= s XML file is named following the procedure described in specification 2 of t= he applicant guidebook. The XML file and potentially the CSV files are always aggregated in a tarball file. For example:

&nb= sp;

gus= tavolozano$ ls -lh example_2009-08-02_full_S1_R0.xml

15M example_2009-08-02_full_S1_R0.xml

&nb= sp;

gustavolozano$ tar -tvf example_2009-08-02_full_S1_R= 0.tar

example_2009-08-02_full_S1_R0.xml

 

The tarball is encrypted and optionally compressed b= y an OpenPGP utility that conforms to RFC4880:

 

gustavolozano$ gpg --recipient dataescrowagent --out= put example_2009-08-02_full_S1_R0.ryde --encrypt example_2009-08-02_full_S1_R0.= tar

 

gustavolozano$ ls -lh example_2009-08-02_full_S1_R0.= ryde

16K example_2009-08-02_full_S1_R0.ryde

 

A signature file for the .ryde file is generated:

 

gustavolozano$ gpg --output example_2009-08-02_full_S1_R0.sig --detach-sig example_2009-08-02_full_S1_R0.ryde

 

The registry operator would then send the .ryde and = .sig file to the data escrow agent.

 

Questions are suggestions are welcome.

 

Regards,

Gustavo

--_000_CD832052F908gustavolozanoicannorg_-- From fobispo@isc.org Thu Apr 4 13:33:55 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5689221F8BA6 for ; Thu, 4 Apr 2013 13:33:55 -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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmxT6m0Z-rbW for ; Thu, 4 Apr 2013 13:33:54 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CE1E521F8B98 for ; Thu, 4 Apr 2013 13:33:54 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 4B2EEC94DE; Thu, 4 Apr 2013 20:33:49 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1365107634; bh=bLmACkx5Y9QYmpldipKrHiYI9GUoryVKTZH2LkdkIJI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=S+wUoWmBmIF+IrrggWa7PsV0VC7/ec+RdwCWPaTzWFlOt8zX2E0+P0xwRnNqTlTeY a0/pBzeJydJ/DknLFzm+QulvFoCPp7M0wYizvzyEDTdlGKhg6uNPYWS6s5YILhgy6O Q8ege6f3YpD7duG8QcZHtT7gP49wgWli06Lm2gL4= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Thu, 4 Apr 2013 20:33:49 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [IPv6:2001:4f8:3:64:744c:6cae:7881:3c84] (unknown [IPv6:2001:4f8:3:64:744c:6cae:7881:3c84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 3F7DB216C43; Thu, 4 Apr 2013 20:33:49 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: Date: Thu, 4 Apr 2013 13:33:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <612A863C-536F-4B1D-BB02-6727E1A9D517@isc.org> References: To: Gustavo Lozano X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 20:33:55 -0000 Why do you want to put it in a tarball? GPG will encrypt+compress the data, leaving you with a .ryde file that = already meets the criteria: Example: -rw-r--r-- 1 fobispo fobispo 490 Mar 21 05:05 = FOO_2013-03-20_full_S1_R0.asc -rw-r--r-- 1 fobispo fobispo 3050 Mar 21 05:03 = FOO_2013-03-20_full_S1_R0.ryde -rw-r--r-- 1 fobispo fobispo 13379 Mar 20 01:21 = FOO_2013-03-20_full_S1_R0.xml Now, we could have a tarball with the .ryde and the .asc files to avoid = transferring the two files, or, we could encrypt+sign+compress the same = file, thus combining the signature with the content. Francisco On Apr 4, 2013, at 12:19 PM, Gustavo Lozano = wrote: > gustavolozano$ ls -lh example_2009-08-02_full_S1_R0.xml > 15M example_2009-08-02_full_S1_R0.xml > =20 > gustavolozano$ tar -tvf example_2009-08-02_full_S1_R0.tar > example_2009-08-02_full_S1_R0.xml > =20 > The tarball is encrypted and optionally compressed by an OpenPGP = utility that conforms to RFC4880: > =20 > gustavolozano$ gpg --recipient dataescrowagent --output = example_2009-08-02_full_S1_R0.ryde --encrypt = example_2009-08-02_full_S1_R0.tar > =20 > gustavolozano$ ls -lh example_2009-08-02_full_S1_R0.ryde > 16K example_2009-08-02_full_S1_R0.ryde > =20 > A signature file for the .ryde file is generated: > =20 > gustavolozano$ gpg --output example_2009-08-02_full_S1_R0.sig = --detach-sig example_2009-08-02_full_S1_R0.ryde > =20 Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From cbbrowne@afilias.info Thu Apr 4 14:10:34 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1945021F8ED4 for ; Thu, 4 Apr 2013 14:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHZPDnWFaHUu for ; Thu, 4 Apr 2013 14:10:33 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 613DC21F8BEA for ; Thu, 4 Apr 2013 14:10:33 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UNrQW-0008QS-5N for ire@ietf.org; Thu, 04 Apr 2013 21:10:32 +0000 Received: from mail-la0-f70.google.com ([209.85.215.70]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UNrQW-0003A2-4p for ire@ietf.org; Thu, 04 Apr 2013 21:10:32 +0000 Received: by mail-la0-f70.google.com with SMTP id eb20so4513802lab.1 for ; Thu, 04 Apr 2013 14:10:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GEtAOpnD5k3jAY4CfGPJH11dst5++FLzbL3+xZkGXqg=; b=l3sVOyiKKhPuSPsfd4FRIjVba4is9OspIJ192CYNB3dWbuab4EXNVQYHJO7iGjcu4B SZqqhCaRNM38ITxO+OvjQQDA6TsPiGevAynFNFl519KfMPaYTqLibwrdUk+xm26tszq7 ZbOGSbNUC+Gu7AdJcm8I0BG15m3HkLM0qcbLf/O7C7P3ZCKqtkGlucoZzgyAAicCxKfh YJoZMB32zEbE7rCOG+byxYs3Yqsao7znGPOQs20XZGETQgdxTdcW6divYXtJxWINDALq 5/0kOL+WVIUgGqGYyYcl+nYsRLZGtFbqKLibCq4LPEBMwQdyB9jeYc6Vsa2rjC8UnK+F u5Ew== X-Received: by 10.194.57.137 with SMTP id i9mr11856049wjq.18.1365109826046; Thu, 04 Apr 2013 14:10:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.57.137 with SMTP id i9mr11856040wjq.18.1365109825944; Thu, 04 Apr 2013 14:10:25 -0700 (PDT) Received: by 10.194.43.2 with HTTP; Thu, 4 Apr 2013 14:10:25 -0700 (PDT) In-Reply-To: <612A863C-536F-4B1D-BB02-6727E1A9D517@isc.org> References: <612A863C-536F-4B1D-BB02-6727E1A9D517@isc.org> Date: Thu, 4 Apr 2013 17:10:25 -0400 Message-ID: From: Christopher Browne To: Francisco Obispo Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm4LPLEEjxL+lDiQrpQ6lginiPKRTP6D/LSeLnKVGpumrjOVNH0683JtfBFkomwCz+om2TQZHGT/zQqb4WSyz8dJtDhLXoAu1PXJ7B5vz0j4JyF1g9QFRZBV8pP93GAsK+FXU3/ Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 21:10:34 -0000 On Thu, Apr 4, 2013 at 4:33 PM, Francisco Obispo wrote: > Why do you want to put it in a tarball? > > GPG will encrypt+compress the data, leaving you with a .ryde file that already meets the criteria: Assuming the CSV representation is approved, that will mandate having a bunch of files, one for each of various streams of data. That is somewhat problematic, at present, since most of the standard seems to contemplate there being a single XML file. I expect that a reasonably substantial amount of rewording would be required to cope with accommodating there being multiple files. And further, since the file naming conventions are stated not in the IRE standard, but rather in the registry operator agreement, then presumably there would need to be amendments made to that document to accommodate the multiplicity of CSV files. The wording of draft-arias-noguchi-registry-data-escrow-06 is a bit curious in this regard; *most* of the document makes no reference to the concept of a "file", instead indicating an XML schema to represent the contents of a "deposit." In section #2 is one of the references; on the one hand, it discusses the XML model, and does so without actually mentioning files. But the addition of CSV requires that the deposit be split into pieces, so it indicates that the data will be contained in files. So that implies that a deposit consists of "files." Section #11 mentions files, but I imagine that it would be better worded if the following two sentences were changed: "It is also of the utmost importance the authentication of the parties passing data escrow deposit files." to (with a bit of grammar repair that I hope is apropos) "It is also of the utmost importance to have proper authentication of the parties passing data escrow deposits." also... "Validation of the contents by the Escrow Agent is RECOMMENDED to ensure not only the file was transmitted correctly from the Registry, but also the contents are also "meaningful"." to (with a little bit of wordsmithing) "Validation of the contents by the Escrow Agent is RECOMMENDED to ensure not only that the deposit was transmitted correctly from the Registry, but also that the contents are "meaningful"." Throughout section #17, the term "data escrow deposit file" is used repeatedly (three times); I should think that the word "file" could be dropped in all three cases without injuring the wording. The Revised New gTLD Registry Agreement presumably needs to be revised more significantly, as it makes a lot more specific statements indicating that the deposits are represented by a single file. http://www.icann.org/en/news/public-comment/base-agreement-05feb13-en.htm - In 3.1 it expressly indicates that the deposit "will be compiled into a file constructed as described in [draft-arias-...]" - In 3.2, extended data is indicated to be "included in the deposit file described in section 3.1" - In 5, a naming convention is given for The Deposit File - In 8.2, it is indicated that if the file is decomposed into pieces, they are "put together" I could readily think of a way of using /usr/bin/tar to turn several smaller files into one bigger one that might be considered to represent the deposit, however the RA document: a) Does not contemplate that, and b) Specifically indicates that the IRE standard is to be used to indicate the construction of the file (e.g. - section 3.1 says that quite specifically). >From the division of responsibilities that is indicated in the RA document, it appears as though the IRE specification needs to speak to how a series of CSV streams would be composed into a singular deposit. From james.mitchell@ausregistry.com.au Fri Apr 5 03:24:42 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B2B21F9691 for ; Fri, 5 Apr 2013 03:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.744 X-Spam-Level: X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APf+M3CR4ztu for ; Fri, 5 Apr 2013 03:24:41 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD0F21F963A for ; Fri, 5 Apr 2013 03:24:41 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 05 Apr 2013 21:24:37 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Fri, 5 Apr 2013 21:24:32 +1100 From: James Mitchell To: "ire@ietf.org" Date: Fri, 5 Apr 2013 21:24:32 +1100 Thread-Topic: Deposit Identifiers Thread-Index: Ac4x58LSZcoh10FEQWiQhiPhblxb2A== Message-ID: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD84E3257531Cjamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: [ire] Deposit Identifiers X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2013 10:24:42 -0000 --_000_CD84E3257531Cjamesmitchellausregistrycomau_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gustavo, The definition of the deposit ID is given below: A REQUIRED "id" attribute that is used to uniquely identify the escrow deposit. Each registry is responsible for maintaining its own escrow deposits identifier space to ensure uniqueness, e.g., using identifiers as described in Section 2.8 of [RFC5730]. Section 2.8 of RFC 5730 describes globally unique identifiers. I do not bel= ieve there is a need for globally unique identifiers, and therefore suggest= updating the text to remove the reference to RFC5730 and instead require r= egistries produce locally unique deposit identifiers. I actually see no nee= d for deposit identifiers as the watermark is unique, one could use prevWat= ermark=3D"" in replacement to prevId=3D"". If global uniqueness is required, we would like to use the concatenation of= the TLD name and date, however the format does not currently allow this. W= e suggest the depositIdType pattern is updated to use a modified ROID patte= rn that allows hyphens, e.g. , allowing = for identifiers such as id=3D"xn--punycode-20130405". This pattern would be= reasonably consistent with the reference to RFC 5730. Regards, James --_000_CD84E3257531Cjamesmitchellausregistrycomau_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Gustavo,

<= /div>
The definition of the deposit ID is given below:

      A REQUIRED "id" attribute that is u= sed to uniquely identify the
      escrow deposit.=  Each registry is responsible for maintaining its
  &n= bsp;   own escrow deposits identifier space to ensure uniqueness, e.g.= ,
      using identifiers as described in Section = 2.8 of [RFC5730].

Section 2.8 of RFC 5730 de= scribes globally unique identifiers. I do not believe there is a need for g= lobally unique identifiers, and therefore suggest updating the text to remo= ve the reference to RFC5730 and instead require registries produce locally = unique deposit identifiers. I actually see no need for deposit identifiers = as the watermark is unique, one could use prevWatermark=3D"" in replacement= to prevId=3D"".

If global uniqueness is required,= we would like to use the concatenation of the TLD name and date, however t= he format does not currently allow this. We suggest the depositIdType patte= rn is updated to use a modified ROID pattern that allows hyphens, e.g. <= pattern value=3D"(\w|_|-){1,89}"/>, allowing for ident= ifiers such as id=3D"xn--punycode-20130405". This pattern would be reasonab= ly consistent with the reference to RFC 5730.

Rega= rds,
James
 --_000_CD84E3257531Cjamesmitchellausregistrycomau_-- From james.mitchell@ausregistry.com.au Mon Apr 8 00:29:08 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5D021F854F for ; Mon, 8 Apr 2013 00:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.794 X-Spam-Level: X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXzLkN4j5akW for ; Mon, 8 Apr 2013 00:29:07 -0700 (PDT) Received: from mx02.ausregistry.net.au (mx02.ausregistry.net.au [202.65.15.42]) by ietfa.amsl.com (Postfix) with ESMTP id 57F3C21F854E for ; Mon, 8 Apr 2013 00:29:07 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron02.off08.stkildard.vic.ausregistry.com.au with ESMTP; 08 Apr 2013 17:29:06 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Mon, 8 Apr 2013 17:29:00 +1000 From: James Mitchell To: "ire@ietf.org" Date: Mon, 8 Apr 2013 17:29:02 +1000 Thread-Topic: Variant Domain Names Thread-Index: Ac40Krwu3ggyGkrFQIWWrrYFZQXq2g== Message-ID: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD87DA9F76C42jamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: [ire] Variant Domain Names X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 07:29:08 -0000 --_000_CD87DA9F76C42jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gustavo, I would like the nameState of NNDNs to include "activated". The "allocated"= value was in revision =9601, however seems to have disappeared without rea= son? Adding "allocated" would make the NNDN consistent with the text in Sec= tion 6 that states that either domain objects or NNDNs may be used to repre= sent variants. Also, the NNDN should be optional as some registries may not track= the creation date of reserved list entries. Regards, James --_000_CD87DA9F76C42jamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Gustavo,

I would like the nameState of NNDNs to include "activated". Th= e "allocated" value was in revision =9601, however seems to have = disappeared without reason? Adding "allocated" would make the NND= N consistent with the text in Section 6 that states that either domain= objects or NNDNs may be used to represent variants.

Also, the NNDN <crDate> should be optional as some registries may = not track the creation date of reserved list entries.

<= div>Regards,
James

--_000_CD87DA9F76C42jamesmitchellausregistrycomau_-- From bmodi@afilias.info Mon Apr 8 09:08:30 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F9821F97D7 for ; Mon, 8 Apr 2013 09:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AgPg827iwBm for ; Mon, 8 Apr 2013 09:08:29 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1D821F97D5 for ; Mon, 8 Apr 2013 09:08:29 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UPEcO-0002Jo-52 for ire@ietf.org; Mon, 08 Apr 2013 16:08:28 +0000 Received: from mail-la0-f69.google.com ([209.85.215.69]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UPEcO-0001Lj-4S for ire@ietf.org; Mon, 08 Apr 2013 16:08:28 +0000 Received: by mail-la0-f69.google.com with SMTP id ek20so8493089lab.4 for ; Mon, 08 Apr 2013 09:08:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=jP9cllKrYO/UkIQCCgzW1jiwY17D9Obm9SP+KAUyJKs=; b=QQQDXPWb038h3IXH4QpaGPNjrbdKN9VoHbvXYcM34rOoZ3X62kSRLYR8KxYd5dxkNK DoJrpdpAR+/DrY1Zh9El5YuwLtnmAuDOWZQYs7YoP+EEmLq6jTI27/t1aklpwYQhAaAI kiQg1rh0QoVw7NGf23YVbuhCtdbdzSfq2x3P3P8vXrf593NTZximYhnmr/pUIAvxO/3J MFljeuFU4ZK/fD93uVH0vzUzJOf+tN2l3jFD2nfSJvZA0N12kUTtbZ4oLjMIJNrJOJ0E iFtVdCgSJkbSn/Gzj2S0Y3c9FyrceeFlwmns9L/VCeJX1P+QYCn2JjU6TtEZvfA40ETh SWew== X-Received: by 10.180.208.47 with SMTP id mb15mr14103590wic.16.1365437242053; Mon, 08 Apr 2013 09:07:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.208.47 with SMTP id mb15mr14103158wic.16.1365437238191; Mon, 08 Apr 2013 09:07:18 -0700 (PDT) Received: by 10.217.117.1 with HTTP; Mon, 8 Apr 2013 09:07:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Apr 2013 12:07:18 -0400 Message-ID: From: Bhadresh Modi To: "ire@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3864c8bbad704d9dba1bc X-Gm-Message-State: ALoCoQnvb6p2L6YNCCy8EyHMO6o9GLa7/dM0UotLITXp04iIQYReXgGXnOYCbK87NjOn2DYUTmv1qUdViS7RHVZprVq5TWYLfyXUekUa7Zl1Dbt69+p+MCr7kz+nuSE/AlfnymJlQmJv Subject: Re: [ire] Variant Domain Names X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:08:30 -0000 --001a11c3864c8bbad704d9dba1bc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree - we were using the "allocated" value in the previous revision to differentiate between IDN variants that simply blocked registration and variants that would actual resolve similar to the original domain name. With the omission of this value there is no longer any way to express this= . Regards, Bhadresh On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell < james.mitchell@ausregistry.com.au> wrote: > Gustavo, > > I would like the nameState of NNDNs to include "activated". The > "allocated" value was in revision =9601, however seems to have disappeare= d > without reason? Adding "allocated" would make the NNDN consistent with th= e > text in Section 6 that states that either domain objects or NNDNs may be > used to represent variants. > > Also, the NNDN should be optional as some registries may not > track the creation date of reserved list entries. > > Regards, > James > > > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > > --001a11c3864c8bbad704d9dba1bc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree - we were using the "allocated" value in the previous rev= ision to differentiate between IDN variants that simply blocked registratio= n and variants that would actual resolve similar to the original domain nam= e. =A0With the omission of this value there is no longer any way to express= this.

Regards,
Bhadresh


On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell <james.mitchell@ausregistry.com.au> wrote:
Gustavo,

I would like the nameState of= NNDNs to include "activated". The "allocated" value wa= s in revision =9601, however seems to have disappeared without reason? Addi= ng "allocated" would make the NNDN consistent with the text in=A0= Section 6 that states that either domain objects or NNDNs may be used to re= present variants.

Also, the NNDN <crDate> should be optional as som= e registries may not track the creation date of reserved list entries.

Regards,
James


_______________________________________________
ire mailing list
ire@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ire


--001a11c3864c8bbad704d9dba1bc-- From ajs@anvilwalrusden.com Mon Apr 8 09:49:09 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD71321F86C1 for ; Mon, 8 Apr 2013 09:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi7gxeulvjNN for ; Mon, 8 Apr 2013 09:49:08 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AFE6221F84B2 for ; Mon, 8 Apr 2013 09:49:08 -0700 (PDT) Received: from mx1.yitter.info (li440-116.members.linode.com [50.116.54.116]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D41FF8A031 for ; Mon, 8 Apr 2013 16:49:07 +0000 (UTC) Date: Mon, 8 Apr 2013 12:49:04 -0400 From: Andrew Sullivan To: ire@ietf.org Message-ID: <20130408164904.GC22596@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [ire] Variant Domain Names X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 16:49:09 -0000 I have no idea how those terms got adopted, but I'd like to point out the distinctions that were made by the variant issues project/IDN TLD project: Delegated: actually in a zone with an SOA and parent NS RRset. Activated: in the DNS somehow. (Delegated is a species of activated. For instance, a DNAME would be activated but not delegated.) Allocated: someone has administrative control over the name, but it is not activated. For instance, any domain on Hold in EPP would be allocated. Blocked: nobody is allowed to register the name. For instance, in .com nobody may register the label example (so example.com is blocked). I think these distinctions are all extremely useful. On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote: > I agree - we were using the "allocated" value in the previous revision to > differentiate between IDN variants that simply blocked registration and > variants that would actual resolve similar to the original domain name. > With the omission of this value there is no longer any way to express this. > > Regards, > Bhadresh > > > On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell < > james.mitchell@ausregistry.com.au> wrote: > > > Gustavo, > > > > I would like the nameState of NNDNs to include "activated". The > > "allocated" value was in revision –01, however seems to have disappeared > > without reason? Adding "allocated" would make the NNDN consistent with the > > text in Section 6 that states that either domain objects or NNDNs may be > > used to represent variants. > > > > Also, the NNDN should be optional as some registries may not > > track the creation date of reserved list entries. > > > > Regards, > > James > > > > > > _______________________________________________ > > ire mailing list > > ire@ietf.org > > https://www.ietf.org/mailman/listinfo/ire > > > > > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire -- Andrew Sullivan ajs@anvilwalrusden.com From bmodi@afilias.info Mon Apr 8 10:06:10 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F5E21F9590 for ; Mon, 8 Apr 2013 10:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NDIsvij5Lzp for ; Mon, 8 Apr 2013 10:06:10 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1731321F9588 for ; Mon, 8 Apr 2013 10:06:09 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UPFWD-0005ay-3u for ire@ietf.org; Mon, 08 Apr 2013 17:06:09 +0000 Received: from mail-fa0-f71.google.com ([209.85.161.71]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UPFWC-0003Li-6D for ire@ietf.org; Mon, 08 Apr 2013 17:06:09 +0000 Received: by mail-fa0-f71.google.com with SMTP id w1so4915316fad.2 for ; Mon, 08 Apr 2013 10:06:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=JiK73StojFsvnFCNBGI8A1lNzk70UPk5T7Ozz2Q94UI=; b=VHnBzP1qTp3esG11L9QfphDDEhsUnt3Zjrd3llYzPZrC7Owxl5CXwDH4cYfp0QmSHP 9UplN0BZ6kY7FME0A929uLFbqd3Q8lK/dnkP7q+1KbNGF2yXhxdyBcbGYxLAxzNiGwWj 9wh7WMEk7mfTK3D2v4EWAY7f/QwXEu+A7UlWKj4Fu6wxR581Pg0hcGARslORpRSjNsc9 UCfsGx+/6maC/GYqXFNvOLbuP7IoNERX7b62kiqwrEgtj/hcAz00pZY3tkgufGj69T/P 8FohBipjT8raMfOtSTNXkA/iwIjmxYTpCNGQZ/zCccLRe/ouysiC2NnONdlD4KwLUtsR jUGw== X-Received: by 10.194.92.231 with SMTP id cp7mr15791476wjb.19.1365440762884; Mon, 08 Apr 2013 10:06:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.92.231 with SMTP id cp7mr15791464wjb.19.1365440762723; Mon, 08 Apr 2013 10:06:02 -0700 (PDT) Received: by 10.217.117.1 with HTTP; Mon, 8 Apr 2013 10:06:02 -0700 (PDT) In-Reply-To: <20130408164904.GC22596@mx1.yitter.info> References: <20130408164904.GC22596@mx1.yitter.info> Date: Mon, 8 Apr 2013 13:06:02 -0400 Message-ID: From: Bhadresh Modi To: ire@ietf.org Content-Type: multipart/alternative; boundary=047d7bfd0c2e9fd46c04d9dc7330 X-Gm-Message-State: ALoCoQkxKBgog19+/uiMMVnv26VCU/xE8Sdlaxp2vVJHdItIfp2vfgewAgX1xso27JvjlZyd0BCCB4wzQAb6wtQv9fSK5WDMKfubcBLO3PQY6Wgf+cDZQxZu9kVd03fObgQaRHQUTcLZ Subject: Re: [ire] Variant Domain Names X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 17:06:11 -0000 --047d7bfd0c2e9fd46c04d9dc7330 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable More precise terms are certainly helpful, I think the main point is that the current set of "blocked" and "withheld" as shown in the draft is insufficient. Perhaps it makes sense to simply use the same terms with the same definitions from the IDN TLD project that Andrew provided. Regards, Bhadresh On Mon, Apr 8, 2013 at 12:49 PM, Andrew Sullivan wr= ote: > I have no idea how those terms got adopted, but I'd like to point out > the distinctions that were made by the variant issues project/IDN TLD > project: > > Delegated: actually in a zone with an SOA and parent NS RRset. > > Activated: in the DNS somehow. (Delegated is a species of activated. > For instance, a DNAME would be activated but not delegated.) > > Allocated: someone has administrative control over the name, but it is > not activated. For instance, any domain on Hold in EPP would be > allocated. > > Blocked: nobody is allowed to register the name. For instance, in > .com nobody may register the label example (so example.com is > blocked). > > I think these distinctions are all extremely useful. > > On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote: > > I agree - we were using the "allocated" value in the previous revision = to > > differentiate between IDN variants that simply blocked registration and > > variants that would actual resolve similar to the original domain name. > > With the omission of this value there is no longer any way to express > this. > > > > Regards, > > Bhadresh > > > > > > On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell < > > james.mitchell@ausregistry.com.au> wrote: > > > > > Gustavo, > > > > > > I would like the nameState of NNDNs to include "activated". The > > > "allocated" value was in revision =9601, however seems to have > disappeared > > > without reason? Adding "allocated" would make the NNDN consistent wit= h > the > > > text in Section 6 that states that either domain objects or NNDNs may > be > > > used to represent variants. > > > > > > Also, the NNDN should be optional as some registries may not > > > track the creation date of reserved list entries. > > > > > > Regards, > > > James > > > > > > > > > _______________________________________________ > > > ire mailing list > > > ire@ietf.org > > > https://www.ietf.org/mailman/listinfo/ire > > > > > > > > > _______________________________________________ > > ire mailing list > > ire@ietf.org > > https://www.ietf.org/mailman/listinfo/ire > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > --047d7bfd0c2e9fd46c04d9dc7330 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable More precise terms are certainly helpful, I think the main point is that th= e current set of "blocked" and "withheld" as shown in t= he draft is insufficient.

Perhaps it makes sense to simp= ly use the same terms with the same definitions from the IDN TLD project th= at Andrew provided.

Regards,
Bhadresh

On Mon, Apr 8, 2013 at 12:49 PM, Andrew Sullivan &= lt;ajs@anvilwal= rusden.com> wrote:
I have no idea how those terms got adopted, = but I'd like to point out
the distinctions that were made by the variant issues project/IDN TLD
project:

Delegated: actually in a zone with an SOA and parent NS RRset.

Activated: in the DNS somehow. =A0(Delegated is a species of activated.
For instance, a DNAME would be activated but not delegated.)

Allocated: someone has administrative control over the name, but it is
not activated. =A0For instance, any domain on Hold in EPP would be
allocated.

Blocked: nobody is allowed to register the name. =A0For instance, in
.com nobody may register the label example (so example.com is
blocked).

I think these distinctions are all extremely useful.

On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote:
> I agree - we were using the "allocated" value in the previou= s revision to
> differentiate between IDN variants that simply blocked registration an= d
> variants that would actual resolve similar to the original domain name= .
> =A0With the omission of this value there is no longer any way to expre= ss this.
>
> Regards,
> Bhadresh
>
>
> On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell <
> james.mitchell@au= sregistry.com.au> wrote:
>
> > Gustavo,
> >
> > I would like the nameState of NNDNs to include "activated&qu= ot;. The
> > "allocated" value was in revision =9601, however seems = to have disappeared
> > without reason? Adding "allocated" would make the NNDN = consistent with the
> > text in Section 6 that states that either domain objects or NNDNs= may be
> > used to represent variants.
> >
> > Also, the NNDN <crDate> should be optional as some registri= es may not
> > track the creation date of reserved list entries.
> >
> > Regards,
> > James
> >
> >
> > _______________________________________________
> > ire mailing list
> > ire@ietf.org
> > https://www.ietf.org/mailman/listinfo/ire
> >
> >

> _______________________________________________
> ire mailing list
> ire@ietf.org
> https://www.ietf.org/mailman/listinfo/ire


--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
ire mailing list
ire@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ire

--047d7bfd0c2e9fd46c04d9dc7330-- From james.mitchell@ausregistry.com.au Mon Apr 8 18:02:58 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CCF21F8E73 for ; Mon, 8 Apr 2013 18:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKPfM5vTAVBW for ; Mon, 8 Apr 2013 18:02:58 -0700 (PDT) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3203C21F8E63 for ; Mon, 8 Apr 2013 18:02:56 -0700 (PDT) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 09 Apr 2013 11:02:54 +1000 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Tue, 9 Apr 2013 11:02:48 +1000 From: James Mitchell To: Bhadresh Modi , "ire@ietf.org" Date: Tue, 9 Apr 2013 11:02:50 +1000 Thread-Topic: [ire] Variant Domain Names Thread-Index: Ac40vfMvCpCvYxAtSYimIAnUYjNwsw== Message-ID: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US, en-AU x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CD897BCC782A7jamesmitchellausregistrycomau_" MIME-Version: 1.0 Subject: Re: [ire] Variant Domain Names X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 01:02:58 -0000 --_000_CD897BCC782A7jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Apologies, I was intending to use the term "activated". I have "allocated" = on my mind from the launch discussions.. Thanks, James From: Bhadresh Modi > Date: Tuesday, 9 April 2013 3:06 AM To: "ire@ietf.org" > Subject: Re: [ire] Variant Domain Names More precise terms are certainly helpful, I think the main point is that th= e current set of "blocked" and "withheld" as shown in the draft is insuffic= ient. Perhaps it makes sense to simply use the same terms with the same definitio= ns from the IDN TLD project that Andrew provided. Regards, Bhadresh On Mon, Apr 8, 2013 at 12:49 PM, Andrew Sullivan > wrote: I have no idea how those terms got adopted, but I'd like to point out the distinctions that were made by the variant issues project/IDN TLD project: Delegated: actually in a zone with an SOA and parent NS RRset. Activated: in the DNS somehow. (Delegated is a species of activated. For instance, a DNAME would be activated but not delegated.) Allocated: someone has administrative control over the name, but it is not activated. For instance, any domain on Hold in EPP would be allocated. Blocked: nobody is allowed to register the name. For instance, in .com nobody may register the label example (so example.com is blocked). I think these distinctions are all extremely useful. On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote: > I agree - we were using the "allocated" value in the previous revision to > differentiate between IDN variants that simply blocked registration and > variants that would actual resolve similar to the original domain name. > With the omission of this value there is no longer any way to express th= is. > > Regards, > Bhadresh > > > On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell < > james.mitchell@ausregistry.com.au> wrote: > > > Gustavo, > > > > I would like the nameState of NNDNs to include "activated". The > > "allocated" value was in revision =9601, however seems to have disappea= red > > without reason? Adding "allocated" would make the NNDN consistent with = the > > text in Section 6 that states that either domain objects or NNDNs may b= e > > used to represent variants. > > > > Also, the NNDN should be optional as some registries may not > > track the creation date of reserved list entries. > > > > Regards, > > James > > > > > > _______________________________________________ > > ire mailing list > > ire@ietf.org > > https://www.ietf.org/mailman/listinfo/ire > > > > > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire --_000_CD897BCC782A7jamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Apologies, I was intending to u= se the term "activated". I have "allocated" on my = mind from the launch discussions..

Thanks,
James

From: = Bhadresh Modi <bmodi@afili= as.info>
Date: Tuesday, = 9 April 2013 3:06 AM
To: "= ire@ietf.org" <ire@ietf.org>
Su= bject: Re: [ire] Variant Domain Names

=
More precise terms are certainly helpful, I think the main point is that th= e current set of "blocked" and "withheld" as shown in t= he draft is insufficient.

Perhaps it makes sense to simply use the same terms wit= h the same definitions from the IDN TLD project that Andrew provided.
=

Regards,
Bhadresh

On Mon, Apr 8, 2013 at 12:49 PM, Andrew Sullivan <ajs@anvilwa= lrusden.com> wrote:
I have no idea how those terms got adopted, but I'd like to point out
the distinctions that were made by the variant issues project/IDN TLD
project:

Delegated: actually in a zone with an SOA and parent NS RRset.

Activated: in the DNS somehow.  (Delegated is a species of activated.<= br> For instance, a DNAME would be activated but not delegated.)

Allocated: someone has administrative control over the name, but it is
not activated.  For instance, any domain on Hold in EPP would be
allocated.

Blocked: nobody is allowed to register the name.  For instance, in
.com nobody may register the label example (so example.com is
blocked).

I think these distinctions are all extremely useful.

On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote:
> I agree - we were using the "allocated" value in the previou= s revision to
> differentiate between IDN variants that simply blocked registration an= d
> variants that would actual resolve similar to the original domain name= .
>  With the omission of this value there is no longer any way to ex= press this.
>
> Regards,
> Bhadresh
>
>
> On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell <
> james.mitchell@au= sregistry.com.au> wrote:
>
> > Gustavo,
> >
> > I would like the nameState of NNDNs to include "activated&qu= ot;. The
> > "allocated" value was in revision =9601, however seems = to have disappeared
> > without reason? Adding "allocated" would make the NNDN = consistent with the
> > text in Section 6 that states that either domain objects or NNDNs= may be
> > used to represent variants.
> >
> > Also, the NNDN <crDate> should be optional as some registri= es may not
> > track the creation date of reserved list entries.
> >
> > Regards,
> > James
> >
> >
> > _______________________________________________
> > ire mailing list
> > ire@ietf.org
> > https://www.ietf.org/mailman/listinfo/ire
> >
> >

> _______________________________________________
> ire mailing list
> ire@ietf.org
> https://www.ietf.org/mailman/listinfo/ire


--
Andrew Sullivan
ajs@anvilwalru= sden.com
_____= __________________________________________
ire mailing list
ire@ietf.org
https:= //www.ietf.org/mailman/listinfo/ire
<= br>
 --_000_CD897BCC782A7jamesmitchellausregistrycomau_-- From gustavo.lozano@icann.org Tue Apr 9 00:23:44 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E02121F905A for ; Tue, 9 Apr 2013 00:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOKJ-Zr4LSA7 for ; Tue, 9 Apr 2013 00:23:43 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7DF21F91BF for ; Tue, 9 Apr 2013 00:23:43 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 9 Apr 2013 00:23:42 -0700 From: Gustavo Lozano To: Christopher Browne , Francisco Obispo Date: Tue, 9 Apr 2013 00:23:37 -0700 Thread-Topic: [ire] New versions of data escrow drafts Thread-Index: Ac408ymjJ1StcZ1DS+C1f0lWSERTEQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD89E255FD99gustavolozanoicannorg_" MIME-Version: 1.0 Cc: "ire@ietf.org" Subject: Re: [ire] New versions of data escrow drafts X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:23:44 -0000 --_000_CD89E255FD99gustavolozanoicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christopher, XML only and XML+CSV are both supported (see http://www.icann.org/en/news/c= orrespondence/atallah-to-drazek-21feb13-en.pdf) The authors of both drafts are working on merging the drafts. A CSV deposit will have an XML file and several CSV files; this is the reas= on of the requirement for the tarball. In order to standardize the process= for Data Escrow Agents, even if you use XML only, the revised base agreeme= nt requires the use of a tarball. Data escrow agents will: 1. Validate the signature (.sig) of the .ryde file. 2. Unencrypt the .ryde file obtaining a tarball. 3. Untar the tarball. 4. Process the XML data file. 5. The XML data file could link CSV data file(s) for some objects if usin= g the CSV model. This has been reflected in the proposed base agreement (see http://blog.ica= nn.org/2013/04/revised-registry-agreement-posted-for-review, Specification = 2) Regards, Gustavo On 4/4/13 2:10 PM, "Christopher Browne" > wrote: On Thu, Apr 4, 2013 at 4:33 PM, Francisco Obispo > wrote: Why do you want to put it in a tarball? GPG will encrypt+compress the data, leaving you with a .ryde file that alre= ady meets the criteria: Assuming the CSV representation is approved, that will mandate having a bunch of files, one for each of various streams of data. That is somewhat problematic, at present, since most of the standard seems to contemplate there being a single XML file. I expect that a reasonably substantial amount of rewording would be required to cope with accommodating there being multiple files. And further, since the file naming conventions are stated not in the IRE standard, but rather in the registry operator agreement, then presumably there would need to be amendments made to that document to accommodate the multiplicity of CSV files. The wording of draft-arias-noguchi-registry-data-escrow-06 is a bit curious in this regard; *most* of the document makes no reference to the concept of a "file", instead indicating an XML schema to represent the contents of a "deposit." In section #2 is one of the references; on the one hand, it discusses the XML model, and does so without actually mentioning files. But the addition of CSV requires that the deposit be split into pieces, so it indicates that the data will be contained in files. So that implies that a deposit consists of "files." Section #11 mentions files, but I imagine that it would be better worded if the following two sentences were changed: "It is also of the utmost importance the authentication of the parties passing data escrow deposit files." to (with a bit of grammar repair that I hope is apropos) "It is also of the utmost importance to have proper authentication of the parties passing data escrow deposits." also... "Validation of the contents by the Escrow Agent is RECOMMENDED to ensure not only the file was transmitted correctly from the Registry, but also the contents are also "meaningful"." to (with a little bit of wordsmithing) "Validation of the contents by the Escrow Agent is RECOMMENDED to ensure not only that the deposit was transmitted correctly from the Registry, but also that the contents are "meaningful"." Throughout section #17, the term "data escrow deposit file" is used repeatedly (three times); I should think that the word "file" could be dropped in all three cases without injuring the wording. The Revised New gTLD Registry Agreement presumably needs to be revised more significantly, as it makes a lot more specific statements indicating that the deposits are represented by a single file. http://www.icann.org/en/news/public-comment/base-agreement-05feb13-en.htm - In 3.1 it expressly indicates that the deposit "will be compiled into a file constructed as described in [draft-arias-...]" - In 3.2, extended data is indicated to be "included in the deposit file described in section 3.1" - In 5, a naming convention is given for The Deposit File - In 8.2, it is indicated that if the file is decomposed into pieces, they are "put together" I could readily think of a way of using /usr/bin/tar to turn several smaller files into one bigger one that might be considered to represent the deposit, however the RA document: a) Does not contemplate that, and b) Specifically indicates that the IRE standard is to be used to indicate the construction of the file (e.g. - section 3.1 says that quite specifically). >From the division of responsibilities that is indicated in the RA document, it appears as though the IRE specification needs to speak to how a series of CSV streams would be composed into a singular deposit. --_000_CD89E255FD99gustavolozanoicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable _ Normal 0 false false false EN-US JA X-NONE
Christopher,

XML only and XML+CSV are both supported (see http://www.ic= ann.org/en/news/correspondence/atallah-to-drazek-21feb13-en.pdf)

 

The authors of = both drafts are working on merging the drafts.

 

A CSV deposit will have an XML file a= nd several CSV files; this is the reason of the requirement for the tarball= .  In order to standardize the process for Data Escrow Agents, even if= you use XML only, the revised base agreement requires the use of a tarball.

 

Data escrow agents will:=


  1. Validate the signature (.sig) of t= he .ryde file.
  2. Un= encrypt the .ryde file obtaining a tarball.
  3. Untar the tarball.
  4. Process the XML data file.
  5. The XML data file could link CSV dat= a file(s) for some objects if using the CSV model.

This has been reflected in the propos= ed base agreement (see http://blog.icann.org/2013/04/revised-re= gistry-agreement-posted-for-review, Specification 2)<= /p>


Regards,

Gustavo


On 4/4/13 2:10= PM, "Christopher Browne" <cbbr= owne@afilias.info> wrote:

On Thu, Apr 4, 2013 at 4:33 PM, Francisco Obispo <fobispo@isc.org> wrote:
Why do you want to put it in a tarball?

GPG will encrypt+compress the data, leaving you with = a .ryde file that already meets the criteria:

Assuming the CSV representation is approved, that will mandate hav= ing
a bunch of files, one for each of various streams of data.

That is somewhat problematic, at present, since most= of the standard
seems to contemplate there being a single XML fi= le.  I expect that a
reasonably substantial amount of r= ewording would be required to cope
with accommodating there being= multiple files.  And further, since the
file naming co= nventions are stated not in the IRE standard, but rather
in the r= egistry operator agreement, then presumably there would need
to b= e amendments made to that document to accommodate the multiplicity
of CSV files.

The wording of draft-arias-noguchi= -registry-data-escrow-06 is a bit
curious in this regard; *most* = of the document makes no reference to
the concept of a "file", in= stead indicating an XML schema to represent
the contents of a "de= posit."

In section #2 is one of the references; on= the one hand, it discusses
the XML model, and does so without ac= tually mentioning files.  But the
addition of CSV requi= res that the deposit be split into pieces, so it
indicates that t= he data will be contained in files.  So that implies
th= at a deposit consists of "files."

Section #11 ment= ions files, but I imagine that it would be better
worded if the f= ollowing two sentences were changed:

   = "It is also of the utmost importance the authentication of the
pa= rties passing data escrow deposit files."

 &n= bsp;  to (with a bit of grammar repair that I hope is apropos)

   "It is also of the utmost importance to= have proper authentication
of the parties passing data escrow de= posits."

also...

 &n= bsp;  "Validation of the contents by the Escrow Agent is RECOMMEN= DED to
ensure not only the file was transmitted correctly from th= e Registry,
but also the contents are also "meaningful"."
    to (with a little bit of wordsmithing)
    "Validation of the contents by the Escrow Agent is= RECOMMENDED to
ensure not only that the deposit was transmitted = correctly from the
Registry, but also that the contents are "mean= ingful"."

Throughout section #17, the term "data e= scrow deposit file" is used
repeatedly (three times); I should th= ink that the word "file" could be
dropped in all three cases with= out injuring the wording.

The Revised New gTLD Reg= istry Agreement presumably needs to be revised
more significantly= , as it makes a lot more specific statements
indicating that the = deposits are represented by a single file.

- In 3.1 it expressly indicates that the deposit "will be = compiled
into a file constructed as described in [draft-arias-...= ]"
- In 3.2, extended data is indicated to be "included in the de= posit
file described in section 3.1"
- In 5, a naming c= onvention is given for The Deposit File
- In 8.2, it is indicated= that if the file is decomposed into pieces,
they are "put togeth= er"

I could readily think of a way of using /usr/b= in/tar to turn several
smaller files into one bigger one that mig= ht be considered to
represent the deposit, however the RA documen= t:
a) Does not contemplate that, and
b) Specifically in= dicates that the IRE standard is to be used to
indicate the const= ruction of the file (e.g. - section 3.1 says that
quite specifica= lly).

From the division of responsibilities that i= s indicated in the RA
document, it appears as though the IRE spec= ification needs to speak to
how a series of CSV streams would be = composed into a singular deposit.

<= /html> --_000_CD89E255FD99gustavolozanoicannorg_-- From gustavo.lozano@icann.org Tue Apr 9 02:04:11 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7BC21F8678 for ; Tue, 9 Apr 2013 02:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjARdgMQ6QhY for ; Tue, 9 Apr 2013 02:04:07 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 12E5F21F85A1 for ; Tue, 9 Apr 2013 02:04:06 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 9 Apr 2013 02:04:05 -0700 From: Gustavo Lozano To: James Mitchell , "ire@ietf.org" Date: Tue, 9 Apr 2013 02:04:03 -0700 Thread-Topic: [ire] Deposit Identifiers Thread-Index: Ac41ATA99pfAdfKtR9yVPYT5egtIHw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD89F705FDCAgustavolozanoicannorg_" MIME-Version: 1.0 Subject: Re: [ire] Deposit Identifiers X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 09:04:12 -0000 --_000_CD89F705FDCAgustavolozanoicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you James, In the new version of the specification the text will be updated to: A REQUIRED "id" attribute that is used to uniquely identify the escrow depo= sit. Each registry is responsible for maintaining its own escrow deposits i= dentifier space to ensure uniqueness. The identifier must be unique even fo= r escrow deposits generated for the same Timeline Watermark. We need the identifier because the data escrow specification was developed = for general escrow in mind, resend is optional (but required for new gTLDs)= and several deposits could have the same Timeline Watermark (e.g. resendin= g). Regards, Gustavo From: James Mitchell > Date: Friday, April 5, 2013 6:24 PM To: "ire@ietf.org" > Subject: [ire] Deposit Identifiers Gustavo, The definition of the deposit ID is given below: A REQUIRED "id" attribute that is used to uniquely identify the escrow deposit. Each registry is responsible for maintaining its own escrow deposits identifier space to ensure uniqueness, e.g., using identifiers as described in Section 2.8 of [RFC5730]. Section 2.8 of RFC 5730 describes globally unique identifiers. I do not bel= ieve there is a need for globally unique identifiers, and therefore suggest= updating the text to remove the reference to RFC5730 and instead require r= egistries produce locally unique deposit identifiers. I actually see no nee= d for deposit identifiers as the watermark is unique, one could use prevWat= ermark=3D"" in replacement to prevId=3D"". If global uniqueness is required, we would like to use the concatenation of= the TLD name and date, however the format does not currently allow this. W= e suggest the depositIdType pattern is updated to use a modified ROID patte= rn that allows hyphens, e.g. , allowing = for identifiers such as id=3D"xn--punycode-20130405". This pattern would be= reasonably consistent with the reference to RFC 5730. Regards, James --_000_CD89F705FDCAgustavolozanoicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable _
<= span style=3D"font-size: 16px;">Thank you James,
 
=

In the new version of the specification the text will be updated to:

 

A REQUIRED "id" attribute tha= t is used to uniquely identify the escrow deposit. Each registry is responsible for maintaining its own escrow deposits identifier space to ens= ure uniqueness. The identifier must be unique even for escrow deposits generate= d for the same Timeline Watermark.

 

We need the identifier because the data escrow specification was developed for general escrow in mind, resend is optional (but required = for new gTLDs) and several deposits could have the same Timeline Watermark (e.g= . resending).


Regards,

=

Gustavo


From: James Mitchell <james.mitchell@ausregistry.com.au>
<= span style=3D"font-weight:bold">Date: Friday, April 5, 2013 6:24 PM=
To: "ire@ietf.org" <ire@ietf.org>
Subject: [ire] Deposit I= dentifiers


=
The definition of the deposit ID is given below:

<= div>
      A REQUIRED "id" attribute that is used t= o uniquely identify the
      escrow deposit. &nbs= p;Each registry is responsible for maintaining its
    =   own escrow deposits identifier space to ensure uniqueness, e.g.,
      using identifiers as described in Section 2.8 o= f [RFC5730].

Section 2.8 of RFC 5730 describ= es globally unique identifiers. I do not believe there is a need for global= ly unique identifiers, and therefore suggest updating the text to remove th= e reference to RFC5730 and instead require registries produce locally uniqu= e deposit identifiers. I actually see no need for deposit identifiers as the= watermark is unique, one could use prevWatermark=3D"" in replacement to pr= evId=3D"".

If global uniqueness is required, we wo= uld like to use the concatenation of the TLD name and date, however the for= mat does not currently allow this. We suggest the depositIdType pattern is = updated to use a modified ROID pattern that allows hyphens, e.g. <pattern value=3D"(\w|_|-){1,89}"/>, allowing for = identifiers such as id=3D"xn--punycode-20130405". This pattern would be rea= sonably consistent with the reference to RFC 5730.

Regards,
--_000_CD89F705FDCAgustavolozanoicannorg_-- From gustavo.lozano@icann.org Tue Apr 9 14:57:16 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D033B21F9948 for ; Tue, 9 Apr 2013 14:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vM6bjD2yEVl for ; Tue, 9 Apr 2013 14:57:15 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id CA89421F98B2 for ; Tue, 9 Apr 2013 14:57:15 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 9 Apr 2013 14:57:15 -0700 From: Gustavo Lozano To: James Mitchell , Bhadresh Modi , "ire@ietf.org" Date: Tue, 9 Apr 2013 14:57:15 -0700 Thread-Topic: [ire] Variant Domain Names Thread-Index: Ac41bTInNcdXZJurSqq0d35mx4h46w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD8AACD3FE73gustavolozanoicannorg_" MIME-Version: 1.0 Subject: Re: [ire] Variant Domain Names X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 21:57:16 -0000 --_000_CD8AACD3FE73gustavolozanoicannorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable James, On version 02, the IDN variants model for data escrow was updated based on = feedback from the list, private emails and internal discussions. Suppose caf=E9.example is a mirroring variant for cafe.example. Following the current version of the draft the registry would escrow: xn--caf-dma.example cafe.example ...... I'd propose a slight change from version 01 draft to be incorporated in the= next version of the data escrow mappings specification as follows: xn--caf-dma.example cafe.example mirrored 2005-04-23T11:49:00.0Z The proposal is that nameState=3Dmirrored would mean that the NNDN is a mir= rored variant, i.e., the NNDN name implicitly has the same data as the orig= inalName. The other two states mentioned in the Integrated Issues Report on= IDN variants are not needed since the registry would need a domain object = to include data fields that diverge from those in the orginalName. An optional attribute "noNSmirroring" would mean when true, that mirroring = is NOT based in the default NS mirroring. Default NS mirroring means: * If the originalName is present in the DNS zone file, the NNDN mirror vari= ant name (NNDN:aName) is also present in the DNS zone file with the same NS= as the original name. * The Registry MUST satisfies glue record requirements of the mirrored vari= ants in the escrow deposit, but the Data Escrow Agent does not verify this. Whether mirrored DNAME (or something else?) is used, will have to be discov= ered by analyzing the DNS zone file and/or reviewing the relevant IDN polic= y. Just to clarify, the blocked and withheld states can be used not only for I= DN variants. There are registry services that may require these states. The= mirrored state would ONLY be used for IDN variants. NNDN and Domain objects variants are explicit variants. Algorithmically ge= nerated variants are generated based in the IDN policy document referenced = by urlPolicy. Comments are welcome. Regards, Gustavo From: James Mitchell > Date: Tuesday, April 9, 2013 9:02 AM To: Bhadresh Modi >, "ire@iet= f.org" > Subject: Re: [ire] Variant Domain Names Apologies, I was intending to use the term "activated". I have "allocated" = on my mind from the launch discussions.. Thanks, James From: Bhadresh Modi > Date: Tuesday, 9 April 2013 3:06 AM To: "ire@ietf.org" > Subject: Re: [ire] Variant Domain Names More precise terms are certainly helpful, I think the main point is that th= e current set of "blocked" and "withheld" as shown in the draft is insuffic= ient. Perhaps it makes sense to simply use the same terms with the same definitio= ns from the IDN TLD project that Andrew provided. Regards, Bhadresh On Mon, Apr 8, 2013 at 12:49 PM, Andrew Sullivan > wrote: I have no idea how those terms got adopted, but I'd like to point out the distinctions that were made by the variant issues project/IDN TLD project: Delegated: actually in a zone with an SOA and parent NS RRset. Activated: in the DNS somehow. (Delegated is a species of activated. For instance, a DNAME would be activated but not delegated.) Allocated: someone has administrative control over the name, but it is not activated. For instance, any domain on Hold in EPP would be allocated. Blocked: nobody is allowed to register the name. For instance, in .com nobody may register the label example (so example.com is blocked). I think these distinctions are all extremely useful. On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote: > I agree - we were using the "allocated" value in the previous revision to > differentiate between IDN variants that simply blocked registration and > variants that would actual resolve similar to the original domain name. > With the omission of this value there is no longer any way to express th= is. > > Regards, > Bhadresh > > > On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell < > james.mitchell@ausregistry.com.au> wrote: > > > Gustavo, > > > > I would like the nameState of NNDNs to include "activated". The > > "allocated" value was in revision =9601, however seems to have disappea= red > > without reason? Adding "allocated" would make the NNDN consistent with = the > > text in Section 6 that states that either domain objects or NNDNs may b= e > > used to represent variants. > > > > Also, the NNDN should be optional as some registries may not > > track the creation date of reserved list entries. > > > > Regards, > > James > > > > > > _______________________________________________ > > ire mailing list > > ire@ietf.org > > https://www.ietf.org/mailman/listinfo/ire > > > > > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire --_000_CD8AACD3FE73gustavolozanoicannorg_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
James,


Regards,
Gustavo

From: James Mitchell <james.mitchell@ausregist= ry.com.au>
Date: Tuesday= , April 9, 2013 9:02 AM
To: Bha= dresh Modi <bmodi@afilias.info= >, "ire@ietf.org" <ire@ietf.org>
Subject: Re: [ire] Variant Domain Names
Apologies, I was intending to use the term "activ= ated". I have "allocated" on my mind from the launch di= scussions..

Thanks,
James

=
From: Bhadresh Modi <= bmodi@afilias.info>
Date: Tuesday, 9 April 2013 3:06 AM
To: "ire@ietf.org" <ire@ietf.org= >
Subject: Re: [ire] Vari= ant Domain Names

More precise terms are c= ertainly helpful, I think the main point is that the current set of "b= locked" and "withheld" as shown in the draft is insufficient= .

Perhaps it makes sense to simply use the same terms wit= h the same definitions from the IDN TLD project that Andrew provided.
=

Regards,
Bhadresh

On Mon, Apr 8, 2013 at 12:49 PM, Andrew Sullivan <ajs@anvilwa= lrusden.com> wrote:
I have no idea how those terms got adopted, but I'd like to point out
the distinctions that were made by the variant issues project/IDN TLD
project:

Delegated: actually in a zone with an SOA and parent NS RRset.

Activated: in the DNS somehow.  (Delegated is a species of activated.<= br> For instance, a DNAME would be activated but not delegated.)

Allocated: someone has administrative control over the name, but it is
not activated.  For instance, any domain on Hold in EPP would be
allocated.

Blocked: nobody is allowed to register the name.  For instance, in
.com nobody may register the label example (so example.com is
blocked).

I think these distinctions are all extremely useful.

On Mon, Apr 08, 2013 at 12:07:18PM -0400, Bhadresh Modi wrote:
> I agree - we were using the "allocated" value in the previou= s revision to
> differentiate between IDN variants that simply blocked registration an= d
> variants that would actual resolve similar to the original domain name= .
>  With the omission of this value there is no longer any way to ex= press this.
>
> Regards,
> Bhadresh
>
>
> On Mon, Apr 8, 2013 at 3:29 AM, James Mitchell <
> james.mitchell@au= sregistry.com.au> wrote:
>
> > Gustavo,
> >
> > I would like the nameState of NNDNs to include "activated&qu= ot;. The
> > "allocated" value was in revision =9601, however seems = to have disappeared
> > without reason? Adding "allocated" would make the NNDN = consistent with the
> > text in Section 6 that states that either domain objects or NNDNs= may be
> > used to represent variants.
> >
> > Also, the NNDN <crDate> should be optional as some registri= es may not
> > track the creation date of reserved list entries.
> >
> > Regards,
> > James
> >
> >
> > _______________________________________________
> > ire mailing list
> > ire@ietf.org
> > https://www.ietf.org/mailman/listinfo/ire
> >
> >

> _______________________________________________
> ire mailing list
> ire@ietf.org
> https://www.ietf.org/mailman/listinfo/ire


--
Andrew Sullivan
ajs@anvilwalru= sden.com
_____= __________________________________________
ire mailing list
ire@ietf.org
https:= //www.ietf.org/mailman/listinfo/ire
<= br>
 --_000_CD8AACD3FE73gustavolozanoicannorg_-- From fobispo@isc.org Tue Apr 9 22:28:58 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE85C21F9377 for ; Tue, 9 Apr 2013 22:28:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPO8ciBx27w1 for ; Tue, 9 Apr 2013 22:28:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 403B621F92CF for ; Tue, 9 Apr 2013 22:28:58 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C1263C94DF; Wed, 10 Apr 2013 05:28:51 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1365571737; bh=cAB1ur5Fy50ri4pwhU5Nex1M0uQby9s/qXxbfhm8tUE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=JBYLwpY90iQGzJeDXDaQjf8n53tklaIquJF7dEQNsKAWj1Uiids5rRMUO3IJiEko2 0Mc8mofYMdnN+6F4PPgBXF7EjR3MY3OpGnH9gG8AJbPMDofSvcGf6+yfYcVLsyDV2Y smYtP9dRMrsksNFtZ4wY9GQLcPlNQmf4qwt5XdcI= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 10 Apr 2013 05:28:51 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.120] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A54C2216C3B; Wed, 10 Apr 2013 05:28:51 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Francisco Obispo In-Reply-To: Date: Tue, 9 Apr 2013 22:28:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James Mitchell X-Mailer: Apple Mail (2.1503) X-DCC--Metrics: post.isc.org; whitelist Cc: "ire@ietf.org" Subject: Re: [ire] Deposit Identifiers X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 05:28:58 -0000 I would suggest using something like UUID for unique identifiers, or = worst case, just free text. We had a discussion the other day with regards to ROID and its nonsense = format on provreg, and I think we should avoid it here if all possible. On Apr 5, 2013, at 3:24 AM, James Mitchell = wrote: > If global uniqueness is required, we would like to use the = concatenation of the TLD name and date, however the format does not = currently allow this. We suggest the depositIdType pattern is updated to = use a modified ROID pattern that allows hyphens, e.g. , allowing for identifiers such as = id=3D"xn--punycode-20130405". This pattern would be reasonably = consistent with the reference to RFC 5730. >=20 Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From jkeating@afilias.info Wed Apr 24 10:56:15 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B13C21F8A6B for ; Wed, 24 Apr 2013 10:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teNxfjDqdoiv for ; Wed, 24 Apr 2013 10:56:15 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id D6C4621F898B for ; Wed, 24 Apr 2013 10:56:14 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UV3vS-0002YV-4y for ire@ietf.org; Wed, 24 Apr 2013 17:56:14 +0000 Received: from mail-ea0-f198.google.com ([209.85.215.198]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UV3vS-0004bq-4W for ire@ietf.org; Wed, 24 Apr 2013 17:56:14 +0000 Received: by mail-ea0-f198.google.com with SMTP id a11so2832575eae.5 for ; Wed, 24 Apr 2013 10:56:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=cmKx866c5QtU8oWrrjM+BP9rxaD0eMDoJEdg6Q+hGb0=; b=AhjJH3FcEi2OiEacYb2e0MylOPJGr51yPnANqFKzUPSZHZHR/jzv0iS+zTSX+xABgN qBpmaeFtOxRhPYh4m6ACNOsvnMLpjeyI1SCn0ZXsbNGSYUxikfwKW/4R3tKx5kFl9y5N fRH5RiqDZSkuF0JK5k2CPMq8XmVrZj0L17yyCBAYf+CmpJ4WkG1iD6CiHNDdoe3Ej3s/ DVGWQFO+bVdrEPWOX3KTVV3aYENxRDJ2tevL0mpdgKtnuVWiI0TcnEKgg757bNRKw9IV F0Jf0MmBPBkM+aI1M3zcJwYA7PNBtZgu9gUxsOJNsegkqgcANNpxE2xmixAhHRE3zCID Zsig== X-Received: by 10.14.110.198 with SMTP id u46mr66040553eeg.41.1366826168184; Wed, 24 Apr 2013 10:56:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.110.198 with SMTP id u46mr66040538eeg.41.1366826168097; Wed, 24 Apr 2013 10:56:08 -0700 (PDT) Received: by 10.223.84.196 with HTTP; Wed, 24 Apr 2013 10:56:07 -0700 (PDT) Date: Wed, 24 Apr 2013 13:56:07 -0400 Message-ID: From: John Keating To: ire@ietf.org Content-Type: multipart/alternative; boundary=089e0158c2263857c604db1f0402 X-Gm-Message-State: ALoCoQkKt/AtYMgmKBLk88nJmBeTFz9/gJnCR4jfS2cZZcS4+QBNgiAU7/6fkrB4E6RDukKR+LDEzs5nBhMjfaxItTtV3G+b92oD5iE2VnFSzwZKJocIfGjPfxhp73BwR+Zhg537IpSb Subject: [ire] rdeDomain-1.0.xsd in objects-mapping-03 doc X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:04:59 -0000 --089e0158c2263857c604db1f0402 Content-Type: text/plain; charset=ISO-8859-1 The domain xsd is different from the other types (registrar, contact, host, etc). All of the xsd files for the other types start their definition like this contact example: Registry Data Escrow contact provisioning schema However, the domain xsd starts its definition like this, with no substitutionGroup for the abstractDomain: Registry Data Escrow Domain provisioning schema This gives a validation error for the first in the file: cvc-complex-type.2.4.a: Invalid content was found starting with element 'rdeDom:domain'. One of '{"urn:ietf:params:xml:ns:rde-1.0":content}' is expected. If I change the domain xsd so that it looks like all of the other types: becoming: Then the xml output (which matches the examples) passes validation. Has anyone else run into this? --089e0158c2263857c604db1f0402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The domain xsd is different = from the other types (registrar, contact, host, etc).

All of t= he xsd files for the other types start their definition like this contact e= xample:

=A0=A0 <annotation>
=A0=A0=A0=A0 <documentation>
=A0= =A0=A0=A0=A0=A0 Registry Data Escrow contact provisioning schema
=A0=A0= =A0=A0 </documentation>
=A0=A0 </annotation>

=A0=A0 &= lt;element name=3D"abstractContact" type=3D"rdeContact:abstr= actContentType"
=A0=A0=A0=A0 substitutionGroup=3D"rde:content" abstract=3D"t= rue"/>
=A0=A0 <element name=3D"contact"
=A0=A0= =A0=A0 substitutionGroup=3D"rdeContact:abstractContact"/>
= =A0=A0 <element name=3D"delete" type=3D"rdeContact:delete= Type"
=A0=A0=A0=A0 substitutionGroup=3D"rde:delete"/>


However, the domain xsd starts its definition like this, with no substit= utionGroup for the abstractDomain:

=A0=A0 <annotation>
=A0= =A0=A0=A0 <documentation>
=A0=A0=A0=A0=A0=A0 Registry Data Escrow Domain provisioning schema
=A0= =A0=A0=A0 </documentation>
=A0=A0 </annotation>

=A0= =A0 <element name=3D"abstractDomain" type=3D"rdeDomain:ab= stractContentType"/>
=A0=A0 <element name=3D"domain" substitutionGroup=3D"rdeD= omain:abstractDomain"/>
=A0=A0 <element name=3D"delete&q= uot; type=3D"rdeDomain:deleteType"
=A0=A0=A0=A0 substitutionGr= oup=3D"rde:delete"/>

This gives a validation error for the first <rde:Dom:domain>= ; in the file:

cvc-complex-type.2.4.a: Invalid content was found sta= rting with element 'rdeDom:domain'. One of '{"urn:ietf:par= ams:xml:ns:rde-1.0":content}' is expected.

If I change the domain xsd so that it looks like all of the other= types:

<element name=3D"abstractDomain" type=3D"r= deDomain:abstractContentType"/>

becoming:

<e= lement name=3D"abstractDomain" type=3D"rdeDomain:abstractCon= tentType"
=A0 substitutionGroup=3D"rde:content" abstract=3D"true"= ;/>

Then the xml output (which matches the examples) passes= validation.

Has anyone else run into this?


--089e0158c2263857c604db1f0402-- From jkeating@afilias.info Wed Apr 24 11:57:38 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AD621F8F08 for ; Wed, 24 Apr 2013 11:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz0WajbKOGo8 for ; Wed, 24 Apr 2013 11:57:38 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E141621F8EF5 for ; Wed, 24 Apr 2013 11:57:37 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UV4sr-0000pc-4u for ire@ietf.org; Wed, 24 Apr 2013 18:57:37 +0000 Received: from mail-ea0-f199.google.com ([209.85.215.199]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UV4sr-0008Sr-47 for ire@ietf.org; Wed, 24 Apr 2013 18:57:37 +0000 Received: by mail-ea0-f199.google.com with SMTP id h14so2792104eak.10 for ; Wed, 24 Apr 2013 11:57:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=zhJMmKMSGtVEUK1W3UCJn6LJ/mG1ALnfOldqH1ebSmw=; b=M7D+hTUblVEHDan7rWcw74cgh32iHXaKFMJSXYfQ7dt3xBc2smE4mLIT1TlrjpoXHc ynQ6/yBo7Mf60sgvp8eddjYZgI+hVigxmN+wcju5aMNhFlARUvNppiontYsPuNwQZKpa EEF6JaVbpnlMZhNE0OO/SZpsQWEtHn/yuQf7rC6heMjT1wj8Z8pSVs8vOrRJusjQvRCY UGfbPf6HaFdHqkJpGXj+ruBZD92CV6yVbnw0noRvNCOGP0d0WrOgAhfKodkOUucCOnTn Tck6uhm3IGs5PZ1g44p4ftmU2wz7uPCZlkwskMt0K1Y6Ip/C1AB0dznX3JtLBlwh2UcT Uw2Q== X-Received: by 10.14.9.71 with SMTP id 47mr21954321ees.21.1366829851165; Wed, 24 Apr 2013 11:57:31 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.9.71 with SMTP id 47mr21954306ees.21.1366829851080; Wed, 24 Apr 2013 11:57:31 -0700 (PDT) Received: by 10.223.84.196 with HTTP; Wed, 24 Apr 2013 11:57:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Apr 2013 14:57:30 -0400 Message-ID: From: John Keating To: ire@ietf.org Content-Type: multipart/alternative; boundary=001a11c277b6be29d904db1fdfc3 X-Gm-Message-State: ALoCoQlhdIVhFhLm3NhxeTBWdB72OO6LDZ/rPl+0j839JoMxcX17oPVaV6uplpLqLYAdsBXv6hRrKnpBLqdEUIvn22DdhJNeVCiG1EA6klmaeS/bkStw7vb3TfiJbPT5gEiG00JuVEIS Subject: Re: [ire] rdeDomain-1.0.xsd in objects-mapping-03 doc X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 18:57:38 -0000 --001a11c277b6be29d904db1fdfc3 Content-Type: text/plain; charset=ISO-8859-1 An error in my post: "This gives a validation error for the first in the file:" Our xml does NOT contain the tag: ; it's as it should be. On Wed, Apr 24, 2013 at 1:56 PM, John Keating wrote: > The domain xsd is different from the other types (registrar, contact, > host, etc). > > All of the xsd files for the other types start their definition like this > contact example: > > > > Registry Data Escrow contact provisioning schema > > > > substitutionGroup="rde:content" abstract="true"/> > substitutionGroup="rdeContact:abstractContact"/> > substitutionGroup="rde:delete"/> > > > However, the domain xsd starts its definition like this, with no > substitutionGroup for the abstractDomain: > > > > Registry Data Escrow Domain provisioning schema > > > > > > substitutionGroup="rde:delete"/> > > This gives a validation error for the first in the file: > > cvc-complex-type.2.4.a: Invalid content was found starting with element > 'rdeDom:domain'. One of '{"urn:ietf:params:xml:ns:rde-1.0":content}' is > expected. > > If I change the domain xsd so that it looks like all of the other types: > > > > becoming: > > substitutionGroup="rde:content" abstract="true"/> > > Then the xml output (which matches the examples) passes validation. > > Has anyone else run into this? > > > --001a11c277b6be29d904db1fdfc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
An error in my post:

"This gives a valida= tion error for the first <rde:Dom:domain> in the file:"

<= /div>Our xml does NOT contain the tag:=A0 <rde:Dom:domain>; it's = <rdeDom:domain> as it should be.



On Wed, Apr 24, 2013 at 1:56 PM, John Keating <= ;jkeating@afilia= s.info> wrote:
The domain xsd is different from the other types (registrar, contact, ho= st, etc).

All of the xsd files for the other types start their definition l= ike this contact example:

=A0=A0 <annotation>
=A0=A0=A0=A0 <documentation>
=A0= =A0=A0=A0=A0=A0 Registry Data Escrow contact provisioning schema
=A0=A0= =A0=A0 </documentation>
=A0=A0 </annotation>

=A0=A0 &= lt;element name=3D"abstractContact" type=3D"rdeContact:abstr= actContentType"
=A0=A0=A0=A0 substitutionGroup=3D"rde:content" abstract=3D"t= rue"/>
=A0=A0 <element name=3D"contact"
=A0=A0= =A0=A0 substitutionGroup=3D"rdeContact:abstractContact"/>
= =A0=A0 <element name=3D"delete" type=3D"rdeContact:delete= Type"
=A0=A0=A0=A0 substitutionGroup=3D"rde:delete"/>


However, the domain xsd starts its definition like this, with no substit= utionGroup for the abstractDomain:

=A0=A0 <annotation>
=A0= =A0=A0=A0 <documentation>
=A0=A0=A0=A0=A0=A0 Registry Data Escrow Domain provisioning schema
=A0= =A0=A0=A0 </documentation>
=A0=A0 </annotation>

=A0= =A0 <element name=3D"abstractDomain" type=3D"rdeDomain:ab= stractContentType"/>
=A0=A0 <element name=3D"domain" substitutionGroup=3D"rdeD= omain:abstractDomain"/>
=A0=A0 <element name=3D"delete&q= uot; type=3D"rdeDomain:deleteType"
=A0=A0=A0=A0 substitutionGr= oup=3D"rde:delete"/>

This gives a validation error for the first <rde:Dom:domain>= ; in the file:

cvc-complex-type.2.4.a: Invalid content was found sta= rting with element 'rdeDom:domain'. One of '{"urn:ietf:par= ams:xml:ns:rde-1.0":content}' is expected.

If I change the domain xsd so that it looks like all of the other= types:

<element name=3D"abstractDomain" type=3D"r= deDomain:abstractContentType"/>

becoming:

<e= lement name=3D"abstractDomain" type=3D"rdeDomain:abstractCon= tentType"
=A0 substitutionGroup=3D"rde:content" abstract=3D"true"= ;/>

Then the xml output (which matches the examples) passes= validation.

Has anyone else run into this?



--001a11c277b6be29d904db1fdfc3-- From jkeating@afilias.info Wed Apr 24 12:25:02 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D0221F8E8F for ; Wed, 24 Apr 2013 12:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSxDBjoEkKvA for ; Wed, 24 Apr 2013 12:25:02 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id B920B21F8E4B for ; Wed, 24 Apr 2013 12:25:01 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1UV5JN-0004IH-3t for ire@ietf.org; Wed, 24 Apr 2013 19:25:01 +0000 Received: from mail-ea0-f200.google.com ([209.85.215.200]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UV5JN-0001gi-3Q for ire@ietf.org; Wed, 24 Apr 2013 19:25:01 +0000 Received: by mail-ea0-f200.google.com with SMTP id z7so2926857eaf.7 for ; Wed, 24 Apr 2013 12:24:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=7jsUEoE26CTYIX1RX5ErpdBSKwlZd+llZzi4+QR+slQ=; b=jeywmp5PlXhORfxem6ihNE5S1mGTfmOrOJOieL6Xig7REYInZw4qZeaLIexilSTwqo GLtv2hwYQ3A3eK4ox68oz6bs0uki/I74J6MkcA4+hwrF20d9b+Apy8dN2AYkD/1xjpaq /hQdECutzNyLzJrvqgD77WUpGwrgFZa+7Nc7KTvemP2PL7rUeZ/BgL9FdEqktm5+F7ks oxVMg4pfJybek10DfcUUjOle8dSIQOSuQq6YwBetbFChODn6Rj6B2eIyXj1zXLxIK+Vn edmHu+RuYKSAUamUtvavPopZ8P0mcLmekwu0G18XHuVTICPhhbzhpcjGgeLXslRHFtNl H1Kg== X-Received: by 10.14.194.70 with SMTP id l46mr19628126een.28.1366831494876; Wed, 24 Apr 2013 12:24:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.194.70 with SMTP id l46mr19628120een.28.1366831494809; Wed, 24 Apr 2013 12:24:54 -0700 (PDT) Received: by 10.223.84.196 with HTTP; Wed, 24 Apr 2013 12:24:54 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Apr 2013 15:24:54 -0400 Message-ID: From: John Keating To: ire@ietf.org Content-Type: multipart/alternative; boundary=047d7b343e34b7822904db204102 X-Gm-Message-State: ALoCoQkVyqGGHfOKK6fuMc4e6p3lKxlmuADutKQtSsfpsndrdBfB9X6VkXttPn2hcE7OlxE7+MVvEUnRAHf/yaE6g8dHQzhzPGCT28WlOMPmxtJhwBByy5FC+O8mlCkwb6l/9zyY4nic Subject: [ire] rdeDomain-1.0.xsd in objects-mapping-03 doc X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 19:25:02 -0000 --047d7b343e34b7822904db204102 Content-Type: text/plain; charset=ISO-8859-1 Turns out the domain xsd is not different from the others. My bad. Can we please delete this thread? --047d7b343e34b7822904db204102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Turns out the domain xsd is not different from the others.= =A0 My bad.=A0 Can we please delete this thread?

--047d7b343e34b7822904db204102-- From johnsonhammond1@hushmail.com Sat Apr 27 14:57:07 2013 Return-Path: X-Original-To: ire@ietfa.amsl.com Delivered-To: ire@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1021F990D for ; Sat, 27 Apr 2013 14:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wrN2D0LlpwH for ; Sat, 27 Apr 2013 14:57:07 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 71B8621F991C for ; Sat, 27 Apr 2013 14:57:07 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id CA9D3E7AAD for ; Sat, 27 Apr 2013 17:47:12 +0000 (UTC) X-hush-relay-time: 214 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:47:12 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 9359CE6739; Sat, 27 Apr 2013 17:47:12 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:47:12 -0400 To: ire@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427174712.9359CE6739@smtp.hushmail.com> Subject: [ire] Biggest Fake Conference in Computer Science X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 21:57:07 -0000 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 any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.
On version 02, t= he IDN variants model for data escrow was updated based on feedback from th= e list, private emails and internal discussions. 

Suppose caf=E9.example is a mirroring variant for cafe.example.=

<= font face=3D"Calibri,sans-serif">Following the current version of the draft= the registry would escrow:

<rdeDom:doma= in>
<rdeDom:name>xn--caf-= dma.example</rdeDom:name>
&l= t;rdeDom:originalName>cafe.example</rdeDom:originalName>
......
</rdeDom:domain>

I'd propose a slight change from version 01 draft to be incorporated i= n the next version of the data escrow mappings specification as follows:

   <rdeNNDN:NNDN>
     <rdeNNDN:aNa= me>xn--caf-dma.example</rdeNNDN:aName>
     <rdeNNDN:originalName>caf= e.example</rdeNNDN:originalName>
     <rdeNNDN:nameState>mirrored</rd= eNNDN:nameState>
&nbs= p;    <rdeNNDN:crDate>2005-04-23T11:49:00.0Z</rdeNNDN:cr= Date>
   &l= t;/rdeNNDN:NNDN>

=
The proposal is that na= meState=3Dmirrored would mean that the NNDN is a mirrored variant, i.e., th= e NNDN name implicitly has the same data as the originalName. The other two= states mentioned in the Integrated Issues Report on IDN variants are not n= eeded since the registry would need a domain object to include data fields = that diverge from those in the orginalName.

An optional attribute "noNSmirroring" would mean when true, that= mirroring is NOT based in the default NS mirroring. 

Default NS mirroring means:
* If the originalName is present in the DNS zone file, = the NNDN mirror variant name (NNDN:aName) is also present in the DNS zone f= ile with the same NS as the original name. 
* The Registry MUST satisfies glue record requirem= ents of the mirrored variants in the escrow deposit, but the Data Escrow Ag= ent does not verify this.

Whether mirrored = DNAME (or something else?) is used, will have to be discovered by analyzing= the DNS zone file and/or reviewing the relevant IDN policy.

Just to clarify, the blocked and withheld states can be u= sed not only for IDN variants. There are registry services that may require= these states. The mirrored state would ONLY be used for IDN variants.

NNDN and Domain objects variants are explicit v= ariants.  Algorithmically generated variants are generated based in th= e IDN policy document referenced by urlPolicy.

Comments are welcome.