AFRINIC, 지오피드를 가리키는 주소 객체 3,573개 보유 — 스키마에는 여전히 geofeed 필드가 없다

요약

• AFRINIC의공식 데이터베이스 덤프(2026년 8월 30일 기준)에는 정확한 폴백 형식인remarks: Geofeed HTTPS-URL을 담은 RPSL 객체가 3,790개 포함되어 있으며, 이 중 3,573개는 RFC 9632 발견 모델이 다루는inetnum또는inet6num주소 객체다.
• 이 폴백은 오류가 아니다. RFC 9632는 전용geofeed:필드가 없는 레지스트리를 위해 이 형식을 명시적으로 정의하고, 마이그레이션 기간 동안 소비자가 두 형식을 모두 이해할 것을 요구한다.
• AFRINIC의 현행 주소 객체 스키마에는 선택적remarks:만 나열되어 있고geofeed:는 없다. 확인된 공개 DBWG 기록에는 작업 항목과 영향 평가 요청, 반복된 후속 요청이 있으며, 2026년 8월까지 이후 공개 처리 결과는 없다.
• 경계가 분명한 마이그레이션 수용 기록(receipt)에는 작업 항목 결정, 승인된 갱신 경로, 문법 및 충돌 규칙, 기존 기록 처리 방식, WHOIS/RDAP 투영, 개인정보·인증 한계, 테스트 결과와 롤백 근거를 담을 수 있다.

AFRINIC의 지오피드 기록에는 두 개의 서로 다른 진짜 숫자가 있으며, 이 둘을 혼동하는 것이 어느 하나의 숫자보다 문제를 더 잘 설명해 준다.

2026년 8월 30일에 마지막으로 갱신된 공식 데이터베이스 덤프에는RFC 9632가 규정한 정확하고 대소문자를 구분하는 행 형식, 즉remarks: Geofeed뒤에 HTTPS URL이 붙는 형식을 담은 객체가 3,790개 있다. 따라서 단순 행 계산기는 3,790을 반환한다. 객체를 인식하는 파서는 두 번째 질문을 던진다. 이 행을 담고 있는 객체는 어떤 종류인가?

그 두 번째 수치는 3,573이다. 이는inetnum객체 3,483개와inet6num객체 90개로 구성된다. 바로 이 주소 클래스를 중심으로 RFC가 지오피드 발견을 정의한다. 나머지 217개의 정확한 문자열은route객체 168개,route6객체 41개,도메인객체 5개,as-set객체 2개,organisation객체 1개에 나타난다.

이는 217개의 네트워크가 고장 나 있다는 증거가 아니다. 범용 서술 텍스트에는 자체적인 유형 경계가 없다는 증거다. remarks 필드는 지오피드 포인터, 지원 안내, 인증서, 어뷰즈 경고 또는 거의 어떤 텍스트든 담을 수 있다. 이 문자열이 운영상 의미를 갖는 것은 데이터베이스 스키마가 그것을 알기 때문이 아니라, 생산자와 소비자가 이를 인식하기로 합의했기 때문이다.

바로 이 구분 때문에 헤드라인은 3,790이 아니라 3,573을 사용한다. 더 큰 숫자는 RPSL 데이터베이스 전반에서의 정확한 텍스트 배치를 기술한다. 더 작은 숫자는 표준의 발견 메커니즘과 관련된 주소 객체 모수를 기술한다. 두 숫자를 모두 공표하는 레지스트리라면 그 차이를 설명할 수 있어야 하고, 하나의 숫자를 공표하는 연구자는 다른 숫자와 조용히 바꿔 쓰면 안 된다.

폴백은 실제로 일하고 있다

AFRINIC의 현재 설계를 가장 강력하게 방어하는 근거는 조직적 편의가 아니라 상호운용성이다.

RFC 9632는 모든 RIR 데이터베이스가 동시에 전용 필드를 추가하지는 않으리라 예상했다.geofeed:가 없는 경우, 문서는 정확한 remarks 형식을 정의한다. 모든 생산자가 필드 지원을 선언하고 등록자가 자신의 객체를 이전하기 전까지, 지오피드 URL을 찾는 소비자는 두 표현을 모두 이해해야 한다. 다른 레지스트리에 전용 속성이 있다는 이유만으로 AFRINIC의 remarks 형식을 거부하는 수집기가 바로 상호운용성을 깨는 쪽이 된다.

고정된 덤프는 이 폴백이 장식이 아니라는 것을 보여준다. 3,573개의 주소 객체는 106개의 서로 다른 HTTPS URL을 가리킨다. 상태 분포는 3,461개의ASSIGNED PA객체가 지배적이며, 그 외ALLOCATED PA71개,ALLOCATED-BY-RIR17개,ASSIGNED PI13개,SUB-ALLOCATED PA11개가 있다. URL이 반복되는 것은 정상이다. 하나의 제공자가 여러 등록 대역을 커버하는 단일 피드를 운영할 수 있기 때문이다.

이 수치들은 위치가 정확하거나, 모든 URL이 응답하거나, 소비자가 이를 사용한다는 것을 증명하지 않는다. 다만 공유된 공표 관례의 채택을 증명한다. 이 관례를 무분별하게 교체하면 더 깔끔한 템플릿을 위해 자원 보유자와 수집기에 비용을 전가하게 된다. 폴백이 실제로 작동하기 때문에 스키마 마이그레이션에는 영향 평가가 필요하다.

AFRINIC이 신중을 기할 만한 타당한 이유도 있다. 새로운 필드는 갱신 승인, 웹 양식, 이메일 갱신, 대량 내보내기, WHOIS 클라이언트, RDAP, 문서, 검증기, 지원 절차에 영향을 미친다. 한 수집기는 수용하고 다른 수집기는 거부하는 문법의 오래된 기록을 노출시킬 수 있다. remarks 포인터와 전용 필드가 공존할 때 충돌을 만들 수 있다. 겉보기에 사소한 데이터베이스 변경을 다중 인터페이스 호환성 프로젝트로 확대시킬 수 있다.

따라서 전용 필드의 논거는 “RFC가 언급한다”보다 더 구체적이어야 한다. 설치된 관례를 깨지 않으면서 이 필드가 기록을 어떻게 개선하는지 보여야 한다.

필드는 문법을 검증할 수 있어도 진실은 검증할 수 없다

RFC 9632는 거버넌스 수사가 흔히 흐리는 경계를 그어 놓는다. 이상적으로는 RPSL에 전용geofeed:속성이 있다. 그것이 없는 동안 remarks 형식은 유효하다. 그러나 RFC는 또한 RIR이 remarks 형식을 형식적으로 검사할 수 없다고 명시한다. 스키마 입장에서는 텍스트일 뿐이며, 주소 객체에 지오피드 참조가 최대 하나여야 한다는 권고나 두 형식이 공존할 때 전용 값을 우선하라는 권고를 스키마 차원에서 강제할 수 없다.

덤프는 이 한계를 측정 가능하게 만든다. 대소문자를 구분하지 않는 지오피드류 remarks 행을 가진 주소 객체는 3,592개이지만, 그중 106개 행은 엄격 형식에서 벗어난다. “Geofeed” 뒤에 콜론을 넣는 경우, 소문자를 쓰는 경우, HTTPS 대신 HTTP를 가리키는 경우가 있다. 이것이 모든 변형이 실제로 실패한다는 뜻은 아니다. 서술 텍스트로 저장된 관례는 스키마 차원의 거부 없이도 표류할 수 있음을 보여준다.

전용 속성은 잘못된 문법을 거부하고, 다중성을 제한하고, 충돌을 가시화하며, 내보내기 인터페이스가 포인터를 서술이 아니라 데이터로 투영하게 할 수 있다. 또한 지원 담당자가 “URL이 문법적으로 잘못됐다”와 “파일에 분쟁 중인 위치가 담겨 있다”를 구분하는 데 도움을 줄 수 있다. 유용한 개선이다.

그러나 그것이 레지스트리를 물리적 진실의 신탁으로 만들지는 않는다.

HTTPS는 파일을 제공하는 종단점을 인증하고, 전송 무결성을 제공하고, 연결을 보호한다. 그것이 그 종단점을 제어하는 당사자가 해당 IP 대역을 대변할 권한이 있음을 증명하지는 않는다. 그래서 RFC 9632는 더 강한 자원 인증을 위해 선택적 RPKI 서명을 기술한다. RPKI 서명된 파일조차 자원 인증서와 서명 데이터 사이의 관계를 증명할 뿐, 파일 안의 모든 도시·국가 코드·좌표가 주소가 실제 사용되는 장소와 매 순간 일치함을 증명하지 않는다.

세 가지 별개의 통제가 있다.

APNIC의 지오피드 필드를 다룬 기존 BTW 기사는 마지막 두 경계에 집중한다. 포인터와 더 강한 인증조차 모든 위치를 참으로 만들지는 않는다. AFRINIC의 문제는 그보다 앞선 단계에 있다. AFRINIC의 스키마는 아직 포인터를 다른 remarks와 전혀 구분하지 못한다.

공개 작업 항목에는 가시적인 종결 수용 기록이 없다

이 변경은 이번 감사에서 시작되지 않았다. 2025년 10월 AFRINIC의 공개 데이터베이스 워킹그룹(DBWG)에 들어왔다.

2025년 10월 27일, 한 참여자가 AFRINIC이 전용 속성을 추가하고 자원 소유자가 이를 갱신하도록 할 것을 제안했다. 이 메시지는 remarks 폴백이 현재 방법이라고 밝히고 PI 자원에 대한 구체적 애로를 기술했다. 필자의 경험상 관련 remarks를 갱신하려면 hostmaster의 도움이 필요했다는 것이다.

다음 날 DBWG 공동 의장은 2주 논의 기간을 열고 직원에게 영향 평가를 준비하도록 요청했다.11월 14일, 공동 의장은 반대가 없다고 보고한 뒤, AFRINIC 직원에게 이 제안을 작업 항목으로 받아 영향 평가를 포함한 구현 방법을 조언해 달라고 요청했다.

공개 스레드는 이후 조용했고, 제안자가2026년 4월 6일보고를 요청했다.4월 16일공동 의장은 직원에게 이 요청이 활성 작업 항목임을 확인해 달라고 하고 구현 및 영향 평가 요청을 반복했다. 참여자 한 명이4월 17일지지를 더했다.

확인된 공개 아카이브에는 2026년 1월, 2월, 3월, 4월, 8월에 메시지가 있는 달이 있다. 5월, 6월, 7월 아카이브는 없고, 8월 스레드 색인에는 이후 지오피드 관련 제목이 없다. 정확한 결론은 좁다. 2026년 8월까지 확인된 공개 DBWG 아카이브에는 이후 응답이나 처리 결과가 나타나지 않는다.

이것이 직원이 요청을 무시했다는 증거도 아니다. 엔지니어가 조사하지 않았거나, 사적 대화가 없었거나, 내부 티켓이 존재하지 않는다는 증거도 아니다. 메일링 리스트는 공개 기록이지 모든 내부 활동을 들여다보는 창이 아니다. 책임성 공백은 공개된 작업 항목 요청에 대한 공개 종결 객체가 없다는 점이다.

처리 결과는 “수용”, “보류”, “거부”, “대체됨”, “의존성 대기”라고 말할 수 있다. 어느 것이라도 방어 가능하다. 그러나 침묵은 운영자에게 어느 것이 해당하는지 알려 줄 수 없다.

PI 관찰은 경계가 있지만 관련성이 있다

원래 제안의 PI 주장을 부풀려서는 안 된다. 한 참여자의 경험만으로 모든 자원 보유자에 대한 보편적 워크플로를 확립할 수는 없다. 그러나 공개 덤프로는 기술된 통제 패턴이 현재 데이터에 존재하는지 검증할 수 있다.

존재한다. 엄격 형식의 지오피드를 가진ASSIGNED PI상태의 주소 객체 13개 모두mnt-by에AFRINIC-HM-MNT를 담고 있다. 또한 하위 수준 필드에는 자원별 유지관리자가 표시되어 있다. 이 구성은 할당 객체를 보호하는 주체와 더 구체적인 데이터를 만들거나 유지할 수 있는 주체의 구분과 일관된다. 그 자체로 모든 이용 가능한 갱신 채널, 모든 지원 예외, AFRINIC 갱신 서비스 뒤의 정확한 승인 코드를 밝혀 주지는 않는다.

따라서 올바른 구현 질문은 “PI 보유자가 차단되어 있는가?”가 아니다. 각 객체 상태와 유지관리자 패턴에 대해, 누가 포인터를 추가·수정·삭제·정정할 수 있고, 어떤 인터페이스를 통해, 어떤 인증 아래에서, 직접 승인이 없을 때 어떤 서비스 경로를 거치는가 하는 것이다.

그런 표는 일괄적인 셀프서비스 약속이나 일괄적인 hostmaster 통제 방어 어느 쪽보다 유용할 것이다. 일화를 검증 가능한 운영 규칙으로 바꾸어 준다.

RDAP는 의미를 서술 텍스트에 맡길 때의 비용을 보여준다

확인된 현행AFRINIC RDAP 응답(160.115.0.0)은 유효해 보이는 지오피드 포인터를 담고 있다. 이는 범용 remarks 설명 안에 나타난다. 응답은rdap_level_0,nro_rdap_profile_0,cidr0을 광고하지만,geofeed1은 광고하지 않고 구조화된 지오피드 링크도 노출하지 않는다.

RFC 9877은 RDAPgeofeed링크 관계와 선택적geofeed1확장을 정의한다. 서버는 지오피드 링크를 포함할 수 있다.geofeed1을 광고한다면, 네트워크 객체의 URL을 보유하고 있으며 공개할 수 있는 경우 해당 링크를 반환해야 한다. 확인된 AFRINIC 응답은 이 확장을 광고하지 않으므로, 링크의 부재는 비준수의 증거가 아니다.

이는 인터페이스 선택의 증거다. 사람이나 텍스트를 인식하는 수집기는 remarks 안의 URL을 알아볼 수 있다. RDAP 클라이언트는 적합성 배열에서 서버가 구조화된 지오피드 발견을 제공한다고 추론할 수 없고, 자체 텍스트 파싱을 적용하지 않는 한 remarks 설명을 표준 링크 관계로 취급할 수 없다.

이것이 스키마 부채가 프로토콜을 넘어서는 모습이다. 데이터는 존재한다. 그 의미만 암묵적으로 남는다.

목적지를 선언하기 전에 수용 기록을 공표하라

유용한 요구는 “즉시 구현하라”가 아니다. “결정과 그 결과를 검증 가능하게 만들라”는 것이다. 지오피드 스키마 마이그레이션 수용 기록에는 12가지 경계 분명한 요소가 담겨야 한다.

1. 작업 항목 식별자, 담당 기능, 접수일, 현재 상태, 다음 검토일;
2. 현재 WHOIS 스키마 버전과 목표 버전(있다면);
3. 갱신 방법, 대량 데이터, WHOIS, RDAP, 주요 수집기를 다루는 영향 평가;
4. 객체 클래스, 자원 상태, 유지관리자 관계별 쓰기 권한 매트릭스;
5. 수용되는 HTTPS 문법의 정확한 정의, 다중성 규칙, 검증 오류;
6. remarks와 전용 필드가 함께 나타날 때의 공존 및 우선순위 규칙;
7. 엄격 형식, 변형, 타 클래스 참조의 목록과 그 마이그레이션 처리 방식;
8. RDAPgeofeed1과 구조화된 링크 투영에 대한 결정;
9. 포인터 문법, HTTPS 종단점 신원, RPKI 자원 권위, 위치 정확성을 분리하는 평이한 안내;
10. 피드 세분성과 개인 노출에 대한 개인정보 안내;
11. 테스트 코호트, 호환성 결과, 정정 경로, 롤백 트리거;
12. 버전, 날짜, 텔레메트리, 미해결 예외를 담은 배포 또는 종결 수용 기록.

이 수용 기록은 구현을 미리 정하지 않는다. AFRINIC은 설치된 폴백과 현재 우선순위를 근거로 보류가 정당하다고 결론 내릴 수 있다. 기존 remarks를 이전하지 않고 단계적으로 필드를 도입할 수 있다. 스키마를 바꾸기 전에 새 엄격 형식 remarks를 검증할 수 있다. RDAP를 미루면서 WHOIS 지원을 먼저 추가할 수 있다. 중요한 것은 공개 작업 항목이 운영자가 명명하고 검증할 수 있는 상태에 도달한다는 점이다.

레지스트리 데이터베이스는 지루한 회계사일 때 가장 좋다. 지루하다는 것은 침묵이 아니다. 모든 필드가 정의된 의미를 갖고, 모든 변경이 책임 있는 경로를 가지며, 기록이 서술 텍스트에 서술이 감당할 수 있는 이상의 제도적 무게를 져 달라고 요구하지 않는다는 뜻이다.