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