Кратко

  • Charleston Road Registry предлагает проверять одну из четырёх форм участия в MCP как условие регистрации домена .mcp.
  • Предлагаемый .MCP Policy Council получит право согласовывать изменения правил, но публичная заявка не объясняет, как формируется совет и как обжаловать отказ.

Открытый протокол и доменная зона — разные институты. Model Context Protocol представляет собой технический проект. Если .mcp будет делегирована, регистр будет управлять именами на основании договора. Эти уровни могут дополнять друг друга, однако участие в проекте само по себе не означает право зарегистрировать домен в определённой зоне.

В заявке Charleston Road Registry Inc. (CRR), юридического заявителя Google Registry, перечислены четыре способа получить право на регистрацию: подтвердить документированные вклады в официальные репозитории MCP; управлять активным совместимым MCP-сервером; владеть записью в официальном MCP Registry или представлять её владельца; либо состоять в Agentic AI Foundation (AAIF) с действующим статусом. Заявитель указывает, что оператор регистра будет проверять критерии при содействии .MCP Policy Council. В ответе на вопрос 151 сказано, что менять политику можно только с согласия этого совета.

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

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

Опубликованная структура управления проектом MCP иная. На официальной странице перечислены Steering Group, а также роли Lead, Core и Maintainer. Там говорится, что техническое управление осуществляют отдельные люди, без мест для компаний. .MCP Policy Council на странице не упоминается. Поэтому нельзя считать предлагаемый совет техническим руководством MCP или предполагать, что решения проекта автоматически обязывают доменный регистр. Регистр вправе администрировать договорные условия для выдаваемых им имён, но это не то же самое, что решать, кто может участвовать в разработке протокола, какие реализации ему соответствуют и как он будет развиваться.

Стадию процесса ICANN также важно не преувеличивать. В файле Reveal Day от 7 октября в предварительную группу по .mcp включены CRR, OPENAI OPCO, Radix, ShortDot и Tidal Case. Во всех пяти общедоступных сводках указан статус Active / Pre-Evaluation Processing. Только в сводке CRR публичное поле tldTypes содержит Community. Пустые массивы у остальных четырёх не доказывают, что у них нет аргумента о сообществе. ICANN не считает группы окончательными до завершения оценки строк.

Если CRR сохранит статус Community Application и согласится на Community Priority Evaluation (CPE), результат может повлиять на приоритет в группе. Действующее руководство ICANN определяет CPE как независимую экспертную оценку заявки, претендующей на приоритет в конкурентном наборе. Для неё необходимо завершить соответствующие этапы оценки, возражений и апелляций; предложенные Registry Commitments проходят отдельную проверку. Успешная заявка сообщества может получить преимущество перед заявками без такого статуса. Если пройдут несколько community-заявок, они участвуют в аукционе. Оценка включает четыре критерия, порог — 12 из 16 баллов.

Руководство отделяет существование сообщества от вопроса о приоритете: сообщество обозначает заявитель, а CPE оценивает, заслуживает ли заявка приоритета. Это не голосование о легитимности технических институтов MCP.

Note 72 помогает поставить вопрос, но её нельзя напрямую переносить на доменные регистры. Предупреждение о том, что список рассылки, встреча или политический консенсус сами по себе не создают право собственности или мандат, относится к полномочиям региональных интернет-регистратур в отношении номерных ресурсов. У регистра общего домена верхнего уровня другой договор и другая задача — администрировать регистрации. Здесь уместнее спрашивать, ограничены ли критерии, можно ли понять и оспорить решение и известно ли участникам, кто вправе менять правила.

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

Источники