Hi Joel, > On Jan 24, 2020, at 5:50 PM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote: > > Thanks Adrian. (And Brian.) > Alissa, do you think we should change the note to simply remove all of section 4? I think it’s better kept in the document so future readers can understand the context. Thanks, Alissa > I can make the other suggested changes. > > Yours, > Joel > > On 1/24/2020 4:51 PM, Adrian Farrel wrote: >> Hi, >> Thanks for this document. I think it is a fine idea to make this small >> change official even if (or perhaps particularly because) it describes what >> the IESG has been doing for some time. >> However, I think the document needs some work before it can be published. >> 1. The document is framed as a proposal. That was great for opening the >> discussion, but when published as an RFC it needs to be phrased as a clear >> statement of practice. Thus, you need to reword it accordingly. That's a >> fairly easy change, but hits several places in the document. >> 2. The Introduction usefully sets out what 2026 requires. However, you also >> need to say what this document does. I think it is conventional to make the >> "updates" statement in the Introduction and to state what the update is: >> such as, "This document updates [RCF2026] by stating rules for establishing >> IETF consensus before the publication of any RFC on the IETF Stream." >> There are also a couple of nits in the text you have: >> a. "it should be remembered that this RFC predates" Since the draft will >> (hopefully) be published as an RFC, the term "this RFC" will be >> misinterpreted as meaning "this document". I think you can fix that as >> "...remembered that that RFC..." >> b. "As a consequence, it is currently permitted for the IETF to approve". >> Once this document is published as an RFC your statement will be wrong and >> confusing. Furthermore, I think you mean IESG not IETF. Maybe you fix this >> as "As a consequence, RFC 2026 permitted the IESG to approve" >> 3. Section 4 is a bit of discussion that no-doubt helped form this document. >> But I wonder whether you want this discussion to remain. You have already >> decided that the final paragraph should be removed. Could you actually >> remove the whole section without loss to the document? >> If you decide to keep Section 4, it will need some work. >> The first sentence of the first paragraph will not age well with the >> publication of this document as an RFC. Maybe it could be rewritten as: >> The procedures defined in [RFC2026] permit the publication of >> some RFCs in the IETF stream without first establishing IETF >> consensus. >> Additionally, while you are correct as to the letter of the 2007 IESG >> statement, I hope you'll agree that the intent of that statement in having >> IETF-wide review was that consensus would be reached. Finally, the >> referenced IESG statement does not say that "no document will be issued >> without first conducting an IETF Last Call", it talks only about "Individual >> Submissions". The fact that the IESG now issues last calls on all IETF >> Stream documents is an established behaviour, but is not (I think) >> documented - IIRC, an IESG just decided to do it. That could all mean some >> substantial clean-up and leads me to think that it is easier to drop the >> rest of the text in the paragraph. >> 4. You should decide whether to use "stream" or "Stream" and be consistent. >> Thanks for the work, >> Adrian >> -----Original Message----- >> From: IETF-Announce <ietf-announce-bounces@xxxxxxxx> On Behalf Of The IESG >> Sent: 24 January 2020 18:09 >> To: IETF-Announce <ietf-announce@xxxxxxxx> >> Cc: draft-halpern-gendispatch-consensusinformational@xxxxxxxx >> Subject: Last Call: >> <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream >> Documents Require IETF Rough Consensus) to Best Current Practice >> The IESG has received a request from an individual submitter to consider the >> following document: - 'IETF Stream Documents Require IETF Rough Consensus' >> <draft-halpern-gendispatch-consensusinformational-02.txt> as Best Current >> Practice >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> last-call@xxxxxxxx mailing lists by 2020-02-21. Exceptionally, comments may >> be sent to iesg@xxxxxxxx instead. In either case, please retain the >> beginning >> of the Subject line to allow automated sorting. >> Abstract >> This document proposes that the IETF never publish any IETF stream >> RFCs without IETF rough consensus. This updates RFC 2026. >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-consensusinformat >> ional/ >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-halpern-gendispatch-consensusinformat >> ional/ballot/ >> No IPR declarations have been submitted directly on this I-D. >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf-announce > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
