While the status is between you and the IESG, in my experience it is
very unusual for the IETF to define a protocol in an Informational RFC.
(I presume there are some exceptions.) The obvious move if the WG does
not want to publish it as standards track is to publish as an
experimental RFC.
Failing that, I hope that you have provided more justification than
"this is what the WG chose" to your area director.
I look forward to seeing the reolution on the other comments.
Yours,
Joel
On 3/14/19 11:16 PM, Jiankang Yao wrote:
-----原始邮件-----
发件人: "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
_______________________________________________
Gen-art mailing list
Gen-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/gen-art
