Re: [Gen-art] Gen-art LC (and telechat) review for draft-ietf-regext-epp-rdap-status-mapping-01

"Gould, James" <> Mon, 10 October 2016 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C57B12958A for <>; Mon, 10 Oct 2016 10:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mWWmRexNn6OM for <>; Mon, 10 Oct 2016 10:43:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69A7D129585 for <>; Mon, 10 Oct 2016 10:43:54 -0700 (PDT)
Received: by with SMTP id m72so8110113oik.3 for <>; Mon, 10 Oct 2016 10:43:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=wgU33bclxOJeIDIcurLXrTQzgqcqJ53fitSKlA41NAI=; b=bwq/l1LQQALL5MchD95KuOkNxKT+ycxmlSngffcJPCquCAnjmI+1Qucjh2+x9Mffh0 v+3Ixf7nI+nvlxX7UixMPWJkoMcLmNW/DxnZnjFEWFtQyZg7oO0AvCwRInMdkFRKiaSY zbT8odHGY9/B1/XgBKIe2OsY66T1cnRcZ4b2ieE3Xw4UU1kcdDEY4rsXNOs9mwknwXp5 odH9FC1xgxDqb3n5Y3PzZcDgSIgpJk0Dg4AIKDSQ7pMzqe1Czh3ZQH4CIWku25VxXpq2 3XwOTrCHwP6SKspAV3YL32pyS2dFGEiuxN/lPUAwPpKfkQMI9PQY4paozSCPRWox9OPh N10w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=wgU33bclxOJeIDIcurLXrTQzgqcqJ53fitSKlA41NAI=; b=f6TCOI7uMrjh69BIqXNBK0IuQfRnyK02KX1GhSq4JMUVGW59CIPc1/s+zthzw3cE/s 0oSU6Ku83RVKdm+xsefbPKbAwTi3asE4a04nC3yM9rjaGhdlC7N7NLkCIzNtucepHjVK rVv8Anu3mZYySu840QQFOJf9dk4SkCvy44Z6mNvbklpdy+8KjHYC2j322lfkQ2NSdDsf n2OqCKOsfsheClxl0Y6icc3E7AJY/0D/YjpQqUmCiFfrDtVn12ADGFI7yTWWyA//OeyD j34kc9YBXZ3xLkC5wmoSesJeFXaekQd4JiVDj7izldijRh6NV4UNbazgYXlrZh5AN6cO wQ5g==
X-Gm-Message-State: AA6/9Rmi8W2fug5YqMVCEAvktdokTzmwO5loiT/1R0+KxYGWvzK00UviSwdnjDIbbXUOZccro88N8NzZ5NzoLJPQolSmx0Pl
X-Received: by with SMTP id k1mr33224810qtk.128.1476121432929; Mon, 10 Oct 2016 10:43:52 -0700 (PDT)
Received: from ( []) by with ESMTPS id j190sm1219033qkd.9.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 10 Oct 2016 10:43:52 -0700 (PDT)
Received: from (brn1wnexcas02 []) by (8.13.8/8.13.8) with ESMTP id u9AHhqUR032671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Oct 2016 13:43:52 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 13:43:49 -0400
From: "Gould, James" <>
To: Robert Sparks <>
Thread-Topic: Gen-art LC (and telechat) review for draft-ietf-regext-epp-rdap-status-mapping-01
Thread-Index: AQHSH0s0QR2PphM9rkml+sbHfJkdnqCiGmkAgAAlxAA=
Date: Mon, 10 Oct 2016 17:43:48 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_CBC40729-032A-42CE-A8C5-6D54B82A841B"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <>
Cc: General Area Review Team <>, "" <>, regext <>, "" <>
Subject: Re: [Gen-art] Gen-art LC (and telechat) review for draft-ietf-regext-epp-rdap-status-mapping-01
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Oct 2016 17:43:57 -0000

I incorporated Robert Sparks feedback and made the following editorial changes in the just published draft-ietf-regext-epp-rdap-status-mapping-02 draft:

Replaced the reference of “redemptionPeriod” to “redemption period” to use the RDAP form
Replaced the reference of “domain name” to “object” to not tie it to one object type
Replaced the reference of “registrar” to “client” and “registry” to “server” to be more consistent across the descriptions

Please review draft-ietf-regext-epp-rdap-status-mapping-02 and provide any feedback.




James Gould
Distinguished Engineer <applewebdata://3E726A32-6A60-4928-9840-5BA9DC4FC7E7/>

12061 Bluemont Way
Reston, VA 20190 <>
> On Oct 10, 2016, at 11:28 AM, Gould, James <> wrote:
> Robert,
> Thank you for your review and feedback.  I provide responses to your feedback below.
> —
> JG
> <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
> James Gould
> Distinguished Engineer
> <x-msg://81/>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> <>
>> On Oct 5, 2016, at 4:58 PM, Robert Sparks < <>> wrote:
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> For more information, please see the FAQ at
>> < <>>.
>> Document: draft-ietf-regext-epp-rdap-status-mapping-01
>> Reviewer: Robert Sparks
>> Review Date: 5 Oct 2016
>> IETF LC End Date: 10 Oct 2016
>> IESG Telechat date: 13 Oct 2016
>> Summary: This draft is on the right track but has open issues, described in the review.
>> Major Issue:
>> Many of the descriptions describe only side-effects of the status instead of the status itself.
>> All of the descriptions for the new rdap status codes start with "For DNR that indicates". This implies that there is a "For not DNR" case that's not discussed. I don't think the phrase is necessary and each description should look more like the other descriptions already registered at <>.
>> For instance, at 'auto renew period' the document currently says:
>> "For DNR that indicates if the object is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the auto renewal"
>> That discusses something (and not the only thing) that can happen while the object is in that state. It does not describe the state.
>> I suggest it should instead say (based on the text in 3915 and the current registry entry style):
>> "The object instance is in a grace period provided between when its registration period expires and when its registration is automatically renewed by the registry."
>> I don't think it's important to include the commentary about providing a credit if the entity is deleted by the registrar during this period, but since that commentary exists in 3915, you can include it if you want. The _important_ part to convey is the actual status.
> The “For DNR that indicates” can be removed from the descriptions.  For example, the "addPeriod = add period; For DRN that indicates if the object is …”  mapping could be "addPeriod = add period; If the object is …”.  The purpose of this draft is to map the statuses defined in EPP and RDAP, so the status descriptions included in the draft where taken from the EPP RFC’s.  There is no intent to redefine the statuses included in the EPP RFC’s in anyway.
>> All of the descriptions will need similar attention. Some of them (such as clientUpdateProhibited) currently have 2119 words in the description. That doesn't make sense - this is a status, not an protocol instruction, and trying to put normative language in a registry will lead to confusion about where the behavior you are trying to describe is actually defined. (To be fair, 5731 has this same problem). Again, I suggest following the style that's already in the registry and say something like "The client has requested that any requests to update this object instance be rejected."
> The clientUpdateProhibited status is defined as:
> clientUpdateProhibited = client update prohibited;  For DNR that
>        indicates the client requested that requests to update the object
>        (other than to remove this status) MUST be rejected.
> Where do you see 2119 words in the clientUpdateProhibited description?  The status descriptions were taken from the EPP RFC’s with no intent on changing their meaning.  
>> Minor Issues:
>> You're setting up a minor maintenance headache for any future work that might update this document by having the descriptions listed in two places. I don't think it's necessary to list the descriptions in section 2 (currently the bulk of page 4 and the beginning of page 5). Instead, stop after the paragraph that ends at the top of page 4, and note that the descriptions of each new status code are provided in section 3.
> The desire was for section 2 to stand on its own to define the statuses and the mapping, and for section 3 to be used to register the statuses in registry.  I believe it would be cleaner to duplicate the descriptions in this instance.  
>> Nits:
>> Near the end of page 3, the document says "In the DNR, the client and server prohibited statuses are separate an RDAP MUST support the same separation." There are several nits to address with this. That MUST is not a good use of 2119. DNR hasn't been expanded (and "the DNR" is not particularly clear).
>> I suggest you replace that sentence, and the one immediately before it with:
>> "EPP provides status codes that allow distinguishing the case that an action is prohibited because of server policy from the case that an action is prohibited because of a client request. The ability to make this distinction needs to be preserved in RDAP.”
> This change will be made.