IETF Logo Mail Archive

Re: [eppext] [IANA #814915] INSERT “Extensible Provisioning Protocol Mapping: Defensive Registration"

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Thu, 02 April 2015 15:36 UTC

Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02491B2D35 for <eppext@ietfa.amsl.com>; Thu, 2 Apr 2015 08:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.431
X-Spam-Level:
X-Spam-Status: No, score=-5.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYqUHB0QPfmo for <eppext@ietfa.amsl.com>; Thu, 2 Apr 2015 08:36:12 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D1E1B2D2D for <eppext@ietf.org>; Thu, 2 Apr 2015 08:36:11 -0700 (PDT)
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Thu, 2 Apr 2015 17:36:09 +0200
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Thu, 2 Apr 2015 17:36:08 +0200
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: =?utf-8?B?W0lBTkEgIzgxNDkxNV0gSU5TRVJUIOKAnEV4dGVuc2libGUgUHJvdmlzaW9u?= =?utf-8?Q?ing_Protocol_Mapping:_Defensive_Registration"?=
Thread-Index: AQHQZYhaFeOqkYl/4EmwJrLXZ72BCp0qVaQQgA+BU4A=
Date: Thu, 2 Apr 2015 15:36:07 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE075467991BC@NICS-EXCH2.sbg.nic.at>
References: <RT-Ticket-814915@icann.org> <7F30D89F-28F5-47C1-B9B8-C6B2D032F45C@verisign.com> <rt-4.2.9-13014-1427128946-1178.814915-9-0@icann.org> <831693C2CDA2E849A7D7A712B24E257F49F89AE6@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F89AE6@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.163]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-XWALL-BCKS: auto
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/MJBwrlmzcHRMXeJBcLjgj9JO4Jw>
Subject: Re: [eppext] =?utf-8?q?=5BIANA_=23814915=5D_INSERT_=E2=80=9CExtensibl?= =?utf-8?q?e_Provisioning_Protocol_Mapping=3A_Defensive_Registration=22?=
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2015 15:36:13 -0000

Hi,

I've finished my review of the extension registration request, and my (nit-picking) comments are as follows:

- The previous comment about the "VERISIGN PROPRIETORY INFORMATION" does apply to the document as well.

 - section 3.1.1 mentions "fully qualified names of the Defensive Registration objects", but then lists the name of the objects in 
the example as "doe" and "john.doe". Understanding this is for the ".name" TLD, those objects don't seem to be "fully qualified", as 
they are missing the TLD (assuming these are objects related to domain names..). I do understand that Section 2.1 defines the format 
of the Defensive registrations, but the relation to "fully qualified" remains unclear..

- For the IDN case, the document could clarify the format of the Defensive registration "name" element. It's pretty obvious from the example
what's intended, but not specified in text. 

- I didn't formally check the XML Schema definition.

tia,
Alex


> -----BEGIN FORM-----
> Name of Extension:
> “Extensible Provisioning Protocol Mapping: Defensive Registration"
> 
> Document Status:
> Informational
> 
> Reference:
> http://www.verisigninc.com/assets/defensive-registration-mapping.pdf
> 
> Registrant Name and Email Address:
> VeriSign Inc., epp-registry@verisign.com
> 
> TLDs: .name
> 
> IPR Disclosure: None
> 
> Status: Active
> 
> Notes: None
> -----END FORM-----

v2.8.7 | Report a Bug | By Email