Re: [regext] Spencer Dawkins' No Objection on draft-ietf-regext-org-ext-09: (with COMMENT)

"Linlin Zhou" <> Mon, 29 October 2018 03:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6604612DD85; Sun, 28 Oct 2018 20:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CPcyYGR5PcK7; Sun, 28 Oct 2018 20:00:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB5E3126CB6; Sun, 28 Oct 2018 20:00:43 -0700 (PDT)
Received: from zll (unknown []) by (Coremail) with SMTP id AQAAf0BJUAjRd9Zb7u0EAA--.3550S2; Mon, 29 Oct 2018 11:00:33 +0800 (CST)
Date: Mon, 29 Oct 2018 11:01:45 +0800
From: "Linlin Zhou" <>
To: "Spencer Dawkins" <>, iesg <>
Cc: regext-chairs <>, "Pieter Vandepitte" <>, regext <>, draft-ietf-regext-org-ext <>
References: <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart036438671175_=----"
X-Coremail-Antispam: 1UD129KBjvJXoW7ZF43uF1fGFy8uF48uw1fCrg_yoW8CFykpF 43Cw47Kr1DJr1UJ34xZr1UJw1Y9F4fJayUJFnxtr1vkFy5AF1DKF1Skr1rAryUGr9Yqr18 Xr1UCryjgw1UA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUH2b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kEwI0E Y4vaYxAvb48xMc02F40E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAFz48EcVAYj2 1lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkE bVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0F y26I8I3I1l7480Y4vEI4kI2Ix0rVAqx4xJMxkIecxEwVAFwVW8GwCF04k20xvY0x0EwIxG rwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4 vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IY x2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26c xKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7Cj xVAFwI0_Gr0_Gr1UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI43ZEXa7IU0x-P5UUUU U==
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <>
Subject: Re: [regext] Spencer Dawkins' No Objection on draft-ietf-regext-org-ext-09: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Oct 2018 03:00:49 -0000

Dear Spencer,
Thanks for your review. Please see my feedbacks inline.


Linlin Zhou
From: Spencer Dawkins
Date: 2018-10-25 10:25
To: The IESG
CC: regext-chairs; pieter.vandepitte; regext; draft-ietf-regext-org-ext
Subject: [regext] Spencer Dawkins' No Objection on draft-ietf-regext-org-ext-09: (with COMMENT)
Spencer Dawkins has entered the following ballot position for
draft-ietf-regext-org-ext-09: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
If "huh?" was a ballot position, I would have used it. I'm actually too
confused to ballot Discuss :-)
I see several subsections of the form
   This extension does not add any elements to the EPP <check> command
   or <check> response described in the EPP object mapping.
I see other subsections in the same section that say what the extension DOES,
not just what the extension does not do.
Is there anything that can be included in these sections to tell the reader
more about what the effect of using the extension actually is?
[Linlin] This is a relatively simple Command-Response Extension defined in section 2.7.3 in RFC 5730. The implementors can add some self-defined elements in the <extension> part, such as,
extension in the EPP command

C: <!-- EPPCommandName can be "create", "update", etc. --> 
C: <EPPCommandName> 
C: <object:command xmlns:object="urn:ietf:params:xml:ns:object"> 
C: <!-- One or more object-specific command elements. --> 
C: </object:command> 
C: </EPPCommandName> 
C: <extension> 
C: <!-- One or more server-defined elements. --> 
C: </extension> 

extension in the EPP response,
S: <result code="1000"> 
S: <msg lang="en">Command completed successfully</msg> 
S: </result> 
S: <extension> 
S: <!-- One or more server-defined elements. --> 
S: </extension> 
S: <trID> 
S: <clTRID>ABC-12345</clTRID> 
S: <svTRID>54321-XYZ</svTRID> 
S: </trID> 

This document extends the exsting EPP object mappings including the organization id and role type information. In section 4.1.1, the extension will not modify the <check> command and response, just keep it as it is defined in RFC5731-RFC5733.  In section 4.1.2, the extension has no change on <info> command, but extends the <info> response. So the document says "This extension does not add any elements to the EPP <info> command described in the EPP object mapping. However, additional elements are defined for the <info> response in the EPP object mapping." There is some explanations in the first paragraph of each  EPP commands section, to tell implementors if this command or response is extended. If it is extended, you can find extension elements in the following text.
regext mailing list