주요 분야
인프라
‘주요 분야’ 패싯에서 인프라 인텔리전스는 보고 내용을 주 영역별로 묶어, 독자가 인터넷 인프라, 거버넌스, 연결성 시장 또는 디지털 자본 가운데 특정 영역을 집중적으로 따라갈 수 있도록 합니다. 이 페이지는 별도 카테고리 페이지에 나뉘어 있을 수 있는 관련 기사, 공개 증거, 기관, 기업, 인물, 지역적 노출, 운영 의존성, 시장 맥락을 한데 모읍니다. 아울러 해당 영역, 예상 행위자 유형, 시장 또는 거버넌스 맥락, 그리고 신호를 비교할 때 독자가 활용해야 할 출처 자료를 설명합니다. 운영자, 분석가, 거버넌스 분야 독자는 같은 영역이 이벤트, 프로필, 시장 변화, 공개 출처 증거, 지역 의존성, 보다 장기적인 주기의 인프라 의사결정 전반에서 시간에 따라 어떻게 나타나는지 살펴볼 수 있습니다.
역사
10억 명의 사용자가 있어도 대다수는 여전히 배제되어 있었다: RFC 3271
2002년 Vint Cerf는 2005년 말까지 인터넷 사용자가 10억 명을 넘을 것으로 전망하면서도, 그 수치가 여전히 세계 인구의 약 16%에 불과하다는 점을 즉시 짚었다. 이 대비는 '인터넷은 모두를 위한 것'이라는 구호가 여러 개별 조건을 요구하는 시험 문제임을 보여준다.
역사
IPsec는 패킷마다 인증했지만 터널 안의 사용자까지는 증명하지 않았다: RFC 3193
RFC 3193은 불편한 사실에서 출발했습니다. 패킷이 암호학적으로 진본일 수 있어도 그 패킷을 보낸 사용자가 누구인지는 증명하지 못했습니다. IKE는 기기를, PPP는 세션 시작 시점의 사람을 검증했습니다. 두 증명 사이에서 L2TP와 IPsec은 포트, 주소, 필터, 종료 절차를 조율하면서 각 계층 고유의 신원을 지워서는 안 되었습니다.
역사
재사용 가능한 블록도 함께 실패할 수 있었다: RFC 3269
신뢰할 수 있는 멀티캐스트에는 재사용 가능한 구성 요소만으로는 부족했다. RFC 3269는 각 RMT 블록이 자신의 한계와 의존성을 선언하고, 완전한 프로토콜이 구성 요소들이 어떻게 결합되는지 설명하도록 요구했다.
역사
주소 계획은 87% 찼지만 대부분의 주소는 여전히 비어 있었다: RFC 3194
RFC 3194는 계층적 주소 지정의 고통에 백분율을 붙였습니다. 그 결과는 익숙해 보였지만 특이한 의미를 지녔습니다: IPv4 규모의 계획이 87% 호스트 밀도일 때 그것은 약 2억 4,000만 주체를 담았고, 43억 주소의 87%가 아니었습니다. 이 척도는 서로 다른 공간들 사이의 확장 압력을 비교했을 뿐, 문자 그대로의 공간이 얼마나 점유되었는지는 세지 않았습니다.
역사
게이트웨이가 오른쪽을 소유하기 전까지 전화번호는 이메일 주소가 아니었다: RFC 3191
골뱅이 왼쪽 문자열은 전화 지시처럼 보였습니다. 그렇다고 모든 메일 서버가 그 번호를 거는 권한을 갖는 것은 아니었습니다. RFC 3191은 오른쪽 도메인이 번호, 서비스, 한정자를 해석할 게이트웨이를 선택하도록 하고, 그 게이트웨이 너머의 전달은 별개의 사건으로 남겼습니다.
역사
최솟값 샘플은 네트워크에서는 오디오, 테이프에서는 오류였다: RFC 3190
파형의 바닥에 있던 그 숫자에는 서로 양립할 수 없는 두 가지 역할이 있었다. RTP는 이를 평범한 샘플로 취급했고, DV 장비는 샘플이 살아남지 못했다는 통지로 취급했다. RFC 3190은 브리지에게 어느 의미가 경계를 넘을지 선택하게 했다.
역사
국가 접두어는 리졸버를 찾아주었다. 아카이브가 객체를 보관했다는 증거가 아니었다: RFC 3188
`fi` 접두어는 클라이언트에게 핀란드의 NBN 분야가 어디서 시작되는지 알려줄 수 있었다. 그러나 수확된 웹 페이지를 살아남게 하거나, 오늘 응답하는 서비스를 인증하거나, 반환된 파일이 원본임을 증명할 수는 없었다. RFC 3188은 각 지역 도서관 번호의 연합체를 전 세계적으로 이름 지을 수 있게 만들었지만, 영속성은 여전히 기관, 아카이브, 운영 중인 리졸버 안에 있었다.
역사
ISBN은 판(版)을 식별했다. 여러 부를 가리킬 수도, 잘못된 책을 가리킬 수도 있었다: RFC 3187
영속적인 이름은 위치가 바뀌어도 살아남아야 했다. RFC 3187은 그 거래를 구체적이면서도 애매하게 만들었다. 하나의 ISBN URN은 여러 URL로 이어질 수도, 디지털 객체 전혀 없이 끝날 수도, 출판사가 번호를 실수로 재사용해 두 개의 서지 기록으로 이어질 수도 있었다. 영속성은 식별자에 속했다. 단일성은 아니었다.
역사
고객은 전용 회선을 봤다. 운영자는 숨겨진 주소 쌍을 쥐고 있었다: RFC 3186
한쪽 끝에서 고객 장비는 평범한 PPP 프레임을 내보냈다. 반대쪽 끝에서 고객 장비는 그것을 받았다. 그 사이에서 스위치들은 프레임의 첫 옥텟들을 교체하고 공유 MAPOS 패브릭을 통해 전달한 뒤 원래 값을 복원하고 그 내부 장치를 시야에서 가렸다. RFC 3186은 그 결과를 투명하다고 불렀다. 그러나 더 오래 남는 교훈은, 단순한 인터페이스가 조밀한 제어 표면을 감추면서도 그 표면을 사라지게 하지는 않는다는 것이다.
역사
수신자 목록은 줄었지만 기존 키는 여전히 메시지를 열었다: RFC 3185
두 번째 암호화 메시지는 첫 번째보다 적은 수신자를 명시했습니다. 그러나 생략된 한 구성원은 여전히 그 메시지를 열 수 있었습니다. 아무것도 오작동한 것이 아니었습니다. RFC 3185는 이것이 이전 그룹에 이미 전달된 콘텐츠 키 자료에서 이후 키 암호화 키를 도출하는 예상된 결과라고 경고했습니다. 가시적 봉투는 좁아졌지만, 실제 복호화 권한은 그렇지 않았습니다.
역사
도메인이 메시지에 서명했다. 개인은 여전히 이름이 없었다: RFC 3183
받는 사람은 메시지가 인증된 조직 경계를 통과했음을 확인할 수 있었지만, 발신자 개인의 이름을 표시할 수는 없었다. RFC 3183은 이 구분을 유례없이 명확하게 만들었다. 이 도메인 보안 체계는 '서명'이라는 단일한 포괄적 행위를 제공하지 않았고, 기원·공개·검토·속성 바인딩·암호화·복호화에 서로 다른 권한을 부여하며, 수신자에게 각 암호화 계층이 실제로 담고 있는 주장이 무엇인지 알도록 요구했다.
역사
이름은 RSVP에 들어왔다. 권한은 여전히 그 의미를 판단해야 했다: RFC 3182
2001년 RSVP 요청은 사용자 이름, 애플리케이션 이름, Kerberos 티켓 또는 인증서를 희소 자원을 배분할 라우터 쪽으로 실어 보낼 수 있었다. 이는 신원이 곧 권한이 되는 것처럼 들린다. 그러나 RFC 3182가 문서화한 것은 훨씬 조건적인 구조였다. 이름은 정책을 가리키고, 자격 증명은 인증을 뒷받침하며, 정책 결정 지점이 규칙을 해석하고, 강제 지점이 로컬에서 실행했다. 멀티캐스트 트리에서는 살아남은 신원조차 선택될 수 있었다. 따라서 이 프로토콜의 역사는 여권을 패킷에 넣은…
역사
새 플로우가 입장에 성공했다. 그 방어 우선순위는 여전히 다음 도착을 버텨야 했다: RFC 3181
늦게 도착한 플로우도 기존 예약을 밀어낼 수 있었다. RFC 3181은 그 역전을 의도적으로 만들었지만, 하나의 숫자에 영구적 권한을 부여하지는 않았다. 새 플로우는 선점 우선순위로 경쟁했고, 입장 후에는 다른 값이 다음 도착에 대한 방어가 되었다. 그 사이에는 정책의 출처, 병합 규칙, 로컬 용량, 집행, 오류 신호가 있었고, 그 너머에는 패킷 처리와 애플리케이션 결과가 있었다. 이 프로토콜의 유용한 역사는 순위와 사람들이 그것이 구매한 것으로 가정한 서비스 사이의 거리다.
역사
런타임은 231로 응답했다. 스크립트는 여전히 종료 수신증을 남겨야 했다: RFC 3179
관리 시스템은 일이 끝나기 전에 올바르게 답할 수 있다. RFC 3179는 그 시간적 간격을 명시적으로 만들었다. 하나의 응답은 관리 스크립트가 런타임 상태에 도달했음을 말했고, 다른 메시지들은 중간 출력이나 오류를 전달했으며, 이후의 응답이 종료를 표시했다. 그중 어느 하나만으로는 의도한 변경이 네트워크에 도달했다는 증거가 되지 않았다. 이 프로토콜의 유서는 원격 스크립팅이 아니라, 명령 수락과 실행 증거, 운영 결과가 하나의 초록 불로 붕괴하지 않도록 유지하는 방법이었다.
역사
코어는 흐름을 잊었다. 에지는 여전히 그 예약을 증명해야 했다: RFC 3175
RFC 3175는 2001년에 매력적인 거래를 제안했다. 모든 코어 라우터가 모든 예약 흐름을 기억하지 않되, 종단 간 수용은 에지에서 유지한다. 이 거래는 상태 압축이 증거 압축으로 이어지지 않을 때만 작동했다. 하나의 커다란 예약은 수천 개의 약속을 실을 수 있었지만, 그중 어느 하나의 약속이 지켜졌음을 증명할 수는 없었다.
역사
레지스트리는 멀티캐스트 주소를 할당했다. 그래도 누군가 사용하는지 물어야 했다: RFC 3171
레지스트리의 항목은 숫자가 움직이지 않기 때문에 영구적인 것처럼 보일 수 있다. RFC 3171은 그 정지를 의심스럽게 다루었다. 전역 조율되는 IPv4 멀티캐스트 주소는 이유, 대안, 주기적 검토, 그리고 가능한 경우 회수를 요구할 만큼 희소했다. 장부는 애플리케이션이 여전히 실행되고 있음을 증명하지 않고도 결정을 보존할 수 있었다.
역사
인덱스는 정책 행을 이름 지었을 뿐, 그 행이 무엇을 의미하는지 설명하지 않았다: RFC 3159
프로비저닝 시스템에 두 개의 행이 도착했습니다. 두 행은 같은 값들을 담고 있고, 행 번호만 다릅니다. 네트워크가 서로 다른 두 정책을 받은 것일까요, 같은 정책을 두 번 받은 것일까요, 아니면 해석을 기다리는 주소 지정 가능한 두 기록일 뿐일까요? RFC 3159는 이 질문의 한 부분에 대해 정확한 답을 선택했습니다. `InstanceId`는 행을 식별할 뿐 그 이상의 것은 아니었습니다. 그 번호는 좌표였습니다. 정책적 의미, 설치, 효과는 다른 곳에서 입증되어야 했습니다.
역사
번역기는 패킷을 바꿨다. 그렇다면 보고서도 바꿔야 했다: RFC 3158
RTP 트랜슬레이터는 인코딩, 패킷 크기, 시퀀스 번호, 타임스탬프 속도를 바꾸면서도 소스 식별자를 유지한 채 스트림을 다른 링크에 맞출 수 있었다. 그 성공은 더 조용한 의무를 낳았다. RTCP 보고서도 같은 패킷 이력으로 번역되어야 했다. 그러지 않으면 미디어는 재생되면서 제어 채널은 수신자 측에 더 이상 존재하지 않는 바이트, 패킷, 손실을 자신 있게 집계할 수 있었다. RFC 3158은 이 불일치를 검증 가능한 경계로 만들었다.
역사
서버는 평문을 몰라도 가용성을 통제했다: RFC 3157
2001년 8월, RFC 3157은 하나의 암호학적 신원이 사용자나 라우터와 함께 한 장치에서 다른 장치로 어떻게 따라갈 수 있는지를 물었다. 그 대답은 기밀성에서 시작했지만 거기서 끝나지 않았다. 자격 증명 서버는 평문으로 사용할 수 없는 객체를 저장하면서도 그것을 목록 조회하거나, 다운로드하거나, 교체하거나, 삭제할 수 있는지를 결정할 수 있었다. 직접 이전은 그 저장소를 피했지만 자체적인 인증된 송신자와 접수 확인이 필요했다. 비밀을 옮기는 것은 하나의 사건이었다. 신원, 권한, 유용한…
역사
송신자는 손실을 보았지만 원인은 보지 못했다: RFC 3155
TCP 윈도우가 줄어드는 것은 하나의 결정을 말할 뿐, 반드시 정체를 말하지는 않습니다. 2001년 8월, RFC 3155는 이 구분에서 출발했습니다. 오류가 잦은 링크에서 손상된 세그먼트는 끝점에서 포화 큐에서 폐기된 패킷과 같은 침묵을 만들 수 있었습니다. 신뢰할 수 있는 인과 표지가 없는 상황에서 TCP는 공유 네트워크를 계속 보호해야 했습니다. 복구 개선은 잃은 시간을 줄였을 뿐, 부재를 진단으로 바꾸지는 못했습니다.