본문으로 건너뛰기

인텔리전스

최신 기사

인프라 운영 주체, 정책 결정, 시장 동향, 디지털 권력 이동에 관한 최신 인텔리전스입니다.

SHUT 상태는 OFF 노드가 아니었다: RFC 1289는 기존 링크를 유지했다

역사

SHUT 상태는 OFF 노드가 아니었다: RFC 1289는 기존 링크를 유지했다

‘종료(shutdown)’라는 단어는 깔끔한 이야기를 유혹합니다. 운영자가 상태를 선택하면 노드가 멈추고 작업이 끝난다는 이야기입니다. RFC 1289는 이보다 더 엄격한 시간 순서를 유지했습니다. 이 RFC의 DECnet Phase IV MIB는 모든 접속 제한을 OFF 노드로 취급하지 않았습니다. `SHUT`은 새 논리 링크를 막았지만 이미 존재하던 링크는 파괴하지 않았고, 그 링크들이 모두 사라졌을 때에만 노드는 `OFF`로 갔습니다. `OFF`는 추가 결과를 실었습니다: 새 링크 없음…

2026년 9월 1일
Todd Herr와 메시지를 안전하게 만들지 않는 DMARC pass

IETF

Todd Herr와 메시지를 안전하게 만들지 않는 DMARC pass

수신자는 두 가지 참된 사실을 동시에 받을 수 있다: 표시된 도메인이 승인을 받아 사용되었고, 그리고 메시지는 여전히 원치 않거나 기만적이거나 위험하다. RFC 9989는 더 큰 판정으로 이 역설을 해결하려 하지 않는다. 오히려 DMARC 판정의 작은 크기를 보호한다.

2026년 9월 1일
한 주간, 두 기관, 그리고 두 개의 회차 번호: npNOG와 SANOG-38 풀어보기

NPNOG

한 주간, 두 기관, 그리고 두 개의 회차 번호: npNOG와 SANOG-38 풀어보기

2022년 7월, 카트만두 메리어트에 도착한 운영자들은 하나의 기술 주간을 맞았습니다. 워크숍 4일 후 컨퍼런스가 이어졌습니다. 그러나 남겨진 기관 기록은 그만큼 통일되어 있지 않습니다. npNOG는 이 행사를 SANOG-38과 함께 열린 NPNOG-6로 기록하고, SANOG의 당시 페이지들은 같은 주간을 npNOG 9라고 불렀습니다. 그 불일치는 오타처럼 작지만, 어떤 기관이 행사의 어떤 부분을 발행·주최·통제했는지를 드러내기에 충분합니다.

2026년 9월 1일
메모는 스스로 표준이라 했지만 기록은 그렇지 않았다: RFC 1097

역사

메모는 스스로 표준이라 했지만 기록은 그렇지 않았다: RFC 1097

1989년 4월 1일, 세 페이지짜리 RFC가 사용자가 인지할 수 없을 만큼 빠르게 깜빡이는 메시지를 위한 Telnet 옵션을 제안했습니다. 그 농담은 쉽게 알아볼 수 있습니다. 더 내구성 있는 교훈은 조용합니다. 메모는 스스로를 표준이라 부를 수 있었지만 그 지위를 자신에게 부여할 수는 없었고, Telnet 클라이언트는 옵션에 동의할 수 있었지만 터미널 앞의 사람이 동의했거나, 표시를 지각했거나, 방침을 바꿨다는 것을 증명할 수는 없었습니다.

2026년 9월 1일
RIR 거버넌스 초안, 긴급 시 자체 변경 경로 동결 예정

스토리

RIR 거버넌스 초안, 긴급 시 자체 변경 경로 동결 예정

공개된 RIR 거버넌스 문서 버전 3.4는 레지스트리 위기가 어떻게 처리될 수 있는지뿐 아니라 작지만 중요한 기관적 브레이크도 제안합니다. 위기 메커니즘이 작동하는 동안 그 메커니즘을 규율하는 규칙은 변경될 수 없습니다.

2026년 9월 1일
Internet Society, 정책 서문에 '복종 의무'를 추가하다. 그 의무가 묶는 대상은 경영진이 아니라 미션

케이스 파일

Internet Society, 정책 서문에 '복종 의무'를 추가하다. 그 의무가 묶는 대상은 경영진이 아니라 미션

한 단어가 통치 문서를 권위주의적으로 보이게 만드는 동시에, 그 밑에 있는 규칙은 오히려 읽기 쉬워질 수 있다. Internet Society 이사회는 2026년 7월 자신들의 수탁자 신의성실 의무 정책 서문에 복종의 의무를 추가했다. 그러나 이사회 결의문은 이번 편집이 본문과의 정합을 위한 것이며, 해당 의무는 이미 적어도 10년간 본문에 존재해 왔다고 밝히고 있다. 더 중요한 것은 이 정책이 복종을 조직의 미션, 구성 문서, 적용 법령에 대한 충실로 정의한다는 점이다. 이는 사무직 보유자에…

2026년 9월 1일
Adrian Farrel과 출간 전에 사라진 구현 영수증

IETF

Adrian Farrel과 출간 전에 사라진 구현 영수증

인터넷 드래프트에서 가장 유용한 절 중 하나는 만료 조건을 달고 작성된다. 그것은 제안을 실체화한 코드, 버전, 적용 범위, 라이선스, 테스트 연락처, 상호운용성 근거를 명시할 수 있다. 그리고 제안이 RFC가 되면 그 절은 사라지도록 되어 있다.

2026년 9월 1일
AFRINIC, 차기 CEO 임명 — 2027년 1월 1일 취임

스토리

AFRINIC, 차기 CEO 임명 — 2027년 1월 1일 취임

임명은 이미 공개되었지만 결정일은 공개되지 않았다. CEO Designate라는 지위만으로 직무 권한이 앞당겨지지 않는다.

2026년 9월 1일
브리지 포트는 반드시 인터페이스가 아니었다. 그 카운터는 전체 회선을 설명하지 않았다: RFC 1286

역사

브리지 포트는 반드시 인터페이스가 아니었다. 그 카운터는 전체 회선을 설명하지 않았다: RFC 1286

네트워크 운영자는 익숙하고 안심이 되는 세 가지 사실을 받을 수 있습니다: 포트 번호, 인터페이스 인덱스, 그리고 카운터. 1991년 브리지 MIB인 RFC 1286은 이러한 사실들이 하나의 그림으로 무너지지 않도록 거부했다는 점에서 가치가 있습니다. 브리지 포트는 인터페이스에 대응할 수 있지만 그것과 동일한 것은 아니었고, 여러 포트가 하나의 인터페이스를 공유할 수 있었으며, 브리지 카운터는 해당 주체가 실제로 브리징하는 프로토콜만 측정할 수 있었습니다. 포워딩 테이블 역시 똑같이 좁았습니다.…

2026년 9월 1일
표시 위치는 Telnet을 건너갔다. 접근 권한은 여전히 X에 속했다: RFC 1096

역사

표시 위치는 Telnet을 건너갔다. 접근 권한은 여전히 X에 속했다: RFC 1096

1989년 3월, 작은 Telnet 옵션이 하나의 어색한 문제, 즉 나뉜 맥락의 문제를 해결했다. 원격 호스트에 로그인한 사람은 그곳에서 X 애플리케이션을 시작할 수 있었지만, 그 호스트는 사용자의 화면이 어디에 있는지 알지 못했다. RFC 1096은 Telnet 클라이언트가 표시 로케이터를 제공하도록 했다. 편의는 실재했지만 좁았다. Telnet은 주소를 운반했을 뿐이며, 별도의 X 연결이 여전히 서버에 도달해 그 통제를 충족해야 했다.

2026년 9월 1일
선택 속성은 클래스를 확장할 수 있었다. 필수 속성은 새 클래스를 시작해야 했다: RFC 1274

역사

선택 속성은 클래스를 확장할 수 있었다. 필수 속성은 새 클래스를 시작해야 했다: RFC 1274

초기 디렉터리는 모든 지역 요구를 보편적 명령으로 바꾸지 않으면서 공통 어휘가 필요했다. RFC 1274가 COSINE과 인터넷 X.500 파일럿을 위해 택한 답은 고정된 목록도, 모든 사이트가 같은 이름을 사적으로 재사용하도록 허용하는 것도 아니었다. 더 신중한 주장이었다. 시스템은 유형을 저장하고 식별하기 위한 스키마를 공유할 수 있지만, 매칭·강제·표시·현실의 진실에 대한 의미론은 별개의 작업으로 남는다는 것이었다. 변경 규칙도 마찬가지로 절제되었다. 선택적 추가는 클래스를 강화할 수…

2026년 9월 1일
RIPE, LatencyMON 재구축. 차트에는 여전히 자체 해석 근거 기록이 필요하다.

스토리

RIPE, LatencyMON 재구축. 차트에는 여전히 자체 해석 근거 기록이 필요하다.

RIPE NCC가 RIPE Atlas의 프로브 간 지연 시간 추세를 비교하는 뷰인 LatencyMON을 재구축했습니다. 이번 업데이트는 측정 표면을 훨씬 더 넓게 드러냅니다. 더 많은 테스트 유형, 그룹화 로직 선택, 집계 시간 범위를 넘어서는 접근 옵션, 자체 설정을 함께 전달하는 공유 가능한 뷰가 그것입니다. 덕분에 차트를 검토하기는 쉬워졌습니다. 하지만 차트 자체가 운영자가 무엇을 결론 내려야 하는지에 대한 완전한 기록이 되는 것은 아닙니다.

2026년 9월 1일
두 프로토콜은 "Recommended"였다. 상호운용을 정의한 것은 프로파일이었다: RFC 1095와 CMOT

역사

두 프로토콜은 "Recommended"였다. 상호운용을 정의한 것은 프로파일이었다: RFC 1095와 CMOT

1989년 4월, 인터넷에는 네트워크 관리에 대한 공식 답이 하나 있지 않았습니다. CMOT와 SNMP는 동일한 Draft Standard 및 Recommended 표지를 달고, 같은 인터넷 MIB를 기술하도록 되어 있었습니다. 그러나 공유된 객체 목록은 공유된 체계가 아니었습니다. RFC 1095는 CMIP부터 TCP 또는 UDP까지 모든 틈새를 명시해야 했고, 그럼에도 하나의 관리 도메인 경계에서 멈췄습니다.

2026년 9월 1일
RIPE NCC가 다중 서비스 취약점을 수정한 방식, 수정 이력 기록이 필요한 이유

스토리

RIPE NCC가 다중 서비스 취약점을 수정한 방식, 수정 이력 기록이 필요한 이유

'수정 완료'는 본래 완전한 상태가 아닙니다. 어떤 변경이 배포되었음을 뜻할 수도 있고, 원래 문제가 재검증을 통해 사라졌음이 확인되었음을 뜻할 수도 있습니다. RIPE NCC는 2026년 6월 여러 서비스에 걸친 취약점 공개를 회고하면서 이 둘을 드물게 구분했습니다. CSRF에 대한 첫 수정은 문제의 일부만 다루었고, 이후 검토에서 원래 개념 증명이 여전히 실행 가능함이 드러났으며, 팀이 추가 경로를 식별하고 계속 처리한 뒤에야 완전한 수정이 성립했습니다.

2026년 9월 1일
Qin Wu와 실무를 따라잡아야 했던 레지스트리 규칙

IETF

Qin Wu와 실무를 따라잡아야 했던 레지스트리 규칙

IANA 레지스터에서 동일한 YANG 모듈 이름이 세 번 등장하고, 각각 다른 날짜와 하나의 XML 네임스페이스에 연결되어 있습니다. 이는 고유성 위반이 아닙니다. 안정적인 정체성과 그 안에서 변화하는 개정판을 구분하는 데 필요한 근거입니다.

2026년 9월 1일
측정은 결과가 되기 전에 허가가 필요했다: RFC 1262

역사

측정은 결과가 되기 전에 허가가 필요했다: RFC 1262

1991년, 인터넷 활동 위원회(IAB)는 연구자들의 정당한 야망에 대해 일부러 낭만 없는 답을 내놓았다. 네트워크 측정은 인터넷의 발전, 진화, 배포 계획에 결정적으로 중요했지만, 동시에 측정이 이해하려는 대상인 운영 그 자체를 흔들 수도 있었다. RFC 1262는 이 두 사실을 한 프레임 안에 함께 두면서, 유용한 측정 질문만으로는 타인의 기계나 네트워크에 부담을 지우는 것을 정당화할 수 없다는 지름길을 거절했다.

2026년 9월 1일
IETF, AUDIT BoF 기각. 새 메일링 리스트는 포럼일 뿐 워킹그룹이 아님

IETF

IETF, AUDIT BoF 기각. 새 메일링 리스트는 포럼일 뿐 워킹그룹이 아님

8월 31일 IETF가 AI 에이전트 행위의 감사 가능성을 위한 잠재적 노력을 위한 메일링 리스트를 열었다. 이는 유용한 제도적 조치였다. 그러나 제안자들이 요청한 노력의 승인은 아니었다: 공개 BoF 기록은 여전히 기각(Declined) 상태이고, 리스트는 명시적으로 비-WG이며, 논의 중인 아키텍처는 여전히 개인 Internet-Draft다. 이 구분은 사무적이지 않다. 그것은 방에 대한 접근과 제도의 이름으로 행동할 권한 사이의 경계다.

2026년 9월 1일
MAC 주소는 있었지만 IP 스택은 없던 장비: RFC 1089의 단일 LAN 관리 채널

역사

MAC 주소는 있었지만 IP 스택은 없던 장비: RFC 1089의 단일 LAN 관리 채널

리피터는 네트워크를 좌우할 수 있었지만 운영자가 관리에 쓰던 인터넷에는 존재하지 않았습니다. RFC 1089는 평범한 SNMP 메시지를 이더넷 프레임 안에 직접 넣는 방식으로 이 어색함을 해결했습니다. 없어진 계층은 에이전트를 단순하게 만들었지만 경계도 좁혔습니다. 하나의 논리적 LAN, 하나의 인터페이스 엔드포인트, 그리고 장비 변경을 허용할 주체에 대한 새로운 답은 없었습니다.

2026년 9월 1일
Daniel Eggert와 안정적인 페이지가 아니었던 메시지 배치

IETF

Daniel Eggert와 안정적인 페이지가 아니었던 메시지 배치

UID 범위는 메일함을 관리 가능한 작업 단위로 나눌 수 있지만, 메일함을 고정하거나 메시지를 하나하나 나열하거나 각 단위의 비용을 동일하게 만들지는 않습니다. RFC 10022는 클라이언트에 분할 결과를 제공할 뿐, 페이지네이션의 확실성을 보장하지는 않습니다.

2026년 9월 1일
하트비트는 X.25 서브어드레스를 유지했지만 요청을 인증하지는 않았다: RFC 1086의 TP0 브리지

역사

하트비트는 X.25 서브어드레스를 유지했지만 요청을 인증하지는 않았다: RFC 1086의 TP0 브리지

한 TCP/IP 호스트가 자신이 속하지 않은 네트워크에서 주소를 원했습니다. RFC 1086은 브리지가 그 호스트를 대신해 X.25 서브어드레스에서 대기하도록 했지만, 별도의 TCP 연결이 열려 있는 동안에만 가능했습니다. 이 메커니즘은 희소한 슬롯을 언제 반환할지는 알았지만, 누가 그 자격이 있는지는 알지 못했습니다.

2026년 9월 1일