요약

  • RFC 2418은 대략적 합의(rough consensus)를 워킹 그룹의 규칙으로 정하면서 51% 과반수로는 부족하다고 명시했고, 의장이 토론을 평가해야 한다고 규정했습니다.
  • 같은 1998년 지침은 허밍(humming), 손 들기 또는 합의된 다른 신호를 허용했지만, 이를 판단에 참고하는 하나의 입력으로 다루었습니다.
  • 2014년 Informational RFC로 발표된 RFC 7282는 허밍이 익명 투표처럼 사용되는 경향을 경고하며, 허밍은 논의를 끝내는 것이 아니라 시작해야 한다고 말했습니다.
  • 이 문서는 의장과 참여자에게 기술적 반대 의견을 식별하고, 그것이 답변되었는지 검토하며, 미해결 반대 의견이 결과를 바꾸지 않는 이유를 설명하도록 요청했습니다.
  • RFC 7282는 기존 원칙을 기술한 것으로, IETF 절차를 변경하거나 새로운 구속력 있는 프로세스를 만들지 않았음을 명시했습니다.

방은 문제를 결정하지 않고 방향을 보여줄 수 있었다

워킹 그룹은 제안이 지지를 받고 있는지 파악할 방법이 필요했습니다. 회의에서 의장은 손을 드는 대신 참석자들에게 찬성 또는 반대 방향으로 허밍하도록 요청할 수 있었습니다. 이렇게 하면 투표 개수 세기로 만들지 않으면서도 방의 전반적인 분위기를 소리로 확인할 수 있었습니다. 이는 의견 차이가 있는 지점을 찾거나 어느 제안에 더 관심이 모였는지 보여줄 수 있었습니다. 그러나 참여자들이 그러한 견해를 가진 이유나 기술적 반대 의견이 여전히 답변되지 않았는지는 드러낼 수 없었습니다.

이 구분은 2014년 이전부터 IETF 지침에 존재했습니다. 1998년 워킹 그룹 지침인RFC 2418은 대략적 합의를 기술적 선택을 수용하는 핵심 방식으로 규정하면서 51%는 기준에 미치지 못한다고 명시했습니다. 그룹이 대략적 합의에 도달했는지 판단할 책임은 의장에게 있었으며, RFC는 메시지 양만으로는 좋은 척도가 아니다라고 경고했습니다. 소수의 사람이 트래픽 대부분을 만들 수 있기 때문입니다. 또한 메일링 리스트는 이동과 시간 비용을 수반하는 회의 참석보다 더 많은 관계자에게 도달할 수 있다고 지적했습니다.

2014년 문서RFC 7282는 이 원칙과 사람들이 이 의례를 실제로 사용하는 방식 사이의 간극을 다시 살폈습니다. 저자인 Pete Resnick은 참여자들이 허밍을 비밀 투표나 결론 처리의 지름길로 취급하는 모습을 기술했습니다. 문서의 핵심 교정은 실용적인 것이었습니다. 허밍은 그룹이 무엇을 해결해야 하는지에 대한 논의를 시작해야 하며, 더 큰 소리를 낸 쪽이 소리 때문에 결정을 차지할 수는 없다는 것이었습니다.

일은 반대 의견에 있었다

RFC 7282는 찬성을 세는 일에서 미해결 문제를 찾는 일로 관심을 옮겼습니다. 의장은 어떤 요소가 누군가 제안을 받아들이지 못하게 하는지 물어볼 수 있고, 그 우려가 진짜 엔지니어링 문제인지, 선호인지, 그룹이 이미 검토한 절충안인지 확인할 수 있습니다. 모든 반대 의견을 수용할 필요는 없습니다. 그러나 그룹은 반대 의견을 이해하고 그 선택에 대한 근거 있는 설명을 제공해야 합니다.

따라서 의장의 역할은 기계적인 표 집계도 아니고 무제한의 개인적 거부권도 아닙니다. 의장은 그룹의 기술적 목표를 충분히 알아 문제를 평가하고, 근거를 요약하며, 결정이 기술적 요구사항을 놓쳤을 경우 항소를 허용할 수 있어야 합니다. 다수가 반대 의견이 틀렸다고 말하는 것만으로는 그 의견을 다루는 대신할 수 없습니다. 반대로 한 참여자가 그룹이 이미 검토하고 답변한 우려를 반복하며 업무를 무기한 멈춰 세울 수도 없습니다.

그 이전의RFC 1603과 RFC 2418은 투표와 허밍을 포함해 그룹의 분위기를 감지하는 여러 방식을 기술했습니다. RFC 7282는 그러한 신호가 그 자체로 실질을 결정할 수 있다는 생각에 이의를 제기했습니다. 손 들기, 설문, 허밍은 토론의 형태를 드러내는 데 도움이 될 수 있습니다. 그러나 결정은 여전히 이유, 워킹 그룹의 요구사항, 의장의 판단에 의존합니다.

2014년 문서가 새로운 규칙을 만들지 않은 이유

RFC 7282는 의도적으로 Informational로 발표되었습니다. 이 문서는 표준 트랙 사양이 아니고, 프로세스 변경을 제안하지 않았으며, Best Current Practice도 아니라고 명시했습니다. 이 지위는 의미가 있습니다. 이 문서는 참여자들이 기존 IETF 전통을 어떻게 이해해야 하는지 명확히 하려는 것이었지, 규칙을 수정하거나 워킹 그룹에 대한 새로운 권위를 만들려는 것이 아니었습니다.

주변 절차도 중요했습니다. RFC 2418은 이전에 논의되지 않은 주제에 대한 대면 결정 또는 메일링 리스트 논의와 실질적으로 다른 결정이 리스트에서 재검토되도록 요구했습니다. RFC 7282는 최종 결정은 거기서 이루어져야 한다고 말했습니다. 이는 방이 견해를 시험하는 한 장소가 되도록 하고, 비동기 기록이 부재한 참여자에게 근거를 확인하고 반대할 기회를 주도록 했습니다.

한계 역시 절차만큼 중요합니다. 이 RFC들은 IETF 워킹 그룹을 위한 지침을 기록한 것입니다. 누가 참여했는지 측정하지 않고, 영향을 받는 모든 네트워크 사업자가 대표되었다는 것을 입증하지도 않으며, 결과 프로토콜이 채택되었는지 보여주지도 않습니다. 반대 의견을 경청하는 프로세스는 기술적 결정을 개선할 수 있지만, 그 과정에 한 번도 참여하지 않은 사람들로부터 승인을 받았다고 주장할 수는 없습니다. 이 구분은 방의 신호가 그것이 수행하도록 설계된 작업 안에 머물게 합니다.