Re: [regext] [Gen-art] Genart last call review of draft-ietf-regext-bundling-registration-09

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@ietf.org>
>> 发送时间: 2019-03-08 07:33:32 (星期五)
>> 收件人: gen-art@ietf.org
>> 抄送: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org
>> 主题: [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@ietf.org
>> https://www.ietf.org/mailman/listinfo/regext
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
> 