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

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

Regards,
Linlin

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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:<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> 
C:</command>

extension in the EPP response,
S:<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> 
S:</response>

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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext