요약

  • 2024년 6월, ARIN은 공통 IETF 표준이 수용되면 RDAP, ARIN Online, Reg-RWS에 지오피드 지원이 이루어지고, 해당 기능이 개발·배포될 때까지 커뮤니티 제안은 Open 상태로 유지된다고 밝혔습니다.
  • RFC 9877은 2025년 10월 Standards Track RFC가 되었습니다. 이 RFC는geofeed1,rel=geofeed,application/geofeed+csv를 정의하여 서버가 지오피드 기능을 정확히 광고할 수 있는 방법을 제공합니다.
  • ARIN의 현재 제안 등록부에는 여전히 해당 요청이 Open으로 표시되어 있습니다. 2026년 9월 12일에 캡처된 ARIN RDAP 도움말 응답에는geofeed1이 나열되어 있지 않으며, 선정된 네트워크 응답 하나에는 여전히 등록 코멘트에만 지오피드 URL이 담겨 있습니다.
  • 이러한 관찰은 비활성이나 데이터베이스 전반의 부재를 증명하지는 않습니다. 대신 ARIN이 트리거, 각 인터페이스, 레거시 마이그레이션, 대량 접근, 프라이버시, 테스트, 롤백과 최종 처분을 다루는 날짜가 명시된 배포 증명서를 발행해야 하는 이유를 보여줍니다.

조건은 바뀌었지만 공개 인수인계는 그대로다

표준 의존성은 기다려야 할 정당한 이유가 되곤 합니다. 다섯 레지스트리가 하나의 의도된 기능을 서로 호환되지 않는 다섯 가지 방언으로 만드는 것을 막아 주기 때문입니다. 그러나 의존성은 하나의 시계이기도 합니다. 지명된 외부 사건이 발생한 이후에는 설명이 “우리는 무엇을 기다리고 있는가”에서 “우리는 무엇을, 어디에 배포하고 있으며, 사용자는 어떻게 알 수 있는가”로 바뀌어야 합니다.

ARIN은 ACSP 제안 2024.10에 대한 답변에서 바로 그 시계를 만들었습니다. 2024년 6월 3일에 제출된 이 제안은 네트워크 객체에 선택적 지오피드 필드를 요구했습니다. 당시 표준 지오피드 URL을 광고하려는 ARIN 자원 보유자는 자유 서식 코멘트에Geofeed [URL]같은 문구를 넣을 수 있었습니다. 제안자는 그 관행을 다른 곳의 타입 지정 필드와 대조하며, 소비자가 기계 판독 가능한 포인터를 얻기 위해 산문을 구문 분석할 필요가 없어야 한다고 주장했습니다.

4일 뒤 ARIN의 답변은 단순히 아이디어를 확인하는 데 그치지 않았습니다. 다섯 RIR이 IETF에서 RDAP 확장을 공동 작업 중이라고 밝히고, “표준이 수용되는 때”가 트리거라고 했습니다. ARIN은 RDAP에서 이 변경을 구현하고 ARIN Online과 Reg-RWS에 필요한 기능을 추가할 것이라 했습니다. 일관된 대량 RDAP 다운로드 형식에 관한 작업도 언급했습니다. 그리고 그 제안은 새 기능이 개발·배포될 때까지 열려 있을 것이라고 말했습니다.

이것은 의존성 하나와 세 개의 제품, 그리고 완료 조건을 명명하는 유용한 공개 약속입니다. 다만 릴리스 계약은 아닙니다. ARIN은 “수용”이 워킹그룹 합의인지, IESG 승인인지, RFC 출판인지, RIR 간 프로필인지, 아니면 이후의 운영 마일스톤인지 정의하지 않았고, 일정도 공개하지 않았습니다. 그럼에도 Standards Track RFC가 존재하는 이상, 이 모호성은 무해한 기록 정리 문제가 아닙니다. 사용자는 트리거가 작동했는지, 그 결과 무엇이 따르는지 알아야 합니다.

RFC 9877은 필드 이름 이상을 제공한다

RFC 9877은 2025년 10월에 출판되었습니다. 그 중요성은 모든 서버에 지오피드 구현을 강제하는 데 있지 않습니다. 그러지 않습니다. 중요성은 구현하는 서버에 등록된 어휘와 클라이언트가 볼 수 있는 약속을 제공한다는 데 있습니다.

이 RFC는 서로 연관된 세 가지를 정의합니다. 링크 관계geofeed는 RDAP 링크의 목적을 식별합니다. 미디어 타입application/geofeed+csv는 대상 표현을 식별합니다. 확장 식별자geofeed1은 서버가 IP 네트워크 객체에 대한 지오피드 URL을 호스팅함을 광고하도록 합니다. IANA의 RDAP 확장 등록부에는 이제 이 식별자가 포함되어 RFC 9877을 가리킵니다.

적합성 토큰이 가장 강한 운영 의미를 갖습니다.geofeed1을 사용하는 서버는 도움말 응답과 IP 네트워크 객체를 포함하는 조회·검색 응답의rdapConformance배열에 그 토큰을 포함해야 합니다. 특정 객체에 대한 지오피드 URL을 보유하고 반환할 수 있을 때 응답에는 해당 링크가 포함되어야 합니다. 따라서 토큰을 본 클라이언트는 링크의 부재를 더 신뢰 있게 해석할 수 있습니다. 서버가 확장을 선언했고, 어떤 제약이 생략을 요구하지 않는 한 사용 가능한 URL을 반환했을 것이기 때문입니다.

중요한 절제도 있습니다. RFC 9877은 서버가geofeed1을 주장하지 않고 등록된 관계와 미디어 타입을 사용하는 것도 허용합니다. RDAP는 이미 일반 응답에서 등록된 링크 관계를 허용합니다. 토큰은 서버 전반의 기능 신호를 추가할 뿐이며, 타입 지정 링크가 나타나는 유일한 합법적 방법은 아닙니다. 이 구분이 단순한 탐지가 전체 레지스트리에 대한 무모한 주장으로 변질되는 것을 막습니다.

두 개의 실제 응답은 판결이 아니라 상태를 보여준다

2026년 9월 12일, ARIN의 실제 RDAP 도움말 응답은 상당한 기능 집합을 광고했습니다: 기본 RDAP 수준, NRO 프로필, CIDR 지원, ARIN 원본 AS 데이터, RIR 검색과 검색 결과 확장. 그러나geofeed1은 광고하지 않았습니다.

이것은 깨끗한 관찰입니다. 캡처된 도움말 응답이 그 시점에 RFC 9877 확장을 주장하지 않았다는 뜻입니다. 이것은 브랜치에 코드가 존재하는지, ARIN Online에 비공개 파일럿이 있는지, RIR 간 의존성이 남아 있는지, 혹은 ARIN이 확장 토큰 없이 등록된 링크를 의도적으로 사용할 계획인지 보여주지 않습니다. 도움말 응답은 공개 프로토콜 상태이지 백로그를 들여다보는 창이 아닙니다.

두 번째 응답은 전환 문제를 구체적으로 만듭니다.154.54.100.0/22의 선정된 네트워크 객체에는Geofeed ai.net/geofeed.csv가 담긴 등록 코멘트(Registration Comments) 비고가 있습니다. 이 객체의rdapConformance배열에는geofeed1이 없습니다. 링크 객체는self,alternate,up뿐이며, 어느 것도rel=geofeed가 아닙니다.

이 예는 커뮤니티 제안이 설명한 코멘트 관행을 보여주기 때문에 선정되었습니다. 무작위 표본이 아닙니다. 하나의 객체로는 그런 코멘트를 담은 ARIN 기록이 얼마나 되는지, 다른 곳에 타입 지정 링크가 얼마나 존재할 수 있는지, 보유자가 여전히 참조 파일을 유지하는지 알 수 없습니다. 당연히 그 파일에 주장된 위치가 정확한지도 알 수 없습니다. 좁은 사실만으로 충분합니다. RFC가 존재한 후에도 이전 공개 경로가 최소 하나의 실제 응답에 남아 있다는 것입니다.

그 관찰의 가치는 고발이 아니라 구조에 있습니다. 타입 지정 필드의 어떤 배포도 그 앞서 있던 산문을 어떻게 처리할지 결정해야 합니다.

회의 한 문장이 재조정 문제를 연다

연표에는 또 하나의 매듭이 남아 있습니다. 2026년 4월 ARIN 57 동안 ARIN의 엔지니어링 업데이트는 지오피드와 RPKI 디렉터리 서비스 향상 작업을 언급하며 “현재 IETF를 거치고 있다”고 했습니다. 그때 이미 RFC 9877은 약 6개월 동안 출판되어 있었습니다.

몇 가지 설명이 맞을 수 있습니다. 발표자가 다른 관련 명세, NRO 프로필, 지속적인 구현 조정을 의미했거나, 단순히 표준 관련 표현이 낡은 슬라이드였을 수 있습니다. 공개 기록은 그중 어느 것도 선택할 수 없고, 엔지니어링이 멈췄음을 증명하지도 못합니다. 할 수 있는 것은 공개 설명이 출판된 RFC와 재조정되지 않았음을 보여주는 것입니다.

이 구분은 제도적 시스템에서 중요합니다. 낡은 의존성은 실제 제약이 아닌 뒤에도 로드맵에 남을 수 있습니다. 그렇다면 운영자는 현재의 병목이 제품 설계인지, 보안 검토인지, 레거시 데이터 정리인지, RIR 간 합의인지, 역량인지, 우선순위인지 알 수 없습니다. 정정은 당혹스러울 필요가 없습니다. 실제 의존성을 지목하는 한 줄 메모가 오래된 표준 시계를 돌려 두는 것보다 더 유익합니다.

JSON 키가 알려진 뒤가 진짜 어려운 부분이다

구현을 링크 하나를 출력하는 일로 축소하기 쉽습니다. 그러면 가장 큰 운영 결정을 놓칩니다. 누가 포인터를 만들 수 있고, 어떻게 검증되며, 레거시 코멘트는 어떻게 되는가?

ARIN은 이 사슬에서 최소 다섯 개 표면을 통제합니다. ARIN Online은 사람이 편집하는 경로를 제공합니다. Reg-RWS는 기계 편집 경로를 제공합니다. RDAP는 결과를 소비자에게 공개합니다. 마이그레이션 절차는 기존 코멘트 형식 참조가 산문으로 남을지 타입 데이터가 될지 결정합니다. 대량 서비스는 개별 RDAP 조회가 스크래핑 시스템이 되지 않으면서 대량 사용자가 그 포인터를 수집하는 방식을 결정합니다.

각 표면은 다른 상태에 있을 수 있습니다. Reg-RWS가 노출하기 전에 ARIN Online에서 필드를 편집할 수 있을 수 있습니다. RDAP는 도움말 응답이 확장을 주장하기 전에 등록된 링크를 공개할 수 있습니다. 대량 스냅샷은 일반 조회에 뒤질 수 있습니다. 레거시 코멘트는 타입 링크와 공존할 수 있습니다. 인터페이스 매트릭스 없이 “배포됨”이라 부르면 이 차이들이 무너집니다.

마이그레이션은 특히 자동화에 저항적입니다. 코멘트에는 깨끗한 URL 하나, 후보 URL 여러 개, URL을 둘러싼 안내, 낡은 참조, 또는 단지 그 관행을 닮은 문자열이 담길 수 있습니다. 전부 무심코 추출하면 필드로 검토된 적 없는 텍스트에 구조적 권한을 부여하게 됩니다. 모든 코멘트를 무시하면 두 개의 발견 시스템이 무기한 남고 클라이언트는 어느 쪽이 우선하는지 추측해야 합니다.

더 안전한 마이그레이션은 재작성이 아니라 목록 작성에서 시작됩니다. 후보 코멘트를 세고, 깨끗함·모호함·복수·접근 불가·범위 밖으로 분류하며, 권한이 불확실한 곳은 자원 보유자에게 확인을 요청합니다. 타입 링크와 코멘트가 동시에 있을 때의 우선순위를 정의하고, 롤백 경로를 보전하며, 더 구체적인 네트워크 객체가 선택에 미치는 영향을 기록합니다. 넓은 피드를 더 구체적인 포인터 위에 적용하면 그 아래 주소의 위치 결정이 바뀔 수 있기 때문입니다.

인증이 위치 주장을 측정으로 바꾸지 않는다

RFC 9877 이전에 출판된 RFC 9632는 RPSL을 통해 지오피드 데이터를 찾는 방법과 파일을 RPKI로 인증할 수 있는 방법을 기술합니다. 인증을 의도적으로 선택 사항으로 두고, 프라이버시 고려사항을 언급하며, 일반 RDAP가 대량 검색 메커니즘이 되어서는 안 된다고 경고합니다.

이러한 주의는 새 인터페이스의 한계를 정의합니다. 자원 보유자는 지오피드 URL을 제공합니다. ARIN은 타입 링크에 그 포인터를 공개할 수 있습니다. 선택적 서명은 소비자가 그 피드가 대상 자원에 대해 승인된 것임을 확인하도록 돕습니다. 그 어떤 행위도 서버, 사용자, 패킷의 실제 위치를 측정하지 않습니다. 그 파일은 여전히 발행자의 위치 주장이며, 하류 시스템이 자체 정책에 따라 해석합니다.

기계 판독 가능한 발견은 도달 범위를 넓힙니다. 소비자는 더 이상 취약한 코멘트 파서가 필요 없고 대량 수집도 더 완전해질 수 있습니다. 그 혜택은 철회, 캐싱, 갱신 지연, 프라이버시를 규모에서 더 쉽게 잘못 다루게 만들기도 합니다. 보유자가 제거한 뒤 스냅샷에 오래된 피드가 남으면, 소비자는 자신이 낡은 데이터를 갖는지 여전히 유효한 기록을 갖는지 알아야 합니다. 더 구체적인 피드가 나타나면 결정론적 우선순위가 필요합니다. URL이 규제나 프라이버시 사유로 보류되면, 링크의 부재에는 유계인 해석이 필요합니다.

그래서 ARIN의 2024년 공통 대량 형식 언급이 배포 기록에 다시 나타나야 합니다. 그것은 주변적 약속이 아니었습니다. 트랜잭션 프로토콜과 배포 제품을 구분했습니다.

배포 증명서에 담아야 할 것

빠진 산출물은 개념상 작습니다. 공개 약속을 관찰 가능한 제품 상태와 묶는 날짜가 명시된 문서입니다. 내부 티켓을 공개하거나 완벽한 출시를 약속할 필요가 없습니다. 자원 보유자와 RDAP 클라이언트가 같은 질문 집합에 답할 수 있어야 합니다.

트리거부터 시작합니다. RFC 9877, 관련 정정(errata), 그리고 ARIN이 지배적이라 여기는 RIR 간 프로필을 명명합니다. ARIN이 2024년 조건을 충족했다고 판단한 날짜를 밝힙니다. 다른 명세가 여전히 의존성이라면 “IETF”를 일반 대기 장소로 쓰는 대신 그것을 명명합니다.

그다음 인터페이스 매트릭스를 공개합니다. ARIN Online, Reg-RWS, RDAP 도움말, RDAP 네트워크 조회, 대량 출력에 대해 각각 기능이 설계 중인지, 테스트 중인지, 사용 가능한지, 기본인지, 폐기 중인지, 완료인지를 용어를 한 번 정의하여 보고합니다. 클라이언트가 기대해야 할 정확한rdapConformance토큰, 관계, 미디어 타입을 기록합니다. 회원의 비공개 운영 선택을 노출하지 않는 양성 테스트 객체와 음성 사례를 하나씩 제공합니다.

작성 규칙을 문서화합니다. 누가 URL을 추가하거나 제거할 수 있는가? HTTPS여야 하는가? 어떤 정규화가 이루어지는가? 보유자가 RDAP 표현을 미리 볼 수 있는가? URL에 접근할 수 없을 때 어떻게 되는가? 접근 가능성이 공개를 막는가, 경고를 만드는가, 아니면 전적으로 보유자의 책임으로 남는가? 검증기가 일시적 네트워크 실패를 조용히 레지스트리 포인터의 제거로 바꿔서는 안 됩니다.

마이그레이션 원장을 추가합니다. URL 자체를 노출하지 않고 후보 코멘트의 수와 처분 클래스를 공개합니다. 어떤 사례에 보유자 확인이 필요하고 어떤 것이 그대로 남으며 언제 타입 데이터가 우선하는지 설명합니다. 마이그레이션 오류를 원본 증거를 지우지 않고 정정할 수 있도록 롤백 조건을 포함합니다.

모든 시계에 각자의 필드를 줍니다: 승인된 편집, ARIN Online 읽기 검증, Reg-RWS 읽기 검증, RDAP 가시성, 대량 스냅샷 포함. 서비스는 불가사의하지 않으면서 결국 일관될 수 있습니다. 소비자에게는 모든 인터페이스가 한 순간에 바뀐다는 불가능한 약속이 아니라 명시된 창과 스냅샷 시각이 필요합니다.

마지막으로 테스트와 거버넌스를 연결합니다. 유효한 링크, 링크 없음, 잘못된 URL, 더 구체적 재정의, 다국어 링크, 보류된 응답, 제거된 포인터에 대한 테스트 고정 장치를 나열합니다. 배포와 롤백 날짜를 기록합니다. ARIN 57 표현을 재조정합니다. 증거가 ARIN 자신의 완료 정의를 충족하면 ACSP 2024.10을 Open에서 바꾸고 그 최종 처분을 증명서에 링크합니다.

증명서는 인터페이스의 양쪽을 모두 보호한다

그런 산출물이 없으면 비판자들은 빠진 토큰을 아무 일도 없었다는 증거로 과잉 해석할 수 있고, ARIN은 비공개 진행을 완료의 충분한 증거로 과잉 해석할 수 있습니다. 두 오류 모두 코드 상태, 제품 상태, 공개 상태가 서로를 대신하도록 남겨져서 생깁니다.

증명서는 ARIN에게 유계인 주장을 줍니다: 이 인터페이스가 이 표준을 이 응답 클래스에서, 이 마이그레이션·지연 규칙 아래, 이 날짜 기준으로 지원한다는 것. 사용자에게는 유계인 테스트를 줍니다. 또한 불확실성을 보존합니다. 포인터는 위치 측정이 아니고, 서명은 지리적 진실이 아니며, 하나의 실제 객체는 인구 조사가 아니고, Open 제안은 직원 작업에 대한 판결이 아닙니다.

가장 신뢰할 수 있는 마무리는 평범할 수 있습니다. ARIN이 RFC가 하나의 선행 조건이었을 뿐이며 다른 프로필이 아직 미완성이라 도움말 토큰은 나중에 올 것이라 설명할 수 있습니다. 또는 일부 표면은 이미 실제이고 공개 등록부만 뒤처져 있음을 보여줄 수 있습니다. 어느 답이든 추론을 책임 있는 경계로 바꾸기 때문에 기록을 개선합니다.

표준은 구문 문제를 해결했습니다. 남은 작업은 제도적입니다: 의존성이 언제 바뀌었는지, 누가 각 인터페이스를 통제하는지, 오래된 데이터가 어떻게 경계를 넘는지, 클라이언트가 결과에서 무엇을 추론할 수 있는지 보여주는 것입니다.

출처