Subject: Genart last call review of draft-ietf-regext-bundling-registration-09

From: Joel Halpern via Datatracker <[email-masked]>
Date: Thu, 07 Mar 2019 15:33:32 -0800

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

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.

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.)

   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.

    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.

Nits/editorial comments:

---

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 15 Mar 2019 11:16:54 +0800 (GMT+08:00)

> -----原始邮件-----
> 发件人: "Joel Halpern via Datatracker" <[email-masked]>
> 发送时间: 2019-03-08 07:33:32 (星期五)
> 收件人: [email-masked]
> 抄送: [email-masked], [email-masked], [email-masked]
> 主题: [regext] Genart last call review of draft-ietf-regext-bundling-registration-09
> 
> Reviewer: Joel Halpern

Thanks for your kind review.

>     Standard, but not Informational.

This document was originally for proposed standard. After WG's discussion, the WG decides to move it as informational.

>     clear.  (And therefore, should also include the text explaining and citing

Yes, will update it.

> of the bundle name schema.

Thanks. We will consider to update it.

>     <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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 Mar 2019 23:27:12 -0400

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:
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 15 Mar 2019 15:13:07 +0100

- -- 
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

> Op 15 mrt. 2019, om 04:27 heeft Joel M. Halpern <[email-masked]> het volgende geschreven:
> 
> 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 think there is a slight misunderstanding here about the document status and IANA registration.
The EPP extension registry has 2 types of registrations:
(see https://datatracker.ietf.org/doc/rfc7451/ <https://datatracker.ietf.org/doc/rfc7451/>)

1. EPP standard track registrations:
These extensions have had thorough review and have consensus that these are standard extensions.
These EPP extensions will point to the IESG in the IANA registry (RFC 7451 section 2.2.1)

2. Proprietary EPP extensions
Extensions that seek registration in the IANA EPP extensions registry, but are only supported by one or few registries.
These extensions should be documented and one way of documenting them is to write an informational RFC describing how the proprietary extension works.
These EPP extensions will have the Registrant information in the IANA registry, which is NOT the IESG!

draft-ietf-regext-bundling-registration is of type 2 since the REGEXT WG could not reach consensus that this extension should become the standard way of bundling. Hence the informational status of the document and the Registrant should be in the IANA registration as mandated by RFC 7451.

- -- 
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392