OQ — открытые вопросы (вопросительные моменты) проекта PKI

ID

Вопрос

дата / Где возник/ статус (автор)

В01

Номер Заявки «Хронограф» и номера её пунктов — в черновиках стоят плейсхолдеры ___ (функции ТЗ: 4.2.2.1 — представление, 4.2.2.5 — обработка, 4.2.2.7 — хранение, 4.2.2.11 — взаимодействие с ВИС). Подставить фактические

ЧТЗ 4.2.2/4.2.3, ПМИ А.2/А.3

-В01-

Впредь использовать:
Создание новой функции (без взаимодействия с внешними ИС) 4.2.1.1
Создание новой функции обработки данных 4.2.1.5
Создание функции взаимодействия с внешними ИС 4.2.1.11

260915 22:13
Решено (А.М.)

-В02-

Состав и порядок подготовки тестовых сертификатов УКЭП для испытаний (издатели, владельцы, периоды действия, дефектные сертификаты)

260928 — ответ (А.Б.): «Список сертификатов для тестирования лучше всего запросить у РТЛабс, а также уточнить их перечень. Я запрошу»

-В03-

Доступ к методам приватного канала сертификатов УЦ на стенде — от имени какого участника выполняются вызовы

260928 — ответ (А.Б.): «Для приватного канала УЦ в зависимости от того, какой канал. У нас три канала, в которых используются методы приватного канала квалифицированных сертификатов: 1. канал аккредитации и сертификатов АУЦ, 2. приватный канал сертификатов ГУЦ, 3. приватный канал квалифицированных сертификатов ИИТ. Таблица с участниками и их правами приведена в документе "Описание реестра аккредитации и сертификатов"»

-В04-

Включать ли проверки А.2 в коллекцию Postman (Приложение А.5.1): текущая коллекция покрывает только проверки А.1

260928 — ответ (А.Б.): «Я думаю A2.1, A2.4–A2.12 нужно включить»

-В05-

Перечень дефектных тестовых сертификатов УКЭП (какие нарушения, какие коды предупреждений); продолжительность фоновых проверок и момент наблюдения isChecked = True

260928 — ответ (А.Б.): «Договорились, формируется массив этих предупреждений без разграничения на коды. Продолжительность фоновых проверок и момент проставления флага isChecked = True мы можем узнать только экспериментально»

-В06-

Подготовка сертификата с неверной подписью; охватывать ли отдельными шагами полную криптографическую проверку цепочки (CHAIN_CRYPTO_*) и запрос списка отозванных сертификатов из локального хранилища; включать ли проверку регистрации корневого сертификата (ERR-0723/0724/0725)

260928 — ответ (А.Б.): «Я думаю не включать. Если будет замечание от заказчика, то в этом случае включить»

В07

Состав цепочки доверия тестовых сертификатов и её влияние на пересечение периодов; включать ли событие «аннулирование» (event = 0) в сценарий

260915
ПМИ А.2.12
открыт (Дис)

-В08-

Состав и порядок подготовки тестовых сертификатов УНЭП

260928 — ответ (А.Б.): «Список сертификатов для тестирования лучше всего запросить у РТЛабс, а также уточнить их перечень. Я запрошу»

-В09-

Поведение при регистрации квалифицированного сертификата в канале УНЭП (маршрутизация проверок по channel_type из REGISTRATION_CHANNEL_POLICY) — включать ли отдельную проверку

260928 — ответ (А.Б.): «Я думаю надо включать»

-В10-

Включать ли проверки А.3 в коллекцию Postman (Приложение А.5.1)

260928 — ответ (А.Б., подтверждён 261001): «Надо включить A3.1, A3.4–A3.12»

-В11-

Для УНЭП в источнике не описана фиксация isChecked = True после фоновых проверок (описано только для УКЭП) — считать ли поведение одинаковым

260928 — ответ (А.Б.): «Поведение считать одинаковым с учетом различий между проверками УКЭП, УНЭП»

-В12-

Проверка регистрации корневого сертификата в канале издателей Госключ (ERR-0723/0724/0725); полная криптографическая проверка цепочки (CHAIN_CRYPTO_*)

260928 — ответ (А.Б.): «Провести функциональную проверку, но в ПМИ не включать»

-В13-

Для УНЭП не описан код ошибки разбора идентификатора cert (у УКЭП — ERR-0731) — проверить фактическое поведение на стенде

260928 — ответ (А.Б., подтверждён 261001): «Ожидаем реализацию»

-В14-

Имя поля типа сертификата УНЭП в записи: модель содержит ownerType (типы владельца), проверки формируют registration_json.owner_type (ROOT_CA/SUB_CA/END_ENTITY) — уточнить фактическое имя поля и множество значений на стенде

260928 — ответ (А.Б.): «По идее root_ca, sub_ca, end_entity, но нужно дождаться реализации»

-В15-

Для УНЭП gherkin алгоритма периодов содержит сценарий «недействующая аккредитация на начало действия», но приложения-алгоритмы и диаграммы УНЭП аккредитацию не используют — уточнить фактическое поведение; включать ли событие «аннулирование» в сценарий

260928 — ответ (А.Б.): «Для УНЭП не должен учитываться параметр "статус аккредитации". Он не участвует в расчете, поэтому связанный сценарий в gherkin надо исключить»

ID

Вопрос

дата / Где возник/ статус (автор)

В16

!ai Дис (гипотеза): блок работ соответствует п. 4.2.4 ТЗ и заголовку-плейсхолдеру «4.2.4 Создание функций маршрутизации запросов…» в ЧТЗ_РР_ОИОК_v02.md; черновик оформлен как этот блок (4.2.4.1–4.2.4.5). Если ЧТЗ по сервисному чейнкоду — отдельный документ со своей нумерацией, блоки перенумеровать

260915
ЧТЗ 4.2.4
открыт (Дис)

В17

Номер и наименование Заявки, обозначения, шифры — плейсхолдеры ___ (в том числе номер пункта Заявки для п. 4.2.4)

260915
ЧТЗ 4.2.4, ПМИ А.4
открыт (Дис)

В18

Наименование документа-основания для обратных ссылок в ПМИ («описание решения, п. 2.1») — уточняется

260915
ПМИ А.4
открыт (Дис)

-В19-

Автоматизация проверок в ПМИ не отражена (коллекции нет); при появлении коллекции методика дополняется ссылками, приложения перенумеровываются (сейчас: Б — протокол, В — акт)

260928 — ответ (А.Б.): «Напрямую методы не используются. Ротация каналов будет проводиться в ручном режиме»

-В20-

Состав проверок А.4.1–А.4.14 предварительный; идеи тестирования (создание коллизий, контрольная сумма, смена версии s_cc, периодическая ротация, недоступность канала) — в диалоге с А.М.

260928 — ответ (А.Б.): «Из возможных проверок для коллизий uuid можно попробовать провести для сертификатов, т.к. серийным номером можно управлять. Но скорее это нужно делать не в рамках ПМИ, а в рамках ручного тестирования. Периодическая ротация — не реализуем на текущий момент»

В21

ПМИ v05: в шаг проверки 6 включено аннулирование/отмена события аккредитации — без него «отменённое событие» в проверках 6 и 10 остаётся без порождающего действия. Допустимо ли такое расширение шага

261001
ПМИ v05
открыт (Дис)

В22

ПМИ v05: изменение/дополнение сведений об УЦ (А.1.2) не покрыто ни одной из десяти проверок. Добавить шаг в проверку 3

261001
ПМИ v05
открыт (Дис)

В23

ПМИ Б.1: в памятке 261007_сс_peer_cli_certs.txt uuid 2e4000b7-7106-72d1-962c-bddab4605cb7 и составной идентификатор 2026-09-28T08:14:51Z;1c91d616… приведены в одной секции «ГУЦ» — ожидаемый результат Б.1 связывает их как одну запись о сертификате. Подтвердить соответствие

261007
ПМИ Б
решено (стенд 08.10: Get вернул id = 2e4000b7…, idCertificate = 1c91d616…, validityNotBefore = 2026-09-28T08:14:51Z)

В24

ПМИ Б.3: событие регистрации сертификата ожидается с кодом 16 (по снимку 261002), тогда как в ЧТЗ v05 и проверках А.4/А.5 — код 1. Какой код каноничен для ПМИ

261007
ПМИ Б
решено (стенд 08.10: GetStatusHistory вернул event = «1»; ПМИ Б.3 поправлен — событие начала действия, код 1)

В25

ПМИ Б: фактическая форма вывода peer chaincode query (обёртка status/message/payload или чистый JSON бизнес-структуры) в источниках не описана; jq-фильтры Приложения Б учитывают оба случая. Подтвердить форму на стенде

261007
ПМИ Б
решено (стенд 08.10: ответ — чистый JSON записи/истории без обёртки; jq-фильтры Б упрощены)

В26

ПМИ Б: в предварительных условиях проверок Б.1–Б.3 требуется интерпретатор jq в окружении вызова (узел admin0.esiapeer.ru). Подтвердить наличие jq на стенде

261007
ПМИ Б
решено (стенд 08.10: jq в окружении узла работает, прогоны Б.1–Б.3 выполнены с jq)

В27

Сверка ЧТЗ v05 и ПМИ А.1–А.10 с обновлёнными источниками — 13 вопросов к А.М. (В-1…В-13: канон endpoint'ов, событие регистрации 1/16, вариант ответа by-date, битовый состав идентификатора, модель ответа на создание, закрепление uuid через RegistryContract, маршрутизация по ОГРН, интерфейс и поля проверки А.7, состав параметров reason, тип сертификата УНЭП, коды ошибок публичного канала, аннотации рецензента, CHAIN_CRYPTO_*) — полные формулировки в разделе 3 отчёта work/ps01/сверка_с_обновлёнными_источниками.md

261007
сверка
открыт (Дис)

ID

Замечание

И01

УНЭП: модель приватного канала содержит ownerType (типы владельца), а проверки п. 4.1.2 формируют registration_json.owner_type ∈ {ROOT_CA, SUB_CA, END_ENTITY, null}. Имя поля и множество значений не согласованы

И02

УНЭП, п. 4.7.3 (END_ENTITY): первое условие записано «Если _id=issuerUUID» — противоречит признаку некорневого сертификата (в 4.7.2 корректно «_id≠issuerUUID»). Вероятная опечатка

И03

УНЭП и аккредитация: gherkin п. 4.2.4 содержит сценарий «1.6 Недействующая аккредитация на начало действия», но приложения-алгоритмы, диаграммы 4.2.3.1/4.2.4.1 и итоговый результат УНЭП аккредитацию не используют; в таблице 20 при этом сохранено поле accreditatioStatus. Что считать правильным — требует решения

И04

УНЭП: фиксация isChecked = True и запуск переноса статуса в публичный канал после фоновых проверок описаны только для УКЭП (примечание 8 к п. 3.1.3); у УНЭП аналога нет, при том что публичный канал использует isChecked

И05

Переходы по статусной модели (таблица 7 = таблица 17): смысл групп строк («Предыдущее изменение статуса», «Последующее изменение статуса», «Изменение статуса отсутствует») и порядок применения матрицы не расшифрованы

И06

Причины 11 и 16: упомянуты в gherkin-сценариях («причина 11» с событием 0; «причина 16» с событием 1), расшифровок в документе нет; в диаграмме статусной модели причины 0–10 (без 7)

И07

Идентификаторы (п. 5.2): (а) разрядность идентификатора издателя: 24 бита в п. 5.2 против «32 старших значащих бита» в таблице 25; (б) сумма бит: 74 LSB заявлены, составляющие 4+12+2+62 = 80 бит; (в) cert_id_hash_algorithm определён как «хэширование TBS», а п. 5.2 хэширует serialNumber; (г) шаг 1.7.3 процесса формирует _id по serialNumber + validityNotBefore + Issuer.OGRN — не согласован с п. 5.2; (д) ссылка «Идентификатор реестра назначается согласно таблице 23» — вероятна ошибка ссылки

И08

Аннотации рецензента в тексте документа (С. Лебедева, 23.08.2026): критика формата идентификатора («Критично. Переделать… externalID»); вопрос порядка переноса в публичный канал — до или после фоновых проверок («Критично»); отсутствие basic constraints в модели расширений; «Договорились добавить сюда еще PKUP» (таблица 9). Требуют решения — учесть в ЧТЗ или снять

И09

Таблица 26 (типы записей): колонка keyDateTimeSrc пустая для КСКПЭП и НСКПЭП; размещение сервисного чейнкода (канал, узел) не описано

И10

Таблица 24 (методы формирования UUID): только getUUIDFromCertificate — методы для УЦ и ЭП в документе отсутствуют (вне объёма?)

ID

Замечание

И11

Дубли номеров таблиц: «Таблица 5» (соотношение полей и коды ошибок), «Таблица 8» (логическая отмена и поиск по фильтру), «Таблица 14» (периоды); в главе 4 — «Таблица 19» и «Таблица 20» дважды; подписи не соответствуют содержанию («Таблица 8. Коды ошибок создания записи…» под методом поиска; «Таблица 20. Коды ошибок создания записи…» под методом поиска УНЭП)

И12

Глава 2 (статусная модель) — только диаграмма, текстового описания нет; нумерация процесса п. 3.1.3.1 начинается с пункта 2

И13

Текст vs диаграмма 3.1.3.2: запрос списка отозванных сертификатов из локального хранилища описан только на диаграмме; условие ветки криптографических проверок на диаграмме ошибочно («Отсутствие родительских сертификатов»)

И14

Опечатки: «Приватныe каналs» (п. 4.1), accreditatioStatus (таблицы 12/20; в JSON — accreditationStatus), «полек указывается как target_cert» (таблица 12), validNotBefore (диаграмма 4.2.4.1), subjectPublicKeylnfo (l вместо I)

И15

Артефакты копирования УКЭП→УНЭП: диаграмма 4.2.4.1 («Получение периодов действия аккредитации»), эндпоинт GET /qual-certificates/... в п. 4.1.5, комментарии к /certificate/unqual/*-методам «в приватных каналах квалифицированных сертификатов» (пп. 4.1.2.3, 4.1.3.3)

И16

Имя поля версии истории: versionStatus в модели, version в примере ответа метода изменения статуса (УКЭП); versionStatus в ответе УНЭП

И17

JSON-примеры документа синтаксически некорректны (двойные скобки, пропущенные/лишние запятые) — как эталон тестовых данных использовать нельзя

И18

Приложение «Правила определения типов владельца»: не описывает значение null; регистр констант (UPPER) не совпадает с моделями (lower)

И19

Приложение «Правила регистрации сертификатов в канале»: не содержит терминов КСКПЭП/НСКПЭП и правила для самоподписанных сертификатов; перечень ОГРН ГУЦ/ФК/ЦБ/ФНС в приложении отсутствует (есть только в проверке п. 4.9.2 и на диаграмме «Разделение сертификатов по каналам»)

И20

Диаграммы алгоритмов (приложения, стр. 127–130): пустой блок цикла, ветвление без «Да/Нет», «reason==1 ИЛИ 3» vs «event==1 ИЛИ 3». Алгоритмы существуют только в виде изображений

ID

Замечание

И21

Отказ при регистрации квалифицированного сертификата в канале УНЭП (есть только маршрутизация проверок по channel_type из REGISTRATION_CHANNEL_POLICY; значения: «квалифицированный» / «unqcert_qoskey»)

И22

Коды ошибок для некорректного параметра time в методе «статус на дату» (для обоих типов)

И23

Поведение при исчерпании значений идентификатора реестра и прочие вопросы сервисного чейнкода — частично перекрываются ЧТЗ 4.2.4

И24

Значение «MAC-адрес с дополнением» в структуре _id (п. 5.2)

ID

Замечание

И25

Коды ошибок не определены — ни одного кода ошибки, перечня отказов, реакции на некорректные данные (превышение registryID 31, отсутствие реестра для актива, повторная регистрация). Все негативные ветки ПМИ — с пометкой

И26

Форматы запросов/ответов не определены — аргументы методов заданы обобщённо («an asset as JSON»); форматы полей, обязательность, ограничения не приведены; REST-эндпоинты чейнкода не описаны (способ вызова в ПМИ — нейтрально: «средства вызова методов сервисного чейнкода»)

И27

Формат даты и времени не установлен — поля dateTimeOpened/dateTimeClosed не привязаны к RFC 3339

И28

Расхождение по типам актива — таблица assetType (1–4) против описания GetAssetType («УЦ, СКПЭП, ЭП», диапазон 0..7); термины КСКПЭП/НСКПЭП против «СКПЭП»; OGRN/ОГРН смешаны

И29

Расхождение по границе ротаций — SetRegistry «registryID + 1 (<=31)» против «32 ротации» в п. 2.1 и таблице 6: 32 значения (0–31) = 31 ротация + первичная регистрация либо 32 ротации; поведение при исчерпании не описано

И30

RecordID не описан — возвращается GetRegistersByIssue, в составе БД (п. 2.1) отсутствует; связь с registryID не установлена

И31

Контрольная сумма UUID — формулировка «побитовая сумма последующих триад для последующих 42 бит» неоднозначна; поведение при несоответствии не описано

И32

«Ключевая дата» актива не определена — какая дата ключевая для каждого типа актива, не указано

И33

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

И34

Версионирование s_cc — порядок смены версии, влияние на ранее сформированные идентификаторы и состав признаков типов не описаны

И35

Периодическая ротация — периодичность не определена; каналы в таблице 1 поименованы обобщённо, без привязки к именам из п. 1.1

И36

Две несогласованные схемы именования каналов — п. 1.1 (mcc, mcc_priv, iit_acc_priv…) против приложения (mcc_0, mccpriv_0, aca-1_priv_0 … с индексом поколения); правило формирования имён не задано

И37

Механизм миграции не описан — состав действий по миграции (кроме регистрации канала в s_cc) и судьба идентификаторов активов при ротации не раскрыты

И38

Участники и топология — s_cc развёрнут у каждого участника (по схеме приложения), но требования к размещению service_cc у участников в тексте отсутствуют

ID

Замечание

И39

POST /certificate/qual/create в swagger отсутствует (есть только /certificate/guc/create) — в ЧТЗ метод создания записи квалифицированного сертификата есть

И40

Маршруты goskey/unqual в swagger — заглушки «ARCHIVES-285» (ответы пустые, без обращения к чейнкоду) — проверки А.2/А.9 ПМИ на текущей сборке невыполнимы

И41

Коды ошибок swagger расходятся с таблицами ЧТЗ: ERR-0733/ERR-1414 против ERR-0729; ERR-0734 (ЧТЗ, таблица 3) в swagger отсутствует. Стенд (08.10): публичный канал фактически вернул ERR-1414 «Отсутствует сертификат» — код совпадает со swagger, текст — с ERR-0729 ЧТЗ

И42

hashTBS: swagger — sha256; ЧТЗ — ГОСТ Р 34.11-2012

И43

Имя метода отмены сертификата ГУЦ: swagger POST /certificate/guc/cancel против certificate-cancel в ЧТЗ

И44

Лишний параметр accreditationID в GET /ca/{ogrn}/accreditation/by-date (swagger) — в ЧТЗ не предусмотрен

И45

Авторизация не согласована: ПМИ — x-api-key; swagger — Authorization (AUTH_ENABLED); новая коллекция — без заголовков; старая АКК — Bearer; ни один запрос коллекции ключ не передаёт

ID

Замечание

И46

Коллекция RR-PKI: 10 из 22 маршрутов — прежний контракт, отсутствующий в swagger (/certificate/create, /certificate/{id}/public-update, /certificates-validity/…, /user/{id}/check/by-date, /certificate/{id}/public, /registry/set, /digital-signature/*)

И47

Тело «[7] accreditation cancel event» — version вместо accreditationID+canceledAt; «[6] certificate update» — событие "13" вне статусной модели; GET-запросы коллекции — с JSON-телами

И48

JSON-модели создания сертификата в коллекции вместо входа {certificate: PEM} по ЧТЗ; опечатка subjectPublicKeylnfo (l вместо I)

И49

Bruno-отчёт r1/260915_bruno_report_АКК.html — пустой шаблон отчёта, фактических данных прогона нет

ID

Замечание

И50

Endpoint'ы переименованы в снимке 261002: /guc-certificates/guc/*, /qual-certificates/qual/*, /goskey-certificates/goskey/*, /certificates/unqual/*, qual-certificate-validity/qual/* (НСКПЭП-validity — без изменений). В ЧТЗ/ПМИ — прежние пути по swagger (/certificate/qual/* и т.д.). В пп. 4.1.4/4.1.5 снимка префиксы остались старыми; пример GET /certificate/qual/search сосуществует с таблицей /qual-certificates/ search…. Какой набор каноничен — вопрос А.М.

И51

Событийная модель противоречива: при регистрации event = 16, в таблицах 4/10 коды событий 0–3; причинная модель 0–16 без расшифровок 4–11; «аннулирование» — то код 0, то причина 11 (З-4)

И52

Ответ «на дату» — два несогласованных варианта (certId/localStatus/accreditationStatus/privateKeyStatus/isChecked против cert/event/valid/privateKeyStatus); privateKeyStatus то boolean, то строка «Действует»; ключ " privateKeyStatus" — с ведущим пробелом; в НСКПЭП-таблице строка accreditatioStatus при том, что аккредитация УНЭП не используется (З-6)

И53

Слитые коды ошибок в таблицах публичного канала: «ERR-072914», «ERR-07140729»; коды для параметра time отсутствуют; текст ERR-0728 склеен с ERR-0727 (З-5)

И54

ERR-0731 («Ошибка разбора идентификатора cert») в таблице логической отмены НСКПЭП отсутствует (только ERR-0010, ERR-0730) — расхождение с КСКПЭП

И55

Методы UserCertificateContract:Get/GetPublic/GetStatusHistory, RegistryContract, имена каналов (mca-channel, aca-pub-channel, iit-aca-priv-channel-2) и чейнкодов, передача параметров через --transient/Args — в снимке отсутствуют полностью; только в памятке 261007_сс_peer_cli_certs.txt и диаграммах (З-16)

И56

Формат ответа чейнкода (обёртка status/message/payload, кодирование payload) в снимке не описан — jq-фильтры Приложения Б ПМИ построены с учётом обоих вариантов (обёртка/чистый JSON)

И57

Внутренние методы публичного канала (3.2.2–3.2.4) без кодов ошибок и таблиц ответов; ретранслятор описан противоречиво между разделами (3.2.2 vs 3.2.3 vs 4.2) (З-17, З-18)

И58

«Модель без истории статусов» канала ГУЦ (из памятки 261007) и «закрепление uuid отдельной транзакцией» (из диаграмм) в снимке отсутствуют (3.6, З-16)

И59

Аннотации рецензента (11 шт., 23.08.2026) в снимке сохранены без ответов: externalID='validityNotBefore;hashTBS', момент попадания записи в публичный канал («до» или «после» фоновых проверок), PKUP в таблице 9 и др. — требуют решения в ЧТЗ (З-15)

ID

Замечание

И60

Шаги ротации в сценарии не зафиксированы командами («Выполняется ротация, демонстрация в консоли») — команды ротации только в памятке 261007_сс_peer_cli_certs.txt (peer CLI)

И61

Расхождение дат в заголовках разделов: 5.1/6.1/7.1 — «от 28.09.26» при сертификате от 29.09.26; 6.2/7.2 — «от 01.10.26» при сертификате от 02.10.26

И62

Механизм переключения маршрута после ротации (как REST-прокси определяет новый канал) в источниках не описан

И63

Модели POST/GET различаются: состав warnings при создании и при чтении разный (PUBLIC_KEY_DUPLICATE — только при чтении)

И64

В памятке 261007 сертификат, внесённый до ротации, запрашивается в канале iit-aca-priv-channel-2 (!ai пометка в конспекте). Стенд (08.10): канал iit-aca-priv-channel-2 отсутствует; проверены все 7 каналов узла (iit-aca-priv-channel, goskey-priv-channel, aca-pub-channel, ca-pub-channel, goskey-issuer-channel, mca-channel, mca-priv-channel) — запись 264002a1 не найдена ни в одном (private: not found в goskey-priv и iit-aca-priv; public: not found / ERR-1414) — памятка устарела, до-ротационные данные утрачены при пересоздании стенда (история ГУЦ записана 07.10)

И65

В схеме приложения 260714 подпись ca-1_pub вместо ca-2_pub для УЦ-2 (проверено по изображению); прочие сценарии прежнего набора диаграмм (ЕСИА, публикация, статусная модель, периоды) не обновлены; механизм межканального вызова чейнкодов в новых диаграммах не описан

И66

Имена поля хэша TBS различаются по методам (стенд 08.10): приватная запись (Get) — idCertificate и tbsHash; публичная копия (GetPublic) — hashTBS (как в табл. 9 снимка); в снимке модель приватного канала — _id/hashTBS. Единый канон имён не установлен