Респондентам предлагается реагировать на данный запрос предложений (RFP) путем отправки ответа по следующему адресу: pre-delegation-testing-bid@icann.org. Период отправки вопросов относительно этого RFP закрыт. Окончательный срок ответа на данный RFP — 20 ноября 2012 г.
В период с 30 октября по 7 ноября 2012 года были получены следующие вопросы. Полный список вопросов и ответов публикуется на веб-сайте ICANN в интересах всех респондентов.
Одинаковые вопросы, а также вопросы с одинаковым ответом сгруппированы вместе.
Приведенный ниже текст основан на вопросах, полученных от потенциальных респондентов RFP, и переработан для исключения упоминаний о поставщиках.
Вопрос 1: Q.16: Что корпорация ICANN конкретно определяет как «три основных этапа»?
Это три отдельные части, которые определены в разделе 2.2 («Объем работ»).
Вопрос 2: Ожидается ли, что веб-интерфейсы систем каждого реестра будет также необходимо проверить?
Интерфейс Whois должен проверяться так, как это описано в разделе 2.3.4.1. Руководство кандидата (РК) содержит следующее положение:
«ICANN выполняет проверку доступности данных службы Whois по протоколу IPv4 и IPv6 через TCP порт 43 и веб-интерфейс, а также проверку представленной документации по самостоятельному подтверждению возможностей осуществления транзакций в службе Whois. Формат ответа в соответствии со Спецификацией 4 соглашения о реестре и доступ к службе Whois (через порт 43 и через веб-интерфейс) тестируются ICANN удаленно из различных точек Интернета с использованием протоколов IPv4 и IPv6».
Вопрос 3: Выделит ли ICANN поставщику услуг тестирования ресурсы для консультаций на этапах проектирования и реализации в случае возникновения каких-либо вопросов?
Да.
Вопрос 4: В запросе предложений указано, что право на заключение договора получит «один или несколько» поставщиков, что может повлиять на ценообразование. Может ли ICANN дать какие-либо дополнительные указания в отношении этого?
Согласно инструкциям Q.24, Q.25 и Q.26, поставщики должны указать свои собственные расценки для каждого из этих перечисленных пунктов.
Вопрос 5: По какой схеме необходимо выполнять проверки: в расчете на одного поставщика конечных услуг реестра или на одного кандидата?
Поставщик услуг проверки перед делегированием должен убедиться в выполнении каждым кандидатом своего обязательства обеспечить функционирование реестра в соответствии с положениями Руководства кандидата на регистрацию рДВУ (РК).
Вопрос 6: Принимая во внимание тот факт, что количество поступивших заявок на уникальные строки составляет около 1400, все еще ожидается что будет проведено приблизительно 2000 проверок с интенсивностью 20 проверок в неделю?
Мы ожидаем, что будет проведена проверка 1400 кандидатов с первоначально указанной интенсивностью, равной 20 проверок в неделю. Однако обратите внимание, что мы также предлагаем поставщику обеспечить возможность увеличения масштабов до 100 проверок в неделю по запросу ICANN.
Вопрос 7: Может ли ICANN представить четко сформулированное заявление относительно ожидаемого минимального числа проверок перед делегированием?
На данном этапе неизвестно, сколько всего указанных в заявках строк будет утверждено. Поэтому мы не можем сделать заявление относительно минимального количества реестров, подлежащих проверке, а можем указать только максимальное количество: 1400. Мы ожидаем, что фактическое число проверяемых реестров будет близким к максимуму.
Вопрос 8: ICANN потребовала, чтобы программное обеспечение для проверки перед делегированием было доступно корпорации в формате исходного кода, и могло бы быть опубликовано ICANN как открытое программное обеспечение. Пожалуйста, поясните данное требование.
Любые ограничения при поставке программного обеспечения или выдаче лицензий должны быть четко сформулированы в конкурсном предложении. Как минимум, ICANN должна получить неэксклюзивную, бессрочную и безвозмездную лицензию на использование программного обеспечения, предоставленного для целей проверки перед делегированием.
Вопрос 9: Распространяется ли термин «программное обеспечение для проверки перед делегированием» на все программное обеспечение, используемое в системе проверки перед делегированием, или только на программное обеспечение для выполнения технических тестов?
На все программное обеспечение, используемое для предоставления услуг проверки перед делегированием.
Вопрос 10: RFP требует от поставщика услуг проверки перед делегированием проанализировать документы по «самостоятельной сертификации», предоставленные проверяемым оператором реестра. Подтверждает ли ICANN, что эта проверка предназначена для обеспечения полноты и не отражает необходимости проведения дополнительных проверок для подтверждения самоаттестации?
Поставщик услуг проверки перед делегированием должен проанализировать документы по самостоятельной сертификации для подтверждения их полноты, достоверности и соответствия конкретным утверждениям, включенным в заявку на рДВУ.
Вопрос 11: Что касается отчетов, которые будет генерировать система проверки перед делегированием, должен ли поставщик услуг проверки перед делегированием предоставить отчет по каждому кандидату или только совокупность универсальных отчетов по каждой технической платформе поставщика конечных услуг реестра?
Да, ожидается, что для каждого проверяемого рДВУ будет предоставлен отчет, отражающий состояние соответствия оператора реестра требованиям проверки перед делегированием.
Вопрос 12: Подлежат ли предложения кандидатов на регистрацию рДВУ или поставщиков конечных услуг реестра и/или поставщиков услуг DNS, с которыми кандидаты на регистрацию новых рДВУ заключили договора, дисквалификации или иным штрафным санкциям в рамках этой процедуры RFP?
ICANN будет принимать предложения от кандидатов на регистрацию новых рДВУ и/или поставщиков конечных услуг реестра в новых рДВУ. Согласно инструкциям Q.3 и Q.6, все конфликты интересов должны быть четко описаны респондентом. Конфликт интересов не приводит к автоматической дисквалификации или наложению штрафных санкций на респондентов.
Вопрос 13: Будет ли ICANN рассматривать резервных поставщиков услуг оператора реестра (EBERO) в качестве поставщиков услуг проверки перед делегированием?
Да.
Вопрос 14: Если кандидат на роль поставщика услуг проверки перед делегированием является поставщиком конечных услуг реестра для самого кандидата, может ли он подтверждать или проверять собственные технические характеристики в соответствии с принципами, изложенными в RFP, или в таких случаях необходимо использовать другие методы? Если такие методы существуют, пожалуйста, опишите их подробно.
Поставщик услуг проверки перед делегированием не может проверять собственные характеристики или предоставляемые им самим услуги реестра, поскольку в такой ситуации возникает конфликт интересов.
Вопрос 15: Разрешит ли ICANN использовать подход с двумя поставщиками для организации проверки перед делегированием (то есть, один поставщик разрабатывает программное обеспечение для проверки перед делегированием и размещает у себя систему для проверки перед делегированием, а второй поставщик предоставляет услуги проверки перед делегированием)?
Да.
Вопрос 16: Будет ли ICANN рассматривать возможность заключения договора с единственным поставщиком, принимая в расчет а) экономию за счет масштабов и б) единую для всех модель тестирования?
Наличие единственного поставщика является предпочтительным для ICANN вариантом. Однако ICANN готова использовать услуги нескольких поставщиков, если это окажется лучшей альтернативой.
Вопрос 17: Можно ли выполнять единственную проверку каждого поставщика конечных услуг реестра (поскольку это ограничило бы требование приблизительно до 80 таких проверок)?
В руководстве кандидата предусмотрена одна проверка перед делегированием для каждого оператора реестра (стороны, заключившей договор с ICANN).
Вопрос 18: Будет ли ICANN рассматривать предложения, в которых предлагается выполнить только часть проверок перед делегированием? Более конкретно: учитывая более технический характер и важность этих задач, будет ли ICANN рассматривать предложения, в которых предлагаются только компоненты DNS и DNSSEC, включенные в RFP?
Нет.
Вопрос 19: Есть ли у ICANN какие-либо опасения в отношении конфликта интересов с другими услугами по оценке заявок, предоставляемыми ICANN в рамках реализации программы ввода новых рДВУ?
Нет.
Вопрос 20: Q.26: При проведении аудита на объекте, сколько человек должно быть задействовано в одной проверке?
Поставщик услуг проверки перед делегированием должен сформировать группу специалистов, компетенция которых позволяет провести аудит на объекте. Ожидается, что потребуется только небольшое количество подобных проверок.
Вопрос 21: Не могла бы ICANN уточнить элементы, подлежащие проверке в ходе аудита на объекте?
Поставщик услуг проверки перед делегированием должен подтвердить соответствие требованиям, изложенным в разделе 5.2 РК, и соответствующим заверениям, включенным в заявку на регистрацию рДВУ.
Вопрос 22: Q.26: Ожидает ли ICANN существенного увеличения числа проверок в течение срока действия договора?
Ожидается, что проверки перед делегированием будут первоначально выполняться с интенсивностью 20 проверок в неделю, при этом существует возможность увеличения интенсивности до 100 проверок в неделю. Как описано в Q.26(a), должна быть указана цена одной проверки.
Вопрос 23: R.6: Допустимо ли не внедрять взаимную проверку подлинности агентов по проверке перед делегированием, если поставщик услуг проверки перед делегированием функционирует в среде внутренней/частной сети?
Нет, система проверки перед делегированием должна быть предназначена для работы в открытой среде (например, через общедоступный Интернет) — взаимная проверка подлинности и шифрование являются обязательными условиями.
Вопрос 24: Является ли использование IPv6 обязательным требованием в тексте «проверки должны осуществляться с использованием протоколов IPv4 и IPv6»?
Проверки должны осуществляться с использованием протокола IPv6, когда это применимо. Обратите внимание, что некоторые службы (например, DNS и Whois) должны функционировать по протоколу IPv6 (согласно требованиям Спецификации 6 Соглашения о новом рДВУ).
Вопрос 25: R.18: Что такое «Договор рДВУ»?
Договор рДВУ — это подписанное «Соглашение о новом рДВУ».
Вопрос 26: R.19: Каково содержание отсутствующей сноски 1?
Вопрос 27: Q.26(b) представлен ненадлежащим образом
«Проверка процесса передачи данных из Депозитария. Ожидается, что ICANN потребует провести порядка 20 проверок за период действия договора».
Вопрос 28: R.25: Предоставит ли ICANN корневой сервер для проверки точек доверия DNSSEC?
Нет.
Вопрос 29: R.26: Может ли ICANN предоставить более подробные сведения о нормах, касающихся заявлений о политике DNSSEC?
Согласно разделу 1.3 Спецификации 6 базового соглашения, заявления о политике DNSSEC должны соответствовать ожидаемому стандарту RFC с описанием концепции заявлений о политике DNSSEC (в настоящее время находится в виде проекта https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/), в котором будут изложены критически важные элементы и процедуры управления безопасностью, например, для хранения данных ключей, доступа к собственным ключам и их использования, а также безопасного получения данных открытых ключей от владельцев регистраций.
Вопрос 30: Вопросы о предельных значениях
- Установлен ли предельный срок прохождения заявкой проверки? Каков срок, необходимый для прохождения заявкой технических проверок перед делегированием рДВУ в зону?
- Если заявке не удалось пройти техническую проверку с первого раза, сколько еще дополнительных попыток имеется у кандидата до прекращения процедуры проверки перед делегированием?
- Или, если необходимы дополнительные проверки, может ли поставщик услуг проверки перед делегированием взимать с ICANN дополнительную плату?
Кандидатам должно быть предоставлено обоснованное количество времени (по согласованию между выбранным поставщиком и ICANN) для устранения технических проблем или представления дополнительной информации. Если кандидат не сможет представить необходимые доказательства в этот установленный срок, считается, что он не прошел проверку.
Вопрос 31: Q.5: Необходимо ли в обязательном порядке представить какие-либо конкретные сведения о включенных в список субподрядчиках?
Как описано в Q.15(a), респонденты должны представить оценку конфликтов интересов на основе текущего списка кандидатов на регистрацию новых рДВУ.
Вопрос 32: Может ли ICANN уточнить ожидаемую степень поддержки оператора ДВУ со стороны поставщика услуг проверки перед делегированием, помимо повторной проверки, в случае, когда операторам ДВУ не удается пройти какой-либо компонент проверки перед делегированием?
Ожидается, что поставщик услуг проверки перед делегированием передаст кандидату ответ с описанием каждой из причин неудачного прохождения проверки и даст кандидату возможность принять меры по их устранению в течение обоснованного срока (подлежащего согласованию между выбранным поставщиком и ICANN) перед вынесением окончательного решения о том, что проверка не пройдена.
Вопрос 33: С учетом требования о списке имен и адресов unicast IPv4/IPv6 для узлов сетей с маршрутизацией anycast, какие действия ICANN желает предпринять в том случае, если оператор ДВУ в рамках своей обычной деятельности не обеспечивает возможность доступа к отдельным серверам в своих группах узлов с маршрутизацией anycast с других публичных IP-адресов, поддерживающих маршрутизацию, отличную от anycast?
Если оператор ДВУ не обеспечивает возможность обработки запросов поставщика услуг проверки перед делегированием по unicast-адресам для всех узлов, поддерживающих маршрутизацию anycast, кандидат в качестве альтернативы должен будет представить заявление о доступности всех узлов, не прошедших проверку.
Вопрос 34: Не могла бы ICANN уточнить элементы аудита, которые должны быть приняты во внимание при проверке выполненных самостоятельно тестов нагрузочной способности?
Поставщик услуг проверки перед делегированием должен проанализировать документы по самостоятельной сертификации для подтверждения их полноты, достоверности и соответствия соответствующим утверждениям, включенным в заявку на рДВУ.
Вопрос 35: На чем должна быть сосредоточена проверка процедуры передачи данных Депозитария: на передаче существующего депозита из Депозитария в ICANN или на передаче поставщику услуг проверки перед делегированием?
Проверка передачи должна быть сосредоточена на передаче депозитов из Депозитария рДВУ поставщику услуг проверки перед делегированием.
Вопрос 36: Что касается депонирования данных в разделе 2.3.4.4, является ли это требованием о проверке депонированных данных на соответствие требованиям при помощи специального программного обеспечения?
Нет, поставщик услуг проверки перед делегированием должен подтвердить, что профиль и формат депонированных данных одного полного и одного инкрементного депозита. Следовательно, эта проверка не связана с применением специального программного обеспечения.
Вопрос 37: R.24: Относится ли фраза «убедиться в том, что данные могут быть переданы в течение 24 часов» к проверке вручную соглашения об уровне обслуживания между поставщиком услуг ответственного хранения данных и кандидатом (представленного кандидатом) или она относится к реальной проверке, которая должна быть проведена поставщиком услуг проверки перед делегированием, чтобы убедиться в передаче и возврате данных с соблюдением требований к депонированию данных?
В большинстве случаев ICANN ожидает только проверки соглашения об уровне обслуживания, но в некоторых случаях ICANN может направить требование о фактической проверке возможностей передачи данных каждого поставщика услуг ответственного хранения данных. Как указано в Q.26, ICANN ожидает проведения порядка 20 таких проверок за период действия договора.
Вопрос 38: Приемлема ли проверка только полных депозитов?
Нет, в РК есть требование как о полных, так и об и инкрементных депозитах, что подразумевает необходимость проверки обоих видов.
Вопрос 39: R.19 и R.20: Пожалуйста, уточните требование о проверке таблиц ИДИ.
Основной задачей является подтверждение того, что возможности кандидата в отношении ИДИ соответствуют тем, которые описаны в представленных им таблицах ИДИ. Выполнение таких проверок существенно упрощается, если таблицы ИДИ представлены в машиночитаемом формате, который позволяет выполнить их чтение программным путем, однако ICANN допускает наличие таблиц ИДИ в других форматах, например, с использованием более сложного алгоритма генерации вариантов.
Вопрос 40: R.13: Должен ли интерфейс EPP проверяться только для включенных в список команд EPP?
Нет, интерфейс EPP должен проверяться на соответствие стандартам, требования которых описаны в разделе 5.2 Руководства кандидата программы ввода новых рДВУ, то есть «проверить соблюдение соответствующих RFC (включая расширения EPP для DNSSEC)».
Вопрос 41: R.18: Необходимы ли какие-либо технические тесты для проверки расширений EPP кандидата?
Нет.
Вопрос 42: 2.3.4.1: Предусмотрено ли требование о проверке веб-интерфейса Whois по протоколу HTTPS?
Если предусмотрен веб-интерфейс Whois по протоколу HTTPS, он должен быть проверен.
Вопрос 43: Q.26: Относится ли «аудит проверки под нагрузкой» к проверке вручную документации кандидата по самостоятельной сертификации, или он относится к фактическим тестам, которые должен выполнить сам поставщик услуг проверки перед делегированием, чтобы убедиться в достоверности утверждений, сделанных кандидатом.
Q.26(c,d,e) относится к реальным техническим тестам под нагрузкой, выполняемым поставщиком услуг проверки перед делегированием. Ожидается, что потребуется только небольшое количество подобных проверок.