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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 15 March 2019 03:27 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3006126CAD; Thu, 14 Mar 2019 20:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EndHqFtpo1r1; Thu, 14 Mar 2019 20:27:15 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81255127876; Thu, 14 Mar 2019 20:27:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 44L9xH1rxkz17WVb; Thu, 14 Mar 2019 20:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1552620435; bh=tdCUNQaPA+jqzTabjNoI9XWGN5+fQxpLT9szrInKVSE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VW1UAl25rOVF/358ipbingDRFOGffJWn2eQkPtmW50fBeiGAg5uSqHUgbw1qHJ6Hw n6Is4Zah3qgoQjimTBnNgqTS+H0n1cMzEuY9ABzyIURXI2gjJ44qr+Xb6C5v3A4Rnl XdFqixrk+AXpx4wttAodBmIOLv+AHhVfCBswdVR0=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 44L9xG26hrzFpwR; Thu, 14 Mar 2019 20:27:14 -0700 (PDT)
To: Jiankang Yao <yaojk@cnnic.cn>
Cc: gen-art@ietf.org, draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org
References: <155200161246.5468.7896585235201756105@ietfa.amsl.com> <2a26b767.b09.1697f5a3e96.Coremail.yaojk@cnnic.cn>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <57d81b46-5d94-6044-7ab1-d7763997d63e@joelhalpern.com>
Date: Thu, 14 Mar 2019 23:27:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <2a26b767.b09.1697f5a3e96.Coremail.yaojk@cnnic.cn>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/INcq5a5cxUpl9eoZaarEc-XEkJM>
Subject: Re: [Gen-art] [regext] Genart last call review of draft-ietf-regext-bundling-registration-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2019 03:27:18 -0000

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
>