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.
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 <i...@antoin.nl> 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, <i...@ietf.org>”.
>
>
> 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 <barryle...@computer.org> 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 <ya...@cnnic.cn> 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" <ya...@cnnic.cn>
>> > 发送时间: 2019-09-13 16:39:04 (星期五)
>> > 收件人: "Barry Leiba" <barryle...@computer.org>
>> > 抄送: draft-ietf-regext-bundling-registration....@ietf.org, regext@ietf.org
>> > 主题: 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" <barryle...@computer.org>
>> > > 发送时间: 2019-09-13 09:21:02 (星期五)
>> > > 收件人: "Jiankang Yao" <ya...@cnnic.cn>
>> > > 抄送: draft-ietf-regext-bundling-registration....@ietf.org, regext@ietf.org
>> > > 主题: 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 <barryle...@computer.org>; 写道：
>> > > > >
>> > > > > 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
>> > > regext@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/regext
>> > _______________________________________________
>> > 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
>
>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
