Re: [ire] Extended Verification Process - FQDN step
James Mitchell <james.mitchell@ausregistry.com.au> Tue, 02 April 2013 15:05 UTC
Return-Path: <james.mitchell@ausregistry.com.au>
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 <ire@ietfa.amsl.com>; 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 <ire@ietfa.amsl.com>; 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 <ire@ietf.org>; 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 <james.mitchell@ausregistry.com.au>
To: Gustavo Lozano <gustavo.lozano@icann.org>, David Kipling <David.Kipling@nccgroup.com>, "ire@ietf.org" <ire@ietf.org>
Date: Wed, 03 Apr 2013 02:05:17 +1100
Thread-Topic: [ire] Extended Verification Process - FQDN step
Thread-Index: Ac4vs3txWmWQ5IkyRdeqomCCLE45bQ==
Message-ID: <CD78A377.6F291%james.mitchell@ausregistry.com.au>
In-Reply-To: <CD7792D1.EA82%gustavo.lozano@icann.org>
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." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ire>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=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" <gustavo.lozano@icann.org> wrote: >Hi David, > >Comments inline. > >Regards, >Gustavo > >On 3/22/13 5:34 AM, "David Kipling" <David.Kipling@nccgroup.com> 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. >> >><rdeDom:name>example1.test</rdeDom:name> means the value of example1.test >>should not exist as a value of the <rdeNNDN:aName> tag e.g. >>rdeNNDN:aName>example1.test</rdeNNDN:aName> and vice versa so if the >>element <rdeNNDN:aName>xn--exampl-gva.test</rdeNNDN:aName> exists then >><rdeDom:name>xn--exampl-gva.test</rdeDom:name> should not exist in the >>deposit. > >You are correct. > > >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. > > >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. > > >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<http://www.nccgroup.com> >>Email: David.Kipling@nccgroup.com<mailto:David.Kipling@nccgroup.com> >> [http://www.nccgroup.com/media/192418/nccgrouplogo.jpg] >><http://www.nccgroup.com/> >>________________________________ >> >>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<http://www.nccgroup.com> >> >>P Before you print think about the ENVIRONMENT >> >> >>For more information please visit <a >>href="http://www.mimecast.com">http://www.mimecast.com<br> >>This email message has been delivered safely and archived online by >>Mimecast. >></a> >> > >_______________________________________________ >ire mailing list >ire@ietf.org >https://www.ietf.org/mailman/listinfo/ire
- [ire] Extended Verification Process - FQDN step David Kipling
- Re: [ire] Extended Verification Process - FQDN st… Gustavo Lozano
- Re: [ire] Extended Verification Process - FQDN st… James Mitchell