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

From: Russ Housley via Datatracker <[email-masked]>
Date: Fri, 08 Mar 2019 21:24:46 -0800

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

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.

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.

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:
      <!--
      Child elements of the <b-dn:create>     command
      All     elements must be present at     time of creation
      -->

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.

---

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 15 Mar 2019 09:47:42 +0800

<           From: Russ Housley via Datatracker
<           Date: 2019-03-09 13:24
<           To: [email-masked]
<           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:
<           <!--
<           Child elements of the <b-dn:create> command
<           All elements must be present at time of creation
<           -->
<           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
<           [email-masked]
<           https://www.ietf.org/mailman/listinfo/regext

---

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

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

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 bij RFC 7451.

- -- 
Antoin Verschuren

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