Re: [regext] Artart telechat review of draft-ietf-regext-launchphase-06

Harald Alvestrand <harald@alvestrand.no> Mon, 11 December 2017 11:47 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA36120721; Mon, 11 Dec 2017 03:47:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 BsMpbEnLZseY; Mon, 11 Dec 2017 03:47:10 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20FC1201FA; Mon, 11 Dec 2017 03:47:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 506107C3579; Mon, 11 Dec 2017 12:47:08 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC9HJUg25R2F; Mon, 11 Dec 2017 12:47:07 +0100 (CET)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id C77017C0771; Mon, 11 Dec 2017 12:47:06 +0100 (CET)
To: "Gould, James" <jgould@verisign.com>, "art@ietf.org" <art@ietf.org>
Cc: "draft-ietf-regext-launchphase.all@ietf.org" <draft-ietf-regext-launchphase.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "regext@ietf.org" <regext@ietf.org>
References: <151256925917.30813.8696470899003053820@ietfa.amsl.com> <5575391F-7165-4A33-8D72-7AA5DECAE06D@verisign.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <b41abd7f-ece8-6af8-17b1-3a225e1e131d@alvestrand.no>
Date: Mon, 11 Dec 2017 12:47:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <5575391F-7165-4A33-8D72-7AA5DECAE06D@verisign.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/0wogSjmnAbWvvghMATJLzNJBZ30>
Subject: Re: [regext] Artart telechat review of draft-ietf-regext-launchphase-06
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Dec 2017 11:47:13 -0000

Den 06. des. 2017 20:18, skrev Gould, James:
> Harald, 
> 
> Thank you for your review and feedback, below are my answers to your feedback.
>   

Thanks for the quick response!
Deleting all below where you said "yes, we'll do that" and where I have
no further comment.




>     2.4
>     
>     This sentence: "if a launch status is supported and the launch status
>     is not one of the final statuses, including the "allocated" and
>     "rejected" statuses." makes equal grammatical sense if "allocated" and
>     "rejected" are final statuses or non-final statuses. Could be clearer.
> 
> Would the use of parenthesis work better as in the sentence below?
> “if a launch status is supported and the launch status is not one of the final statuses ("allocated" and "rejected").”

This is much more readable, thank you.

>     It is not clear what causes the transition from "validated" to
>     "pendingAllocation". It is also not clear if a transition possibility
>     exists straight from "validated" to "allocated" for the case where no
>     external process is needed.
> 
> The transitions between the statuses is up to the server policy.  There is no pre-defined timeframe that a domain must remain in a status.  In general, the processing is done asynchronously and based on a batch schedule, where a batch may validate thus putting the domains in the “validated” status.  A separate batch may prepare the domains for the allocation process thus putting the domains in the “pendingAllocation” status.  Finally, a batch will allocate the domains thus putting the domains in either the “allocated” or the “rejected” status.  
> 
> Yes, there can be a server policy that supports moving domains to the “validated” or “invalid” status in one step and then deciding on the allocation in a separate step synchronously.  In this case, there is no need for the “pendingAllocation” status.  
>   
> One scenario is that a pendingValidation domain may skip the validated status and transition immediately to the pendingAllocation status, or 

In that case, it would be clearer if the drawing was preceded by a
sentence saying: "The transitions between states is a matter of server
policy. One possible set of permitted transitions is given in the
diagram below".

This will make it clear to people that this isn't a total map of
possible transitions.


>     
>     2.5
>     
>     "A Launch Application MUST and a Launch Registration MAY" would be
>     clearer if there were commas around "and a Launch Registration MAY".
> 
> How about trying to fix the sentence overall, with the following two sentences?
> 
> “A Launch Application MUST be handled as an EPP domain name object, as specified in RFC 5731 [RFC5731], with the "pendingCreate" status and with the launch status values defined in Section 2.4.  A Launch Registration MAY be handled as an EPP domain name object, as specified in RFC 5731 [RFC5731], with the "pendingCreate" status and with the launch status values defined in Section 2.4.” 
> 

This looks good to me.


>     2.6.3
>     
>     This section's sentence structure is unclear due to a missing comma
>     before "or the <smd:encodedSignedMark>".
> 
> I believe the fix here is to remove “either” and the comma from the sentence as in:
> 
> “Digital signatures MAY be used by the server to validate the mark information when using the "signed mark" validation model with the <smd:signedMark> (Section 2.6.3.1) element or the <smd:encodedSignedMark> (Section 2.6.3.2) element.”
> 
> Do you agree that this is better?

I'm still a bit confused about where the beginning of the sentence is
that ends with "or". Is it obvious to everyone that the "signed mark"
validation model is used both with <smd:signedMark> and with
<smd:encodedSignedMark>? It's possible to read this as there being two
validation models, one that is called "signed mark and uses
<smd:signedMark>, and another one that's not named, but uses
<smd:encodedSignedMark>.


>     
>     3.1
>     
>     It is completely unclear what functional difference there is between
>     the "Claims Check Form" (3.1.1) and the "Trademark Check Form"
>     (3.1.3). I suspect the idea behind "whether or not there are any
>     matching trademarks, in the specified launch phase, for each domain
>     name passed in the command, that requires the use of the "Claims
>     Create Form" on a Domain Create Command." (3.1.1) versus "whether or
>     not there are any matching trademarks for each domain name passed in
>     the command, independent of the active launch phase of the server and
>     whether the "Claims Create Form" is required on a Domain Create
>     Command." (3.1.3) is that the latter will return claims info in cases
>     where the former would not, but it's not clear when this makes a
>     difference to the caller - the same reply info seems to be returned in
>     both cases.
>     
>     Another interpretation is that there exist trademarks that match in a
>     given phase and do not match outside that phase, so that the "claims
>     check form" may return matches that "trademark check form" would not -
>     this seems a bit bizarre.
>     
> The Trademark Check Form was explicitly requested on the list to support checking for the existence of trademarks independent of the active or specified phase and without requiring an indication that a claims notice is required on a domain create.  The primary purpose of a check is to indicate to the client whether a create will work, which is the goal of the Claims Check Form.  Depending on the phase, the Claims Check Form may not return the claims information because the create does not require it.  However, the Trademark Check Form will always return the claims information if there is at least one trademark associated with the domain name.  This is a subtle difference, but an important difference since some systems require providing the raw trademark information without including the extra phase-specific logic of the Claims Check Form.  
>     
> 

This makes perfect sense (if I interpret it correctly), and was the most
reasonable interpretation I had.

Would it make sense to add a sentence saying "The Trademark Check Form
will always return at least the marks returned by a similiar Claims
Check Form, but may return additional marks"?

Happy that the review was useful!

Harald