Subject: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09

From: Barry Leiba <[email-masked]>
Date: Thu, 12 Sep 2019 21:21:02 -0400

>       Thanks a lot. We will update a new version based on your guidance.

It's been almost 12 weeks.  Is a new version forthcoming?  When can we
expect it?

Barry

> > 在 2019年6月22日，02:28，Barry Leiba <[email-masked]>; 写道：
> >
> > Hey, regext folks,
> >
> > This document had an AD review from Adam, a Gen-ART review from Joel,
> > and a SecDir review from Russ, and went through IETF last call.  All
> > three reviews were responded to on the regext mailing list (by
> > Jiankang and by Antoine), but there has been no revision of the draft
> > to address the issues raised.  That has to happen.
> >
> > While we're there, there's the issue of the Informational status and
> > the registrant contact for the namespace:
> >
> > It's my understanding that this isn't specifying a standard, but,
> > rather, is documenting an existing non-standard extension that is not
> > expected to be a standard nor widely implemented.  Is that correct?
> >
> > If so, the document should make that clear in the Abstract (briefly)
> > and in the Introduction (somewhat less briefly).
> >
> > Also, the shepherd writeup doesn't help me understand why this is
> > Informational, and it should: (from the writeup text, emphasis mine)
> > "Explain briefly what the intent of the document is (the document's
> > abstract is usually good for this), and WHY THE WORKING GROUP HAS
> > CHOSEN THE REQUESTED PUBLICATION TYPE".  You say the working group
> > decided, but you don't say why.
> >
> > So:
> > Please revise the draft to address the last call reviews, and also
> > please add something to the Introduction (and possibly the Abstract)
> > to explain the status of the document, making clear what the standards
> > or non-standards status is and what applicability we expect for it.
> >
> > I'm putting this into a "Revised I-D Needed" substate, awaiting such revision.
> >
> > Thanks,
> > Barry

---

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 13 Sep 2019 16:39:04 +0800 (GMT+08:00)

Thanks Barry.
We have finished an initial new version. We will refine it and submit it within 2 weeks.

Best Regards.

Jiankang Yao

> -----原始邮件-----
> 发件人: "Barry Leiba" <[email-masked]>
> 发送时间: 2019-09-13 09:21:02 (星期五)
> 收件人: "Jiankang Yao" <[email-masked]>
> 抄送: [email-masked], [email-masked]
> 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Jiankang Yao" <[email-masked]>
Date: Sat, 21 Sep 2019 19:15:20 +0800 (GMT+08:00)

Dear Barry,

     The new version has been submitted. It addresses the comments received during IETF LC.
     https://datatracker.ietf.org/doc/html/draft-ietf-regext-bundling-registration-10

  Thanks.

Jiankang Yao

> -----原始邮件-----
> 发件人: "Jiankang Yao" <[email-masked]>
> 发送时间: 2019-09-13 16:39:04 (星期五)
> 收件人: "Barry Leiba" <[email-masked]>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 26 Sep 2019 00:17:10 -0400

This remains quite incomplete: the last call comments have not been
properly handled.

In Sections 6.1, 6.2, 7.1.2, and all the 7.2.x you made changes in response
to Adam’s AD review, but you tried to use the second of his suggested
fixes.  What you did do is flawed, as you have introduced a space character
between the two U+ characters (which is why he advised against that fix,
because doing it without the extra space makes it hard to read, but adding
the space makes it wrong).  Please fix that.  I suggest using Adam’s
XML-escaping example to fix it.

The Gen-ART review asked for BCP 14 key words in Section 5, and you said
you would add them.  You did not.  That’s fine if you ultimately decided
not to (I personally think it is not necessary), but I want to make sure
you didn’t simply forget to make that change.

The Gen-ART review asked for a brief explanation of what the conditions
might be for not complying with the “SHOULD” requirements in Sections
7.2.x, and what the consequences would be.  You did not add that, and I
think it’s necessary.  Please add an explanation in each of those sections.

The SecDir review suggested changing the contact for the IANA registrations
to the IETF, rather than the authors, and I agree: it should be “the IETF”,
probably with the regext mailing list as the contact information.  You did
not make any change.  Please do.

You also did not address my comment about needing an explanation for why
this is Informational and not Proposed Standard.  It’s fine for it to be
Informational, but the shepherd writeup needs to explain why (please update
it), and the Introduction probably should also, assuming that reason has to
do with the deployment, applicability, or maturity of what’s documented
here.

I won’t pass this up to the IESG until all these points are addressed.  So
back into Revised I-D needed this goes, and please handle this without
undue delay.

Thanks,

Barry

On Sat, Sep 21, 2019 at 7:15 AM Jiankang Yao <[email-masked]> wrote:

> > 主题: Re: [regext] New-AD review of
> draft-ietf-regext-bundling-registration-09
> >
> >
> > Thanks Barry.
> > > 主题: Re: [regext] New-AD review of
> draft-ietf-regext-bundling-registration-09
> > >

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 27 Sep 2019 17:13:31 +0200

Barry,

I have not reviewed all the comments yet, but I am only responing to this one:

> The SecDir review suggested changing the contact for the IANA registrations to the IETF, rather than the authors, and I agree: it should be “the IETF”, probably with the regext mailing list as the contact information.  You did not make any change.  Please do.

This is incorrect according to RFC4741, and I have replied to the SecDir review on the list that it is as well.
Section 2.2.1. of RFC4741 states:

Registrant Name and Email Address: The name and email address of the
   person that is responsible for managing the registry entry.  If the
   registration is of an IETF Standards Track document, this can simply
   be listed as "IESG, <[email-masked]>”.

draft-ietf-regext-bundling-registration is NOT an IETF Standard Track document.
draft-ietf-regext-bundling-registration is an IETF INFORMATIONAL document, and it is for a reason.
The REGEXT working group did not consent that this draft produces a standard, and therefor refused Standards track stream.
The REGEXT working group did allow the authors to document their proprietary EPP extension in an informational IETF document, and adopted the document to help review.
This informational document only documents a proprietary EPP extension.

Proprietary EPP extensions are allowed in the IANA EPP Extensions registry, with an informational RFC as one type of documentation, but they are registered in the IANA registry with the name and email address of the one that registers the proprietary extension, which is the authors and NOT the IESG. Only Standard track documents are listed with the IESG as contact in the IANA EPP extensions registry.
The purpose of the IANA EPP extensions registry is to eventually consolidate all proprietary extensions to standards and the registered contact is one of the recognition points if an EPP extension is a standard.
We do not want proprietary EPP extensions to become standards without consent of the REGEXT working group.

I can understand that this can be confusing for the IESG, since they mostly review standards track documents as output from the REGEXT working group, but this is one of the few exceptions that is deliberately an informational document.

- -- 
Antoin Verschuren

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

> Op 26 sep. 2019, om 06:17 heeft Barry Leiba <[email-masked]> het volgende geschreven:
> 
> This remains quite incomplete: the last call comments have not been properly handled.
> 
> In Sections 6.1, 6.2, 7.1.2, and all the 7.2.x you made changes in response to Adam’s AD review, but you tried to use the second of his suggested fixes.  What you did do is flawed, as you have introduced a space character between the two U+ characters (which is why he advised against that fix, because doing it without the extra space makes it hard to read, but adding the space makes it wrong).  Please fix that.  I suggest using Adam’s XML-escaping example to fix it.
> 
> The Gen-ART review asked for BCP 14 key words in Section 5, and you said you would add them.  You did not.  That’s fine if you ultimately decided not to (I personally think it is not necessary), but I want to make sure you didn’t simply forget to make that change.
> 
> The Gen-ART review asked for a brief explanation of what the conditions might be for not complying with the “SHOULD” requirements in Sections 7.2.x, and what the consequences would be.  You did not add that, and I think it’s necessary.  Please add an explanation in each of those sections.
> 
> The SecDir review suggested changing the contact for the IANA registrations to the IETF, rather than the authors, and I agree: it should be “the IETF”, probably with the regext mailing list as the contact information.  You did not make any change.  Please do.
> 
> You also did not address my comment about needing an explanation for why this is Informational and not Proposed Standard.  It’s fine for it to be Informational, but the shepherd writeup needs to explain why (please update it), and the Introduction probably should also, assuming that reason has to do with the deployment, applicability, or maturity of what’s documented here.
> 
> I won’t pass this up to the IESG until all these points are addressed.  So back into Revised I-D needed this goes, and please handle this without undue delay.
> 
> Thanks,
> Barry
> 
> On Sat, Sep 21, 2019 at 7:15 AM Jiankang Yao <[email-masked] <mailto:[email-masked]>> wrote:
> Dear Barry,
> 
>      https://datatracker.ietf.org/doc/html/draft-ietf-regext-bundling-registration-10 <https://datatracker.ietf.org/doc/html/draft-ietf-regext-bundling-registration-10>
> 
>   Thanks.
> 
> Jiankang Yao
> 
> 
> > -----原始邮件-----
> > 发件人: "Jiankang Yao" <[email-masked] <mailto:[email-masked]>>
> > 收件人: "Barry Leiba" <[email-masked] <mailto:[email-masked]>>
> > 抄送: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> > > 发件人: "Barry Leiba" <[email-masked] <mailto:[email-masked]>>
> > > 收件人: "Jiankang Yao" <[email-masked] <mailto:[email-masked]>>
> > > 抄送: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> > > > > 在 2019年6月22日，02:28，Barry Leiba <[email-masked] <mailto:[email-masked]>>; 写道：
> > > > >
> > > > > Hey, regext folks,
> > > > >
> > > [email-masked] <mailto:[email-masked]>
> > > https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 27 Sep 2019 17:20:24 +0200

> Section 2.2.1. of RFC4741 states:

This should be RFC 7451 of course. Don’t know where that cut and paste went wrong ;-)

- -- 
Antoin Verschuren

> Op 27 sep. 2019, om 17:13 heeft Antoin Verschuren <[email-masked]> het volgende geschreven:
> 
> Barry,
> 
>    be listed as "IESG, <[email-masked] <mailto:[email-masked]>>”.
> 
>> Op 26 sep. 2019, om 06:17 heeft Barry Leiba <[email-masked] <mailto:[email-masked]>> het volgende geschreven:
>>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 27 Sep 2019 11:29:22 -0400

Thanks, Antoin; I agree with your analysis, and I agree that the
contact info is fine as it is, given that.

But this is also why I think it's important for the document to
clearly say that this is documenting a proprietary extension, and that
that is why it's Informational.  Without that being clear, we're going
to get pushback from the IESG about a few things.  So let's be very
clear about it.  Makes sense?

Barry

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 27 Sep 2019 17:39:57 +0200

Yes Barry, I agree. Not everybody understands the background why it is an informational document and what it’s purpose is.

- -- 
Antoin Verschuren

> Op 27 sep. 2019, om 17:29 heeft Barry Leiba <[email-masked]> het volgende geschreven:
>

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 30 Sep 2019 10:19:46 +0800

How about adding some explanation in the Shepherd write-up?

Jiankang Yao

From: Barry Leiba
Date: 2019-09-27 23:29
To: Antoin Verschuren
CC: Jiankang Yao; draft-ietf-regext-bundling-registration.all; regext
Subject: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
Thanks, Antoin; I agree with your analysis, and I agree that the
contact info is fine as it is, given that.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 30 Sep 2019 10:00:13 -0400

> How about adding some explanation in the Shepherd write-up?

That's not sufficient: no one will ever read the shepherd writeup
after the document is approved for publication.  The explanation that
this is a proprietary extension and where it comes from needs to be in
the Introduction (early in the Introduction).  I would also mention it
in the abstract (change "This document describes an extension" to
something like, "This document describes a non-standard proprietary
extension").

Barry