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.