Subject: [regext] Genart last call review of draft-ietf-regext-allocation-token-09

From: Peter Yee <[email-masked]>
Date: Sun, 05 Aug 2018 22:12:58 -0700

Reviewer: Peter Yee
Review result: Ready with Nits

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-regext-allocation-token-09
Reviewer: Peter Yee
Review Date: 2018-08-05
IETF LC End Date: 2018-08-03
IESG Telechat date: 2018-08-16

Summary: The draft is ready with a nit and a question.

Major issues: N/A

Minor issues:

Page 6, 1st line: how is the client expected to differentiate between the two
reasons behind this response, so that it can remedy the problem?  [I'm not sure
this is considered much of a problem, so ignore this question if the handing is
well understood in the community.]

Nits/editorial comments:

Page 9, 1st partial paragraph, 2nd line: change "auhorization" to
"authorization".

---

From: "Gould, James" <[email-masked]>
Date: Mon, 6 Aug 2018 13:06:35 +0000

Peter,

Thank you for the review and feedback.  My responses are embedded below.

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 8/6/18, 1:13 AM, "Peter Yee" <[email-masked]> wrote:

    Reviewer: Peter Yee

    

    
    Major issues: N/A
    
    Minor issues:

JG - I assume that you're referring to the <domain:reason> value included in the "Example <check domain response".  The <domain:reason> is defined in RFC 5731 as containing "the server-specific text to help explain why the object cannot be provisioned".  Only the check command is extended (decorated) by draft-ietf-regext-allocation-token to support the client passing the allocation token to help the server determine the availability of the object with the allocation token.  The client should key off of the "avail" attribute to determine whether the object is available and if not the reason text provides why, per RFC 5731 or another EPP object mapping.

    Nits/editorial comments:

 JG-Thanks, that will fixed in draft-ietf-regext-allocation-token-10.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 Aug 2018 21:35:07 -0400

Peter, thanks for your review. James, thanks for your response. I entered a No Objection ballot.

Alissa

> On Aug 6, 2018, at 9:06 AM, Gould, James <jgould=[email-masked]> wrote:
> 
> Peter,
> 
> [email-masked] <mailto:[email-masked]>
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com <http://verisign.com/> <http://verisigninc.com/ <http://verisigninc.com/>> 
> 
> On 8/6/18, 1:13 AM, "Peter Yee" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>    Reviewer: Peter Yee
> _______________________________________________
> Gen-art mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>