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

[Joel M. Halpern]

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" 
发送时间: 2019-03-08 07:33:32 (星期五)
收件人: gen-...@ietf.org
抄送: draft-ietf-regext-bundling-registration@ietf.org, i...@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

.

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  command seems lacking.  After
saying that it needs an extension element, it says:
 The  element SHOULD contain a child  element
 that identifies the bundle namespace and the location of the bundle
 name schema.
It is unclear when it is reasonable to omit this  element.  (We
normally include with "SHOULD" explanations of this sort.) It is unspecified
what format of the information in the  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  given in the
schema is the  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  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  command, the 7.2.4 EPP
  command, and the 7.2.5 EPP  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-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art



___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Jiankang Yao]

> -原始邮件-
> 发件人: "Joel Halpern via Datatracker" 
> 发送时间: 2019-03-08 07:33:32 (星期五)
> 收件人: gen-...@ietf.org
> 抄送: draft-ietf-regext-bundling-registration@ietf.org, i...@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
> 
> .
> 
> 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  command seems lacking.  After
>saying that it needs an extension element, it says:
> The  element SHOULD contain a child  element
> that identifies the bundle namespace and the location of the bundle
> name schema.
> It is unclear when it is reasonable to omit this  element.  (We
> normally include with "SHOULD" explanations of this sort.) It is unspecified
> what format of the information in the  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  given in the
> schema is the  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  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  command, the 7.2.4 EPP
>  command, and the 7.2.5 EPP  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
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Secdir last call review of draft-ietf-regext-bundling-registration-09

[Jiankang Yao]

<   From: Russ Housley via Datatracker
<   Date: 2019-03-09 13:24
<   To: sec...@ietf.org
<   CC: draft-ietf-regext-bundling-registration.all; ietf; regext
<   Subject: [regext] Secdir last call review of 
draft-ietf-regext-bundling-registration-09
<   Reviewer: Russ Housley
<   Review result: Has Issues
<   I reviewed this document as part of the Security Directorate's 
ongoing
<   effort to review all IETF documents being processed by the IESG. 
These
<   comments were written primarily for the benefit of the Security Area
<   Directors. Document authors, document editors, and WG chairs should
<   treat these comments just like any other IETF Last Call comments.
<   Document: draft-ietf-regext-bundling-registration-09
<   Reviewer: Russ Housley
<   Review Date: 2019-03-09
<   IETF LC End Date: 2019-03-15
<   IESG Telechat date: unknown

Thanks for your kind review.

<   Summary: Has Issues
<   Major Concerns:
<   If this document is going to be published on the IETF Stream, then 
the
<   IANA registrations should point to the IESG, not the document 
authors.

We will update it. IANA registrations will point to the IESG.


<   Minor Concerns:
<   Section 2: Please update the first paragraph to reference RFC 8174
<   in addition to RFC 2119, as follows: 
<   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
<   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
<   "OPTIONAL" in this document are to be interpreted as described in
<   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
<   capitals, as shown here.

Thanks, will update it. 

<   Nits:
<   The document has many grammer errors. For example, the first 
paragraph
<   of the Introduction has three things that need to be corrected:
-  s/which has identical/which have identical/
-  s/labels(LABEL)/labels (LABEL)/
-  s/(V-tld);/(V-tld)./
<   In addition, there are several places in the document with arbitrary
<   extra white space. For example, in Section 8, it says:
<   
<   Please correct the grammar and eliminate the extra white space.
<   Ins Section 7.2.2, some of the lines in the examples do not begin
<   with "S:". Please correct.
<   ___

Thanks, we will have a detailed review and update it in the new version.


Jiankang Yao


<   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

Re: [regext] AD Review: draft-ietf-regext-bundling-registration

[Jiankang Yao]

< From: Adam Roach
< Date: 2019-03-02 06:17
< To: draft-ietf-regext-bundling-registration.all
< CC: Registration Protocols Extensions
< Subject: AD Review: draft-ietf-regext-bundling-registration
< This is my Area Director review for 
< draft-ietf-regext-bundling-registration. I
< have a handful of comments on the document's comments, but none are of the
< nature that preclude going into IETF last call, which should begin shortly.
< Please treat my comments below the same as as IETF last call comments.
< Thanks to everyone who worked on this specification.
< ---

Thanks a lot to AD's kind and detail review.

< General: This document is grammatically incorrect or awkward in many 
< places in
< a way that detracts from its readability. I believe it would benefit from an
< editorial pass by a skilled editor. I call out specific issues in section 1
< below; however, in the interest of primarily reviewing the technical content
< of this document, I have not indicated them for other sections.
< ---
< §1:
< Bundled domain names are those which share the same TLD but whose
  xn--
<  fsq270a.example
< I presume that this would literally be:
<  xn--fsq270a.example
< ...and that the use of the "U+" format is to deal with the current
< restrictions on the RFC format, correct? If so, the handling of 
< quotation marks
< in the preceding example is very confusing: XML requires attributes to be
< fully enclosed in quotation marks, and the current example leaves ".example"
< outside of them.
< Consider using the XML escaping mechanism in these examples instead:
<  
< xn--fsq270a.example
< Alternately, if you want to use the format described in Section 2, this 
< would
< look like:
<  xn--fsq270a.example
< I would, however, advise using a different convention than this, as it is
< somewhat difficult to read.
< This same comment applies to other examples of the "uLabel" attribute as 
< well.
< ---

Thanks.
We will see whether useor  
 .
either way has advantage and disadvantage. 


< §7.2.1:
< The  element SHOULD contain a child
  element that identifies the bundle namespace and the
 location of the bundle name schema.
< This description appears to be somewhat incomplete; the example shows it 
< also
< containing a  element. Please either expand the text to 
< include the
< purpose and meaning of the  element in this context; or, if it 
< should
< not be in the example, remove it from the example.
< ---

Ok, thanks. We will update it.


< §8:
< 
< 
< 
< 
< 
< 
< >
< 
< 
< 
< 
< 
< Although there's nothing syntactically wrong with it, the use of 
< "trnDataType"
< (implying "" operations) for all six operations is a bit 
< confusing.
< Consider renaming something like "bundleDateType".
<

Good suggestion. We will consider to use   "bundleDateType".


Jiankang Yao

< /a___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext