Внимание! Соединение с приложением прервано. Дождитесь повторного подключения.
Обсуждение документации - Просмотр сообщения № 1069499
Тема сообщения
Нарушения в ТС
Тип сообщения
Запрос о разъяснении КД
Поставщик
AI-Trade ИП
Представитель поставщика
ОРАЗБАЕВА АНОРА БЕИМБЕТОВНА
Дата и время отправки сообщения
2026-10-04 19:49:56
Текст сообщения
1. Просим разъяснить правовую и техническую природу авторизационного письма.
2. Является ли письмо характеристикой товара?
3. Если нет, почему оно установлено в технической спецификации?
4. Является ли наличие письма характеристикой потенциального поставщика?
5. Если да, как это согласуется с примечанием о недопустимости квалификационных требований?
6. Почему письмо требуется именно от правообладателя или официального дистрибьютора?
7. Почему его не может заменить документ легального реселлера?
8. Почему не допускается договор поставки?
9. Почему не допускается лицензионный сертификат?
10. Почему не допускается лицензионное соглашение?
11. Почему не допускается документ об активации?
12. Может ли участник приобрести лицензию после определения победителем?
13. Если может, зачем письмо на стадии заявки?
14. Если не может, на каком основании участник обязан заранее иметь отношения с правообладателем?
15. Кто определяет понятие «официальный дистрибьютор»?
16. Как подтвердить такой статус?
17. Может ли быть несколько официальных дистрибьюторов?
18. Может ли зарубежный дистрибьютор выдать письмо?
19. Может ли письмо выдать официальный партнер?
20. Почему партнер не указан в ТС?
21. Допускается ли электронное письмо с ЭЦП?
22. Требуется ли оригинал?
23. Требуется ли печать?
24. Требуется ли подпись руководителя правообладателя?
25. Как будет проверяться подлинность?
26. Какой срок действия письма?
27. Что произойдет, если правообладатель отзовет письмо после подачи заявки?
28. Может ли такое действие третьего лица повлечь отклонение?
29. Почему участник должен нести такой риск?
30. Сколько правообладателей могут обеспечить пункт 5.1?
31. Сколько — пункт 5.2?
32. Являются ли это одни и те же правообладатели?
33. Не требуется ли участнику получать два разных авторизационных письма?
34. Можно ли представить одно письмо на оба программных продукта?
35. Если программы разных разработчиков, требуется ли два письма?
36. Проверял ли Заказчик доступность таких писем?
37. Получит ли письмо любой потенциальный участник?
38. Есть ли публичная процедура получения?
39. Просим указать контакт/порядок без привязки к конкретному поставщику.
40. Требуется ли вступление в партнерскую сеть?
41. Требуется ли обучение или сертификация сотрудников поставщика?
42. Требуется ли коммерческий план?
43. Требуется ли закупка минимального количества лицензий?
44. Если такие условия имеются, почему они отсутствуют в КД?
45. Не образуют ли такие условия скрытые требования к участнику?
46. Почему Заказчику недостаточно сертификата уровня доверия 5?
47. Почему недостаточно записи в реестре?
48. Что дополнительного подтверждает письмо?
49. Какая угроза устраняется именно письмом?
50. Просим привести техническое обоснование.
51. Почему уровень доверия 5 требуется по файловому менеджеру?
52. Почему 5+ требуется по доверенной загрузке?
53. Какие данные будут защищаться?
54. Какая модель угроз утверждена Заказчиком?
55. Существует ли модель угроз?
56. Если существует, просим указать, какие функции ТС из нее вытекают.
57. Если модели угроз нет, на каком основании выбраны уровни 5 и 5+?
58. Почему требуется DXE-архитектура?
59. Почему не разрешено иное решение?
60. Что является главным: архитектура или результат защиты?
61. Допускается ли средство с более высоким уровнем безопасности, но иной архитектурой?
62. Допускается ли решение с уровнем выше 5, но без требуемого реестра?
63. Допускается ли решение из реестра с иной системой лицензирования?
64. Допускается ли решение с подписочной лицензией?
65. Допускается ли облачное решение?
66. Допускается ли локальное решение?
67. Почему криптографический сервер должен находиться в РК?
68. Как Заказчик намерен это проверять?
69. Как такой критерий фиксируется в официальной документации производителя?
70. Просим исключить письма из состава заявки.
71. Просим разрешить предоставление доказательств легальности ПО при поставке.
72. Просим исключить конкретный архитектурный способ реализации функций.
73. Просим разрешить функциональные аналоги.
74. Просим исключить условия, исполнение которых зависит от волеизъявления третьих коммерческих организаций.
75. Просим привести ТС в соответствие с собственным примечанием о недопустимости требований к потенциальному поставщику.
2. Является ли письмо характеристикой товара?
3. Если нет, почему оно установлено в технической спецификации?
4. Является ли наличие письма характеристикой потенциального поставщика?
5. Если да, как это согласуется с примечанием о недопустимости квалификационных требований?
6. Почему письмо требуется именно от правообладателя или официального дистрибьютора?
7. Почему его не может заменить документ легального реселлера?
8. Почему не допускается договор поставки?
9. Почему не допускается лицензионный сертификат?
10. Почему не допускается лицензионное соглашение?
11. Почему не допускается документ об активации?
12. Может ли участник приобрести лицензию после определения победителем?
13. Если может, зачем письмо на стадии заявки?
14. Если не может, на каком основании участник обязан заранее иметь отношения с правообладателем?
15. Кто определяет понятие «официальный дистрибьютор»?
16. Как подтвердить такой статус?
17. Может ли быть несколько официальных дистрибьюторов?
18. Может ли зарубежный дистрибьютор выдать письмо?
19. Может ли письмо выдать официальный партнер?
20. Почему партнер не указан в ТС?
21. Допускается ли электронное письмо с ЭЦП?
22. Требуется ли оригинал?
23. Требуется ли печать?
24. Требуется ли подпись руководителя правообладателя?
25. Как будет проверяться подлинность?
26. Какой срок действия письма?
27. Что произойдет, если правообладатель отзовет письмо после подачи заявки?
28. Может ли такое действие третьего лица повлечь отклонение?
29. Почему участник должен нести такой риск?
30. Сколько правообладателей могут обеспечить пункт 5.1?
31. Сколько — пункт 5.2?
32. Являются ли это одни и те же правообладатели?
33. Не требуется ли участнику получать два разных авторизационных письма?
34. Можно ли представить одно письмо на оба программных продукта?
35. Если программы разных разработчиков, требуется ли два письма?
36. Проверял ли Заказчик доступность таких писем?
37. Получит ли письмо любой потенциальный участник?
38. Есть ли публичная процедура получения?
39. Просим указать контакт/порядок без привязки к конкретному поставщику.
40. Требуется ли вступление в партнерскую сеть?
41. Требуется ли обучение или сертификация сотрудников поставщика?
42. Требуется ли коммерческий план?
43. Требуется ли закупка минимального количества лицензий?
44. Если такие условия имеются, почему они отсутствуют в КД?
45. Не образуют ли такие условия скрытые требования к участнику?
46. Почему Заказчику недостаточно сертификата уровня доверия 5?
47. Почему недостаточно записи в реестре?
48. Что дополнительного подтверждает письмо?
49. Какая угроза устраняется именно письмом?
50. Просим привести техническое обоснование.
51. Почему уровень доверия 5 требуется по файловому менеджеру?
52. Почему 5+ требуется по доверенной загрузке?
53. Какие данные будут защищаться?
54. Какая модель угроз утверждена Заказчиком?
55. Существует ли модель угроз?
56. Если существует, просим указать, какие функции ТС из нее вытекают.
57. Если модели угроз нет, на каком основании выбраны уровни 5 и 5+?
58. Почему требуется DXE-архитектура?
59. Почему не разрешено иное решение?
60. Что является главным: архитектура или результат защиты?
61. Допускается ли средство с более высоким уровнем безопасности, но иной архитектурой?
62. Допускается ли решение с уровнем выше 5, но без требуемого реестра?
63. Допускается ли решение из реестра с иной системой лицензирования?
64. Допускается ли решение с подписочной лицензией?
65. Допускается ли облачное решение?
66. Допускается ли локальное решение?
67. Почему криптографический сервер должен находиться в РК?
68. Как Заказчик намерен это проверять?
69. Как такой критерий фиксируется в официальной документации производителя?
70. Просим исключить письма из состава заявки.
71. Просим разрешить предоставление доказательств легальности ПО при поставке.
72. Просим исключить конкретный архитектурный способ реализации функций.
73. Просим разрешить функциональные аналоги.
74. Просим исключить условия, исполнение которых зависит от волеизъявления третьих коммерческих организаций.
75. Просим привести ТС в соответствие с собственным примечанием о недопустимости требований к потенциальному поставщику.
