요약

  • 레이 벨리스는 RFC 5625(BCP 152, 2009년 8월)의 단독 저자이고 RFC 8490(Proposed Standard, 2019년 3월)의 여섯 공저자 중 한 명이며, 두 경우 모두 그의 의무는 텍스트에 대한 것이지 다른 이의 구현 동작에 대한 것이 아니다.
  • 검토한 기록은 문서에 대한 의무(AUTH48 서명, errata 문의 응답)와 RFC 8126에 따른 특정 레지스트리 심사 의무를 확인하지만, 구현자에 대한 모니터링·보고·강제 의무는 부여하지 않는다.

종이에 남아 있는 것

RFC 5625 「DNS Proxy Implementation Guidelines」는 2009년 8월 날짜에 BCP 152 식별자와 Best Current Practice 범주를 달고 있으며, 단독 저자는 레이 벨리스다(rfc5625.txt). 12쪽의 Author's Address에는 소속이 Nominet UK로 적혀 있다. 그것은 출판물과 함께 인쇄된 소속이며 현재 고용 상태에 대한 진술이 아니다.

요약 과정에서 흔히 사라지는 세부가 하나 있다. RFC 5625의 1쪽 상태 블록에는 IESG 승인을 명시한 문장이 없다. 승인은 다른 곳에 기록되어 있다. 선행 초안 draft-ietf-dnsext-dnsproxy의 Datatracker 이력에서 2009년 7월 6일 IESG 승인이, 7월 7일 RFC Editor 큐로의 이관이 표시된다(초안 이력). 두 기록은 서로를 보완한다. 특정 헤더에 그 문장이 없다는 사실은 승인이 없었다는 증거가 아니다.

문서 셰퍼드도 저자가 아니다. 2009년 4월 24일자 기록은 DNSEXT 워킹그룹 공동의장 Olafur Gudmundsson을 셰퍼드로 지목한다(초안 이력). 문서 카드에는 담당 Area Director가 Ralph Droms, 워킹그룹이 dnsext로 적혀 있다(RFC 5625 카드).

사람이 아니라 프로그램에 걸린 요구

RFC 5625 4.1절(4쪽)은 프록시가 이해하지 못하는 DNS 헤더 플래그를 어떻게 처리할지를 다룬다(rfc5625.txt). 이것은 프록시에 대한 요구다. 텍스트의 저자가 세상 모든 프록시가 그 절을 어떻게 구현했는지 지켜봐야 한다는 요구로 바뀌지 않는다.

두 번째 문서는 저자 구성이 더 크다. RFC 8490 「DNS Stateful Operations」는 2019년 3월 날짜에 Standards Track 표기를 달고 있고, Datatracker는 같은 출판물을 Proposed Standard로 분류한다(rfc8490.txt, RFC 8490 카드). 저자는 여섯 명이다. 레이 벨리스, Stuart Cheshire, John Dickinson, Sara Dickinson, Ted Lemon, Tom Pusateri다. 63쪽 Authors' Addresses에는 벨리스의 소속이 Internet Systems Consortium, Inc.로 적혀 있고, 1쪽 머리말에서는 ISC로 줄여 쓴다(rfc8490.txt). 1쪽 상태 절은 문서가 공개 검토를 거쳤고 IESG에 의해 출판 승인을 받았다고 밝힌다(RFC 8490 HTML).

5.1절(1213쪽)은 DSO 엔드포인트의 동작을 규율하며, 세션이 수립되기 전에 성립해야 하는 전제 조건을 포함한다(RFC 8490 5.1절). 10.3절(5758쪽)은 특정 타입 코드 등록에 전문가 심사를 요구한다. 그 절은 벨리스를 그 전문가로 지목하지 않고, 구현 동작을 강제할 권한도 주지 않는다(RFC 8490 10.3절, txt). 이 문서는 RFC 1035와 RFC 7766을 갱신하며, 담당 Area Director는 Warren Kumari, 워킹그룹은 dnsop다(RFC 8490 카드).

절차 이력은 날짜로 읽힌다. 2018년 12월 7일 IESG 승인, 2019년 2월 11일 AUTH48 진입, 2019년 3월 15일 AUTH48-DONE. 2018년 5월 15일자 기록에서는 Tim Wicinski가 셰퍼드로 이름을 올린다(초안 이력).

실제로 존재하는 두 가지 의무

첫째는 텍스트에 대한 의무다. 2014년 9월 RFC 7322 Style Guide 4.1.1절(9쪽)은 열거된 저자와 편집자를 AUTH48 단계의 문서 서명, 그리고 errata를 포함한 문의 응답과 연결한다(rfc7322). 이것은 RFC 5625보다 다섯 해 뒤에 나온 일반 규칙이며 2009년의 구체적 관행을 기술하지 않는다. 또한 텍스트와 텍스트에 관한 질문을 다루지, 배포된 시스템을 다루지 않는다.

둘째는 레지스트리에 대한 의무다. 2017년 6월 RFC 8126을 보면, 5.1절(27쪽)은 지정 전문가가 배정 요청 검토를 조정하고 IANA에 권고를 반환하도록 한다. 5.2절(2728쪽)은 방어 가능한 결정을 요구하고, 심사 대상 규격의 저자라는 이해 충돌을 포함한 회피를 다룬다. 5.2.1절(2829쪽)은 IETF 레지스트리 전문가의 임명과 해임을 IESG에 둔다. 5.3절(29쪽)은 적시성과 투명성을 요구한다(rfc8126).

여기서 기록은 서로 어긋난다. Datatracker 프로필은 조회 시점에 「Ray does not currently have any active roles」라고 밝히고, 그의 문서로 RFC 5625(2009년 8월)와 RFC 8490(2019년 3월)을 나열했다(프로필). IANA 「Domain Name System (DNS) Parameters」 레지스트리는 2026년 11월 9일 마지막 갱신 상태로 벨리스를 Resource Record TYPEs 전문가 중 한 명, 그리고 EDNS0 옵션 코드의 2차 전문가로 올린다. DSO Type Codes 전문가는 Ted Lemon, Sara Dickinson, John Dickinson이다(IANA 레지스트리). 검토한 어떤 기록도 이 두 목록을 화해시키지 않는다. 프로필 문구는 현재 시제로 역할 패널을 서술한 것이며 과거 임명 전체의 목록이 아니다. 역할이 한 번도 없었다는 증거도 아니다.

의장석은 절차다

2014년 3월 19일 IAB 전화회의 의사록 2.2절 IESG Liaison 보고의 인사 변동 항목은 벨리스가 Alissa Cooper를 이어 geopriv 의장이 되었다고 기록한다(IAB 의사록). 발효일과 임기는 이 기록에서 나오지 않는다.

IETF 93 자료 페이지는 벨리스와 Mark Townsley를 Homenet 워킹그룹 의장으로 나열하며, 세션 날짜는 2015년 7월 22일이다(IETF 93 자료). 이것은 한 회의 기록에 실린 의장 명단이지 현직 임명이 아니다.

의장직에는 고유한 절차 의무가 붙는다. 1998년 9월 RFC 2418 3.1절(11쪽)은 워킹그룹 의장이 세션 의사록을 작성·배포하도록 책임을 지우면서 그 업무의 위임을 허용한다. 6.1절(17쪽)은 의장이 Area Director에게 회의 후 짧은 보고를 하도록 요구한다(rfc2418). 이것은 개인에게 걸린 보고 의무이며 행정적·절차적이다. 규격 구현에 대한 감사로 확장되지 않는다.

기록에 없는 것

부정적 결론은 좁게 정식화된다. 검토한 RFC 어느 조항도 저자라는 이유만으로 벨리스에게 구현자의 준수 여부를 감시하고, 보고하고, 강제할 의무를 부여하지 않는다. 범위는 이 기사를 위해 실제로 읽은 문서로 한정된다. RFC 5625, RFC 8490과 그 HTML 판본, 문서 카드 두 건과 Datatracker 이력 두 건, 프로필, IANA 레지스트리, RFC 7322, RFC 8126, RFC 2418, 2014년 IAB 의사록, IETF 93 자료다(rfc5625.txt, rfc8490.txt, RFC 8490 HTML, RFC 5625 카드, RFC 8490 카드, dnsproxy 이력, session-signal 이력, 프로필, IANA 레지스트리, rfc7322, rfc8126, rfc2418, IAB 의사록, IETF 93 자료).

이것은 그런 의무가 어디에도 없다는 뜻이 아니다. 고용 계약, 조달 요건, 법률, 인증 제도, 별도의 임명 문서에서 생길 수 있다. 검토한 기록에서는 그런 도구가 하나도 발견되지 않았다.

세 개의 사슬, 다섯 개의 요소

사람 수준의 책임을 시험하려면 다섯 요소가 필요하다. 의무의 출처, 그 사람의 역할이나 실제 통제, 구체적 작위 또는 부작위, 운영상 결과와의 인과 연결, 적용 가능한 구제 수단과 포럼이다. 입증된 의무와 통제가 텍스트나 레지스트리 심사에서 끝난다면, 책임의 귀속도 거기서 끝나야 한다.

문서 사슬은 텍스트와 그에 관한 질문을 다룬다. 출판 당시 유효했던 규칙에 따른 AUTH48 서명과 errata 응답이다(rfc7322, rfc5625.txt, rfc8490.txt). 공급자가 적합한 코드를 출하했는지, 운영자가 올바로 설정했는지는 이 사슬에 없다.

레지스트리 심사 사슬은 특정 레지스트리의 배정 요청 검토를 다룬다. 방어 가능성, 적시성, 투명성, 그리고 심사 대상 규격의 저자일 때의 회피를 포함한 이해 충돌 처리가 그것이다(rfc8126, IANA 레지스트리). 패킷 수준 모니터링이나 배포된 시스템에 대한 강제는 여기에 없다. 회피 규칙은 역할을 넓히는 것이 아니라 좁힌다.

구현 사슬은 코드 적합성, 설정과 사고 대응, 조달자와 감사자가 지는 요건, 그리고 계약·법률·기타 의무 창설 수단이 부여할 때만 존재하는 강제를 다룬다. 이 중 어느 것도 검토한 기록이 문서 저자에게 귀속시키지 않는다.

구현 실패는 누구의 것인가

보통 소리 내어 던지는 질문은 이렇다. 구현이 규격을 무시했을 때 누가 답했는가. 기록에 답은 있지만 저자에 관한 답이 아니다. 구현 책임은 코드를 쓰는 사람, 제품을 고르고 배포하는 사람, 설정하는 사람, 구매하는 사람, 그리고 법에 따라 운영을 감독하는 사람이 나눠 진다. 강제는 계약·법률·기타 구속력 있는 수단이 만들어 낼 때만 나타나며, 검토한 어떤 문서도 텍스트 저자에게 그런 역할을 주지 않는다.

경계는 곧게 말하는 편이 정직하다. 저자는 실제로 책임을 진다. 텍스트와 특정 레지스트리 기능에 대해서다. 그가 하지 않는 것은 남의 운영 중인 네트워크를 심사하는 일이다. 이 비대칭이 실제 발견이다. 책임은 존재하고, 이름이 붙고, 한정되어 있으며, 그 나머지 절반인 구현 감독은 누군가 계약·법률·직무 기술서로 채우기 전까지 공석으로 남는다.