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

[Barry Leiba <[e-mail]>]

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

On Fri, Sep 27, 2019 at 11:13 AM Antoin Verschuren <[e-mail]> wrote:
>
> 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, <[e-mail]>”.
>
>
> 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: [phone]
>
>
>
>
>
>
> Op 26 sep. 2019, om 06:17 heeft Barry Leiba <[e-mail]> 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 <[e-mail]> wrote:
>>
>> 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" <[e-mail]>
>> > 发送时间: 2019-09-13 16:39:04 (星期五)
>> > 收件人: "Barry Leiba" <[e-mail]>
>> > 抄送: [e-mail], [e-mail]
>> > 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
>> >
>> >
>> > 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" <[e-mail]>
>> > > 发送时间: 2019-09-13 09:21:02 (星期五)
>> > > 收件人: "Jiankang Yao" <[e-mail]>
>> > > 抄送: [e-mail], [e-mail]
>> > > 主题: Re: [regext] New-AD review of draft-ietf-regext-bundling-registration-09
>> > >
>> > > >       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 <[e-mail]>; 写道：
>> > > > >
>> > > > > 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
>> > >
>> > > _______________________________________________
>> > > regext mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/regext
>> > _______________________________________________
>> > regext mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/regext
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>
>