> -----原始邮件----- > 发件人: "Joel Halpern via Datatracker" <noreply@xxxxxxxx> > 发送时间: 2019-03-08 07:33:32 (星期五) > 收件人: gen-art@xxxxxxxx > 抄送: draft-ietf-regext-bundling-registration.all@xxxxxxxx, ietf@xxxxxxxx, regext@xxxxxxxx > 主题: [regext] Genart last call review of draft-ietf-regext-bundling-registration-09 > > Reviewer: Joel Halpern > Review result: Almost Ready > > 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-bundling-registration-09 > Reviewer: Joel Halpern > Review Date: 2019-03-07 > IETF LC End Date: 2019-03-15 > IESG Telechat date: Not scheduled for a telechat > > Summary: This document is almost ready for publication as some form of RFC > Thanks for your kind review. > Major issues: > This document defines protocol extensions and mandatory procedures to go > with them. As such, it seems it is either Experimental or Proposed > Standard, but not Informational. > This document was originally for proposed standard. After WG's discussion, the WG decides to move it as informational. > Minor issues: > Section 5 consists of a list of behavioral requirements that appear > normative, but do not use RFC 2119 language. If these are indeed normative > behavioral requirements, the document should use RFC 2119 language to be > clear. (And therefore, should also include the text explaining and citing > RFC 2119.) > Yes, will update it. > The description in 7.2.1 of the EPP <create> command seems lacking. After > saying that it needs an extension element, it says: > The <extension> element SHOULD contain a child <b-dn:create> element > that identifies the bundle namespace and the location of the bundle > name schema. > It is unclear when it is reasonable to omit this <b-dn:create> element. (We > normally include with "SHOULD" explanations of this sort.) It is unspecified > what format of the information in the <b-dn:create> element has. I suspect > that it is assumed to be the same as some other piece of EPP information, but > it does not say so. The only child element for <b-dn:create> given in the > schema is the <b-dn:rdn> which is neither a namespace identifier nor a location > of the bundle name schema. > Thanks. We will consider to update it. > Again in 7.2.2 on the EPP <delete> command, when discussing the addition to > the response, it is a SHOULD with no explanation of when it is okay to omit > it. The same applies to the 7.2.3 EPP <renew> command, the 7.2.4 EPP > <transfer> command, and the 7.2.5 EPP <update> command. > Thanks. We will consider to change it to "MUST" or add some explanations. Best Regards. Jiankang Yao > Nits/editorial comments: > > > _______________________________________________ > regext mailing list > regext@xxxxxxxx > https://www.ietf.org/mailman/listinfo/regext
