참고 65

노트 65: 실행 코드 우선성: 인터넷의 원래 설계를 보존하기 위해 필요한 패치

레지스트리 계층에서 인터넷의 원래 디자인을 복원하는 단일 패치는 무엇입니까?

Lu Heng · 2026년 5월 7일 · 36 최소 읽기

이 시퀀스의 앞선 7개 Heng.lu 노트는 다음과 같습니다.

이전 7개의 에세이는 지역 인터넷 등록 기관을 위한 개혁 프로그램이 아니었습니다.

부검이었죠.

그들은 서로 다른 계층을 통해 동일한 제도적 병리를 추적했습니다. 결과로부터 분리된 책임; 정치적 재산으로 재분류된 자원 수; 고유성이 이중 추출로 바뀌었습니다.; 주권이 뒤집어졌다; 평등이라는 이름으로 빈곤에 세금을 부과하다; 서비스를 제공할 예정이었던 네트워크에 반대되는 합의가 이루어졌습니다.; 그리고 마지막으로 서기가 주권자처럼 들리기 시작할 때까지 위임장은 세탁되었습니다. 실패는 하나의 잘못된 보드, 하나의 잘못된 등록, 하나의 소송 또는 하나의 불편한 시장 이벤트가 아니기 때문에 순서가 중요합니다. 다른 옷에서 나타나는 시스템 결함이었습니다. 이제 CircleID의 작성자 페이지에 다음을 포함하여 해당 시퀀스가 명확하게 표시됩니다. 실행 코드 배신 그리고 세탁 위임. (Circleid.com)

이 에세이는 RIRs를 더 나은 거버너로 만드는 것이 아닙니다.

현재의 레지스트리 명령이 왜 종점이 될 수 없는지, 왜 최소한의 방해를 주는 복구가 인터넷의 원래 기술 설계를 보완하는 것인지 설명하는 것입니다.

그 보충제는 실행 코드 우선권.

이에 대한 필요성은 더 이상 이론적인 것이 아닙니다. 최근 CircleID 교환에서 John Curran은 현 사건의 가장 강력한 형태를 제시했습니다. 그의 주장은 RIR 시스템의 권한이 단순히 좁은 기술 조정의 부산물이 아니라 백서, ICANN, ASO, ICP-2, IANA 관리 전환 및 지속적인 민간 부문 다중 이해관계자 거버넌스와 같은 역사적인 체인의 결과라는 것입니다. 그는 RIR 시스템의 권한은 미국 정부가 지시한 민간 부문 다중 이해관계자 모델 내에서 운영된 결과라고 말합니다. (Circleid.com)

그 주장은 분쟁을 가시화하기 때문에 유용합니다.

문제는 더 이상 역사적 위임이 존재했는지 여부가 아닙니다. 물론 그랬습니다. 문제는 역사적으로 위임된 조정 기능이 나중에 자신이 제어하는 동일한 프로세스 기계를 통해 상설 거버넌스 명령으로 확대될 수 있는지 여부입니다. 현직의 대답은 '그렇다'입니다. 위임, 인정, 제도적 연속성, 커뮤니티 절차는 스스로 갱신되는 의무가 됩니다.

인터넷의 원래 기술 설계에서 요구하는 대답은 '아니요'입니다.

원래의 인터넷 전통은 더 좁고, 더 어렵고, 더 좋았습니다. RFC 3935에서는 IETF의 목표가 "인터넷이 더 잘 작동하도록 만드는 것"이라고 말합니다. 이는 기술 역량, 실제 구현, "대략적인 합의 및 실행 코드"를 바탕으로 작업을 기반으로 합니다. 또한 IETF가 프로토콜이나 기능에 대해 책임을 지지 않는 경우 이를 제어하려고 시도하지 않는다고 명시되어 있습니다. (rfc-editor.org) RFC 7282는 David Clark의 이전 문구를 반복합니다. "우리는 거부합니다: 왕, 대통령 및 투표" 및 "우리는 믿습니다: 대략적인 합의 및 실행 코드." (rfc-editor.org) RFC 9592는 반주권 주장을 더욱 분명하게 만듭니다. IETF는 인터넷을 운영, 통제 또는 순찰하지 않으며 "프로토콜 경찰"이 아닙니다. (rfc-editor.org)

그 전통이 결코 문서가 마술이라는 것을 의미하지는 않았습니다. 이는 시스템 실행에 도움이 되는 문서가 중요하다는 것을 의미했습니다. 이는 배포를 제공했기 때문에 프로세스가 허용되었음을 의미했습니다. 이는 공간이 운영 현실을 중심으로 스스로를 규율할 때만 유용하다는 것을 의미했습니다.

레지스트리 계층은 그 정당성을 빌렸습니다.

그 규율을 완전히 받아들이지 않았습니다.

누락된 패치입니다.

실행 코드 우선순위의 의미

실행 코드 우선주의는 인터넷 조정 시스템이 원래 네트워크 실행을 정당화했던 최소한의 기술적 기능을 참조하여 협소하게 해석되어야 함을 의미합니다.

숫자 리소스 계층은 실행 중인 시스템을 보호하기 위해 존재합니다. 고유성, 상호 운용성, 라우팅 인접 연속성, 보안 주장, 제어 증명, 독립 네트워크가 함께 작동하는 데 필요한 최소한의 공통 의미 체계입니다.

정치적 권위를 만들어내는 것은 존재하지 않습니다.

상업적 도덕성을 감시하는 것은 존재하지 않습니다.

서비스 지역을 제목으로 변환하는 기능은 존재하지 않습니다.

메일링 리스트를 입법부로 바꾸는 것은 존재하지 않습니다.

내부 정책 이론이 변경되기 때문에 개인 레지스트리가 이미 실행 중인 네트워크 자산을 사라지게 하는 것은 존재하지 않습니다.

레지스트리는 상태가 아닙니다.

데이터베이스 연락처는 기업 위임장이 아닙니다.

서비스 지역은 사람이 아닙니다.

정책실은 입법부가 아닙니다.

레지스트리 기록은 운영 현실을 설명할 수 있습니다. 그것은 그것을 생성하지 않습니다.

이것은 보수주의가 아닙니다. Running-Code Primacy는 배포된 시스템이 결코 변경될 수 없다고 말하지 않습니다. 변화에 대한 제도적 권력은 역사적 위임이나 순환적 인정, 의례적 절차로 정당화되어서는 안 된다는 것이다. 이는 운영자가 로컬에서 확인할 수 있는 결정론적 규칙과 실행 중인 시스템의 채택을 통해 정당화되어야 합니다.

올바른 순서는 초기 사양, 분산 원장 상태, 로컬 유효성 검사, 구현 실행, 자발적 채택, 호환성 집합, 문서화입니다.

잘못된 순서는 정책실, 선언, 청구된 의무, 준수 라벨, 강제 운영 준수입니다.

RIR 시스템은 점점 더 두 번째 순서를 선택하기 때문에 실패했습니다.

핵심 수정 사항은 초기 사양 이후에는 지속적으로 청원할 기관이 없다는 것입니다. 어떤 위원회도 비채택이 위반인지 여부를 결정하지 않습니다. 어떤 등록소도 단지 차후 변경을 거부한다는 이유만으로 참가자를 무효로 선언하지 않습니다. 코드, 원장 상태, 검증, 채택, 호환성, 로컬 거부, 포크 및 선택적 상호 운용성만 있습니다.

이후 변경을 거부하는 운영자는 인터넷을 중단하지 않습니다. 이전 호환성 세트에 남아 있을 수 있습니다. 포크가 될 수 있습니다. 연결이 끊어질 수 있습니다. 호환되지 않는 규칙을 채택한 참가자와 상호 운용되지 않을 수 있습니다. 그러나 상호 호환되는 코드를 계속 실행하는 다른 사람들의 상호 운용성을 깨뜨릴 수는 없습니다.

설계 직관은 분산 원장을 유용하게 만드는 것과 동일합니다. 일반적인 유효성을 결정하는 데 상설 기관이 필요하지 않습니다. 참가자는 결정론적 규칙에 따라 로컬로 상태 전환을 검증합니다. 유효하지 않은 상태는 기관에서 처벌하지 않습니다. 이를 수락하지 않는 참가자는 무시됩니다.

이는 숫자-자원 조정에서 누락된 필수 패치입니다.

설계 실패는 처음부터 존재했습니다.

첫 번째 RIR 디자인은 낮은 가치의 세계를 가정했습니다.

숫자 자원은 기술적이고 풍부하며 사무적이고 갈등이 적은 것처럼 보였습니다. 그 세상에서는 비공식이 효율적으로 보였습니다. 오픈 메일링 리스트가 대표적인 것 같았습니다. 접촉 기반 관리가 적절해 보였습니다. 유한 책임 계약은 무해해 보였습니다. 지역 등록부는 주소록처럼 보일 수 있습니다.

IPv4 희소성은 그 전제를 파괴했습니다.

IPv4 주소는 부족하고, 양도 가능하고, 금융 가능하고, 임대되고, 자본화되고, 소송을 제기하고, 승인을 받고 라이브 네트워크에 내장되었습니다. 등록 계층은 더 이상 사무 항목 위에 위치하지 않습니다. 그것은 생산적인 인프라 위에 자리잡고 있었습니다. 자산 가치보다 높았습니다. 이는 고객 연속성, 클라우드 배포, 통신 운영, 국가 연결, 법원 명령 및 자본 배분보다 뛰어났습니다.

제도적 형태는 새로운 위험에 맞춰 축소되지 않았습니다.

확장되었습니다.

그 결과 인프라 거버넌스의 효과를 발휘하면서 여전히 기술 조정 언어를 사용하는 시스템이 탄생했습니다. 이는 등록 결정이 상업적 운명에 영향을 미치는 동안 등록 프로세스를 중립적으로 취급하도록 운영자에게 요청합니다. 참가자들을 "커뮤니티"라고 부르는 반면, 그 결과를 감수하는 사람들 중 다수는 방에 있는 사람들에게 명확한 법적 대변을 제공하지 않았습니다.

NRS는 구조적 문제를 명확하게 설명합니다. 인터넷 번호 레지스트리는 기술 조정 기관으로 설계되었지만 IPv4 희소성이 주소를 귀중한 자산으로 바꾸자 레지스트리 재량권이 경제력이 되었습니다. 조정 시스템이 자본을 통제할 때 중앙집권화는 구조적 위험이 되고, 분권화는 이념이 아닌 시스템 엔지니어링이 됩니다. NRS는 또한 반대 설계 방향을 제시합니다. 즉, 하나의 인터넷, 개방적이고 자율적인 인프라, 핵심에 사람의 참여를 최소화하는 분산형 거버넌스입니다. (nrs.help)

그것이 진짜 문제입니다. 조정 테이블이 자산 게이트가 된 순간에는 레지스트리 레이어가 패치되지 않았습니다.

Running-Code Primacy가 바로 그 패치입니다.

더 나은 RIR 교리는 아닙니다.

이는 RIR 이후의 규율입니다.

패치의 세 가지 규칙

구성문법이 개정되었습니다. 참고 64: 최소 초기 사양, 현지화된 향후 결정 및 인터넷 조정 시스템에 대한 자발적 채택: 최소 초기 사양, 현지화된 미래 결정, 그리고 자발적인 채택.

이름은 변경되지 않습니다. 논리가 정확해야 합니다.

최소 초기 사양 이는 공통 계층에 고유성, 상호 운용성, 제어 증명, 공유 안전 및 보안에 필요한 결정적이고 로컬로 검증 가능한 규칙만 포함되어 있음을 의미합니다. 여기에는 비즈니스 모델 선호도, 가격 책정 이론, 지역적 정치적 정서, 재량적 집행 권한 또는 제도적 임무 확장이 포함되어 있지 않습니다.

현지화된 미래 결정 이는 기관이 향후 결정을 지역적으로 결정한다는 의미는 아닙니다. 그러면 이미 권위 계층이 다시 도입될 것입니다. 이는 초기 사양이 제한 작업을 미리 수행한다는 의미입니다. 배포 후에는 코드를 실행하는 참가자에게 일반적인 향후 선택 사항이 남아 있습니다. 참가자는 선택적으로 채택, 거부, 분기, 연결 해제 또는 상호 운용할 수 있습니다. 어떤 참가자도 상호 호환 가능한 규칙을 계속 실행하는 다른 참가자의 상호 운용성을 변경할 수 없습니다.

자발적인 채택 이는 나중에 변경 사항이 구현, 검증, 배포 및 사용을 통해서만 현실화된다는 것을 의미합니다. 출판은 현실이 아니다. 추천은 현실이 아닙니다. 현직 인정은 현실이 아니다. 비채택은 잘못된 상태를 생성하지 않습니다. 이후 변경 사항을 채택하지 않은 참가자는 기존 호환성 집합에 남아 있습니다. 다른 참가자의 결정론적 규칙에 따라 유효하지 않은 상태를 내보내는 참가자는 로컬에서 무시될 수 있습니다. 효과는 제도적 처벌이 아닌 적합성 선택입니다.

이 세 가지 규칙은 등록소 주권을 회복하지 않습니다.

새로운 이름으로 다시 나타나는 것을 방지합니다.

APNIC: 법적 구조가 위험했습니다

APNIC는 첫 번째 실패를 보여줍니다. 처음에는 최소값이 충분히 엄격하게 지정되지 않았습니다.

이것은 행동 강령 이야기가 아닙니다. 에티켓 이야기가 아닙니다. 평론가가 현 기관에 대해 예의를 갖추었는지에 대한 이야기가 아니다.

법적 구조에 관한 이야기입니다.

2023년 3월, LARUS는 APNIC의 거버넌스 구조가 브리즈번의 한 회사뿐만 아니라 아시아 태평양 지역 전체의 인터넷 거버넌스에 위험을 초래했다는 경고를 경고하는 법적 검토를 발표했습니다. 검토 결과에 따르면 APNIC의 사무총장은 APNIC를 폐쇄하고 선출된 집행위원회를 해임할 수 있는 궁극적인 법적 권한을 갖고 있으며 긴급 거버넌스 개정이 필요하다고 밝혔습니다. 또한 이 구조는 10억 명 이상의 아시아 태평양 인터넷 사용자에 대한 인터넷 거버넌스의 보안에 대한 의문을 제기했다고 밝혔습니다. (larus.net)

첫 번째 첨부 파일인 ASIC 회사 추출은 회사 기준을 제공합니다. APNIC Pty Ltd는 퀸즈랜드에 등록된 호주 독점 유한회사로 등록되어 있습니다. 폴 바이런 윌슨(Paul Byron Wilson)이 이사 겸 비서로 등재되었습니다. 주식 정보에는 발행된 보통주 1주가 나와 있으며, 폴 바이런 윌슨(Paul Byron Wilson)이 해당 주식을 보유하고 있는 회원으로 기재되어 있습니다. (larus.net)

이는 중요한 지역 인터넷 조정 기능을 수용하는 일반적인 방법이 아닙니다.

두 번째 첨부 파일인 Peter Felter 박사의 법적 의견은 거버넌스 결론을 도출했습니다. 이는 APNIC Pty Ltd 정관 제9.3조에 기초한 특별위원회로서 회원, 선거, 집행위원회, 사무총장 및 사무국과 같은 공개 APNIC 구조를 설명했습니다. APNIC Pty Ltd는 25년 동안 한 명의 이사, 한 명의 주주 및 한 명의 비서에 의해 관리되는 독점 회사였다고 명시되어 있습니다. (larus.net)

그 구별이 중요합니다.

공공 커뮤니티를 대상으로 하는 기관은 최종 법적 컨테이너가 아니었습니다. 그것은 민간 회사 구조로 지어진 건물이었습니다.

그런 다음 법적 의견에서는 구별이 중요한 이유를 설명했습니다. APNIC의 내규는 정관과 회사, 이사, 임원 및 회원의 권한에 따라 적용되는 것으로 명시되었습니다. 해당 읽기에서 공개 APNIC 구조는 APNIC Pty Ltd의 이사 결의에 의해 변경될 수 있습니다. 의견에서는 APNIC를 사실상 APNIC Pty Ltd.(larus.net)

이 의견의 가장 해로운 점은 APNIC가 기술적으로 불법이라는 것이 아닙니다. 합법성과 타당성은 같은 것이 아니라는 것입니다. 집행이사회의 권한은 여전히 특별위원회 구성에 대한 이사의 결의에 달려 있기 때문에 신탁제도로는 문제가 해결되지 않는다는 의견이다. 또한 APNIC Pty Ltd는 구조와 목적이 대부분의 사람들이 지역 공익 등록소와 연관시키는 비주식 비영리 모델과 유사하지 않은 민간 주식 회사라는 점도 지적했습니다. (larus.net)

이는 가장 깔끔한 형태의 최초의 설계 실패입니다.

지역 규모의 번호 조정 시스템은 단일 주식 독점 회사, 특별 위원회, 신탁 증서 및 선출된 위원회가 어떻게든 아시아 태평양 번호 등록에 대한 합법적인 통제로 결합되는지를 변호사가 설명하도록 요구하는 구조에 의존해서는 안 됩니다.

중요한 조정 레이어는 외부에서 읽을 수 있어야 합니다.

문서 뒤에 있는 문서에 대한 신뢰를 요구해서는 안 됩니다.

수년간의 제도적 의존 이후에 선출된 계층이 궁극적인 법적 계층이 아닐 수도 있다는 사실을 회원들이 발견하도록 요구해서는 안 됩니다.

공식적인 권한을 다른 곳에 맡기면서 회원 거버넌스의 모습을 보여서는 안 됩니다.

이것이 최소 초기 사양이 제도적 신뢰가 아닌 분산 유효성을 포함해야 하는 이유입니다. 미래의 기관에 더 나은 거버넌스가 필요하기 때문이 아닙니다. 미래의 RIR 이후 시스템에서는 해당 기관이 전혀 필요하지 않아야 하기 때문입니다.

공통 레이어는 독점 회사의 숨겨진 제어 구조에 의존해서는 안 됩니다. 결정론적 유효성 검사 규칙, 제어 증명 상태, 상태 전환 규칙, 충돌 규칙, 원장 복제, 종료 경로, 포크 경로 및 호환성 집합을 정의해야 합니다. APNIC가 사라지거나, 스스로 캡처하거나, 법적 자세를 바꾸거나, 유효한 상태 인식을 거부하는 경우, 실행 중인 네트워크는 누가 어떤 숫자의 리소스를 제어하는지 알기 위해 APNIC의 지속적인 인식에 의존해서는 안 됩니다.

레지스트리가 유효성의 원천이 되어서는 안 됩니다.

초기 사양에 따라 검증된 분산 원장 상태는 다음과 같아야 합니다.

ARIN: 정책이 자산 현실을 충족했습니다.

ARIN은 두 번째 실패를 보여줍니다. 법적 및 시장 현실은 등록 이론을 능가할 수 있습니다.

결정적인 사건은 Nortel과 Microsoft의 거래였습니다. Nortel이 파산 신청을 했을 때, Nortel의 666,624개 IPv4 주소는 소송 과정에서 귀중한 자산이 되었습니다. 해당 주소는 Microsoft에 750만 달러에 매각되었습니다. ARIN은 주소가 재산이 아니며 등록 정책 없이 무료로 판매될 수 없다는 이론에 개입했습니다. 캐나다 산업부는 이러한 견해를 지지했습니다. 파산 법원은 이를 기각했습니다. Microsoft는 나중에 기존 계약에 서명했습니다. 실제 결과는 분명했습니다. 법원과 시장이 숫자 자원을 자산으로 취급하면 등록 정책이 현실의 유일한 원천으로 남을 수 없었습니다. (btw.미디어)

중요한 교훈은 ARIN이 독특하게 결함이 있다는 것이 아닙니다.

교훈은 레지스트리 계층이 새로운 범주에 진입했다는 것입니다.

등록 기록은 운영자, 법원, 구매자, 판매자, 채권자 및 네트워크가 이에 의존하기 때문에 가치가 있습니다. 그 의존성을 부인한다고 해서 권위가 있는 것은 아닙니다. 신뢰할 수 있을 만큼 법률, 시장 및 운영 현실을 면밀히 추적하는 경우에만 유용합니다.

IPv4가 부족해지면 등록 프로세스가 시장 인터페이스가 되었습니다. 전학 규칙, 요구 사항 평가, 인식 지연 및 지역 제한 사항은 더 이상 사무적인 세부 사항이 아닙니다. 그것은 자산 마찰이 되었습니다. 공개 분석에서는 이제 5개 지역 시스템이 주소당 약 18~45달러의 시장 거래를 관리하는 단편적인 RIR 규칙서에 대해 설명하고 있으며, 자산을 좌초시키고 합병을 지연시키며 별도의 기업 구조를 단순히 숫자 블록을 유지하도록 강요할 수 있는 상충되는 규칙이 있습니다. (btw.미디어)

그것은 중립적인 조정이 아닙니다.

이는 규제 책임이 없는 규제 효과입니다.

ARIN은 자발적 채택이 중요한 이유를 입증합니다. 레지스트리 정책은 행위자가 실제로 구현하고, 거래하고, 자금을 조달하고, 소송을 제기하고 의존하는 내용을 설명하는 경우에만 신뢰할 수 있습니다. 출판이 현실을 조작하기에 충분할 정도로 취급되면 위험해집니다.

현실을 거부하는 레지스트리는 주권을 갖지 않습니다.

오래된 데이터베이스가 됩니다.

Running-Code Primacy 디자인에서는 교훈이 더욱 선명해졌습니다. 법원과 시장에서는 가치가 존재하는지 여부를 결정하기 위해 현직 등기소가 필요하지 않습니다. 운영자는 블록 경로 여부를 알기 위해 위원회가 필요하지 않습니다. 참가자에게는 통제 증명, 충돌 해결, 원장에 표시되는 상태 전환 및 호환성을 허용하는 결정론적 규칙이 필요합니다. 이전 레지스트리는 보기를 게시할 수 있습니다. 소프트웨어 클라이언트는 보기를 표시할 수 있습니다. 원장 탐색기에 뷰가 표시될 수 있습니다. 타당성의 원천은 없습니다.

이동할 레지스트리가 없습니다.

물어볼 레지스트리가 없습니다.

참가자가 검증, 수락, 거부, 포크 또는 상호 운용하는 분산 상태만 있습니다.

AFRINIC: 레지스트리 이론이 자산 실행을 위협하는 경우

AFRINIC는 문제를 필수 요소까지 제거했기 때문에 핵심 사례입니다.

잘못된 이야기는 문제의 회원이 지역 등록을 마비시켰다는 것입니다.

그것이 현재의 도덕극이다.

구조적인 이야기는 다릅니다. AFRINIC는 상업적 사용, 고객 지역, 임대, 회원 관계 및 내부 정책 해석을 이미 실행 중인 번호 리소스의 등록을 취소하기 위한 주장된 권한으로 변환하려고 시도했습니다. 일단 그러한 주장이 제기되면 갈등은 더 이상 정책실의 불일치로 남아 있을 수 없습니다. 이는 민간 등록 기관이 운영상 내장된 자산을 위협하기 위해 지역 수사 및 정책 침묵을 사용할 수 있는지 여부에 대한 테스트가 되었습니다.

사실은 연극적 인플레이션을 요구하지 않습니다. 공개 보고에서는 AFRINIC 분쟁을 IP 주소에 대한 단순한 상업적 분쟁으로 묘사했으며, 이는 아프리카에서 가장 큰 인터넷 거버넌스 이야기가 되었습니다. 또한 Cloud Innovation은 종종 악당으로 묘사되었으며 이후의 다큐멘터리 자료에서는 AFRINIC 자체 내부의 파괴적인 세력과 AFRINIC의 비용으로 AFRINIC 대표에 의해 소송이 지연, 연장 및 지속되고 있음을 지적했습니다. (btw.미디어)

이는 일반적인 이야기를 뒤집기 때문에 중요합니다.

소송으로 인해 구조적 실패가 발생하지 않았습니다.

소송을 통해 드러났습니다.

민간 등기소가 명시적 허가의 부재를 강압적 통제의 근거로 간주했을 때 관련 실패는 이미 존재했습니다. 임대는 고유성에 위협이 되지 않았습니다. 고객 지역이 중복 할당이 아니었습니다. 상업적인 사용은 라우팅 보안 실패가 아니었습니다. 레지스트리가 싫어하는 비즈니스 모델은 전역 불변이 아니었습니다.

그러나 레지스트리 주장은 이러한 문제를 해지 프레임 내에 두었습니다.

조정이 거버넌스가 되는 순간입니다.

AFRINIC가 2021년 3월 Cloud Innovation에 정책 위반을 주장하고 멤버십 종료를 위협하는 편지를 보냈다는 기록을 보고합니다. 2021년 7월 모리셔스 대법원은 AFRINIC가 Cloud Innovation의 멤버십을 종료하는 것을 금지했습니다. AFRINIC의 멤버십 취소 추가 시도는 2021년 12월에 차단되었습니다. (btw.미디어) 그 시퀀스는 레지스트리가 침착하게 인터넷을 보호한다는 이야기가 아니다. 등기소가 보통법을 만나는 이야기입니다.

너무 적은 등록 권한으로 인해 광범위한 제도적 붕괴가 발생한 것도 아닙니다. 더 깊은 문제는 락인(lock-in)이었습니다. 하나의 레지스트리가 귀중한 실시간 자산에 대한 독점 인식을 보유하면 모든 내부 오류가 인터넷 연속성 위험이 됩니다. 회원이 인정시스템을 떠나지 못하면 등기실패는 인질이 된다.

등록 기관은 자체 기록에서 입증 가능한 등록 사기를 정정할 수 있습니다.

레지스트리 모델이 여전히 존재하는 동안 중복 할당을 방지할 수 있습니다.

참가자가 여전히 보안 주장에 의존하는 동안 보안 주장을 유지할 수 있습니다.

그러나 이는 오래된 아키텍처의 과도기적 기능입니다.

RIR 이후 아키텍처에서는 이러한 기능이 레지스트리에 의해 수행되지 않습니다. 이는 분산 원장 상태, 제어 증명 규칙, 충돌 규칙 및 로컬로 검증 가능한 전환으로 인코딩됩니다.

민간 기관은 임대를 지역 반역으로 전환해서는 안됩니다.

고객 지역을 해지 트리거로 전환해서는 안 됩니다.

상업적 불일치를 기술적 무효로 간주해서는 안 됩니다.

자산 연속성을 허가로 전환해서는 안 됩니다.

AFRINIC는 지역화된 미래 결정의 필요성을 올바르게 이해했음을 증명합니다. 미래의 상업적 결정이 "지역에 속한다"고 결정하는 중앙 기관은 없습니다. 오히려 초기 사양에서는 이러한 결정이 애초에 공통 계층에 입력되지 않도록 해야 합니다. 임대, 고객 지역, 상업적 사용, 가격 책정, 자금 조달, 고객 구성 및 배포 전략은 고유성, 보안, 제어 증명 또는 상호 운용성에 직접적인 영향을 미치지 않는 한 결정론적 유효성 규칙을 벗어나게 됩니다.

운영자는 주소를 임대하여 다른 운영자의 상호 운용성을 깨뜨릴 수 없습니다.

운영자는 과거 등록 지역 외부의 고객에게 서비스를 제공함으로써 다른 운영자의 상호 운용성을 깨뜨릴 수 없습니다.

운영자는 레지스트리가 싫어하는 비즈니스 모델을 사용하여 다른 운영자의 상호 운용성을 깨뜨릴 수 없습니다.

기껏해야 운영자는 다른 참가자가 실행하는 결정적 규칙을 충족하지 못할 수 있습니다. 이 경우 다른 참가자는 유효하지 않은 상태를 로컬에서 거부합니다. 처벌 계층이 없습니다. 준수 법원이 없습니다. 지역 주권자는 없습니다.

그 노선은 이념적인 것이 아니다.

운영 중입니다.

프록시 문제는 세부 사항이 아닙니다.

AFRINIC 선거 논쟁은 두 번째 결함인 대표성을 드러냈습니다.

NRS는 직접적인 법적 용어로 표현 기반을 명시합니다. 상장된 회원은 RIR 거버넌스 문제에서 자신을 대표하도록 NRS를 위임했으며, 등재된 각 회원은 위임장을 제공했다고 합니다. (nrs.help) AFRINIC 선거 분쟁 중에 NRS는 회원들에게 자신의 이름이 유권자 등록부에 표시되는지 또는 참여하지 않고 투표가 기록되었는지 보고하도록 요청했으며 그러한 사실 보고는 합법적인 채널을 통해 처리될 것이라고 말했습니다. (nrs.help)

이는 법적 표현과 커뮤니티 수사 간의 차이를 보여주기 때문에 중요합니다.

RIR 시스템은 종종 여러 범주를 하나로 축소합니다: 기업 대표, 데이터베이스 담당자, 기술 담당자, 직원, 컨설턴트, 대리인 보유자, 정책 참가자, 메일링 리스트 일반. 이것들은 같은 것이 아닙니다.

데이터베이스 담당자는 기록 관리에 도움을 줄 수 있습니다.

위임장은 유효하고 범위 내에 있는 경우 대리인을 승인할 수 있습니다.

정책 참가자는 전문 지식을 제공할 수 있습니다.

메일링리스트 발표자는 의견을 진술할 수 있습니다.

이들 중 어느 것도 레지스트리 결정의 결과를 초래하는 모든 회사, 고객, 주, 채권자, 대출 기관, 구매자, 임차인 또는 네트워크에 대해 자동으로 법적 주체가 되지 않습니다.

이러한 구별은 공통 레이어가 얇게 유지되는 동안에만 무시될 수 있습니다. 등록소가 취소, 이전, 임대, 시장 접근, 제재 처리, 자산 연속성 또는 국가 기반 시설 위험에 대한 권한을 주장하면 대리가 합헌이 됩니다.

방은 의무사항이 아닙니다.

메일링 리스트는 사람이 아닙니다.

연락처 기록은 기업 위임장이 아닙니다.

서비스 지역은 주권 선거구가 아닙니다.

이는 절차적인 까다로움이 아니다.

조정과 규칙의 차이입니다.

Running-Code Primacy 시스템은 표현이 필요한 결정의 수를 줄임으로써 이러한 함정을 피합니다. 타당성이 결정적이고 지역적이면 투표할 항목이 줄어듭니다. 향후 변경이 자발적인 경우 비채택자의 상태가 좋지 않은지 여부를 결정할 필요가 없습니다. 상태가 분산 원장에 표시되면 기존 등록 기관에 자신의 지속적인 존재를 인정해달라고 요청할 필요가 없습니다. 호환성 집합이 명시적인 경우 참가자는 정치적 공간에 묻지 않고도 누구와 상호 운용할 수 있는지 알 수 있습니다.

최고의 거버넌스 문제는 시스템 설계가 제거하는 문제입니다.

RIPE NCC 및 LACNIC: 클럽 및 초크 포인트

RIPE NCC 및 LACNIC는 일부 RIRs가 다른 RIRs보다 더 문명화되었음을 증명하지 않습니다. 그들은 RIR 모델에 기술적 기능 외에 두 가지 적용 계층이 있음을 증명합니다. 클럽 그리고 초크 포인트.

클럽은 누가 존경받을 만한지를 결정합니다. 초크 포인트는 누구의 레지스트리 상태를 이동할 수 있는지 결정합니다.

RIPE NCC가 RIPE 90에 대한 LARUS 후원 수락을 거부한 것은 클럽 레이어를 명백하게 보여주었습니다. 한 회원이 후원을 제안했습니다. 레지스트리 측 생태계는 다른 지역의 관련 없는 분쟁으로 인해 이를 거부했습니다. 그것은 라우팅 보안 결정이 아니었습니다. 그것은 고유성 결정이 아니었습니다. 이는 결정론적 검증 규칙이 아니었습니다. 컨퍼런스 접속을 통한 비공개 블랙리스트였습니다. LACNIC도 나의 후원을 거절했습니다. 다른 지역, 동일한 본능: 등록 클럽은 회의실, 가시성, 후원, 평판 및 사회적 정당성을 통제하여 스스로를 보호합니다.

그건 커뮤니티가 아닙니다. 게이트키핑입니다.

제재 레이어는 법적인 형식으로 중심적인 질식점을 보여주기 때문에 더욱 심하다. RIPE NCC는 네덜란드에 기반을 두고 있기 때문에 EU 제재를 준수해야 한다고 명시합니다. 제재가 적용되면 RIPE 데이터베이스의 등록이 동결되고 취득 및 양도가 차단되며, 당사자가 충분한 문서를 제공할 수 없는 경우 사례가 동결된 것으로 처리될 수 있습니다. 또한 은행 관계가 지불에 영향을 미치기 때문에 OFAC 목록을 검사합니다. (RIPE NCC 제재 투명성)

이는 법률 준수에 대한 RIPE NCC의 비판이 아닙니다. 네덜란드 법인은 네덜란드 및 EU 법률을 준수해야 합니다. 문제는 아키텍처입니다. 왜 하나의 네덜란드 민간 기업이 여러 국가, 운영자 및 법률 시스템에 걸쳐 숫자-자원 이동성의 중앙 인식 지점이 되어야 합니까?

제재는 은행을 구속할 수 있습니다. 제재는 네덜란드 법인을 구속할 수 있습니다. 제재는 거래를 하지 않기로 선택한 상대방을 구속할 수 있습니다. 이는 다른 모든 사람에게 글로벌 기술 타당성 조건이 되어서는 안 됩니다.

그게 바로 설계실패입니다.

클럽이 비판자를 배제할 수 있게 하는 것과 동일한 중심성으로 인해 관할권이 등록 이동성을 동결할 수도 있습니다. 하나는 사회적 집행이다. 다른 하나는 법적 집행입니다. 둘 다 레지스트리가 유효성이 있어서는 안 되는 위치에 있기 때문에 작동합니다.

이는 세 가지 원칙과 직접적으로 연결됩니다.

최소 초기 사양: 클럽의 존경심, 스폰서 자격, 지역 정치, 제재 분류 및 평판은 결코 공통 계층에 들어가서는 안 됩니다. 공통 계층에는 고유성, 제어 증명, 충돌 처리, 상태 전환 및 보안에 대한 결정적 규칙만 포함되어야 합니다.

현지화된 미래 결정: 법적 위험, 상대방 선택, 후원, 상업적 신뢰 및 제재 노출은 이를 부담하는 행위자에게 속합니다. 네덜란드 법인은 거래를 거부할 수 있습니다. 은행에서 지급을 거부할 수 있습니다. 상대방이 거래를 거부할 수 있습니다. 그 어느 것도 보편적인 레지스트리 진실이 되어서는 안 됩니다.

자발적인 채택: 참가자는 코드를 실행하고, 상태를 검증하고, 상호 운용할 대상을 선택하여 상대방을 수락합니다. 채택하지 않는 것은 위법 행위가 아닙니다. 지역적 거부는 전역적 무효가 아닙니다. 클럽의 거부로 인해 유효한 상태가 지워져서는 안 됩니다. 제재 의무는 그 대상이 되는 행위자를 제한해야 하며, 세계의 자원 수 장부를 다시 작성해서는 안 됩니다.

이것이 바로 분산원장 설계가 필요한 이유입니다. RIR 이후 시스템에서는 RIPE NCC, LACNIC, 제재 데스크, 회의 위원회 또는 후원사 사무실에 의해 일반적인 유효성이 결정되지 않습니다. 참가자는 로컬에서 상태를 검증합니다. 상대방은 자발적으로 수락하거나 거부합니다. 포크가 보입니다. 호환성 세트는 명시적입니다. 중앙 레지스트리는 진실의 원천으로서 사라진다.

수정은 더 나은 에티켓이 아닙니다.

수정 사항은 더 투명한 제재 대기열이 아닙니다.

해결 방법은 클럽과 초크 포인트 모두에서 유효성을 제거하는 것입니다.

분산된 상태. 로컬 검증. 자발적인 상대방 수락. 유효성의 소스가 되는 레지스트리가 없습니다.

NRO 편지: 상향 탈출

가장 심각한 증거는 AFRINIC의 과도한 도달 시도가 아닙니다.

이는 시스템의 집단적 대응입니다.

2022년에 Number Resource Organization은 모리셔스 정부에 편지를 보냈습니다. 편지에는 NRO가 전 세계 RIRs의 조정 기관이라고 설명하고 RIRs가 해당 지역의 숫자 리소스를 관리한다고 명시했습니다. 5개 등록소 모두 지역적으로 채택된 규칙이나 만장일치로 채택된 글로벌 정책에 따라 숫자 자원을 관리하는 기능을 수행한다고 명시되어 있습니다. (nro.net)

같은 편지에서는 Cloud Innovation의 소송을 비판하고, 25개 이상의 소송이 제기되었으며, AFRINIC의 계정을 동결하고 선거를 중단한 법원 명령에 대해 불만을 토로했으며, AFRINIC가 모리셔스에 이를 국제 조직으로 인정해 줄 것을 반복적으로 요청했다고 명시했습니다. NRO는 정부가 아프리카에서 AFRINIC의 독립성과 인터넷 안정성을 보존하기 위한 조치를 취할 것을 촉구했습니다. (nro.net)

그것은 전체 이야기에서 가장 드러나는 문서입니다.

개인 등기소가 일반 법원과 충돌했을 때 시스템의 반사 작용은 권한을 좁히지 않는 것이었습니다.

레지스트리 잠금을 제거하기 위한 것이 아닙니다.

기록 보관과 집행을 분리하기 위한 것이 아니었습니다.

분산 검증을 정의하는 것이 아니었습니다.

운용자산에 대한 일방적인 말소권이 처음부터 불법이었는가를 묻기 위한 것이 아니다.

반사는 상향 탈출이었습니다.

민간 조정 기관은 재량을 원할 때 기술적일 수 없고, 합법성을 원할 때 공동체 기반, 수수료를 원할 때 계약적, 소유권 책임을 피하고 싶을 때 비재산, 법원으로부터의 격리를 원할 때 준국제적일 수 없습니다.

그 패키지는 거버넌스가 아닙니다.

이는 시스템 수준에서 세탁을 의무화하는 것입니다.

RIRs가 공법 특권을 원하는 경우 공법 책임을 수락해야 합니다. 사법 유연성을 원한다면 사법 소송을 받아들여야 합니다. 그들이 합리적으로 요구할 수 없는 것은 사적 재량, 공공 인프라의 중요성, 낮은 책임, 취약한 대표성, 독점 지위, 준외교적 고립 등이다.

그것이 재앙의 길이다.

Running-Code Primacy는 이를 거부합니다.

등록소가 법적 저항에 부딪히면 면제를 받기 위해 탈출해서는 안 됩니다. 아키텍처는 이를 정당화하는 좁은 실행 코드 기능으로 축소되어야 합니다.

주권이 적습니다.

유효성의 소스가 되는 레지스트리가 없습니다.

집행이 적습니다.

더욱 분산된 검증.

ICP-2 개정판은 충분하지 않습니다

현재 시스템은 뭔가가 고장났다는 것을 알고 있습니다.

RIR 거버넌스 문서의 두 번째 초안에 대한 ICANN의 공개 의견 페이지에는 이 제안이 새로운 RIRs, RIRs의 운영 의무 및 요구 사항, 인식 취소 규칙을 인식하기 위한 규칙과 기준을 설정할 것이라고 나와 있습니다. 채택되면 ICP-2를 대체하게 됩니다. 같은 페이지에는 NRO가 ASO에 RIR 시스템에 인터넷 커뮤니티에 대한 더 큰 책임을 제공하기 위한 업데이트를 제안하도록 요청한 후 프로세스가 시작되었다고 나와 있습니다. (icann.org)

이는 연속성 조치로 필요할 수 있습니다.

정당성 이론으로는 충분하지 않다.

인식 및 제거 규칙은 다음과 같은 늦은 질문에 답합니다. 레지스트리가 제거될 만큼 심각하게 실패한 경우는 언제입니까?

앞의 질문이 더 중요합니다. 애초에 레지스트리가 치명적인 실패를 겪을 만큼 강력해야 하는 이유는 무엇입니까?

단지 인식, 감사, 전달 및 인식 취소를 강화하는 ICP-2의 후속 버전은 범주 오류를 유지하면서 기관의 위생을 향상시킬 수 있습니다. 여전히 RIR가 숫자-자원 조정의 기본 주권 형태라고 가정합니다.

Running-Code Primacy는 다른 질문을 던집니다.

RIR가 붕괴되면 인터넷은 어떻게 계속됩니까?

현직 허가 없이 숫자 자원 주장을 어떻게 검증할 수 있나요?

독점 재량권 없이 독특함이 어떻게 살아남을 수 있을까요?

기록이 집행 무기가 되는 것을 어떻게 방지합니까?

진정한 전역 불변이 위험에 처하지 않는 한 상업적 결정은 어떻게 결정론적 타당성을 벗어나 유지됩니까?

권위 있는 레지스트리 없이 어떻게 조정을 계속 사용할 수 있나요?

운영자는 상설 기관에 상태를 요청하지 않고 어떻게 일반 상태를 검증합니까?

거절이 위반 라벨이 되는 것을 방지하려면 어떻게 해야 합니까?

이것은 개혁 문제가 아닙니다.

RIR 이후의 질문입니다.

이것이 원래 디자인에 대한 패치인 이유

문제는 기존 레지스트리를 좋아하는지, 싫어하는지가 아닙니다.

문제는 숫자-자원 계층이 인터넷이 작동하도록 만든 설계 원칙(최소 공통 규칙, 로컬 유효성 검사, 자발적 채택 및 코드 실행)을 여전히 따르는지 여부입니다.

Running-Code Primacy는 홍보 전략도 아니고 제도적 타협도 아닙니다. 이는 원래 디자인이 암시하는 기술적 수리입니다. 기술적인 진실의 원천인 왕, 대통령, 투표를 거부하도록 인터넷이 구축되었다면 숫자-자원 계층은 등록 프로세스, 역사적 위임 또는 커뮤니티 연극을 통해 이러한 형식을 재현할 수 없습니다.

합의만이 의식화될 수 있다. 레지스트리 계층이 인식의 업스트림에 있으면 실행 코드만 종속될 수 있습니다. 누락된 규칙은 해석적이며 구조적입니다. 제도적 프로세스가 실행 중인 시스템에 필요한 최소한의 기술 기능과 충돌하는 경우 실행 중인 코드가 우선권을 갖습니다. 나중에 변경이 제안되는 경우 유효성 확인 규칙을 실행하는 참가자의 자발적인 채택을 통해서만 현실이 됩니다.

그래야 원래의 디자인을 버리지 않고 보존할 수 있습니다.

인터넷이 중요한 이유는 단일 주권자, 사역, 교회, 기업 또는 문지기의 사전 허가가 필요하지 않은 최초의 글로벌 통신 시스템이 되었기 때문입니다. 그 성과가 여전히 방어할 가치가 있다면 레지스트리 계층은 규칙을 삼키는 예외가 될 수 없습니다.

왕을 피하기 위해 만들어진 시스템에서는 회계사가 왕 역할에 대한 오디션을 허용할 수 없습니다.

패치는 코드 우선, 연산자 우선, 결정론적 검증 우선, 분산 상태 우선이라는 원래 계층 구조를 복원합니다. 기관은 전환 중에 남아 있는 경우 권위가 없는 인공물로만 남아 있으며 타당성의 원천으로는 결코 사용되지 않습니다.

RIR 이후 조정에 필요한 것

RIR 이후 조정은 혼란을 의미하지 않습니다.

이는 공통 레이어가 현재의 RIR 독점보다 더 얇고, 더 객관적이고, 더 결정적이고, 더 분산된다는 것을 의미합니다.

이동할 레지스트리가 없습니다.

왕관에 대한 새로운 등록이 없습니다.

대체 신권은 없습니다.

결정론적 검증 규칙, 제어 증명 메커니즘, 충돌 처리, 호환성 세트, 상태 전환 기록 및 참가자의 로컬 검증을 갖춘 숫자 리소스 상태의 분산 원장이 있습니다.

공통 계층은 식별자 고유성, 제어 증명, 전송 상태, 위임 상태, 라우팅 인접 보안 주장, 감사 가능성, 충돌 메타데이터 및 포크 가시성을 보존해야 합니다.

운영자 계층은 상업적 사용, 임대, 고객 지역, 라우팅 관행, 자금 조달, 상대방 선택 및 변하지 않는 비즈니스 규칙을 제어해야 합니다.

채택 계층에서는 무엇이 현실화되는지 결정해야 합니다. 조정 규칙은 운영자가 이를 실행할 수 있고, 상대방이 이를 수용할 수 있고, 시장이 이를 신뢰할 수 있고, 법원이 이를 이해할 수 있고, 현직 인정을 현실의 유일한 원천으로 삼지 않고 상호 운용성이 보존되는 경우에만 중요합니다.

시행 레이어는 상태 레이어와 병합되어서는 안 됩니다. 분산 원장은 상태를 기록할 수 있습니다. 전환을 검증할 수 있습니다. 갈등이 노출될 수 있습니다. 증거를 휴대 가능하게 만들 수 있습니다. 검사, 판사, 제재 당국, 시장 규제자, 상업 도덕주의자, 자산 관리인이 한꺼번에 되어서는 안 됩니다.

가장 중요한 것은 이식성을 올바르게 이해해야 한다는 것입니다.

분산 원장 세계에서 이식성은 한 레지스트리에서 다른 레지스트리로 이동하는 것을 의미하지 않습니다. 그것은 여전히 레지스트리 사고입니다. 이동할 레지스트리가 없습니다. 보유자의 통제 증명, 상태 기록 및 전송 기능은 기존 데이터베이스 내에 갇혀 있지 않습니다. 이는 참가자가 현지에서 검증하고 상대방이 자발적으로 수락하는 공유된 검증 가능한 상태로 존재합니다.

그렇지 않으면 모든 레지스트리가 잠금 지점이 됩니다.

이를 통해 레지스트리는 유효성 소스로서 사라집니다.

따라서 RIR 이후 조정에는 네 가지 설계 속성이 필요합니다.

첫째, 결정론적 타당성이다. 참가자는 사양을 로컬에 적용하여 상태 전환, 증명, 위임, 전송 또는 주장이 유효한지 여부를 알아야 합니다.

둘째, 호환성 세트입니다. 참가자가 다른 미래 규칙을 채택하는 경우 시스템은 반대 의견을 위법 행위로 처리하기보다는 호환성 경계를 명확하게 설명해야 합니다.

셋째, 분산된 통제 증명입니다. 보유자는 자신의 자원을 다른 등록소로 "이동"해서는 안 됩니다. 이는 모든 상대방이 현직의 축복 없이 확인할 수 있는 원장 유효 상태를 통해 통제력을 입증해야 합니다.

넷째, 포크 가시성. 규칙 세트가 서로 다른 경우에는 그 차이가 명시적이어야 합니다. 참가자는 실행할 호환성 세트와 수락할 상대방을 결정합니다. 포크는 참가자를 격리시킬 수 있습니다. 한쪽에 다른 쪽을 지울 수 있는 제도적 권한을 부여하지 않습니다.

그것은 다섯 가지 더 나은 독점을 주장하는 것이 아닙니다.

이는 타당성의 원천으로서 독점에 반대하는 주장이다.

실패 경로가 예측 가능한 이유

아무것도 변경되지 않으면 실패 경로가 분명합니다.

첫째, 더 많은 분쟁이 정책실에서 법원으로 옮겨갈 것입니다. 부족한 자산은 법적 조사를 받습니다. 법원은 계정 동결, 기록 보존, 부적절한 선거 차단, 수령인 지정, 양도 인정, 등기소 대리인 결정 등의 작업을 수행해야 합니다.

둘째, 주정부는 RIRs를 무해한 기술 협회로 취급하는 것을 중단할 것입니다. 번호 매기기 연속성은 국가 연결, 제재, 법 집행, 통신 탄력성, 클라우드 인프라 및 경제 안보에 영향을 미칩니다. 어떤 국가도 외국의 민간 등록 셸을 국가 통신 연속성의 검토되지 않은 상류 지점으로 영원히 받아들이지 않을 것입니다.

셋째, 운영자는 가능한 경우 등록 기관을 우회합니다. 등록 기록이 정치적이거나 안전하지 않거나 대표성이 없거나 자산 현실과 동떨어진 경우 운영자는 민간 계약, 소송 지원 이전, 대체 증명, 국가 인정 또는 사실상의 라우팅 현실에 의존하게 됩니다.

넷째, ICANN와 NRO 계층은 중앙 집중화하려는 유혹을 받을 것입니다. 권한 자체가 좁아지지 않는 한 이는 동일한 문제의 더 두꺼운 버전을 생성할 것입니다.

다섯째, 정부는 국유화하려는 유혹을 받게 될 것이다. 그것은 예측 가능하고 위험할 것입니다. 민간 등기소가 공적 책임 없이 준주권을 주장한다면 국가는 결국 주권을 되찾게 될 것입니다. 그 결과는 분열, 보복, 등록부 충돌, 정치적 라우팅 압력 등이 될 수 있습니다.

인터넷은 패킷 이동이 중지된 경우에만 실패하지 않습니다.

또한 식별자를 사용할 수 있는 사람을 설명하는 기관이 패킷을 이동하는 운영자의 신뢰를 잃으면 실패합니다.

분산 원장은 모든 정치적 문제를 해결하지 않습니다. 이는 더 중요한 작업을 수행합니다. 즉, 일반적인 유효성 소스인 등록부를 제거합니다. 그러면 공격 표면이 좁아집니다. 이는 제도적 인질의 힘을 감소시킵니다. 미래의 불일치를 행정전쟁이 아닌 호환성 선택으로 바꾸는 것입니다.

질문이 바뀌다

기존 시스템에서는 다음과 같이 묻습니다. 누가 권한을 갖고 있습니까?

그것은 잘못된 질문입니다.

더 나은 질문은 실행 중인 코드에 실제로 무엇이 필요한가입니다.

이 규칙은 고유성을 보호합니까?

상호 운용성을 유지합니까?

결정론적 증거를 통해 입증 가능한 등록 사기를 정정합니까?

라우팅 인접 보안을 보호합니까?

제어 증명 정확성을 유지합니까?

로컬 검증이 가능합니까?

한 재임자에 대한 의존성을 제거합니까?

채택된 현실을 설명합니까, 아니면 채택되지 않은 의무를 선언합니까?

참가자가 무효 상태를 할당받지 않고 거부할 수 있나요?

참가자는 등록 기관에 상태를 요청하지 않고 일반 유효성을 확인할 수 있습니까?

상대방이 자발적으로 상태를 수락하거나 거부할 수 있습니까?

기관이 한쪽을 지우지 않고 포크가 일어날 수 있을까?

대답이 결정론적 실행 코드 필요성과 관련되어 있지 않은 경우 해당 전력은 공통 계층에 있어서는 안 됩니다.

이것이 바로 Running-Code 우선순위입니다.

토론을 위해

이 제안은 토론용입니다. 최종 합의는 아닙니다.

다음 단계는 숫자 리소스부터 시작하여 인터넷 조정 시스템에 대한 Running-Code Primacy를 정의하는 심각한 인터넷 초안 또는 BCP 스타일 문서입니다. 초안은 RIR 독점을 회복하는 방법을 묻지 않아야 합니다. 분산 원장 상태, 결정론적 검증, 자발적 채택, 상대방 수락 및 명시적 호환성 세트를 통해 RIR 이후 조정을 구축하는 방법을 질문해야 합니다.

운영자, 변호사, 경제학자, 프로토콜 엔지니어, 라우팅 보안 전문가, 시장 참가자, 정부 및 비평가가 테스트해야 합니다.

초안은 어려운 질문을 던져야 합니다.

전역 불변성은 무엇입니까?

어떤 검증 규칙이 결정적인가요?

어떤 상태 전환이 전역적으로 표시되어야 합니까?

어떤 오래된 등록 권한이 역사적 잔여물입니까?

어떤 결정이 운영자의 몫인가요?

공통 계층에 입력되어서는 안 되기 때문에 표현이 필요하지 않은 결정은 무엇입니까?

거절 경로는 무엇입니까?

포크 경로는 무엇입니까?

로컬 거부 경로는 무엇입니까?

현직 등기소 없이 보유자가 지배력을 어떻게 증명합니까?

상대방은 등록 없이 상태를 어떻게 확인합니까?

RIR가 무너져도 인터넷을 계속할 수 있나요?

현재 권한 없이 숫자 리소스를 고유하게 유지할 수 있습니까?

상설기관 없이 참가자가 정상적인 상태를 검증할 수 있나요?

정책 프로세스가 실행 코드 불변성과 제도적 욕구를 구별할 수 있습니까?

검증 가능한 상태를 잃지 않고 이전 레지스트리 계층이 사라질 수 있습니까?

기록이 현실을 지배하지 않고도 현실을 묘사할 수 있을까요?

관심 있는 사람은 누구나 저에게 연락할 수 있습니다. 링크드인. 커뮤니티에서 유용하다고 생각하는 경우 이를 첫 번째 인터넷 초안으로 전환하고 결국 RFC 또는 BCP 토론으로 전환하는 데 도움을 주고 싶은 진지한 연구원, 기술 작성자, 기관 또는 정책 전문가는 저에게 연락해야 합니다. LARUS Foundation 그리고 나는 이 방향에 대한 진지한 연구를 지원하고 자금을 지원할 의향이 있습니다.

RIR 시스템의 첫 번째 설계는 실제로 필요한 실행 코드가 무엇인지 묻지 않았기 때문에 실패했습니다.

그 방에서 누가 말할 수 있는지 물었습니다.

다음 시스템은 그 순서를 바꿔야 합니다.

세탁을 의무화하지 않음.

실행 코드 배신이 아닙니다.

실행 코드 우선권.

부록: 최소 초기 사양, 현지화된 향후 결정 및 인터넷 조정 시스템의 자발적 채택

참고 64

초록

이 문서에서는 시스템을 실행하는 참가자 위에 지속적인 권한을 생성하지 않고 공유된 기술 참조 지점을 제공하는 것이 목적인 인터넷 조정 시스템의 설계 패턴을 설명합니다. 이는 최소 초기 사양, 현지화된 향후 결정, 자발적 채택이라는 세 가지 연결된 원칙을 정의합니다.

이 모델에서 초기 사양은 고유성, 상호 운용성, 제어 증명, 공유 안전 및 보안에 필요한 결정론적이고 로컬로 검증 가능한 규칙만 정의합니다. 초기 사양 이후 향후 변경 사항은 중앙 기관의 승인을 받지 않습니다. 코드를 실행하는 참가자는 이를 채택, 무시, 분기 또는 포기합니다.

의도된 디자인 패턴은 유효한 상태의 분산 원장이거나 레지스트리 계층 구조가 아닌 동등한 분산 검증 가능 상태 메커니즘입니다. 일반적인 유효성을 결정하는 상설 등록 기관은 없습니다. 참가자는 로컬에서 상태를 확인하고, 상대방을 자발적으로 수락하고, 실행할 호환성 세트를 결정합니다.

채택하지 않는 것은 위반이 아닙니다. 이후 변경 사항을 채택하지 않은 참가자는 기존 호환성 집합에 남아 있습니다. 다른 참가자가 수락한 결정론적 규칙에 따라 유효하지 않은 상태를 내보내는 참가자는 해당 참가자에 의해 로컬로 무시될 수 있습니다. 효과는 제도적 처벌이 아닌 호환성 선택, 포크, 격리 또는 선택적 상호 운용입니다.

이 문서는 유선 프로토콜을 정의하지 않습니다. 영구적인 거버넌스 기관이 되어서는 안 되는 프로토콜, 식별자 시스템, 분산 원장 및 조정 메커니즘의 설계에 대한 현재 모범 사례를 지정합니다.

1. 소개

많은 인터넷 시스템은 공통 참조 지점, 식별자 공간, 유효성 검사 규칙, 원장 상태 또는 제어 증명 기록을 공유하여 독립적인 행위자가 상호 운용할 수 있도록 하는 좁은 기술적 목적으로 시작됩니다. 시간이 지남에 따라 이러한 시스템은 초기 상호 운용성에 필요하지 않은 권한을 축적하는 경우가 많습니다.

이는 일반적으로 세 단계로 이루어집니다.

첫째, 향후 질문은 기술적으로 필요하기 전에 기초 계층에 배치됩니다.

둘째, 자체 시스템을 운영하는 참가자가 선택해야 하는 선택은 지속적인 기관의 인식, 해석 또는 상태 결정에 따라 달라집니다.

셋째, 참가자가 운영 시스템의 변경을 채택하지 않은 경우에도 출판, 등록, 권장 또는 절차적 승인은 운영 의무를 생성하기에 충분한 것으로 간주됩니다.

그 결과 시스템이 취약해졌습니다. 기술 참조 레이어는 거버넌스 레이어가 됩니다. 기록 보관인이 문지기가 됩니다. 조정 아티팩트는 향후 제어의 소스가 됩니다.

이 문서에서는 다른 디자인 분야를 제안합니다.

최소 초기 사양: 기본 상호 운용성, 고유성, 제어 증명, 공유 안전 및 보안에 필요한 결정론적 공통 규칙만 지정합니다.
현지화된 미래 결정: 초기 사양 이후에는 참가자가 코드를 실행하면서 향후 선택 사항을 유지합니다. 참가자는 선택적으로 채택, 거부, 분기, 연결 해제 또는 상호 운용할 수 있습니다. 어떤 참가자도 상호 호환 가능한 규칙을 계속 실행하는 다른 참가자의 상호 운용성을 변경할 수 없습니다.
자발적인 채택: 코드를 실행하는 참가자의 구현, 운영, 검증 및 채택을 통해서만 나중에 변경 사항을 현실화할 수 있습니다.

이러한 원칙은 서로 연관되어 있습니다. 처음에 너무 많은 것을 지정하는 시스템은 향후 제어를 공통 계층에 미리 로드합니다. 지속적인 인식 계층을 떠나는 시스템은 배포 후 권한이 다시 나타날 수 있도록 허용합니다. 출판을 현실로 취급하는 시스템은 문서를 명령으로 변환합니다.

설계 직관은 간단합니다. 유효성은 참가자가 공유 상태에 대해 로컬로 확인할 수 있는 결정론적 규칙에 따라 결정되어야 합니다. 참가자는 이후 변경 사항을 채택하거나 거부하거나, 분기하거나, 연결을 끊거나, 선택적으로 상호 운용할 수 있습니다. 기껏해야 호환성 세트에서 자체적으로 제거될 수 있습니다. 변경을 거부함으로써 상호 호환되는 코드를 계속 실행하는 다른 참가자의 상호 운용성을 깨뜨릴 수 없습니다.

이것이 분산 원장 설계의 일반적인 교훈입니다. 합의 규칙은 검증 코드를 실행하고 승인할 상태를 결정하는 참가자에 의해 시행되며, 그 위에 있는 기관에 의해 시행되지 않습니다.

2. 범위

이 문서는 식별자 시스템, 명명 및 번호 지정 프레임워크, 프로토콜 확장 메커니즘, 제어 증명 시스템, 이식성 시스템, 분산 원장 및 독립 행위자가 공통 기술 참조 지점에 의존하는 기타 아키텍처를 포함하되 이에 국한되지 않는 인터넷 조정 시스템에 적용됩니다.

이 문서는 일반적인 규칙에 반대하지 않습니다. 이는 공통 규칙이 결정적이어야 하고, 최소화되어야 하며, 로컬에서 검증 가능해야 하며, 시스템이 실행되기 위해 실제로 필요한 것으로 제한되어야 한다고 주장합니다.

이 문서에는 특정 분산 원장 구현이 필요하지 않습니다. 설계 속성이 필요합니다. 참가자는 권한이나 상태에 대해 상임 기관에 문의하지 않고도 공유 또는 복제 가능한 상태에 로컬로 초기 사양을 적용하여 유효성을 확인할 수 있어야 합니다.

3. 규약 및 정의

3.1. 요구사항 언어

이 문서에서 대문자로 표시된 요구 사항 용어는 BCP 14, 특히 RFC 2119 및 RFC 8174에 정의된 의미로 해석됩니다.

3.2. 용어

초기 사양:
시스템의 첫 번째 배포에 필요한 규칙, 데이터 구조, 형식, 불변, 유효성 검사 절차, 상태 전환 규칙 및 충돌 규칙 집합입니다.

공통층:
독립적인 참가자가 상호 운용하는 데 필요한 최소 공유 규칙 세트 또는 참조 구조입니다. 공통 계층은 기관이 아닙니다. 참여자가 구현하고 검증하는 기술적 내용입니다.

분산 원장:
참가자가 상설 등록부, 위원회 또는 기타 권한에 의존하지 않고 일반적인 유효성을 확인할 수 있도록 하는 상태 전환에 대한 복제되거나 배포된 기록입니다. 이 용어는 특정 합의 알고리즘이나 구현을 요구하지 않습니다.

결정론적 검증 규칙:
참가자가 로컬 계산이나 로컬 확인을 통해 상태, 레코드, 전환, 주장 또는 메시지가 지정된 규칙 세트에서 유효한지 여부를 결정할 수 있도록 하는 규칙입니다.

전역 불변성:
고유성, 기본 상호 운용성, 제어 증명 무결성, 공유 안전 또는 보안을 유지하기 위해 호환성 집합 내에서 공통으로 유지되어야 하는 속성입니다.

참가자:
시스템을 실행, 확인, 배포 또는 의존하는 운영자, 구현, 노드, 네트워크, 조직 또는 기타 행위자입니다.

호환성 세트:
검증 규칙을 구현하여 상호 운용이 가능한 참가자 그룹입니다. 일부 참가자는 이를 채택하고 다른 참가자는 채택하지 않는 경우 나중에 변경하면 새로운 호환성 집합이 생성될 수 있습니다.

채택:
시스템을 실행하는 참가자의 실제 구현, 배포, 검증 및 사용입니다.

상대방 수락:
실행되는 검증 규칙에 따라 다른 참가자의 상태를 수락, 거래, 상호 운용 또는 의존하려는 참가자의 자발적인 결정입니다.

비채택:
제안된 변경 사항을 구현하거나 사용하지 않기로 한 참가자의 선택입니다. 비채택은 무효 상태를 생성하지 않습니다. 이는 참가자가 해당 변경 사항으로 생성된 호환성 집합에 참여하지 않았음을 의미할 뿐입니다.

국부적으로 거절:
실행되는 유효성 검사 규칙에 따라 유효하지 않거나 호환되지 않는 상태, 메시지, 기록 또는 전환을 무시, 거부 또는 상호 운용하지 않기로 한 참가자의 로컬 결정입니다.

포크:
둘 이상의 호환성 집합을 생성하는 유효성 검사 규칙 또는 운영 관행의 차이입니다.

조정 아티팩트:
참가자가 조정하는 데 도움이 되는 문서, 권장 사항, 구현 메모, 프로필, 참조 구현, 원장 탐색기, 미러 또는 기타 아티팩트입니다. 조정 아티팩트는 참가자가 실행 중인 시스템에서 이를 채택하지 않는 한 구속력 있는 운영 현실을 생성하지 않습니다.

4. 문제 설명

디자이너는 기본 레이어에 너무 많은 내용을 입력하거나 미래의 질문을 해석하기 위해 계속적인 본문을 남겨두어 미래의 불확실성을 줄이려고 노력하는 경우가 많습니다. 이는 신중한 것으로 보입니다. 위험한 경우가 많습니다.

기초 계층의 과잉 사양에는 세 가지 비용이 발생합니다.

첫째, 미래의 선택을 변경이 더 어렵고 캡처가 더 큰 효과가 있는 공통 계층으로 이동합니다.

둘째, 기술적 타당성과 제도적 인정 사이에 모호성을 야기한다.

셋째, 기록을 유지하고 문서를 게시하거나 참가자를 소집하는 기관이 그러한 행위를 미래 현실에 대한 권위로 취급하도록 권장합니다.

배포 후에도 동일한 문제가 나타납니다. 시스템에서 변경 승인, 상태 결정 또는 일반적인 운영 해석을 위해 지속적인 기관이 필요한 경우 시스템은 창립 후 제어 계층을 만들었습니다. 해당 계층은 관리로 시작될 수 있습니다. 거버넌스가 될 수 있습니다. 그러면 그것은 질식 지점이 될 수 있습니다.

이 문서의 설계 목표는 더 나은 제도적 재량권이 아닙니다. 디자인 목표는 그러한 재량권이 필요하지 않도록 하는 것입니다.

잘 설계된 인터넷 조정 시스템은 처음부터 결정론적이고 지역적으로 검증 가능한 유효성 규칙을 정의해야 합니다. 분산 또는 복제 가능한 형태로 유효한 상태를 나타냅니다. 공통 레이어 외부에 변하지 않는 선택 사항을 남겨둡니다. 참가자가 실행 중인 시스템에서 자발적으로 채택한 경우에만 나중에 변경 사항이 현실화되도록 허용합니다.

5. 원칙 1: 최소 초기 사양

5.1. 성명

초기 사양은 기본 상호 운용성, 고유성, 제어 증명, 공유 안전 및 보안에 필요한 최소한의 결정론적 공통 규칙만 정의해야 합니다.

5.2. 요구사항

이 원리를 사용한 디자인:

전역 불변성을 명시적으로 식별해야 합니다.
각 전역 불변성에 대한 결정론적 유효성 검사 규칙을 정의해야 합니다(MUST).
유효한 상태가 어떻게 표현되고, 복제되고, 확인되고, 업데이트되는지 정의해야 합니다.
명시된 전역 불변성을 유지하거나 첫 번째 배포를 활성화하는 데 규칙이 필요한 경우를 제외하고는 초기 사양에 규칙을 배치해서는 안 됩니다.
검증 규칙을 정책 선호도, 비즈니스 준비, 제도적 역할, 거버넌스 목표 및 재량적 판단과 분리해야 합니다.
참가자가 기관, 등록 기관, 위원회, 정책 기관 또는 기타 당국에 묻지 않고 현지에서 일반 유효성을 확인할 수 있도록 허용해야 합니다.
데이터 구조, 서명, 증명, 상태 전환 규칙, 충돌 규칙 또는 로컬 확인에 필요한 기타 메커니즘을 정의해야 합니다(SHOULD).
향후 변형이 예측 가능한 경우 확장 신호, 버전 관리, 호환성 라벨링 또는 포크 식별을 정의해야 합니다(SHOULD).
필요한 조정 아티팩트가 이식 가능하고, 감사 가능하고, 재현 가능하고, 교체 가능함을 보장해야 합니다(MUST).
주관적인 장점 판단보다 객관적인 기계 검증 조건을 선호해야 합니다(SHOULD).
미래의 제도적 인정을 유효한 상태가 알려지거나 기록되거나 사용될 수 있는 유일한 경로로 만들어서는 안 됩니다.

5.3. 디자인의 의미

최소 초기 사양은 모호한 사양을 의미하지 않습니다. 이는 공통되어야 하는 것만 엄격하게 지정하는 것을 의미합니다.

시스템을 실행하려면 여전히 충분한 공통 구조가 필요합니다. 규율은 다음을 구별하는 것입니다.

고유성, 상호 운용성, 제어 증명, 공유 안전 및 보안에 대한 공통 사항은 무엇입니까? 그리고
운영자 선호도, 비즈니스 관행, 상대방 선택, 배포 시기 또는 이후 채택 선택과 관련이 있기 때문에 공통 계층 외부에 남아 있을 수 있는 것은 무엇입니까?

전역 불변성과 결정론적 검증 규칙을 명확하게 기술할 수 없는 설계는 너무 많은 재량권과 너무 적은 검증 가능한 내용을 지정했다고 가정해야 합니다.

6. 원칙 2: 지역화된 미래 결정

6.1. 성명서

초기 사양 이후 향후 결정은 코드를 실행하는 참가자에게 로컬로 유지되어야 합니다. 미래 결정은 참가자가 이를 채택한 호환성 집합에 대해서만 유효합니다. 이를 승인하는 데 지속적인 권한이 필요하지 않으며, 채택하지 않아도 무효 상태가 생성되지 않습니다.

6.2. 요구사항

이 원리를 사용한 디자인:

참가자가 참여하는 호환성 세트의 결정론적 검증 규칙을 변경하지 않는 선택에 대해 기존 기관, 등록 기관, 위원회, 이사회, 정책 기관 또는 기타 권한으로부터 허가를 받도록 참가자에게 요구해서는 안 됩니다.
인식이 나중에 변경 사항이 운영상 현실화될 수 있는 유일한 경로인 상설 기관을 생성해서는 안 됩니다.
초기 사양에 따른 유효성과 이후 선택적 변경 사항의 호환성을 구별해야 합니다.
이후 변경 사항을 채택하지 않는 것을 무효로 처리해서는 안 됩니다.
참가자가 이후 변경 사항을 채택하지 않을 때 기존 호환성 세트를 유지하도록 허용해야 합니다(MUST).
참가자가 새로운 검증 규칙이나 운영 프로필을 채택하여 새로운 호환성 세트에 참여할 수 있도록 허용해야 합니다(MUST).
참가자가 실행하는 유효성 검사 규칙에 따라 유효하지 않거나 호환되지 않는 상태, 기록, 전환 또는 메시지를 로컬에서 거부할 수 있도록 허용해야 합니다.
참가자가 승인한 검증 규칙 및 호환성 세트에 따라 상대방을 자발적으로 선택할 수 있도록 허용해야 합니다.
기관, 등록 기관, 위원회, 정책 기관 또는 기타 행위자가 단순히 이후 변경을 거부했다는 이유만으로 참가자를 무효로 선언하는 권한을 부여해서는 안 됩니다.
참가자가 실행 중인 규칙과 상호 운용할 수 있는 다른 참가자를 알 수 있도록 포크, 버전, 프로필 또는 호환성 세트를 명시적으로 만들어야 합니다.
현직 기록 보관자가 유효한 참가자가 계속해서 상호 운용하는 것을 방해할 수 있는 설계는 피해야 합니다(SHOULD).

6.3. 디자인의 의미

지역화된 미래 결정은 중앙 당국이 미래 결정을 지역 행위자에게 할당한다는 의미는 아닙니다. 이는 초기 사양 이후 일반적인 미래 선택에는 그러한 할당이 필요하지 않도록 시스템이 설계되었음을 의미합니다.

초기 사양은 사전에 제한 작업을 수행합니다. 고유성, 상호 운용성, 제어 증명, 공유 안전 및 보안에 필요한 최소 불변성을 정의합니다. 다른 모든 것은 공통 레이어 외부에 남아 있습니다.

향후 변경 사항은 중앙에서 승인되지 않습니다. 코드를 실행하는 참가자에 의해 채택, 무시, 분기 또는 폐기됩니다.

변경을 거부하는 참가자는 해당 변경으로 생성된 호환성 집합 외부에 남아 있을 수 있습니다. 다른 사람과의 연결이 끊어질 수 있습니다. 이전 호환성 세트에서 계속될 수 있습니다. 포크가 될 수 있습니다. 선택적으로 상호 운용될 수 있습니다. 그러나 상호 호환 가능한 규칙을 계속 실행하는 다른 참가자의 상호 운용성을 깨뜨릴 수는 없습니다.

유효하지 않거나 양립할 수 없는 상태의 효과는 처벌이 아니라 지역적 거부입니다. 누구도 참가자의 상태가 좋지 않다고 결정할 필요가 없습니다. 호환 가능한 유효성 검사 규칙을 실행하는 참가자는 유효하지 않거나 호환되지 않는 상태를 단순히 수락하지 않습니다.

7. 원칙 3: 자발적인 채택

7.1. 성명서

인터넷 조정 시스템의 변경 사항은 게시나 선언만으로 실행되는 것이 아니라 구현, 검증, 배포, 상대방 수락, 참가자 채택을 통해 운영상 현실화되어야 합니다.

7.2. 요구사항

이 원리를 사용한 디자인:

출판, 추천, 회의 승인 또는 절차적 승인을 보편적인 운영 의무를 생성하기에 충분한 것으로 취급해서는 안 됩니다.
새로운 규칙, 확장, 프로필 또는 절차를 실행하기로 선택한 참가자가 점진적으로 배포할 수 있도록 허용해야 합니다(MUST).
참가자의 상태 전환이 호환성 집합의 결정론적 유효성 검사 규칙을 충족하는 한 참가자가 유효하지 않은 상태를 획득하지 않고 이후 변경을 거부할 수 있도록 허용해야 합니다(MUST).
참가자가 초기 사양에서 이러한 연속성을 허용하는 이전 호환성 세트를 계속 사용할 수 있도록 허용해야 합니다.
하나의 호환성 세트를 실행하는 참가자가 규칙이 호환되지 않는 다른 호환성 세트의 상태를 로컬에서 거부하거나 무시하도록 허용해야 합니다(MUST).
버전 신호, 호환성 라벨링, 전환 지침 및 테스트 벡터를 포함한 주요 변경 사항에 대한 채택 경로를 정의해야 합니다(SHOULD).
채택하지 않은 참가자가 작업을 계속하는 방법, 호환성 세트를 식별하고 모호한 상호 운용을 방지하는 방법을 포함하여 주요 변경에 대한 거부 경로를 정의해야 합니다(SHOULD).
불가능한 전환 비용 없이 필요한 조정 아티팩트를 종료, 미러링, 재구현 또는 교체할 수 있는지 확인해야 합니다(MUST).
채택되지 않은 미래 현실이 존재한다고 선언하기보다는 채택된 현실을 설명하는 기록, 권장 사항 및 조정 아티팩트가 있어야 합니다.
변경이 현실화되는 유일한 방법은 현 기관의 사전 승인뿐인 시스템 설계를 피해야 합니다.

7.3. 디자인의 의미

자발적 채택은 변경 사항이 유용하고 허용 가능하며 실제 배포와 호환되는지 여부를 테스트하는 운영 테스트입니다.

제안은 현실이 아닙니다. 추천은 현실이 아닙니다. 문서는 현실이 아닙니다. 참가자가 상대방을 구현, 검증, 배포, 수락하고 변화에 의존할 때 현실이 나타납니다.

비채택은 위반 상태를 생성하지 않습니다. 이는 단지 사실만을 생성합니다. 참가자는 변경으로 생성된 호환성 집합에 가입하지 않았습니다.

이는 표준 프로세스, 문서, 구현 노트, 탐색기, 미러 또는 검토를 제거하지 않습니다. 그것은 그들의 주장을 제한합니다. 참가자들이 조정하는 데 도움이 될 수 있습니다. 참고 자료를 출판할 수도 있습니다. 입양을 설명할 수도 있습니다. 그들은 추천할 수도 있습니다. 선언만으로는 채택되지 않은 미래 현실을 실행하지 않는 참가자에게 구속력을 부여할 수 없습니다.

8. 세 가지 원칙의 관계

세 가지 원칙은 서로 강화되며 단독으로는 효과적이지 않습니다.

최소 초기 사양은 공통 계층에 임의 권한이 아닌 결정론적 유효성 검사 규칙이 포함되도록 보장합니다.

지역화된 미래 결정은 중앙 승인 계층에 의해 다시 포착되지 않고 참가자가 코드를 실행하면서 미래의 선택이 유지되도록 보장합니다.

자발적인 채택은 이후의 변경 사항이 구현, 검증, 상대방 승인 및 사용과 관련해서도 살아남아야 함을 보장합니다.

이러한 원칙 중 한두 가지만 채택하는 시스템은 다른 수단을 통해 동일한 중앙 집중화를 재현할 수 있습니다.

현지화된 향후 결정이 없는 최소 초기 사양은 배포 후에도 권한이 누적되도록 허용할 수 있습니다.
최소 초기 사양 없이 지역화된 미래 결정은 참가자가 지역적으로 유효성을 결정할 수 없기 때문에 모호성을 초래할 수 있습니다.
결정론적 검증 없이 자발적으로 채택하면 참가자가 호환 가능한 변형과 유효하지 않은 상태를 구별할 수 없기 때문에 혼란을 초래할 수 있습니다.
분산 상태가 없는 결정적 검증은 여전히 참가자를 권한 있는 기록 보관자에게 의존하게 만들 수 있습니다.
포크 가시성이 없는 분산 상태는 운영이 실패할 때까지 불일치를 숨길 수 있습니다.
자발적인 상대방 수락이 없는 분산 상태는 다른 인터페이스를 통해 강제를 다시 생성할 수 있습니다.

이 원칙들은 공통 계층이 얇고, 타당성이 로컬로 검증 가능하며, 향후 변경이 자발적이고, 상태가 분산되며, 일반 운영을 결정하는 데 상설 기관이 필요하지 않은 시스템을 생성합니다.

9. 추천 디자인 패턴

9.1. 결정적 분산 공통 계층

공통 레이어는 다음으로 제한되어야 합니다.

안정적인 식별자 의미론;
결정론적 타당성 규칙;
고유성을 유지하는 데 필요한 갈등 해결 규칙;
제어 증명 메커니즘;
상태 전환 규칙;
와이어 수준 또는 프로토콜 수준 상호 운용성 요구 사항
공유 보안 불변성;
이식 가능하고 감사 가능한 상태 형식
분산 또는 복제된 상태 가시성;
확장 신호 및 호환성 집합 식별.

공통 레이어에는 다음이 포함되어서는 안 됩니다.

비즈니스 모델 규칙;
가격 책정 규칙;
지역적 정치적 선호;
기술적 불변성과 관련되지 않은 적격성 이데올로기;
재량적 집행 권한;
주관적인 장점 평가;
제도적 사명 확장;
기존 기관의 권위를 보존하는 것이 주요 기능인 모든 규칙.

9.2. 운영자 결정 표면

다음은 명시된 전역 불변성을 직접 변경하지 않는 한 공통 계층 외부에 남아 있어야 합니다.

배포 시기;
상업적 이용;
고객 지역;
임대, 융자 또는 양도 계약;
지역 적격성 우선권;
운영 순서;
공유 유효성에는 라우팅 관행이 필요하지 않습니다.
비즈니스 모델;
조직 구조;
자발적 이주 시기;
선택적 프로필 또는 확장;
상대방 선택.

참가자는 이러한 영역에서 다양한 선택을 채택할 수 있습니다. 이러한 선택에 따라 다양한 호환성 집합, 비즈니스 관계, 피어링 계약 또는 운영 커뮤니티가 생성될 수 있습니다. 호환성 집합의 결정적 유효성 검사 규칙을 위반하지 않는 한 무효성을 생성하지 않습니다.

9.3. 채택 루프

가능한 경우 재료 시스템 변경에 대한 선호 순서는 다음과 같습니다.

제안;
구현;
테스트 벡터 또는 결정론적 검증 방법;
자발적인 참가자에 의한 제한된 배포;
상호 운용성 및 보안 효과 관찰;
호환성 설정 라벨링;
채택된 현실을 설명하는 문서 또는 권장 사항.

조정 아티팩트는 선점을 시도하기보다는 채택을 따라야 합니다.

9.4. 포크, 로컬 거부 및 상대방 수락

적합한 설계는 포크, 로컬 거부 및 상대방 수락을 실패가 아닌 일반적인 설계 요구 사항으로 처리해야 합니다.

시스템은 참가자가 다음을 수행할 수 있는 방법을 정의해야 합니다.

이전 호환성 세트를 계속 사용합니다.
최신 호환성 세트를 채택합니다.
다른 호환성 세트로 분기합니다.
현직 기록 보관인에게 의존하지 않고 상태를 확인합니다.
상대방을 자발적으로 수락합니다.
유효하지 않거나 호환되지 않는 상태를 로컬에서 거부합니다.
호환성이 허용되는 경우 선택적으로 상호 운용됩니다.

유효한 운영을 파괴하지 않고 포크되거나, 로컬에서 검증되거나, 선택적으로 승인될 수 없는 시스템은 아마도 기록 보관 기능 내에 거버넌스 권한을 숨겼을 것입니다.

10. 적용 범위 및 한계

이 디자인 패턴은 특히 다음과 같은 경우에 적용 가능합니다.

시스템은 다중 행위자 및 다중 관할권을 갖고 있습니다.
독립적인 배포가 중요합니다.
배위층은 얇게 유지되도록 고안되었습니다.
미래의 변화가 일어날 가능성은 있지만 자세히 예측할 수는 없습니다.
종속은 거버넌스 위험을 야기합니다.
타당성은 결정론적이거나 지역적으로 검증 가능하도록 만들어질 수 있습니다.
분산된 상태는 제도적 포획 위험을 줄일 수 있습니다.

다음과 같은 경우에는 덜 직접적으로 적용 가능합니다.

단일 관리 도메인이 의도된 아키텍처입니다.
강력한 실시간 결합을 위해서는 항상 균일한 동작이 필요합니다.
생명 안전 문제에는 즉각적인 전 세계적 통일이 필요합니다.
유효성은 실제적인 메커니즘으로 로컬에서 확인할 수 없습니다.

이러한 경우에도 설계자는 공통 계층을 최소화해야 하며 가능하면 향후 임의 제어를 피해야 합니다.

11. 논골

이 문서는 다음을 수행하지 않습니다.

모든 조정을 금지합니다.
특정 분산 원장 구현이 필요합니다.
합의를 보장합니다.
정치적 중립성을 보장합니다.
모든 참가자가 이후의 모든 변경 사항을 채택하도록 요구합니다.
입양 거부를 무효로 간주합니다.
호환성을 주장하면서 호환되지 않는 지역적 행동을 합법화합니다.
보안에 중요한 공통 규칙이 필요하지 않습니다.

12. 보안 고려 사항

더 얇은 조정 레이어는 포획 위험을 줄이고 제도적 오류의 폭발 반경을 낮추며 교체 가능성을 향상시킬 수 있습니다. 그러나 로컬 재량권이 증가하고 상태가 분산되면 일관되지 않은 보안 상태, 다운그레이드 경로, 조각화 압력, 모호한 호환성 주장, 안전하지 않은 포크, 원장 상태 분쟁 및 위조 증명 시도가 발생할 수도 있습니다.

따라서 이 문서를 적용하는 디자이너는 보안 불변성을 명시적으로 지정해야 합니다. 특히:

공유 유효성에 필요한 인증 및 권한 부여 요구 사항은 결정적이어야 하며 로컬에서 검증 가능해야 합니다.
제어 증명 메커니즘은 위조, 재생 및 무단 전송을 방지해야 합니다.
버전 협상 및 확장 처리는 보안이 영향을 받는 경우 자동 다운그레이드를 피해야 합니다.
거부, 분기 및 교체 경로의 남용 및 서비스 거부 위험을 분석해야 합니다.
호환성 레이블은 호환되지 않는 규칙 세트 간의 우발적인 상호 운용을 방지할 수 있을 만큼 명확해야 합니다.
분산 상태는 일관되지 않은 뷰를 감지할 수 있을 만큼 충분히 감사 및 재현 가능해야 합니다.
로컬 변형은 자신이 만족하지 않는 규칙 세트와의 호환성을 거짓으로 주장하도록 허용되어서는 안 됩니다.

보안 예외가 존재한다고 해서 일반 권한 계층이 정당화되는 것은 아닙니다. 이는 명시된 전역 불변성을 보존하는 데 필요한 결정론적 보안 규칙만을 정당화합니다.

13. IANA 고려 사항

이 문서에는 IANA 작업이 없습니다.

14. 참고자료

14.1. 규범적 참고자료

RFC 2119 — 브래드너, S., 요구 사항 수준을 나타내기 위해 RFC에서 사용되는 키워드, BCP 14, RFC 2119.
RFC 8174 - 레이바, B., RFC 2119 핵심 단어에서 대문자와 소문자의 모호함, BCP 14, RFC 8174.

14.2. 유익한 참고 자료

RFC 6709 - Carpenter, B. 및 B. Aboba, 프로토콜 확장을 위한 설계 고려 사항, RFC 6709.
RFC 7282 - 레스닉, P., IETF의 합의 및 허밍에 대하여, RFC 7282.

부록 A. 설계 체크리스트

이 문서에 대한 적합성을 주장하는 디자인은 다음 질문에 명확하게 대답할 수 있어야 합니다.

전역 불변성이란 무엇입니까?
전역 불변성을 보존하는 결정론적 검증 규칙은 무엇입니까?
초기 사양의 어떤 규칙이 첫 번째 배포에 꼭 필요한가요?
유효한 상태는 어떻게 표현되고 검증됩니까?
상태가 분산, 복제되거나 독립적으로 검증될 수 있습니까?
공통 레이어 외부에 의도적으로 남겨둔 미래 질문은 무엇입니까?
참가자가 속한 호환성 세트를 변경하지 않고 향후 어떤 선택을 할 수 있습니까?
참가자는 이후 변경 사항을 어떻게 채택합니까?
참가자가 유효하지 않은 상태를 할당받지 않고 이후 변경을 어떻게 거부합니까?
호환성 세트는 어떻게 레이블 지정되거나 검색됩니까?
참가자가 실행하는 규칙에 따라 상태가 유효하지 않거나 호환되지 않는 경우 로컬 거부는 어떻게 작동합니까?
포크 경로는 무엇입니까?
현 기록 보관인 없이 보유자가 통제권을 어떻게 증명합니까?
상대방은 등록 없이 상태를 어떻게 확인합니까?
참가자는 현 기록 보관자에게 의존하지 않고 일반적인 유효성을 확인할 수 있습니까?
기록과 조정 아티팩트가 채택된 현실을 설명합니까, 아니면 채택되지 않은 미래 현실이 존재하도록 선언하려고 시도합니까?
시스템이 공통 계층에 포함된 의사결정 수를 최소화했습니까?
시스템이 일반 참가자 상태를 결정하는 지속적인 권한을 회피했습니까?
참가자가 상대방을 자발적으로 수락하거나 거부할 수 있습니까?
모든 기존 레지스트리가 사라져도 시스템을 계속 사용할 수 있습니까?

저자 주소

Lu
[TBD]

이 노트가 있는 곳

무엇이 안정적으로 유지되어야 하며, 누구를 위해 존재해야 합니까?

이 노트의 초점

12. 보안 고려 사항

전시회에서의 이 질문

“Every system eventually reaches a moment when it must either adapt to reality or attempt to freeze itself in place.”홀 5 · The Scale of TimeThe Mountain Stays, Weather Passes 참고 25

지도 읽기

시작하기 전에

연속성은 현재 관리자가 실패하거나 교체되어야 하는 경우에도 작동 중인 네트워크가 계속 작동할 수 있음을 의미합니다.

문제
사람들이 실제로 보존해야 할 것은 기록과 다른 곳에서 계속할 수 있는 능력인 경우에도 "안정성"은 영구 문지기를 방어하는 데 자주 사용됩니다.
제안된 방향
서비스를 교체 가능하게 유지하고 종료 경로를 실제적으로 유지하면서 기록의 연속성을 보호합니다.
지금 그것이 중요한 이유
눈에 보이는 실패를 기다리는 것은 떠나는 데 필요한 대안, 지식, 협상력이 이미 사라질 때까지 기다리는 것을 의미할 수 있습니다.