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