I2P 제안 프로세스 | I2P - 보이지 않는 인터넷 프로젝트

개요

이 문서는 I2P 사양을 변경하는 방법, I2P 제안이 작동하는 방식, 그리고 I2P 제안과 사양 사이의 관계를 설명합니다.

이 문서는 Tor 제안 프로세스를 바탕으로 만들어졌으며, 아래의 많은 내용은 Nick Mathewson이 원래 작성했습니다.

이 문서는 정보 제공을 위한 문서입니다.

동기

이전에 I2P 사양을 업데이트하기 위한 우리의 과정은 상대적으로 비공식적이었습니다: 개발 포럼에 제안을 올리고 변경 사항을 논의한 다음, 합의에 도달하고 (반드시 그 순서가 아닌) 사양을 초안 변경안으로 패치하고, 마지막으로 변경 사항을 구현했습니다.

이 과정에는 몇 가지 문제가 있었습니다.

첫째, 가장 효율적인 경우에도, 이전 과정에서는 사양이 코드와 동기화되지 않는 경우가 종종 있었습니다. 구현이 연기된 경우가 가장 나쁜 사례였으며, 그 결과 사양과 코드는 몇 버전 동안 동기화되지 않을 수 있었습니다.

둘째, 토론에 참여하기가 어려웠습니다. 이는 토론 스레드의 어느 부분이 제안의 일부인지, 또는 사양에 대한 어떤 변경이 구현되었는지가 항상 명확하지 않았기 때문입니다. 또한 개발 포럼은 I2P 내에서만 액세스할 수 있어, 제안은 I2P를 사용하는 사람들만 볼 수 있었습니다.

셋째, 포럼 스레드 목록의 여러 페이지 뒤에 묻혀 있기 때문에 몇몇 제안을 잊기가 매우 쉬웠습니다.

현재 사양을 변경하는 방법

첫째, 누군가 제안 문서를 작성합니다. 이 문서는 구현할 대로의 변경을 상세히 설명하고 이를 구현하는 방법에 대한 아이디어를 제시해야 합니다. 충분히 구체화되면 이는 공식 제안이 됩니다.

RFC와 마찬가지로, 각 제안은 고유 번호를 얻습니다. RFC와는 달리, 제안은 시간이 지나며 변경되고 같은 번호를 유지할 수 있으며, 최종적으로 수락되거나 거부됩니다. 각 제안의 이력은 I2P 웹사이트 저장소에 저장됩니다.

제안이 저장소에 들어가면, 우리는 해당 스레드에서 이를 논의하고 합의에 도달할 때까지 개선하여 구현할 만큼 자세하게 합니다. 이러한 일이 발생하면 우리는 제안을 구현하고 이를 사양에 통합합니다. 따라서, 사양은 I2P 프로토콜에 대한 표준 문서로 남습니다: 구현된 기능에 대해 어떤 제안도 표준 문서가 절대 아닙니다.

(이 과정은 Python Enhancement Process와 매우 유사하지만, I2P 제안은 구현 후 사양에 재통합되지만 PEP는 새로운 사양이 된다는 점이 주요 차이입니다.)

작은 변경

코드가 거의 즉시 작성될 수 있거나 코드 변경이 필요하지 않은 경우, 사소한 변경을 사양에 직접 하는 것이 여전히 허용됩니다. 이 문서는 현재 개발자들의 의도를 반영하며, 항상 이 과정을 사용할 것을 영구적으로 약속하는 것은 아닙니다: 매우 흥분하여 커피나 M&M에 힘입어 밤새 해킹하는 것을 실행할 권리를 보유합니다.

새로운 제안의 추가 방법

제안을 제출하려면, 개발 포럼에 게시하거나 제안을 첨부하여 티켓을 입력하세요.

아이디어가 제안된 다음, 아래의 포맷에 맞춘 초안이 존재하며, 활성 개발 커뮤니티 내에서 이 아이디어가 고려될 만한 가치가 있다는 대략적인 합의가 이루어진 경우, 제안 편집자가 공식적으로 제안을 추가합니다.

현재 제안 편집자는 zzz와 str4d입니다.

제안에 포함해야 할 내용

모든 제안에는 다음과 같은 필드를 포함하는 헤더가 있어야 합니다:

:author:
:created:
:thread:
:lastupdated:
:status:

author 필드에는 이 제안의 저자들의 이름이 포함되어야 합니다.
thread 필드는 이 제안이 처음 게시된 개발 포럼 스레드의 링크이거나, 이 제안을 논의하기 위해 생성된 새 스레드의 링크여야 합니다.
lastupdated 필드는 초기에는 created 필드와 동일해야 하며, 제안이 변경될 때마다 업데이트되어야 합니다.

필요에 따라 설정해야 하는 필드:

:supercedes:
:supercededby:
:editor:

supercedes 필드는 이 제안이 대체하는 제안의 번호 리스트입니다. 해당 제안은 거부된 것으로 표시되어야 하고, 그들의 supercededby 필드는 이 제안의 번호로 설정되어야 합니다.
editor 필드는 이 제안에 실질적인 변경 없이 중요한 변경이 이루어졌을 때 설정해야 합니다. 내용이 크게 변경되는 경우, 추가 author를 추가하거나, 이 제안을 대체하는 새로운 제안을 만들어야 합니다.

이 필드는 선택사항이지만 권장됩니다:

:target:
:implementedin:

target 필드는 제안이 구현되기를 희망하는 버전을 설명해야 합니다 (만약 Open 또는 Accepted 상태인 경우).
implementedin 필드는 제안이 구현된 버전을 설명해야 합니다 (만약 Finished 또는 Closed 상태인 경우).

제안의 본문은 제안이 무엇인지, 무엇을 하는지, 그리고 어떤 상태인지 설명하는 개요 섹션으로 시작해야 합니다.

개요 이후, 제안은 더 자유로운 형식이 될 수 있습니다. 길이나 복잡성에 따라, 적절한 섹션으로 나눌 수 있거나 간단한 서술 형식을 따를 수 있습니다. 모든 제안은 수락되기 전에 적어도 다음 정보를 포함해야 하며, 정보는 반드시 이 이름의 섹션에 포함될 필요는 없습니다.

동기: 제안이 해결하고자 하는 문제는 무엇인가? 이 문제가 왜 중요한가? 여러 접근 방식이 가능한 경우, 왜 이 방식을 선택했는가?
설계: 새로 추가되거나 수정되는 기능의 개요, 새로 추가되거나 수정된 기능이 어떻게 작동하는지, 서로 어떻게 상호 운용하는지, 그리고 I2P의 나머지 부분과 어떻게 상호 작용하는지를 설명하는 고급 개요입니다. 이것이 제안의 주요 부분입니다. 일부 제안은 처음에는 동기와 설계만으로 시작하며, 설계가 적절해 보이기 전까지는 사양을 기다립니다.
보안 관련 사항: 제안된 변경이 익명성에 미칠 수 있는 영향, 이러한 영향을 얼마나 잘 이해하고 있는지를 설명합니다.
사양: 제안을 구현하기 위해 I2P 사양에 추가해야 하는 항목을 자세히 설명합니다. 이 내용은 결국 사양에 포함될 내용과 거의 동일해야 하며, 독립적인 프로그래머들이 사양을 기반으로 제안의 상호 호환되는 구현을 작성할 수 있어야 합니다.
호환성: 제안에 따라 제작된 I2P 버전이 그렇지 않은 버전과 호환될 것인가? 그렇다면 호환성은 어떻게 이루어지는가? 일반적으로, 우리는 가능한 경우 호환성을 상실하지 않으려 하며, 2008년 3월 이후로 “플래그 데이” 변경을 하지 않았으며 또다시 그렇게 하고 싶지 않습니다.
구현: 제안이 I2P의 현재 아키텍처에서 구현하기 어려울 경우, 이를 작동하게 만드는 방법에 대한 논의가 포함될 수 있습니다. 실제 패치는 공공의 monotone 브랜치에 적용되거나 Trac에 업로드되어야 합니다.
성능과 확장성 관련 주의 사항: 기능이 성능(RAM, CPU, 대역폭) 또는 확장성에 영향을 미친다면, 이 영향이 얼마나 중요한지에 대한 분석이 필요하며, 이는 매우 비싼 성능 퇴행을 피하고 시간 낭비를 막기 위해 중요하지 않은 이득에서 벗어나는 데 도움이 됩니다.
참고 자료: 제안이 외부 문서를 참조하는 경우, 이를 나열해야 합니다.

제안 상태

Open: 논의 중인 제안.
Accepted: 제안이 완료되었으며 구현할 것입니다. 이 시점 이후로, 제안에 대한 실질적인 변경은 피해야 하며, 프로세스의 실패를 나타내는 것으로 간주됩니다.
Finished: 제안이 수락되고 구현되었습니다. 이 시점 이후로 제안은 변경되어서는 안 됩니다.
Closed: 제안이 수락되고 구현되며, 메인 사양 문서에 통합되었습니다. 이 시점 이후로 제안은 변경되어서는 안 됩니다.
Rejected: 문서상에 설명된 기능을 구현할 계획이 없으며, 다른 버전을 구현할 수도 있습니다. 문서 내 의견을 참조하십시오. 이 시점 이후로 제안은 변경되어서는 안 됩니다; 아이디어의 다른 버전을 제기하려면 새로운 제안을 작성하십시오.
Draft: 이건 아직 완전한 제안이 아닙니다; 분명히 누락된 부분이 있습니다. 이 상태로 새 제안을 추가하지 마십시오; 대신 “ideas” 하위 디렉토리에 넣으세요.
Needs-Revision: 제안의 아이디어는 훌륭하지만, 현재의 상태에서는 수락되지 못하게하는 심각한 문제가 있습니다. 문서 내 의견을 참조하십시오.
Dead: 제안이 오랫동안 손대지 않았으며, 곧 완료될 것으로 보이지도 않습니다. 새로운 지지자가 나설 경우 “Open” 상태로 다시 전환될 수 있습니다.
Needs-Research: 제안이 좋은 아이디어인지 명확해지기 전에 해결해야 할 연구 문제가 있습니다.
Meta: 이건 제안이 아니라, 제안에 관한 문서입니다.
Reserve: 현재 구현할 계획이 없는 제안이지만, 언젠가 제안하는 것과 유사한 무언가를 하기로 결정할 경우 부활시킬 수도 있는 제안입니다.
Informational: 이 제안은 해당 역할에 관한 최종 결론을 포함합니다. 누군가 새로운 하위 시스템에 대한 새 사양으로 복사하여 붙여 넣지 않는 한 사양으로 변하지 않습니다.

편집자는 대략적인 합의와 자신의 재량에 기초하여 제안의 적절한 상태를 유지합니다.

제안 번호

번호 000-099는 특별 및 메타 제안용으로 예약되어 있습니다. 100부터는 실제 제안에 사용됩니다. 번호는 재활용되지 않습니다.

참고 자료

Tor 제안 프로세스

개요

동기