IETF Stream Documents Require IETF Rough Consensus
draft-halpern-gendispatch-consensusinformational-04
Yes
(Adam Roach)
(Alvaro Retana)
(Barry Leiba)
(Martin Vigoureux)
No Objection
Roman Danyliw
(Deborah Brungard)
(Magnus Westerlund)
Note: This ballot was opened for revision 03 and is now closed.
Roman Danyliw
No Objection
Éric Vyncke
No Objection
Comment
(2020-03-04 for -03)
Sent
Sharing Alexey's concern about documents that are in the queue.
Adam Roach Former IESG member
Yes
Yes
(for -03)
Not sent
Alissa Cooper Former IESG member
Yes
Yes
(2020-02-24 for -03)
Sent
A few tweaks in Section 4 to align the verb tense to past tense: s/this BCP permit/this BCP permitted/ s/it makes it worse/it made it worse/ s/this has the IESG/this had the IESG/
Alvaro Retana Former IESG member
Yes
Yes
(for -03)
Not sent
Barry Leiba Former IESG member
Yes
Yes
(for -03)
Not sent
Martin Vigoureux Former IESG member
Yes
Yes
(for -03)
Not sent
Suresh Krishnan Former IESG member
Yes
Yes
(2020-03-05 for -03)
Sent
Some minor nits. Feel free to ignore. * Section 4 Since this talks about the Independent Stream itself suggest replacing "procedure" with "path" s/we have an explicit procedure for such publication/we have an explicit path for such publication/ Typo: s/authorithy/authority/
Alexey Melnikov Former IESG member
No Objection
No Objection
(2020-02-25 for -03)
Sent
I generally support this document, but I want to understand what will happen to documents already in works that don't have IETF Consensus when this document is approved.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-03-03 for -03)
Sent
Abstract This document proposes that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026. Will "proposes" or "requires" be better in the final RFC? Section 1 IETF procedures, as defined by [RFC2026] allow for Informational or Experimental RFCs to be published without IETF rough consensus. For nit: "as defined by [RFC2026]" sounds like a parenthetical expression that would benefit from a second comma, after it. Section 4 The IETF procedures prior to publication of this BCP permit such information or experimental publication without IETF rough consensus. nit: s/information/informational/ Section 7 Whereas normal procedures would have us cite BCP 9 rather than "just" RFC 2026, given that this document will itself become part of BCP 9, the RFC-specific citation seems correct (as-is).
Deborah Brungard Former IESG member
No Objection
No Objection
(for -03)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -03)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2020-03-04 for -03)
Sent
I think at least the first two paragraphs in section 4 would have some value to be left in the final RFC for some background knowledge. Update: ---- I've just been looking at RFC2026 again which is updated by this document. RFC2026 says: 4.2.2 Informational An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). This text often leads to confusion, so I think it would have actually been useful for this draft to further clarify this text or even this text in OLD/NEW style. Just leaving this as a comment but I guess it not too late to do that... Also note that the following page on the ietf.org should be updates as well as soon as this document is published: https://www.ietf.org/standards/process/informational-vs-experimental/