Минимальная исходная спецификация, дальнейшие решения на уровне участников и добровольное внедрение в системе интернет-координации

Договориться о соединении, оставить пространство для разных конструкций. Лу Хэн предлагает ограничить общие правила тем, что необходимо для совместимости, а последующие решения оставить самим участникам.

Аннотация

В этом документе описан подход к проектированию систем интернет-координации, предназначенных для создания общих технических точек отсчёта без учреждения постоянной власти над участниками, обеспечивающими работу системы. Он определяет три взаимосвязанных принципа: Минимальная исходная спецификация, Дальнейшие решения на уровне участников и Добровольное внедрение.

В этой модели Исходная спецификация определяет только детерминированные, локально проверяемые правила, необходимые для уникальности, совместимости, общей безопасности и защищённости. После принятия Исходной спецификации дальнейшие изменения не утверждаются центральным органом. Участники, запускающие программный код, внедряют их, игнорируют, создают на их основе ответвления или отказываются от них.

Отказ от внедрения не является нарушением. Участник, не внедряющий последующее изменение, остаётся в своей существующей группе совместимости. Если участник передаёт состояние, которое не соответствует детерминированным правилам, принятым другим участником, этот другой участник может локально игнорировать участника, передающего такое состояние. Результатом становится выбор совместимости, ответвление, изоляция или избирательное взаимодействие, а не наказание со стороны института.

Этот документ не определяет протокол передачи данных. Он формулирует актуальную передовую практику (Best Current Practice) проектирования протоколов, реестров, систем идентификаторов и механизмов координации, которые не должны превращаться в постоянные институты управления.

1. Введение

Многие интернет-системы создаются с узкой технической целью: дать независимым участникам возможность взаимодействовать благодаря общей точке отсчёта, пространству идентификаторов, правилу проверки или записям, устроенным по типу реестра. Со временем такие системы нередко накапливают полномочия, которые не требовались для первоначальной совместимости.

Обычно это происходит в три этапа.

Сначала вопросы будущего закладывают в исходный слой системы ещё до того, как возникает техническая необходимость их решать.

Затем решения, которые должны принимать участники, эксплуатирующие собственные системы, начинают зависеть от признания, толкования или определения статуса постоянно действующим органом.

Наконец, публикацию, регистрацию, рекомендацию или процедурное утверждение считают достаточным основанием для возникновения обязательств при эксплуатации, даже если участники не внедрили изменение в работающие системы.

В результате система становится хрупкой. Технический опорный слой превращается в слой управления. Хранитель записей становится распорядителем доступа. Материал, предназначенный для координации, становится источником дальнейшего контроля.

В этом документе предлагается иной подход к проектированию:

– Минимальная исходная спецификация: определять только детерминированные общие правила, необходимые для базовой совместимости, уникальности, общей безопасности и защищённости.
– Дальнейшие решения на уровне участников: после принятия Исходной спецификации оставлять дальнейший выбор за участниками, запускающими программный код. Участник может внедрить изменение, отказаться от него, создать ответвление, отключиться или взаимодействовать избирательно. Ни один участник не может изменить совместимость других участников, продолжающих работать по взаимно совместимым правилам.
– Добровольное внедрение: последующее изменение становится реальностью только через реализацию, эксплуатацию, проверку и внедрение участниками, запускающими программный код.

Эти принципы связаны между собой. Система, которая слишком многое определяет на старте, заранее закладывает в общий слой будущий контроль. Система, сохраняющая постоянный слой признания, позволяет власти возникнуть вновь уже после развёртывания. Система, приравнивающая публикацию к реальности, превращает документацию в приказ.

Основная идея проста: корректность должна определяться детерминированными правилами, которые участники могут проверять локально. Участник может внедрить последующее изменение, отказаться от него, создать ответвление, отключиться или взаимодействовать избирательно. Самое большее, что он может сделать, — вывести себя из группы совместимости. Отказываясь от изменения, он не может нарушить совместимость других участников, продолжающих запускать взаимно совместимый код.

Тот же общий вывод можно сделать из устройства таких систем, как Bitcoin: соблюдение правил консенсуса обеспечивают те, кто запускает проверяющий код, а не стоящий над ними институт.

2. Область применения

Этот документ относится к системам интернет-координации, включая, помимо прочего, общие реестры, системы идентификаторов, системы имён и нумерации, механизмы расширения протоколов, системы подтверждения контроля, системы переносимости и другие архитектуры, в которых независимые участники опираются на общую техническую точку отсчёта.

Этот документ не выступает против общих правил. Он утверждает, что общие правила должны быть детерминированными, минимальными, локально проверяемыми и ограниченными тем, что действительно необходимо для работы системы.

Этот документ не требует блокчейна, распределённого реестра или какой-либо конкретной технологии. Он требует определённого свойства архитектуры: участники должны иметь возможность определять корректность, применяя Исходную спецификацию локально, без обращения к постоянно действующему органу власти за разрешением или подтверждением статуса.

3. Условные обозначения и определения

3.1. Язык требований

Термины требований, выделенные в этом документе прописными буквами, следует понимать в смысле, определённом BCP 14, а именно RFC 2119 и RFC 8174.

3.2. Терминология

Исходная спецификация:
Совокупность правил, структур данных, форматов, инвариантов, процедур проверки и правил перехода, необходимых для первого развёртывания системы.

Общий слой:
Минимальный общий набор правил или опорная структура, необходимые для взаимодействия независимых участников. Общий слой — не институт. Это техническое содержание, которое участники реализуют и проверяют.

Детерминированное правило проверки:
Правило, позволяющее участнику путём локальных вычислений или локальной проверки определить, соответствует ли состояние, запись, переход, утверждение или сообщение заданному набору правил.

Глобальный инвариант:
Свойство, которое должно оставаться общим внутри группы совместимости, чтобы сохранялись уникальность, базовая совместимость, общая безопасность или защищённость.

Участник:
Оператор, реализация, узел, сеть, организация или иной субъект, который обеспечивает работу системы, проверяет её, развёртывает её или опирается на неё.

Группа совместимости:
Группа участников, реализованные правила проверки которых позволяют им взаимодействовать. Последующее изменение может создать новую группу совместимости, если одни участники внедряют его, а другие — нет.

Внедрение:
Фактическая реализация, развёртывание, проверка и использование участниками, обеспечивающими работу системы.

Отказ от внедрения:
Решение участника не реализовывать или не использовать предлагаемое изменение. Отказ от внедрения не придаёт участнику статуса некорректного. Он означает лишь, что участник не присоединился к группе совместимости, созданной этим изменением.

Локальное отклонение:
Локальное решение участника игнорировать, отклонить или не взаимодействовать с состоянием, сообщением, записью или переходом, которые некорректны или несовместимы с применяемыми им правилами проверки.

Ответвление:
Расхождение в правилах проверки или практике эксплуатации, создающее две или более группы совместимости.

Координационный материал:
Документ, запись в реестре, рекомендация, примечание к реализации, профиль, эталонная реализация или иной материал, помогающий участникам координировать работу. Координационный материал не создаёт обязательной для исполнения эксплуатационной реальности, если участники не внедрили его в работающие системы.

4. Постановка проблемы

Разработчики часто пытаются уменьшить неопределённость будущего, закладывая слишком многое в исходный слой системы или оставляя постоянно действующему органу право толковать будущие вопросы. Это кажется предусмотрительным. Нередко это опасно.

Избыточная детализация исходного слоя имеет три издержки.

Во-первых, она переносит будущий выбор в общий слой, где изменения проводить труднее, а захват контроля имеет более серьёзные последствия.

Во-вторых, она размывает границу между технической корректностью и институциональным признанием.

В-третьих, она побуждает орган, ведущий записи, публикующий документы или собирающий участников, считать эти действия основанием для власти над будущей реальностью.

Та же проблема возникает после развёртывания. Если система требует, чтобы постоянно действующий орган утверждал изменения, определял статус или толковал обычную работу, значит, в ней создан слой контроля, действующий после её учреждения. Этот слой может начинаться с администрирования. Затем он может превратиться в управление. А потом — в узкое место, через которое приходится проходить всем.

Цель проектирования, предложенная в этом документе, — не повысить качество решений, принимаемых институтами по своему усмотрению. Цель — избежать самой необходимости в таком усмотрении.

Хорошо спроектированная система интернет-координации должна с самого начала определять детерминированные, локально проверяемые правила корректности; оставлять за пределами общего слоя решения, не относящиеся к инвариантам; и позволять последующим изменениям становиться реальностью только тогда, когда участники добровольно внедряют их в работающие системы.

5. Принцип 1: Минимальная исходная спецификация

5.1. Формулировка

Исходной спецификации СЛЕДУЕТ определять только минимальные детерминированные общие правила, необходимые для базовой совместимости, уникальности, общей безопасности и защищённости.

5.2. Требования

Архитектура, использующая этот принцип:

1. ДОЛЖНА явно определять свои Глобальные инварианты.
2. ДОЛЖНА определять детерминированные правила проверки для каждого Глобального инварианта.
3. НЕ ДОЛЖНА включать правило в Исходную спецификацию, если оно не требуется для сохранения заявленного Глобального инварианта или для первого развёртывания.
4. ДОЛЖНА отделять правила проверки от предпочтений в области политики, деловых договорённостей, институциональных ролей, притязаний на управление и суждений по усмотрению.
5. ДОЛЖНА позволять участникам проверять корректность в ходе обычной работы локально, не обращаясь к какому-либо институту, оператору реестра, комитету, органу выработки политики или иному органу власти.
6. СЛЕДУЕТ определять структуры данных, подписи, доказательства, правила перехода состояний, правила разрешения конфликтов или другие механизмы, необходимые для локальной проверки.
7. СЛЕДУЕТ определять сигнализацию расширений, управление версиями, обозначение совместимости или идентификацию ответвлений там, где можно предвидеть будущие различия.
8. ДОЛЖНА обеспечивать переносимость, проверяемость, воспроизводимость и заменяемость необходимых координационных материалов.
9. СЛЕДУЕТ отдавать предпочтение объективным, машинно проверяемым условиям перед субъективной оценкой достоинств.
10. НЕ ДОЛЖНА делать будущее институциональное признание единственным способом установить, зафиксировать или использовать корректное состояние.

5.3. Следствия для проектирования

Минимальная исходная спецификация не означает расплывчатой спецификации. Она означает строгое описание только того, что должно быть общим.

Системе по-прежнему нужна общая структура, достаточная для работы. Задача состоит в том, чтобы различать:

– то, что должно быть общим ради уникальности, совместимости, общей безопасности и защищённости; и
– то, что может оставаться за пределами общего слоя, поскольку относится к предпочтениям операторов, деловой практике, срокам развёртывания или последующему выбору внедрять либо не внедрять изменение.

Если при проектировании невозможно чётко назвать Глобальные инварианты и детерминированные правила проверки, следует исходить из того, что в архитектуру заложено слишком много усмотрения и слишком мало проверяемого содержания.

6. Принцип 2: Дальнейшие решения на уровне участников

6.1. Формулировка

После принятия Исходной спецификации Дальнейшим решениям СЛЕДУЕТ оставаться на локальном уровне участников, запускающих программный код. Дальнейшее решение действует только в той группе совместимости, участники которой его внедряют. Для его утверждения не требуется постоянная власть, а отказ от внедрения не придаёт участнику статуса некорректного.

6.2. Требования

Архитектура, использующая этот принцип:

1. НЕ ДОЛЖНА требовать от участников разрешения действующего института, оператора реестра, комитета, правления, органа выработки политики или иного органа власти на решения, которые не меняют детерминированных правил проверки в группе совместимости, к которой они принадлежат.
2. НЕ ДОЛЖНА создавать постоянный орган, признание которого служит единственным способом превратить последующее изменение в эксплуатационную реальность.
3. ДОЛЖНА различать корректность по Исходной спецификации и совместимость с последующим необязательным изменением.
4. НЕ ДОЛЖНА считать отказ от внедрения последующего изменения некорректностью.
5. ДОЛЖНА позволять участникам оставаться в существующей группе совместимости, если они не внедряют последующее изменение.
6. ДОЛЖНА позволять участникам присоединяться к новой группе совместимости путём внедрения новых правил проверки или эксплуатационных профилей.
7. ДОЛЖНА позволять участникам локально отклонять состояния, записи, переходы или сообщения, которые некорректны или несовместимы с применяемыми ими правилами проверки.
8. НЕ ДОЛЖНА уполномочивать какой-либо институт, оператора реестра, комитет, орган выработки политики или иного субъекта объявлять участника некорректным лишь потому, что он отказался от последующего изменения.
9. СЛЕДУЕТ явно обозначать ответвления, версии, профили или группы совместимости, чтобы участники знали, по каким правилам они работают и с какими другими участниками могут взаимодействовать.
10. СЛЕДУЕТ избегать любой архитектуры, в которой действующий хранитель записей может помешать участникам, в остальном соответствующим правилам, продолжать взаимодействовать.

6.3. Следствия для проектирования

Принцип Дальнейших решений на уровне участников не означает, что центральная власть распределяет будущие решения между локальными субъектами. Он означает, что система устроена так, чтобы после принятия Исходной спецификации обычные дальнейшие решения не требовали подобного распределения.

Исходная спецификация заранее устанавливает необходимые ограничения. Она определяет минимальные инварианты, требуемые для уникальности, совместимости, общей безопасности и защищённости. Всё остальное остаётся за пределами общего слоя.

Будущие изменения не утверждаются централизованно. Участники, запускающие программный код, внедряют их, игнорируют, создают на их основе ответвления или отказываются от них.

Участник, отказавшийся от изменения, может остаться за пределами группы совместимости, созданной этим изменением. Он может отключиться от других. Может продолжить работу в более старой группе совместимости. Может создать ответвление. Может взаимодействовать избирательно. Но он не может нарушить совместимость других участников, продолжающих работать по взаимно совместимым правилам.

Последствием некорректного или несовместимого состояния становится локальное отклонение, а не наказание. Никому не нужно решать, что участник утратил надлежащий статус. Участник, применяющий совместимые правила проверки, просто не принимает некорректное или несовместимое состояние.

7. Принцип 3: Добровольное внедрение

7.1. Формулировка

Изменениям в системе интернет-координации СЛЕДУЕТ становиться эксплуатационной реальностью через реализацию, проверку, развёртывание и внедрение участниками, а не посредством одной лишь публикации или декларации.

7.2. Требования

Архитектура, использующая этот принцип:

1. НЕ ДОЛЖНА считать публикацию, регистрацию, рекомендацию, одобрение на собрании или процедурное утверждение достаточным основанием для возникновения всеобщего обязательства при эксплуатации.
2. ДОЛЖНА позволять участникам, решившим применять новые правила, расширения, профили или процедуры, развёртывать их постепенно.
3. ДОЛЖНА позволять участникам отказываться от последующего изменения, не получая статуса некорректных, пока их собственные переходы состояний соответствуют детерминированным правилам проверки их группы совместимости.
4. ДОЛЖНА позволять участникам продолжать использовать более старую группу совместимости там, где Исходная спецификация допускает такую непрерывность работы.
5. ДОЛЖНА позволять участникам одной группы совместимости локально отклонять или игнорировать состояние из другой группы совместимости, если правила несовместимы.
6. СЛЕДУЕТ определять способы внедрения крупных изменений, включая сигнализацию версий, обозначение совместимости, рекомендации по переходу и тестовые векторы.
7. СЛЕДУЕТ определять способы отказа от крупных изменений, включая то, как участники, не внедряющие их, продолжают работу, обозначают свою группу совместимости и избегают неоднозначности при взаимодействии.
8. ДОЛЖНА обеспечивать возможность отказаться от использования необходимых координационных материалов, перенести их, создать их зеркала, реализовать их заново или заменить без непосильных затрат на переход.
9. СЛЕДУЕТ предусматривать, чтобы реестры, записи, рекомендации и координационные материалы описывали уже внедрённую реальность, а не объявляли ещё не внедрённую будущую реальность существующей.
10. ДОЛЖНА избегать устройства системы, при котором изменение может стать реальностью только после предварительного признания действующим органом.

7.3. Следствия для проектирования

Добровольное внедрение — это проверка на практике: полезно ли изменение, приемлемо ли оно и совместимо ли с реальным развёртыванием.

Предложение — ещё не реальность. Рекомендация — ещё не реальность. Обновление реестра — ещё не реальность. Документ — ещё не реальность. Реальность возникает, когда участники реализуют изменение, проверяют его, развёртывают и опираются на него в работе.

Отказ от внедрения не создаёт статуса нарушителя. Он создаёт лишь факт: участник не присоединился к группе совместимости, возникшей благодаря изменению.

Это не упраздняет процессы стандартизации, реестры, документацию или рассмотрение предложений. Это ограничивает их притязания. Они могут помогать участникам координировать работу. Могут публиковать справочные материалы. Могут описывать внедрение. Могут рекомендовать. Но одной лишь декларацией они не могут сделать ещё не внедрённую будущую реальность обязательной для участников, которые её не применяют.

8. Связь между тремя принципами

Эти три принципа усиливают друг друга и не действуют эффективно по отдельности.

Минимальная исходная спецификация обеспечивает, чтобы общий слой содержал детерминированные правила проверки, а не власть решать по своему усмотрению.

Дальнейшие решения на уровне участников обеспечивают, чтобы будущий выбор оставался за участниками, запускающими программный код, а не переходил вновь под контроль центрального слоя утверждения.

Добровольное внедрение обеспечивает, чтобы последующее изменение выдержало проверку реализацией и использованием.

Система, принимающая лишь один или два из этих принципов, может воспроизвести ту же централизацию иными средствами.

– Минимальная исходная спецификация без Дальнейших решений на уровне участников всё ещё может допустить накопление власти после развёртывания.
– Дальнейшие решения на уровне участников без Минимальной исходной спецификации могут породить неоднозначность, поскольку участники не могут локально определить корректность.
– Добровольное внедрение без детерминированной проверки может породить путаницу, поскольку участники не могут отличить совместимый вариант от некорректного состояния.
– Детерминированная проверка без возможности выхода, переносимости или заменяемости всё ещё может создать зависимость, если от материалов, обеспечивающих ведение записей, становится невозможно отказаться.

Вместе эти принципы дают систему, в которой общий слой остаётся тонким, корректность проверяется локально, дальнейшие изменения добровольны, а для решения вопросов обычной работы не нужен постоянный институт.

9. Рекомендуемый подход к проектированию

9.1. Детерминированный общий слой

Общий слой СЛЕДУЕТ ограничить следующим:

– стабильная семантика идентификаторов;
– детерминированные правила корректности;
– правила разрешения конфликтов, необходимые для сохранения уникальности;
– требования совместимости на уровне передачи данных или протокола;
– общие инварианты защищённости;
– механизмы подтверждения контроля, если они необходимы;
– переносимые и пригодные для аудита форматы записей, если записи необходимы;
– сигнализация расширений и идентификация групп совместимости.

В общий слой НЕ СЛЕДУЕТ включать:

– правила бизнес-модели;
– правила ценообразования;
– региональные политические предпочтения;
– идеологию допуска к участию, не связанную с техническими инвариантами;
– полномочия применять принудительные меры по усмотрению;
– субъективные оценки достоинств;
– расширение миссии института;
– любое правило, основная функция которого состоит в сохранении власти действующего органа.

9.2. Круг решений оператора

Следующие вопросы СЛЕДУЕТ оставлять за пределами общего слоя, если они непосредственно не меняют заявленный Глобальный инвариант:

– сроки развёртывания;
– коммерческое использование;
– география клиентов;
– условия аренды, финансирования или передачи;
– локальные предпочтения относительно допуска к участию;
– последовательность эксплуатационных действий;
– практика маршрутизации, не требуемая для общей корректности;
– бизнес-модель;
– организационная структура;
– сроки добровольного перехода;
– необязательные профили или расширения.

Участники МОГУТ принимать разные решения в этих областях. Такие решения могут создавать разные группы совместимости, деловые отношения, пиринговые договорённости или сообщества операторов. Они не означают некорректности, если не нарушают детерминированных правил проверки в группе совместимости.

9.3. Цикл внедрения

Там, где это осуществимо, для существенного изменения системы предпочтителен следующий порядок:

1. предложение;
2. реализация;
3. тестовые векторы или детерминированный метод проверки;
4. ограниченное развёртывание участниками, желающими внедрить изменение;
5. наблюдение за влиянием на совместимость и защищённость;
6. обозначение группы совместимости;
7. документация или рекомендация, описывающая внедрённую реальность.

Координационному материалу СЛЕДУЕТ следовать за внедрением, а не пытаться предрешить его.

9.4. Выход, ответвление и переносимость

Архитектуре, соответствующей этому документу, СЛЕДУЕТ рассматривать выход, ответвление и переносимость как обычные требования к проектированию, а не как неудачи.

Системе СЛЕДУЕТ определять, как участник может:

– продолжать работу в более старой группе совместимости;
– перейти в более новую группу совместимости;
– создать ответвление с другой группой совместимости;
– перенести записи, идентификаторы, доказательства или эксплуатационное состояние;
– проверить корректность записей, не полагаясь на действующего хранителя записей;
– взаимодействовать избирательно там, где это допускает совместимость.

Если выход из системы или создание ответвления невозможны без разрушения корректной работы, вероятно, система спрятала власть управления внутри функции ведения записей.

10. Применимость и ограничения

Этот подход к проектированию особенно применим там, где:

– система объединяет множество субъектов и юрисдикций;
– важно независимое развёртывание;
– координационный слой должен оставаться тонким;
– будущие различия вероятны, но их невозможно предсказать в деталях;
– зависимость от системы создала бы риск в области управления;
– корректность можно сделать детерминированной или локально проверяемой.

Он может быть менее непосредственно применим там, где:

– предполагаемая архитектура представляет собой единый административный домен;
– тесная связь в реальном времени требует единообразного поведения в каждый момент;
– требования защиты жизни требуют немедленного глобального единообразия;
– корректность нельзя проверить локально никаким практически осуществимым механизмом.

Даже в таких случаях разработчикам всё же СЛЕДУЕТ минимизировать общий слой и по возможности избегать будущего контроля по усмотрению.

11. Что не является целью документа

Этот документ:

– не запрещает любую координацию;
– не запрещает все общие реестры;
– не требует блокчейна или технологии распределённого реестра;
– не гарантирует консенсуса;
– не гарантирует политической нейтральности;
– не требует, чтобы все участники внедряли каждое последующее изменение;
– не считает отказ от внедрения некорректностью;
– не оправдывает несовместимое локальное поведение при одновременном заявлении о совместимости;
– не устраняет необходимость в общих правилах, критически важных для защищённости.

12. Вопросы защищённости

Более тонкий координационный слой может снизить риск захвата контроля, сократить масштаб последствий институциональной ошибки и облегчить замену. Однако более широкая свобода локальных решений может также привести к разному уровню защищённости, появлению способов перехода к менее защищённым вариантам, давлению в сторону фрагментации, неоднозначным заявлениям о совместимости и небезопасным ответвлениям.

Поэтому разработчики, применяющие этот документ, ДОЛЖНЫ явно определять инварианты защищённости. В частности:

– требования аутентификации и авторизации, необходимые для общей корректности, ДОЛЖНЫ быть детерминированными и локально проверяемыми;
– согласование версий и обработка расширений ДОЛЖНЫ предотвращать незаметный переход к менее защищённому варианту там, где это влияет на защищённость;
– способы отказа, создания ответвления и замены ДОЛЖНЫ анализироваться на предмет злоупотреблений и риска отказа в обслуживании;
– обозначения совместимости СЛЕДУЕТ делать достаточно ясными, чтобы предотвращать случайное взаимодействие между несовместимыми наборами правил;
– локальным вариантам НЕ ДОЛЖНО быть позволено ложно заявлять о совместимости с набором правил, которому они не соответствуют.

Наличие исключений, связанных с защищённостью, не оправдывает общий слой разрешений. Оно оправдывает только детерминированные правила защищённости, необходимые для сохранения заявленных Глобальных инвариантов.

13. Вопросы IANA

Этот документ не предусматривает действий со стороны IANA.

14. Ссылки

14.1. Нормативные ссылки

– RFC 2119 — Bradner, S., Ключевые слова для обозначения уровней требований в RFC, BCP 14, RFC 2119.
– RFC 8174 — Leiba, B., Неоднозначность употребления прописных и строчных букв в ключевых словах RFC 2119, BCP 14, RFC 8174.

14.2. Информационные ссылки

– RFC 6709 — Carpenter, B. и B. Aboba, Вопросы проектирования расширений протоколов, RFC 6709.
– RFC 7282 — Resnick, P., О консенсусе и гудении в IETF, RFC 7282.

Приложение A. Контрольные вопросы для проектирования

Архитектуре, заявляющей о соответствии этому документу, СЛЕДУЕТ давать ясные ответы на следующие вопросы:

1. Каковы Глобальные инварианты?
2. Какие детерминированные правила проверки сохраняют эти Глобальные инварианты?
3. Какие правила Исходной спецификации строго необходимы для первого развёртывания?
4. Какие будущие вопросы намеренно оставлены за пределами общего слоя?
5. Какие дальнейшие решения участники могут принимать, не меняя группу совместимости, в которой они находятся?
6. Как участник внедряет последующее изменение?
7. Как участник отказывается от последующего изменения, не получая статуса некорректного?
8. Как обозначаются или обнаруживаются группы совместимости?
9. Как действует локальное отклонение, если состояние некорректно или несовместимо с применяемыми участником правилами?
10. Как создаётся ответвление?
11. Как обеспечивается переносимость?
12. Как можно отказаться от использования любого необходимого координационного материала?
13. Могут ли участники проверять корректность в ходе обычной работы, не полагаясь на действующего хранителя записей?
14. Описывают ли записи и координационные материалы уже внедрённую реальность или пытаются объявить ещё не внедрённую будущую реальность существующей?
15. Сведено ли к минимуму число решений, заложенных в общий слой системы?
16. Удалось ли системе избежать какой-либо постоянной власти, определяющей статус участников в ходе обычной работы?

Адрес автора

H. Lu