I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> Please resolve these comments along with any other Last Call comments you may receive. Document: draft-resnick-on-consensus-05 Reviewer: Russ Housley Review Date: 11-October-2013 IETF LC End Date: 11-November-2013 IESG Telechat date: Unknown Summary: This draft is ready for publication as an Informational RFC. Major issues: Section 4 says: "... members of any given working group ..." Working groups do not have members; they have participants. Please reword to avoid confusion on this point. Minor issues: Section 4 says that humming should be the start of a conversation, not the end. However, it can be either. Using the document's example, the chair could ask, "Hum now if you cannot live with choice A." Silence confirms that rough consensus has been reached. So, I guess I do not agree with the last sentence in Section 5. Section 6 tells about some pitfalls to avoid, but the hum can still be a very valuable tool to help a chair determine if the group has reached consensus. Further, a hum in a BOF is different. The topic of consensus on procedural matter comes up in Section 5, but it does not get much attention. For example in a BOF the hum might ask: "Hum now if you think that the IETF should take on this work... Hum now if you think the IETF should not take on this work..." The BOF Chair or AD is trying to figure out if there is enough support for the work to go forward. This type of of hum is quite different than judging rough consensus on a technical issue. Yes, it can be the beginning of a conversation, and it must allow for participants to explain why they believe the IETF taking on the work might be harmful. However, this difference should be explained in the document. Nits: In section 2, the document says "... not appealing to some others." When I read it the firs time, the RFC 2026 definition of "appeal" jumped into my mind. That is not the intent here. Maybe it is just me. Please consider rewording, especially since the RFC 2026 meaning is used in Section 3.