Sasha Romijn의 NRTMv4 초안은 의도와 다른 규칙을 담았다

요약

IRRD의 최초 개발자이자 유지관리자인 Sasha Romijn은 인터넷 레지스트리 미러를 동기화하는 NRTMv4의 공동 저자다.
IRRD와 RIPE NCC가 별도 구현을 만들자 동작이 달랐다. Romijn은 초안을 다시 읽고 의도했던 규칙과 실제 문구가 다르다는 점을 확인했다.
IESG 검토자는 IPv6 예제에서 route 대신 route6을 써야 한다고 지적했다. 2026년 11월 2일 현재 IETF 문서는 RFC Editor의 최종 승인을 기다린다.

Sasha Romijn은 처음에 RIPE NCC가 NRTMv4를 잘못 구현했다고 생각했다. 초안을 다시 읽자 문제는 다른 곳에 있었다. 문구가 그녀의 의도를 담지 못했다.

독립 개발자인 Romijn은 IRRD 버전 4를 처음 만들고 계속 유지해 왔다. NRTMv4 공동 저자이기도 하다. 이 프로토콜은 권위 있는 Internet Routing Registry 데이터베이스에서 미러 시스템으로 레코드를 전달한다. 네트워크 운영자는 IRR 데이터를 경로 필터와 네트워크 설정에 쓰므로 미러가 최신인지 알아야 한다.

기존 NRTMv3는 전체 데이터 덤프와 이후 변경분 조회를 서로 다른 방식으로 처리했다. 일련번호의 의미는 어느 서버 인스턴스를 조회했는지에 따라 달라졌고, 미러가 원본을 따라잡았는지 알려 주는 신호도 약했다.

NRTMv4는 스냅샷과 작은 델타 파일을 HTTPS로 공개한다. 서명된 업데이트 알림 파일은 각 파일과 해시를 가리킨다. 클라이언트는 서명을 확인하고 받은 파일의 해시를 대조한다.

문구가 시험대에 오른 것은 다른 팀의 코드가 생긴 뒤였다. Romijn과 RIPE NCC는 각자의 구현을 병행했지만 분리해 개발했다. 결과가 달랐을 때 그녀는 먼저 RIPE 구현을 의심했다. IRRD는 그녀가 의도한 규칙을 따랐고, 초안은 다른 규칙을 적고 있었다. 두 구현을 비교하자 초기 초안의 빈틈이 드러났다.

IESG 검토에서는 작은 예제 오류도 발견됐다. IPv6 경로 객체는 route6이어야 하는데 예제에는 route가 적혀 있었다. 이는 운영 장애가 아니라 문서 검토에서 잡힌 실수다. 하지만 예제는 개발자가 규칙을 구현할 때 가장 먼저 참고하는 부분이기도 하다.

2026년 5월 RIPE 92에서 Romijn은 다섯 구현이 상호운용된다고 보고했다. 그녀의 발표에 따르면 RIPE NCC는 NRTMv4를 운영 환경에 적용했고, IRRD는 클라이언트와 서버 역할을 모두 지원했다.

RIPE의 현재 데이터베이스 문서에는 운영 알림 파일 주소와 공개 키가 나와 있다. 11월 2일 현재 IETF Datatracker는 -11 초안을 RFC Editor 대기열에 두고 최종 승인을 기다리고 있다.

저자의 코드가 실행된다는 사실만으로 규격의 의미가 확정되지는 않는다. 다른 팀의 코드가 같은 문장을 어떻게 읽는지가 규칙의 명료성을 시험한다. 라우팅 레지스트리 미러에서는 그 차이를 운영 단계에 넘기기 전에 확인할 가치가 있다.