Респондентам предлагается реагировать на данный Запрос предложений путем отправки ответа по следующему адресу: rws-opensource@icann.org. Период отправки вопросов относительно данного RFP закрыт. Окончательный срок ответа на данный RFP — 15 июня 2012 г.
В период с 16 мая до 5 июня 2012 года по адресу rws-opensource@icann.org было направлено 26 вопросов. Полный список вопросов и ответов публикуется на веб-сайте ICANN в интересах всех респондентов.
Одинаковые вопросы, а также вопросы с одинаковым ответом сгруппированы вместе.
Требования
Вопрос: В разделе «Требования» RFP содержится ссылка http://tools.ietf.org/id/weirds. На странице, соответствующей указанному URL-адресу, перечислено довольно много проектов, не имеющих тесной связи с классической объектной моделью Whois доменных имен ДВУ (которая обычно допускает запросы на поиск регистраторов, доменов,узлов и контактных лиц в местном хранилище объектов реестра). В частности, вместо этого draft-fiorelli-weirds-rws относится к базе данных RIPE, draft-newton-et-al-weirds-rir-json-response и draft-newton-et-al-weirds-rir-query относятся к Региональным реестрам Интернета (РРИ), draft-newton-weirds-arin-whoisrws относится к службе Whois ARIN, а draft-lacnic-weirds-restwhois-redirects имеет отношение к переадресации с глобального сервера Whois. Что касается требований RFP, можем ли мы в силу вышесказанного предположить, что только оставшиеся документы (draft-designteam-weirds-using-http, draft-kucherawy-weirds-requirements и draft-sheng-weirds-icann-rws-dnrd), — два из которых также явным образом упоминаются в разделе «Ссылки» RFP, — уместно использовать в качестве требований для эталонной реализации? Если это не так, укажите, какие еще проекты из расположенных по адресу http://tools.ietf.org/id/weirds тоже необходимо поддерживать и по какой причине.
Ответ: Да, это правильное предположение. Ожидаемый объем работ охватывает только реестры доменных имен.
Вопрос: Группа WEIRDS создает два стандарта IETF для запросов данных РРИ. И стандарты для запросов регистрационных данных доменных имен. Необходимо ли в обязательном порядке внедрять в эталонной реализации все эти стандарты или только те стандарты, которые относятся к регистрационным данным доменных имен.
Ответ: С учетом того, что существует только 5 РРИ, большинство из которых уже входит в состав группы WEIRDS и работает над созданием собственных реализаций, мы сосредоточили внимание только на доменных именах. Принимая во внимание наличие более тысячи аккредитованных ICANN регистраторов, возможность появления нескольких сотен новых рДВУ, а также существующие нДВУ, и учитывая ограниченность финансовых средств, мы приняли решение сосредоточить усилия на центральной группе серверов.
Вопрос: В разделе 2.4.4 указано, что реализация должна включать «прокси» сервер порта 43, который использует службу RESTful Whois для ответа на запросы и преобразует запросы и ответы через порт 43 соответствующим образом. Хотя это является одним из возможных подходов, наша текущая реализация сервера Whois включает такую реализацию порта 43, которая *напрямую* получает доступ к базе данных сервера Whois (то есть она не пересылает запросы и ответы через другой внешний интерфейс), что позволяет существенно повысить производительность обслуживания через порт 43. Допустимо ли в эталонной реализации использовать прямой подход вместо описанного в RFP подхода с «прокси», при условии что в реализации будет предусмотрена служба Whois через порт 43, отвечающая на запросы таким же образом, как и в режиме «прокси»?
Ответ: Нет. Если уточнить, то мы хотим, чтобы все основные службы были созданы на основе RESTful, однако понимая, что некоторые клиенты тем не менее могут направлять запросы через порт 43, мы хотим предусмотреть прокси сервер, способный преобразовывать эти запросы клиентов в запросы RESTful и возвращать результат через порт 43.
Вопрос: Должна ли эталонная реализация обслуживать и рДВУ, и нДВУ?
Ответ: Да. Ожидается, что эталонную реализацию можно будет использовать как для рДВУ, так и для нДВУ.
Вопрос: Сервер WHOIS по существу является системой обслуживания запросов к базе данных. База данных — это совокупность информации о доменах, имеющейся у реестра или регистратора, языком запросов является любой язык, распознаваемый сервером WHOIS, а результат выбирается из лежащей в основе базы данных. Что содержит база данных, и какие запросы поддерживаются языком запросов?
Хотя можно интуитивно получить ответы на эти вопросы из приложений WHOIS существующих соглашений о реестрах, использующих WHOIS с расширенным набором данных, эти приложения не одинаковы. Например, в соглашении .INFO регламентируются частично покрываемые запросы, в то время как в соглашении .BIZ они не упоминаются. В реестре .AERO предусмотрено поле «ENS_Authid» и имеются метки конфиденциальности, в то время как в реестре .ASIA есть поле «ENS_Authid», но нет меток конфиденциальности. В соглашении .XXX упоминаются данные DNSSEC, в то время как в заключенных ранее соглашениях такие упоминания отсутствуют. В соглашении .POST упоминается поле «Maintainer» (Специалист по обслуживанию) вместо поля «Email» (Электронная почта) в остальных соглашениях. В соглашении .NAME описаны несколько уровней доступа и объекты Защитной регистрации.
Мы понимаем, что у различных реестров по-прежнему будут в некоторой степени различающиеся требования, однако создается впечатление, что причиной многих различий между соглашениями в большей степени является эволюция понимания потребностей, а не намеренные решения о введении различий, например частично покрываемые запросы в противоположность точным, DNSSEC, и поле «Maintainer» в противоположность «Email». Может ли ICANN предложить некоторые указания относительно содержания основной базы данных и тех видов запросов, которые необходимо поддерживать?
Ответ: Как было указано в приведенном выше вашем описании, содержание основной базы данных и виды поддерживаемых запросов определяются органом, формирующим политику реестров/регистраторов.
Другими словами, мы ожидаем, что эта открытая реализация RWS сможет обрабатывать различные поля, разрешенные в запросах (будет настраиваемой).
Вопрос: В документе RFP не уточняется структура вывода. Есть ли какие-либо ожидания в отношении последовательности элементов данных? Если это так, каковы они?
Ответ: Ожидается, что структура вывода будет определена в протоколе IETF. В настоящее время упомянутые в RFP интернет-проекты имеют структуру, предназначенную для доменных имен.
Вопрос: Предусмотрены ли конкретные требования к производительности системы? Например, существует ли требование к минимальному количеству обрабатываемых в секунду запросов, с учетом конкретных спецификаций оборудования?
Ответ: На данном этапе нами установлены только те требования, которые описаны в RFP. Мы с интересом изучим соответствующие предложения потенциальных поставщиков.
Вопрос: Существует ли конкретный список кодировок данных Whois, подлежащих обязательной поддержке? Например, достаточно ли будет ограничиться поддержкой кодировки UTF-8 в запросах и ответах или необходимо обеспечить поддержку большего количества кодировок? Может ли потребоваться преобразование данных реестра/регистратора из одной кодировки в другую?
Ответ: Это зависит от протокола, который еще не определен. По нашим предположениям, он потребует использования UTF-8, но также может потребоваться поддержка других кодировок.
Вопрос: Существует ли минимальное требование относительно типов форматов проводного обмена данными, подлежащих обязательной поддержке? Например, может ли в эталонной реализации использоваться только JSON с последующей возможностью добавления других форматов или должна быть обязательно обеспечена поддержка минимального набора представлений?
Ответ: Как и в случае вопроса о кодировке, это зависит от требований протокола.
Вопрос: Существуют ли минимальные требования в отношении альтернативных вариантов политики? В запросе предложений указано следующее: «Реализация должна обеспечивать настройку параметров в зависимости от альтернативных вариантов политики», но такая формулировка является достаточно широкой. Имеются ли примеры типов политик, которые могут оказаться обязательными? Например, будут ли включены такие политики, как регулирование количества запросов, фильтрация запросов (то есть расширенные сведения для запросов Whois, поступающих от конкретных клиентов) и т.д.?
Ответ: Мы ожидаем, что параметры конфигурации функциональных возможностей будут определены в спецификациях протокола. Мы не планируем осуществлять реализацию того, что не будет определено в протоколе. Однако мы ожидаем, что реализация будет носить модульный характер, который позволит заинтересованному реестру/регистратору изменять ее с минимальными усилиями для включения новых функциональных возможностей.
Вопрос: Входит ли в состав требований тестирование безопасности и, если это так, потребуется ли подрядчику, разрабатывающему эталонную реализацию, выполнить эти проверки безопасности?
Ответ: Мы ожидаем, что окончательная реализация будет пригодна для производственного применения. Поэтому мы ожидаем проведения по крайней мере некоторых базовых проверок безопасности, которые будут предложены подрядчиком.
Вопрос: Предъявляются ли какие-либо требования к общему управлению проектом или это будет оставлено на усмотрение подрядчика? Например, где будет размещаться код? Какие рабочие процессы будут использоваться для отслеживания проблем и разработки?
Ответ: Нет, никакие требования в этом отношении, кроме описанных в RFP, не предусмотрены.
Вопрос: Чтобы свести к минимуму работу по интеграции, в документе RFP приведен пример возможного разделения различных уровней, см. раздел 2.4.2. RFP. Стремитесь ли вы к созданию модульной реализации, при которой существуют различные продукты для уровней представления, программного кода, реализующего функциональность, и доступа к данным, которые могут использоваться совместно или автономно?
Ответ: Мы не стали бы называть это отдельными продуктами, однако их реализация в виде отдельных модулей или по крайней мере возможность раздельной настройки их конфигурации имеет смысл.
Вопрос: Что касается настройки параметров согласно разделу 2.5. документа RFP, необходимо ли только предусмотреть возможность настройки реализации или ICANN будет готова рассмотреть предложения, например, в отношении интерфейса для настройки различных параметров, которые уже могут присутствовать в реализации? Можно ли предложить такой подход в качестве дополнительного и необязательного модуля?
Ответ: Мы готовы рассмотреть предложения.
Вопрос: Должен ли использоваться только английский язык для продукта, документации и поддержки или необходимо охватить большее число языков? Если это так, укажите необходимые языки.
Ответ: По крайней мере английский язык, и мы крайне приветствовали бы возможность использования других языков.
Вопрос: Включение кода сторонних разработчиков (2.6.) может привести к непредсказуемым издержкам в части контроля качества и документации. Будет ли ICANN открыта для модели затрат, включающей такую дополнительную работу в части времени и материальной основы? То же самое относится к непредусмотренной необходимости новых вариантов кода в соответствии с пунктом 2.2 или поддержке.
Ответ: Да, мы готовы рассмотреть предложения. Однако для уточнения сообщаем, что возможность включения кода сторонних разработчиков должна использоваться только в целесообразных для поставщика случаях (с точки зрения расходов) вместо выполнения самостоятельной работы с нуля.
Сроки проекта
Вопрос: Каковы сроки проекта? В документе RFP указан период поддержки, равный одному году, однако нет сведений относительно ожидаемого конечного срока создания рабочей группой окончательной спецификации, и не указаны конкретные сроки поставки первоначальной реализации.
Ответ: В текущем графике работ IETF указано, что спецификации будут готовы к августу 2013 года, однако этот срок может измениться.
Вопрос: Каков ожидаемый интервал времени между итерационным опубликованием спецификаций и внесением изменений в систему?
Ответ: Мы не рассчитываем на внедрение выбранным поставщиком всех без исключения интернет-проектов. Мы планируем встречаться с поставщиком каждый раз, когда, по нашему мнению, будет целесообразно подготовить новый выпуск кода, для согласования с поставщиком сроков и объемов поставки.
Оценка ответов на RFP и заключение договора
Вопрос: Какая аудитория будет рассматривать ответ на RFP? Какой отборочный комитет?
Ответ: Предложение будет рассматриваться отборочным комитетом, состоящим из технических специалистов.
Вопрос: Выделены ли на этот проект бюджетные средства?
Ответ: Мы предусмотрели некоторые бюджетные средства на оставшуюся часть текущего финансового года и запросили дополнительные средства на следующий финансовый год. Мы хотели бы рассмотреть предложения заинтересованных поставщиков.
Вопрос: Каков общий бюджет проекта? Заинтересована ли ICANN в предложении с фиксированной ценой, или корпорация также открыта для поэтапного подхода, при котором сначала осуществляется сбор и определение требований, а затем выполняется оценка затрат или стоимости, исходя из выводов по результатам такого взаимодействия с ICANN?
Ответ: Мы хотели бы рассмотреть предложения заинтересованных поставщиков. И мы готовы рассмотреть ваши варианты.
Вопрос: Существует ли предпочтительный тип договора (из расчета затраченного времени и материалов, с твердой фиксированной ценой и т.д.)?
Ответ: Мы не против любого из двух вариантов, однако с учетом переменных сроков вероятно, что договор с твердой фиксированной ценой можно в большей степени нацелить на результат, чем общий проект.
Вопрос: В разделе «Оценка и определение победителя» документа RFP отмечается, что точные сроки определения победителя могут зависеть от процесса стандартизации IETF. Каким образом ICANN планирует поставить сроки определения победителя в зависимость от процесса IETF? В частности, существует ли вероятность того, что победитель будет определен, скажем, в течение приблизительно одного месяца после конечного срока ответа на RFP, или возможна задержка и определение победителя только после ноября 2012 года или августа 2013 года (диапазон дат, указанный в этапах работы РГ WEIRDS)?
Ответ: Мы намерены определить победителя и заключить с ним договор в максимально короткие сроки. Мы ожидаем получить от поставщика результаты работы до выпуска документов RFC, после определения достаточно стабильной спецификации и получения от ICANN заблаговременного указания.
Прочие вопросы
Вопрос: В документе RFP содержится следующее требование: «окончательный продукт должен соответствовать применимым RFC, которые будут стандартизированы в рабочей группе WEIRDS комиссии IETF». Существует ли ожидание или требование ICANN относительно участия подрядчика и/или его вклада в деятельность РГ WEIRDS с целью обеспечить сохранение соответствия проекта с открытым исходным кодом решениям этой РГ?
Ответ: Требование участия отсутствует, но, вероятно, подрядчику целесообразно как минимум войти в список рассылки группы.
Вопрос: ICANN недавно опубликовала оперативный план реализации рекомендаций SAC 051 (http://www.icann.org/ru/news/announcements/announcement-6-04jun12-ru.htm), в котором охвачена работа IETF над новым протоколом, но также ожидаются предложения сообщества ICANN, в частности реестров и регистраторов нДВУ и рДВУ, а также ОПРИ: «в настоящем оперативном плане рекомендуется использовать комплексный подход к утверждению замены протокола WHOIS». Ограничены ли рамки проекта эталонной реализации спецификациями протокола, которые будут подготовлены IETF?
Ответ: Да, эта реализация должна соответствовать документам RFC, подготовленным в IETF, однако также ожидается качество, пригодное для производственного применения.
Вопрос: Можем ли мы рассчитывать на участие реестров в процессах разработки и тестирования?
Ответ: Возможно, некоторые реестры и регистраторы примут участие, однако выбранный поставщик не должен на это рассчитывать.