녹색 상자는 틀린 질문에 답할 때 증거가 아니다

요약

• 밀라노의 IETF 예비 회의장소 보고서는 시험 3.1을 충족(Met)으로 표기했습니다. 이 시험은 참석자의 80%가 과도한 노력이나 비용 없이 비자를 받을 수 있는지를 묻지만, 게시된 설명은 차별 금지, 즉 별개의 시험 3.2의 주제를 다룹니다.
• 이 불일치는 공개 근거의 연결 실패이며, 밀라노가 80% 기준을 통과하지 못한다는 증거가 아닙니다. 보고서는 커뮤니티 피드백 단계를 통해 정정되거나 보완될 수 있으며, 설계상 어떤 권고도 담고 있지 않습니다.
• 몬테비데오의 병행 보고서는 의도된 분리를 보여줍니다. 3.1 항목은 80% 접근 질문을 명시적으로 다루고, 3.2는 차별 금지를 다룹니다. 이 비교는 어느 도시가 선정되어야 하는지가 아니라 기록 구조에 관한 것입니다.
• Daniel Kade는 각 상태를 정확한 시험, 출처, 방법, 기준 시점, 불확실성, 평가자, 개정 이력 및 이후 결정 단계에 연결하는 간결한 기준-근거 영수증을 제안합니다.

표기와 문장이 어긋나다

밀라노 보고서는 2026년 7월 9일 작성된 5페이지짜리 예비 평가입니다. Allianz MiCo를 가능한 회의장소로 명시하고, 회의장 수용력, 인터넷 접근, 비자, 여행 위험, 보건, 대기질, 소요 사태 및 차별에 대한 체감 경험을 다루는 9개 시험을 제시합니다. 요약에는 8개가 충족(Met), 불확실(Uncertain)이나 미충족(Not Met)은 없으며, 1개가 평가되지 않았다고 기록되어 있습니다. 보고서의 시각적 문법은 단순합니다. 녹색은 충족, 노란색은 불확실하지만 가능, 빨간색은 미충족, 회색은 평가 불능 또는 미평가를 뜻합니다.

3.1 행에서 이 문법이 깨집니다. 왼쪽 열에 인쇄된 시험은 구체적입니다. "비자 요건상 IETF 참석자의 80%가 과도한 노력이나 비용 없이 비자를 받을 수 있어야 한다." 따라서 뒷받침 설명은 최소한 참석자 출신국 분포가 무비자 입국이나 합리적 비용의 표준 신청 경로와 어떻게 관련되었는지 보여주어야 합니다. 현재 IETF 템플릿조차 그 형태의 답변을 제공합니다.

그러나 밀라노 문장은 다른 것을 말합니다. 이탈리아 비자 규정은 인종, 민족, 종교, 성별, 성적 지향 또는 성별 정체성을 근거로 차별적이지 않다고 진술하고 이탈리아 외교부를 가리킵니다. 이것은 바로 3.2 행에 필요한 종류의 답변입니다. 다음 행이 바로 그 차별 금지 질문을 묻고, 사실상 동일한 문장과 출처를 반복합니다. 두 표기 모두 녹색입니다.

결함은 좁고 가시적입니다. 이것은 이탈리아 법, 밀라노의 접근성 또는 Allianz MiCo의 적합성에 대한 발견이 아닙니다. 공개 행은 단지 독자에게 3.1이 왜 통과했는지 알려주지 않을 뿐입니다. 참석자 출신국 분포도, 가중치 적용 백분율, 무비자 경로와 표준 신청 경로의 구분, 과도한 노력이나 비용의 해석, 결론 옆의 평가 기준 시점이 전혀 없습니다. 사무국이 그 작업을 수행했는데 잘못된 문장이 보고서에 붙여넣어졌을 수도 있습니다. 계산될 예정이었던 수치가 아직 추가되지 않았을 수도 있습니다. 공개 기록은 어느 쪽 추론도 사실로 만들지 않습니다.

이 구분이 핵심입니다. 근거 없는 녹색 표기가 곧 거짓 녹색 표기는 아닙니다. 그것을 제시하는 문서로부터 그 근거를 아직 재구성할 수 없는 상태일 뿐입니다.

몬테비데오는 경쟁 판정이 아니라 대조군이다

몬테비데오 병행 보고서는 같은 날짜에 같은 템플릿을 사용하기 때문에 유용합니다. 3.1 행은 참석자의 80%가 국가별로 무비자이거나 합리적 비용의 표준 신청 절차를 통해 우루과이에 입국할 수 있다고 말합니다. 3.2 행은 별도로 나열된 근거를 기준으로 비자 규정이 차별적이지 않다고 말합니다. 문장은 짧고 국가별 표를 공개하지 않지만, 각각 옆에 인쇄된 질문에 답합니다.

이 비교를 도시 대결로 만들어서는 안 됩니다. 몬테비데오에는 자체 미해결 항목이 있습니다. 불충분한 대기질 데이터와 체감 경험 시험 모두 미평가로 남아 있습니다. 요약에는 7개 충족, 2개 미평가로 기록되어 있습니다. 밀라노는 8개 충족, 1개 미평가입니다. 이 총계는 순위표를 형성하지 않으며, 어느 보고서도 승인이나 거부를 권고하지 않습니다.

몬테비데오는 여기서 내부 대조군으로만 유용합니다. 보고서 형식이 접근 범위와 차별 금지를 분리할 수 있음을 보여줍니다. 따라서 밀라노의 불일치는 템플릿에 고유한 모호성이 아닙니다. 한 행이 이웃 행의 설명을 물려받은 것입니다.

몬테비데오의 표현조차 건전한 거버넌스를 위한 두 번째 질문을 남깁니다. "80%" 뒤의 계산은 어디에 있는가? 명확한 결론이 틀린 결론보다 낫지만, 재현 가능한 결과는 둘 다보다 낫습니다. 집계표는 참석자 출신국 기준 기간, 사용된 모집단, 무비자 비율, 표준 절차 비율, 제외 또는 누락 사례, 가정된 비용 범위, 결과 백분율을 명시할 수 있습니다. 참가자의 이름, 국적, 비자 이력을 공개할 필요는 없습니다.

권고 없음이 맞는 예비 상태다

비어 있는 권고 섹션은 미완성이거나 결함 있는 절차의 증거가 아닙니다. 현재 IETF 회의장소 평가 보고서 템플릿은 예비 보고서가 부분적 정보만 담을 수 있으므로 권고가 없다고 명시합니다. 커뮤니티 피드백과 그에 따른 추가 조사가 예비 보고서와 최종 보고서의 차이를 채우도록 되어 있습니다.

8월 14일 의견 요청은 이 설계를 따릅니다. 밀라노와 몬테비데오 모두 "권고 없음"으로 묘사하고, 공개적으로 열람 가능한 일방향 리스트를 통해 메시지를 요청하며, 피드백이 공개 Trello 보드에도 모인다고 밝힙니다. 요청은 2026년 8월 28일에 마감될 예정이었습니다. 관측 기준 시점에서 어느 도시도 승인, 거부 또는 선정되었다고 말하는 것은 옳지 않습니다.

각 보고서의 회색 행이 이 점을 강화합니다. 시험 6.1은 IETF 참가자의 체감 경험을 통해 평가하여, 차별 때문에 그 도시가 참가자에게 불안전한지를 묻습니다. 두 보고서 모두 커뮤니티 피드백이 필요하다고 말합니다. 데스크 리서처는 여행 권고나 법적 요약으로 체감 경험을 만들어낼 수 없습니다. 여기서 "미평가"는 제도적 약함이 아니라, 근거가 관련 경험을 가진 사람들에게서 와야 한다는 옳은 인정입니다.

절차는 기록을 바꾸도록 설계되어 있습니다. 피드백 후 IETF LLC는 추가 원격 조사를 수행하고, 평가를 수정하고, 승인 또는 거부 권고가 담긴 갱신 보고서를 발행할 수 있습니다. 거부는 그 도시의 경로를 끝냅니다. 승인은 경로를 전진시킬 뿐입니다. 상세 평가, 가능한 현지 방문, 상업적 질문, 호텔 가용성, 현지 지원이 뒤따릅니다. IETF가 회의를 개최하는 핵심 이유에 관한 우려는 IESG의 실현 가능성 판정을 요할 수 있습니다. LLC 이사회는 계약 전에 기밀 결정 팩을 검토하고, 공개 통지는 계약 이후에 옵니다.

이 단계들은 별개의 권한 행위입니다. 녹색 칸은 최고경영자(Executive Director) 권고가 아닙니다. 권고는 상세 상업 평가가 아닙니다. 평가는 IESG 판정이 아닙니다. IESG 판정은 LLC 이사회 승인이 아닙니다. 이사회 승인은 서명된 계약이 아닙니다. 보고서가 중요한 이유는 한 단계의 근거를 다음 단계로 전달하기 때문이며, 이후 단계를 대행하도록 만들어서는 안 됩니다.

"압도적 다수"가 운영상 시험이 되다

RFC 8718이 제도적 틀을 제공합니다. IASA에 최선의 판단을 적용하고, 선정 절차를 가능한 한 개방적으로 유지하며, 계약이 고려되기 전에 의견이 반영될 수 있을 만큼 조기에 커뮤니티와 협의하도록 요구합니다. 중요한 도시 기준 가운데, 입국에 대한 여행 장벽 — 비자 요건 포함 — 은 참여 의사가 있는 압도적 다수의 참석을 허용할 가능성이 높아야 한다고 말합니다. IASA에 성공적인 회의를 개최할 수 있는지의 맥락에서 여행 장벽을 넓게 읽도록 지시합니다.

보고서 템플릿은 이 일반 요구를 80% 시험으로 운영화합니다. 그 조치는 유용합니다. 막연한 형용사가 평가가 답할 수 있는 무언가가 되기 때문입니다. 그러나 운영화는 새로운 의무를 낳습니다. 백분율이 사용되는 순간 기록에는 분모, 모집단, 방법이 필요합니다. 그렇지 않으면 겉보기 정밀성이 질문에는 속하지만 답변에는 속하지 않습니다.

분모는 사소하지 않습니다. "IETF 참석자"는 최근 여러 회의의 등록 참가자, 해당 지역에서 예상되는 참가자, 고유 개인, 회의-인원 관측치 또는 다른 예측치를 뜻할 수 있습니다. 국가 가중치는 국적, 거주지, 통상 여행 출발지를 사용할 수 있으며, 각각 다른 프라이버시·예측 결과를 낳습니다. "표준 신청 절차"에는 경계가 필요하고, "합리적 비용"은 고용주 후원 여행자와 자비 참여자에게 매우 다르게 의미할 수 있습니다. 이 글은 방법을 선택하지 않습니다. 공개 기록에 사용된 방법을 명명하도록 요구할 뿐입니다.

이것은 개인적 상황의 스프레드시트 공개를 주장하는 것이 아닙니다. 계산은 집계일 수 있습니다. 기관은 기준 회의, 국가별 계수, 공식 입국 경로, 가정된 수수료, 일반 처리 절차, 예외 사례, 결측 데이터 처리, 결과를 명시할 수 있습니다. 그러면 검토자는 누가 어떤 여권을 가지는지 알지 못한 채 출처나 가정에 이의를 제기할 수 있습니다.

같은 규율이 평가자를 보호합니다. 방법이 없으면 녹색 상태는 가벼운 판단으로 읽힐 수 있습니다. 경계가 명시된 계산과 기준 시점이 있으면, 이후 정책 변화가 새 평가를 요구하더라도 특정 시점에 이용 가능한 근거 기준으로 합리적이었던 결과가 됩니다.

공개 피드백은 기록을 추측이 아니라 정정해야 한다

밀라노 불일치에 대한 정상적 대응은 단순합니다. 공개 피드백 절차에서 이를 지적하고, 기준에 맞는 근거를 게시하거나 상태를 변경하며, 개정을 보존하는 것입니다. 악의 주장이 필요 없습니다. 이탈리아가 시험을 통과하지 못한다는 주장도 정당화되지 않습니다. 공개 절차는 이미 정확히 이런 정정을 위한 단계에 있습니다.

좋은 피드백은 간결할 수 있습니다. 보고서와 버전을 명명하고, 시험 번호 3.1을 인용하며, 설명이 3.2에 답한다고 밝히고, 80% 방법이나 상태 변경을 요구하고, 서면 문제와 밀라노에 대한 실질적 견해를 구분하는 것입니다. 이는 직원이 도시에 대한 일반적 반대를 해석하도록 강요받는 대신 실행 가능한 정정을 받게 합니다.

RFC 8711은 별개의 더 형식적인 책임 경로를 제공합니다. 참가자는 IETF BCP나 LLC 정책·절차를 따르지 않았다고 믿어지는 최고경영자 또는 이사회의 결정이나 행위에 대해 LLC 이사회에 검토를 요청할 수 있습니다. 그러한 요청은 행위, 주장된 위반, 제안된 구제를 서술해야 하며, LLC는 요청과 응답 또는 결과를 게시해야 합니다. 이 메커니즘을 예비 표를 고치는 일상적 방법으로 확대해서는 안 됩니다. 피드백 단계가 더 이르고, 더 가볍고, 더 비례적입니다.

비례성은 제도적 정당성에 중요합니다. 모든 오탈자가 항소가 되면 검토 체계는 사용 불가능해집니다. 가시적 불일치가 "그냥" 오탈자일 수 있다는 이유로 무시되면 게시된 기록은 신뢰할 수 없게 됩니다. 추적 가능한 이력을 가진 국소 정정은 행정 용량과 공신력을 모두 보존합니다.

기준-근거 영수증

Daniel Kade의 제안은 평가된 모든 행에 간결한 기준-근거 영수증을 붙이는 것입니다. 이것은 분석이며 현재 IETF 정책이 아닙니다. 영수증이 5페이지 보고서를 데이터 웨어하우스로 바꿀 필요는 없습니다. 상태가 다른 사람이 이해하고, 검증하고, 수정할 수 있을 만큼의 맥락과 함께 이동하도록 만들면 됩니다.

첫째, 권한과 버전을 명명합니다. RFC 요구, 갱신하는 BCP, 평가 템플릿 버전입니다. 둘째, 시험 식별자와 정확한 질문을 보존합니다. 상태는 그것에 의미를 부여하는 라벨 없이 복사되어서는 안 됩니다. 셋째, 범위를 명시합니다. 국가, 도시 또는 회의장, 명시된 대상, 평가 기준 시점입니다.

넷째, 근거를 연결합니다. 기준 옆에 관련 출처 또는 집계 계산을 나열하고, 왜 이 시험에 답하는지 한 문장으로 설명합니다. 다섯째, 방법을 명시합니다. 모집단, 가중치, 기준선, 결측 데이터 처리, 지역 예외입니다. 여섯째, 상태와 불확실성을 함께 기록합니다. "충족"에는 근거가 따라야 하고, "평가 불능"에는 어떤 근거가 대기 중인지 밝혀야 합니다.

일곱째, 책임 부서와 단계를 식별합니다. 기록은 그 행이 사무국 초기 평가, 최고경영자 예비 보고서, 수정된 최종 보고서 또는 이후 결정 팩에 속하는지 밝혀야 합니다. 여덟째, 개정을 보존합니다. 이전 상태, 정정된 문장, 피드백 참조, 날짜, 이유입니다. 아홉째, 기준에 병합하지 않고 하위 처리 결과를 기록합니다. 추가 조사, 권고, 거부, 상세 평가, 필요 시 IESG 검토, 이사회 결정, 계약 상태입니다.

영수증에는 한계도 필요합니다. 개인 비자 이력, 비공개 피드백, 보호되는 개인 특성, 기밀 회의장 입찰 또는 이사회 상업 팩의 내용을 드러내서는 안 됩니다. LLC로부터 선정 권한을 이전하지 않고, 공개 투표를 만들지 않으며, 모든 출처를 거부권으로 바꾸지 않습니다. 그 목적은 더 작습니다. 근거와 권한 사이의 인계를 판독 가능하게 만드는 것입니다.

정정은 증거의 일부다

흔한 유혹은 중복된 밀라노 문장을 교체하고 넘어가는 것입니다. 그것은 보고서를 개선하지만 거버넌스 기회를 잃습니다. 개정 노트는 예비 3.1 설명이 3.2를 중복했다고 밝히고, 정정된 근거를 식별하며, 녹색 상태가 변경되었는지 진술할 수 있습니다. 원본 버전은 계열상으로 남거나 최소한 지문화되고 날짜가 기록될 수 있습니다.

이 이력은 세 독자층에 봉사합니다. 커뮤니티 검토자는 자신의 의견이 기록을 바꿨다는 것을 볼 수 있습니다. 직원은 내용 정정과 정책 변경을 구분할 수 있습니다. 이후 결정자는 녹색 결과가 안정적이었는지, 새로 뒷받침되었는지, 뒤집혔는지 알 수 있습니다. 정정은 당혹감 관리처럼 보이는 대신 절차가 작동한다는 증거가 됩니다.

버전 이력은 표가 시각적으로 압축될 때 특히 중요합니다. 색상은 슬라이드, 요약 또는 결정 팩으로 복사될 수 있고 설명 문장은 남겨질 수 있습니다. 영수증이 시험 ID, 근거 해시 또는 출처 날짜와 현재 개정판을 함께 가지면 복사된 상태도 추적 가능합니다. 그렇지 않으면 표기가 그것에 색을 칠한 이유보다 오래 살아남습니다.

IETF에는 이 규율을 선호할 이유가 있습니다. 그 기술적 작업은 정확한 버전 관리, 귀속 가능한 변경, 그리고 제안·승인된 문서·구현의 구분에 의존합니다. 회의장소 행정은 프로토콜 설계가 아니지만, 제도적 교훈은 그대로 전이됩니다. 출처 없는 진술은 옮기기 쉽고 신뢰하기 어렵습니다.

지금 기록이 뒷받침하는 것

기준 시점에서 뒷받침 가능한 결론은 의도적으로 절제되어 있습니다. 밀라노 예비 보고서에는 시험 3.1과 그 설명 사이의 공개 불일치가 있습니다. 동일한 설명이 이웃한 차별 금지 시험 아래 나타납니다. 보고서는 둘 다 충족으로 표기합니다. 병행 몬테비데오 보고서와 공식 템플릿은 두 질문이 별도로 답되도록 의도되었음을 보여줍니다.

기록은 밀라노가 80% 접근 시험을 통과하지 못한다는 것, 녹색 상태가 반드시 빨간색이나 노란색으로 바뀌어야 한다는 것, 또는 몬테비데오가 선호되어야 한다는 것을 확립하지 않습니다. 어떤 내부 조사가 존재할지도 밝히지 않습니다. 최종 권고도 산출하지 않습니다. 이후 권한이 근거에 부착되기 전에 공개 피드백이 정확히 어디에서 근거를 개선할 수 있는지만 보여줍니다.

오류의 작음이 무시해야 할 이유는 아닙니다. 그것이 정정이 저렴해야 하는 이유입니다. 회의장소 결정에는 계약, 여행 부담, 참여, 제도적 신뢰가 걸릴 수 있습니다. 증거 사슬은 보통 표의 보통 행에서 시작됩니다. 그 행들이 자기 질문에 답하면 이후 재량은 가시적으로 남습니다. 답하지 않으면 색이 설명의 대체물이 됩니다.

녹색 상자는 "충족"이라고 말할 수 있어야 합니다. "우리를 믿으세요"라고 말하도록 요구되어서는 안 됩니다.

증거의 한계

이 분석은 두 예비 보고서, 현재 보고서 템플릿, 의견 요청, IETF 회의 계획 페이지, RFC 8718·8711·9712를 사용합니다. 사무국의 내부 작업 문서, 참석자 출신국 계산, 비공개 피드백, 전체 Trello 기록, 기밀 회의장 정보, 이후 최종 보고서는 갖고 있지 않습니다. 어느 도시의 최종 권고, 상업적 가용성, 이사회 결정, 계약 상태도 판단할 수 없습니다.

출처의 누락은 공개 관련 발견일 뿐입니다. 계산이 수행된 적이 없다는 증명이 아닙니다. 몬테비데오 비교는 의도된 필드 의미론을 보여주지만 그 기반 계산을 검증하거나 도시의 순위를 매기지 않습니다. 기준-근거 영수증은 Daniel Kade가 제안한 행정적 안전장치이며 채택된 IETF 요구가 아닙니다.

출처

1. 의견 요청: 몬테비데오와 밀라노 회의장소 평가 보고서
2. 밀라노 회의장소 평가 보고서
3. 몬테비데오 회의장소 평가 보고서
4. IETF 회의장소 평가 보고서 템플릿 v3
5. IETF 회의장소 식별 및 선정 절차
6. IETF 회의 장소 평가
7. RFC 8718: IETF 플레너리 회의 회의장소 선정 절차
8. RFC 8711: IETF 행정 지원 활동의 구조, 버전 2.0
9. RFC 9712: IETF 회의장소 요구사항 검토