노트 66: i.LEASE가 존재하는 이유와 브로커 문제는 사실 레지스트리 위험 문제인 이유

모든 진지한 IPv4 구매자는 결국 동일한 실제 질문에 도달합니다. 브로커를 사용해야 한다면 어느 브로커를 신뢰해야 합니까?

그 질문은 상업적인 것처럼 들립니다.

그렇지 않습니다.

진짜 질문은 누가 판매자를 소개하고, 서류를 준비하고, 가격을 제시하고, 에스크로 계좌를 개설하고, RIR 정책 준수 언어를 반복할 수 있는지가 아닙니다. 많은 브로커가 그렇게 할 수 있습니다. 진짜 질문은 등록 계층이 중립적인 서류 관리 사무소처럼 행동하는 것을 멈추고 귀중한 운영 자산에 대해 재량권처럼 행동하기 시작할 때 나타나는 위험을 누가 감당할 수 있느냐는 것입니다.

이는 IPv4 중개 시장의 대부분이 피하는 질문입니다.

구매자와 판매자만 매칭할 수 있는 브로커는 레지스트리 리스크를 해결하지 못합니다. 그는 그것을 통과하고 있습니다. "우리는 RIR 정책을 따릅니다"라고만 말할 수 있는 브로커는 레지스트리 위험을 제어하지 않습니다. 그는 그것에 의존하고 있음을 인정하고 있습니다. 깨끗한 서류 작업, 에스크로 및 이전 요청만 지적할 수 있는 브로커는 연속성을 시행하지 않습니다. 그는 트랜잭션이 종료될 때까지 레지스트리 계층이 오랫동안 정중하게 유지되기를 바라고 있습니다.

희망은 인프라가 아닙니다.

i.LEASE IPv4 시장이 일반 중개업을 능가했기 때문에 존재합니다.

IPv4가 관리 잔여물로 처리되면 중개업은 얇은 매칭 사업으로 남을 수 있습니다. 홀더를 찾아보세요. 구매자를 찾으세요. 평판을 확인하세요. 서류를 제출하세요. 레지스트리 처리를 기다립니다. 수수료를 징수합니다. 자산이 적고, 정치가 조용하고, 등기재량권의 단점이 아직 가시화되지 않았을 때는 그것만으로도 충분했습니다.

그 세상은 사라졌습니다.

IPv4는 이제 자본입니다. 희소하고, 가격이 책정되고, 자금이 조달되고, 임대되고, 라우팅되고, 필터링되고, 평판이 평가되고, 법적으로 분쟁이 발생하고, 운영상 내장되어 있습니다. 블록은 데이터베이스의 단순한 라인이 아닙니다. 고객, 클라우드 서비스, 데이터 센터, VPN 네트워크, 모바일 인프라, SaaS 플랫폼, 이메일 전달 가능성, 방화벽 규칙, 규정 준수 시스템, 라우팅 정책 및 수익을 지원합니다.

실패한 IPv4 거래는 단순한 구매 실패가 아닙니다.

이는 비즈니스 연속성 이벤트가 될 수 있습니다.

그렇기 때문에 중개 문제를 재구성해야 합니다. 기존 시장에서는 누가 나에게 주소를 알려줄 수 있는지 묻습니다. 더 나은 시장에서는 누가 해당 주소에 수반되는 레지스트리 계층 위험을 구조적으로 관리할 수 있는지 묻습니다.

이것이 일반 브로커와 다른 점입니다. i.LEASE.

i.LEASE는 단순한 시장이 아닙니다. 이는 더 광범위한 전환 아키텍처의 실행 계층입니다. 이는 IPv4의 가시적인 시장과 해당 시장 아래 숨겨진 위험 표면 사이에 위치합니다: RIR 멤버십, 등록 프로세스, 이전 규칙, 라우팅 조정, WHOIS 유지 관리, 규정 준수 처리, 운영 수명 주기, 문서화 및 종료 후 연속성.

목록은 실행이 아닙니다.

서명된 계약은 연속성이 아닙니다.

에스크로 해제는 취득한 자산이 스트레스 상황에서도 계속 사용할 수 있다는 증거가 아닙니다.

이것은 많은 구매자가 너무 늦게까지 보지 못하는 부분입니다. IPv4 거래에서 눈에 보이는 상업 이벤트는 위험의 가장 작은 부분입니다. 보이지 않는 부분은 레지스트리 인터페이스입니다. RIR는 누가 다루나요? 정책 표면을 누가 이해합니까? 레지스트리 요청이 일상적인 경우와 위험 신호인 경우를 누가 알 수 있습니까? 이전 프로세스가 집행 경로가 되는 시기를 누가 확인할 수 있습니까? 단순히 정책 매뉴얼을 읽지 않고 레지스트리 갈등을 겪어본 사람이 누구입니까?

대부분의 브로커는 이 질문에 답할 수 없습니다.

그들은 경험이 있다고 말할 수 있습니다. 그들은 신뢰할 수 있다고 말할 수 있습니다. 그들은 중립적이라고 말할 수 있습니다. 그들은 인증을 받고 규정을 준수하며 글로벌하고 투명하며 전문적이라고 말할 수 있습니다.

그러나 이러한 단어는 레지스트리 위험을 관리하지 않습니다.

레지스트리 위험은 브랜딩으로 관리되지 않습니다. 이는 위치, 문서, 운영 지식, 법적 기억, 등록 절차가 실제 위협이 될 때 고객의 네트워크를 보호하는 능력에 따라 관리됩니다.

이것이 바로 i.LEASE가 중요한 이유입니다.

그것은에 의해 구동됩니다 LARUS, 그리고 그것은 미용상의 요점이 아닙니다. LARUS는 또 다른 IPv4 임대인이 아닙니다. 내가 설명했듯이 참고 35: 레지스트리 계층이 구조적 위험인 이유 및 LARUS가 유일하게 입증된 비즈니스 연속성 보증인 이유, 레지스트리 계층은 무해한 관리 표면이 아닙니다. 구조적 위험 표면입니다. 직접 보유한다고 해서 그러한 위험이 제거되는 것은 아닙니다. 이는 종종 해당 위험을 운영자의 법인 내부에 집중시킵니다.

LARUS는 무엇보다 연속성이 필요한 운영 회사 내부에 위험이 맹목적으로 존재해서는 안 되기 때문에 존재합니다.

해당 경험이 없는 브로커도 거래를 처리할 수 있습니다.

해당 구조를 가진 브로커는 실패 도메인을 이해할 수 있습니다.

그것은 다른 사업입니다.

이는 또한 i.LEASE가 다음과 어떻게 관련되는지 설명합니다. BTW.Media 그리고 NRS.

BTW는 현실을 설명하기 위해 존재합니다. 내가 쓴대로 참고 36: BTW.Media가 존재하는 이유와 옹호가 아닌 현실이 제품인 이유, 그 역할은 제품을 판매하거나 논쟁에서 승리하는 것이 아닙니다. 숨겨진 구조를 보이게 해줍니다. 이는 대부분의 거버넌스 언어가 은폐하고 있는 내용을 말합니다. 즉, 레지스트리 계층은 주권 시스템도 아니고 조약 시스템도 아니며 집행 가능한 글로벌 법률 질서도 아니고 무해한 데이터베이스도 아닙니다. 희소성, 가치, 법률 및 지정학에 의해 가정이 테스트되는 소수의 민간 기관입니다.

NRS는 거버넌스의 방향을 바꾸기 위해 존재합니다. 내가 쓴대로 참고 37: NRS가 존재하는 이유와 분산화가 더 이상 선택 사항이 아닌 이유, 그것은 분산화 계층입니다. 도덕적 서사 대신 종료, 이식성, 중복성 및 메커니즘을 고집합니다. NRS는 IPv4 거래를 판매하지 않습니다. 이는 시스템을 독점 레지스트리 의존성에서 벗어나 생존 가능한 숫자 자원 거버넌스 방향으로 밀어냅니다.

LARUS는 연속성 레이어로 존재합니다. 이는 일반 시장 행위자가 할 수 없는 방식으로 레지스트리 계층 노출에 대한 상업적 및 운영적 부담을 짊어집니다. 주소, 라우팅, 고객, 재생성 및 안정성이 필요하기 전에 최종 아키텍처를 기다릴 수 없는 운영자를 위한 다리입니다.

i.LEASE는 시장 실행 레이어로 존재합니다.

그 구별이 중요합니다.

BTW가 설명합니다.

NRS 옹호자.

LARUS는 연속성을 전달합니다.

i.LEASE가 실행됩니다.

그들은 다른 이름으로 동일한 기능을 수행하는 동일한 기관이 아닙니다. 이는 동일한 손상된 시스템의 다양한 결함에 응답하는 서로 다른 레이어입니다.

결함은 간단합니다. IPv4 시장이 존재하지만 그 아래의 레지스트리 계층은 자산 등급 거래용으로 설계되지 않았습니다.

이러한 불일치로 인해 브로커 문제가 발생합니다.

일반적인 자산시장에서는 법률 인프라가 두꺼워서 브로커의 업무 범위가 좁습니다. 소유권이 인정됩니다. 기록은 집행 가능합니다. 양육권이 정의됩니다. 전송 규칙은 안정적입니다. 법원은 자산을 이해합니다. 중개자는 성숙한 프레임워크 내에서 운영됩니다.

IPv4는 다릅니다.

시장은 가격을 창출할 만큼 성숙했지만, 제도적 계층은 불확실성을 창출할 만큼 미성숙했습니다. 자산은 가치가 있지만 소유권 언어는 의도적으로 약합니다. 구매자는 실제 돈을 지불하지만 등록 기록은 여전히 ​​서비스, 멤버십, 등록, 할당, 할당 또는 허가로 구성될 수 있습니다. 네트워크는 연속성에 의존하지만 레지스트리 계약은 연속성 규모의 구제책을 제공하지 않을 수 있습니다.

그렇기 때문에 일반 중개업은 구조적으로 빈약합니다.

실제 위험이 더 깊은 곳에 있는 동안 이는 거래 표면에서 작동합니다.

일반 브로커가 블록 구매를 도와줄 수 있습니다. 하지만 등록소에서 문서화 이상의 질문을 할 때 귀하를 보호할 수 있습니까? 정책 해석이 바뀔 때 운영 모델을 방어할 수 있습니까? 기술적 독창성과 상업적 간섭을 구별할 수 있습니까? WHOIS, 라우팅, RPKI, 남용 기록, 고객 사용, 지역적 가정 또는 멤버십 상태가 논쟁의 여지가 있는 경우 이전 후 라이프사이클을 관리할 수 있습니까? 압력이 귀하의 운영 회사에 도달하기 전에 압력을 흡수할 수 있습니까?

대답이 '아니오'라면 브로커가 주요 위험을 줄이지 않은 것입니다.

거래가 질서있게 보이도록 만들었습니다.

이것은 핵심 i.LEASE 질문입니다.

브로커를 선택해야 한다면 레지스트리 위험을 이해하는 연속성 구조가 지원되는 브로커를 선택하시겠습니까, 아니면 위험을 생성하는 동일한 레지스트리 계층으로 문서를 전달하는 것만이 유일한 실제 권한을 가진 브로커를 선택하시겠습니까?

그것은 마케팅 질문이 아닙니다.

위험 배치 질문입니다.

시장은 모든 브로커가 비교 가능한 척하는 것을 좋아합니다. 그렇지 않습니다. 등재 및 에스크로가 있는 브로커는 등록 프로세스 경험, 운영 수명주기 지원, 라우팅 지식, 규정 준수 처리 및 연속성 원칙이 뒷받침되는 브로커와 동일하지 않습니다. 모든 것이 작동하면 차이가 눈에 띄지 않게 됩니다. 뭔가 실패하면 결정적이 됩니다.

인프라를 평범한 날로만 판단해서는 안 됩니다.

스트레스로 판단해야 합니다.

평범한 날에는 모든 브로커가 유능해 보일 수 있습니다. 평상시에는 모든 RIR 프로세스가 관리 가능해 보입니다. 일반적인 날에는 모든 이체는 서류 작업인 것처럼 보입니다. 평소에는 레지스트리 위험이 각주처럼 보입니다.

그러나 운영자는 평상시에만 IPv4를 구매하지 않습니다. 그들은 그들의 사업이 그것에 의존하기 때문에 그것을 구입합니다. 고객이 지금 서비스가 필요하기 때문에 임대합니다. 유휴 자본이 갇혀 있어서는 안 되기 때문에 그들은 이를 현금화합니다. 잘못된 보유자, 잘못된 계약, 잘못된 등록 인터페이스 또는 잘못된 중개자가 롱테일에서 가치를 파괴할 수 있기 때문에 그들은 이를 구성합니다.

해당 롱테일에는 i.LEASE가 존재합니다.

IPv4 시장을 유동화하는 것만으로는 충분하지 않습니다. 연속성이 없는 유동성은 취약합니다. 가격을 투명하게 만드는 것만으로는 충분하지 않습니다. 강제성이 없는 투명성은 외관상일 뿐입니다. 목록을 깨끗하게 만드는 것만으로는 충분하지 않습니다. 깨끗한 목록은 레지스트리 재량권을 제거하지 않습니다. 거래를 빠르게 하는 것만으로는 충분하지 않습니다. 빠른 실패는 여전히 실패입니다.

목표는 속도만이 아닙니다.

목표는 조작성입니다.

IPv4 거래는 돈이 움직일 때 종료되어서는 안 됩니다. 리소스가 라우팅, 기록, 갱신, 검토, 질문, 유지 관리 및 사용될 때 관리 가능한 상태로 유지되어야 합니다. 그렇기 때문에 관리형 IPv4 임대 중요합니다. 그렇기 때문에 RIR 회원관리 중요합니다. 그렇기 때문에 IPv4 주소 구매 체계적인 프로세스를 통해 중요합니다. 그렇기 때문에 IPv4 주소 판매 보호된 실행 채널을 통한 것이 중요합니다.

시장은 공급을 보여줍니다.

실행 계층은 공급을 사용할 수 있게 만듭니다.

그것이 바로 차이점입니다.

판매자에게도 동일한 논리가 적용됩니다. 판매자는 수요를 찾기 위해 누군가만 필요한 것이 아닙니다. 판매자에게는 가치를 보호하고, 상대방을 심사하고, 문서를 관리하고, 남용 위험을 줄이고, 양도 또는 임대 조건을 조정하고, 판매자가 통제할 수 없는 다운스트림 운영 실패에 연루되는 것을 방지하는 구조가 필요합니다.

유휴 IPv4는 자본입니다.

잘못 구성된 IPv4는 책임입니다.

브로커의 임무는 차이점을 이해하는 것입니다.

이것이 바로 IPv4 시장에 보다 일반적인 브로커가 필요하다는 생각을 받아들이지 않는 이유입니다. 더 적은 수의 얇은 중개자와 구조적으로 더 유능한 실행 계층이 필요합니다. 숫자 자원은 평범한 상품이나 정치적 선물이 아니라는 점을 이해하는 사람들이 필요합니다. 이는 결함이 있는 레지스트리 아키텍처 내부에 있는 운영 자산입니다.

그 아키텍처는 더 넓은 노트의 주제입니다.

에서 참고 52: 레지스트리 전원이 책임에서 분리될 때 켜짐, 높은 결과를 초래하는 레지스트리 권한이 의미 있는 책임에서 분리되면 현재 RIR 모델이 생존할 수 없는 이유를 설명했습니다.

~ 안에 참고 53: 인터넷 번호 자원이 정치적 재산이 아닌 이유, 나는 숫자 자원이 지역 트로피나 커뮤니티 자산이 아닌 작동하는 네트워크에 내장된 운영자 보유 자산인 이유를 설명했습니다.

에서 참고 56: 지역 인터넷 등록 기관의 Thick Governance가 고유성을 이중 추출로 전환하는 방법에 대해, 저는 레지스트리 계층이 고유성을 사용하여 두 번 추출하는 방법을 설명했습니다. 한 번은 제어를 통해, 또 한 번은 자산 가치 억제를 통해.

에서 참고 61: 실행 코드 배신, 나는 그들이 서비스를 제공해야 하는 실행 중인 네트워크에 대해 합의와 절차가 어떻게 반대되는지 설명했습니다.

에서 참고 62: 위임장 세탁, 나는 등기 사무원이 주권자처럼 들리기 시작할 때까지 어떻게 민간 행정 역할이 공동체, 지역, 청지기직 수사를 통해 세척되었는지 설명했습니다.

에서 참고 64: 최소 초기 사양, 현지화된 향후 결정 및 자발적 채택, 저는 건설적인 디자인 규칙을 설정했습니다. 즉, 상호 운용성이 요구하는 것만 지정하고, 향후 선택은 로컬에 두고, 선언이 아닌 채택을 통해 변화를 현실로 만듭니다.

에서 참고 65: 실행 코드 우선순위, 저는 마스터 원칙을 설명했습니다. 레지스트리 계층은 실행 코드가 요구하는 범위 내에서만 해석되어야 합니다.

참고 66: 해당 논리를 시장에 적용합니다.

레지스트리 계층이 구조적으로 위험한 경우 브로커 계층은 중립적인 서류 작업인 척할 수 없습니다. 단순한 메신저인지 아니면 연속성을 지닌 실행 구조인지를 결정해야 합니다.

대부분의 브로커는 메신저입니다.

유용할 수 있습니다. 그들은 정직할 수도 있습니다. 좁은 의미에서는 능력이 있을 수도 있다. 그러나 등록 위험을 관리, 흡수 또는 구조적으로 배치할 수 없다면 그들은 여전히 ​​전달자입니다.

메신저가 문서를 전달할 수 있습니다.

인프라를 보호할 수 없습니다.

i.LEASE는 반대 전제를 기반으로 구축되었습니다. IPv4 시장에서 실행은 서류 작업이 아닙니다. 실행은 레지스트리 계층의 불확실성 하에서 연속성입니다.

그렇기 때문에 LARUS 자사 IPv4 임대 중요합니다. 그렇기 때문에 LARUS IP 관리 중요합니다. 그렇기 때문에 LARUS 네트워크 파트너 문제. 별도의 마케팅 페이지가 아닙니다. 동일한 기본 문제를 해결하는 다른 방법입니다. IPv4는 이제 운영 자산이며 운영 자산에는 트랜잭션 도입뿐만 아니라 연속성 구조가 필요합니다.

시장이 이미 성숙했다면 i.LEASE는 불필요할 것입니다.

소유권이 명확하게 인식되고 이동성이 의무화되고 등록 책임이 비례하며 이전 규칙이 안정적이고 탈퇴 권한이 보호된다면 중개는 단순하게 유지될 수 있습니다.

그러나 그것은 우리가 물려받은 세상이 아닙니다.

우리는 귀중한 IPv4 자산이 민간 레지스트리 계약, 재량 정책, 취약한 구제책, 일관되지 않은 거버넌스, 시장에 조용히 의존하면서도 여전히 부차적인 척하는 제도적 서술 아래 있는 세계를 물려받았습니다.

그런 세상에서는 브로커 문제가 피상적으로만 있을 수는 없습니다.

문제는 누가 재고를 가지고 있는가가 아닙니다.

문제는 누가 재고 뒤에 숨은 위험을 이해하는가입니다.

문제는 누가 이체를 제출할 수 있는가가 아닙니다.

문제는 이적이 문제의 끝이 아닐 때 일어나는 일을 누가 관리할 수 있느냐는 것입니다.

문제는 누가 가장 낮은 수수료를 부과하느냐가 아닙니다.

문제는 레지스트리 위험이 현실화될 때 누가 구조적으로 연속성을 보호할 수 있는가입니다.

이것이 바로 i.LEASE가 존재하는 이유입니다.

세상에 또 다른 IPv4 브로커가 필요했기 때문이 아닙니다.

세상에는 대부분의 브로커가 관리할 수 없는 것, 즉 레지스트리 위험을 이해하는 브로커 계층이 필요했기 때문입니다.

레지스트리 위험을 관리할 수 없는 브로커는 메신저일 뿐입니다.

메신저가 문서를 전달할 수 있습니다.

인프라를 보호할 수 없습니다.

i.LEASE는 실제로 중요한 위험을 위해 만들어졌습니다.

시장은 그 중개업체를 부를 수도 있습니다.

그렇지 않습니다.

레지스트리 계층의 불확실성 하에서 실행됩니다.