IETF Stream Documents Require IETF Rough Consensus
RFC 8789
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Alvaro Retana Yes
Roman Danyliw No Objection
Éric Vyncke No Objection
Sharing Alexey's concern about documents that are in the queue.
(Adam Roach; former steering group member) Yes
(Alissa Cooper; former steering group member) Yes
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/
(Barry Leiba; former steering group member) Yes
(Martin Vigoureux; former steering group member) Yes
(Suresh Krishnan; former steering group member) Yes
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 steering group member) No Objection
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 steering group member) No Objection
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 steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
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/