Рабочая группа Network Working Group M. O'Dell
Запрос комментариев: 2438 UUNET Technologies
BCP: 27 H. Alvestrand
Категория: Лучшая современная практика Maxware
B. Wijnen
IBM T. J. Watson Research
S. Bradner
Harvard University
Октябрь 1998
Продвижение спецификаций MIB по IETF Standards Track
Статус данного меморандума
Этот документ определяет Лучшую современную практику Интернета для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение данного меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (1998). All Rights Reserved.
2. Аннотация
Процесс интернет-стандартизации [1] требует, чтобы все спецификации
IETF Standards Track имели «множественные, независимые и
взаимодействующие реализации», прежде чем они смогут быть продвинуты
за пределы статуса Proposed Standard. Этот документ определяет процесс,
который IESG будет использовать для установления того, соответствует ли
документ спецификации MIB этим требованиям. Он также рассматривает
обоснование этого процесса.
3. Сущность проблемы
Процесс интернет-стандартизации [1] требует, чтобы для продвижения
спецификации IETF за пределы уровня Proposed Standard было показано
корректное взаимодействие по меньшей мере двух генетически не связанных
реализаций со всеми возможностями и опциями. Для этого требования есть
две различные причины.
Первая причина состоит в проверке того, что текст спецификации
достаточно ясен и точен. Это демонстрируется тем, что несколько групп,
реализующих спецификацию, использовали её для создания взаимодействующих
реализаций.
Вторая причина состоит в предотвращении чрезмерного числа опций и
«разрастания функциональности». Это достигается требованием
взаимодействующей реализации всех возможностей, включая опции. Если
опция не включена по меньшей мере в две различные взаимодействующие
реализации, можно с уверенностью предположить, что она не была признана
полезной и должна быть удалена, прежде чем спецификация сможет быть
продвинута.
В случае спецификации протокола, определяющей «биты в канале», которыми
обмениваются исполняющиеся автоматы состояний, понятие
«взаимодействия» достаточно интуитивно: реализации должны успешно
«разговаривать друг с другом», обмениваясь «битами в канале» при
использовании всех возможностей и опций.
В случае спецификации базы управляющей информации SNMP (MIB) то, что
именно образует «взаимодействие», менее очевидно. Этот документ
определяет, как IESG решила оценивать «взаимодействие спецификаций MIB»
в контексте Процесса интернет-стандартизации IETF.
Существует ряд правдоподобных толкований взаимодействия спецификаций
MIB; многие из них обоснованны, но имеют весьма разные затраты и
сложности реализации.
Цель состоит в том, чтобы обеспечить достижение двух целей — ясности
спецификации и оценки возможностей — посредством такого толкования
понятия взаимодействия спецификаций MIB, которое уравновешивает
сложность тестирования и практичность.
4. О природе спецификаций MIB
По сравнению с протоколами «автоматов состояний», которые сосредоточены
на процедурных спецификациях, спецификация MIB намного в большей степени
ориентирована на данные. Обобщая чрезмерно, в типичной спецификации MIB
совокупность спецификаций типов данных и экземпляров значительно
превосходит по числу процедурную или причинную семантику между объектами.
Центральный вопрос заключается в том, что спецификация MIB не существует
сама по себе; она образует интерфейс доступа к расположенным под ней
средствам инструментирования. Без средств инструментирования MIB имеет
форму, но не имеет значений. Вместе с большим числом объектов даже в
простой спецификации MIB это приводит к тому, что спецификация MIB по
виду и ощущению больше похожа на API или словарь, чем на протокол
автомата состояний.
Важно различать оценку взаимодействия приложений, которые могут
использовать MIB или взаимодействовать с ними, и самих MIB. Достаточно
очевидно, что к таким приложениям может быть применено тестирование
«чёрного ящика» и что этот подход обладает определённой зрелостью в
практике программной инженерии. Спецификация MIB, с другой стороны,
нелегко поддаётся планам тестирования чёрного ящика.
5. Обсуждение и рекомендуемый процесс
Чтобы выполнить свои обязательства в рамках Процесса
интернет-стандартизации IETF, директора области Operations and Management
и IESG должны быть убеждены, что каждая спецификация MIB, продвигаемая
до статуса Draft Standard или Internet Standard, ясно написана, что
имеются требуемые множественные взаимодействующие реализации и что
реализованы все опции. Существуют несколько способов достижения этой
цели. В Приложении A перечислены некоторые подходы к тестированию,
которые можно использовать при попытке документировать множественные
реализации.
Подходы полного покрытия или «стимул—реакция» являются весьма
тщательными и при их применении повышали бы уверенность в том, что
требование выполнено. Однако опыт реальной программной инженерии ясно
показывает, что такая уверенность достигается чрезвычайно высокой ценой;
даже при наиболее исчерпывающем тестировании часто неясно, что именно
было продемонстрировано таким тестированием. Мы считаем, что оба этих
стандарта доказательств существенно выходят за пределы того, что может
быть разумно достигнуто в эксплуатационном смысле, а достижение требуемых
семантических спецификаций ещё менее вероятно.
Поэтому область Operations and Management и IESG приняли более
прагматичный подход к определению пригодности спецификации MIB для
продвижения по Standards Track за пределы статуса Proposed Standard.
У каждой спецификации MIB, предложенной к продвижению, должен быть один
или несколько защитников, способных убедительно обосновать, что
спецификация MIB удовлетворяет требованиям Процесса
интернет-стандартизации IETF в отношении множественных реализаций и
поддержки возможностей. Конкретный способ обоснования оставляется на
усмотрение защитника, но обычно будет включать отчёты о выполнении
базового тестирования сравнения объектов.
Таким образом, любая рекомендация о продвижении спецификации MIB должна
сопровождаться отчётом о реализации, как и все запросы на продвижение
спецификаций IETF. Отчёт о реализации должен включать причины, по которым
IESG следует считать, что существуют множественные реализации
рассматриваемой спецификации MIB и что все объекты MIB в спецификации,
подлежащей продвижению, поддерживаются более чем одной реализацией. Но
следует отметить, что первоочередной заботой IESG будет обеспечение
исходных причин для взаимодействующих реализаций, то есть того, что текст
спецификации ясен и недвусмысленен, а возможности спецификации, не
получившие поддержки, удалены.
Отчёт о реализации будет размещён на веб-странице IETF вместе с другими
отчётами о реализации до продвижения, и на него будет специально сделана
ссылка в IETF Last-Call. Как и в случае всех таких отчётов о реализации,
решение об адекватности принимается директором (директорами)
соответствующей области IETF. Это решение об адекватности может быть
оспорено в течение периода Last-Call.
6. Вопросы безопасности
Некоторые могут счесть, что эта политика, возможно, приведёт к снижению
уровня уверенности, который люди могут иметь в спецификациях MIB, но
директора области O&M и IESG считают, что она надлежащим образом
обеспечит разумную оценку уровня ясности спецификаций MIB и позволит
обеспечить выявление и удаление неиспользуемых опций до продвижения
спецификации.
Хорошие, ясно написанные спецификации MIB могут существенно помогать в
управлении Интернетом и другими сетями и тем самым содействовать снижению
некоторых видов угроз безопасности.
8. Ссылки
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
9. Адреса авторов
Michael D. O'Dell
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031
Phone: +1-703-206-5890
EMail: mo@uu.net
Harald T. Alvestrand
Maxware
Pirsenteret
N-7005 Trondheim, Norway
Phone: +47-73-54-57-94
EMail: Harald.Alvestrand@maxware.no
Bert Wijnen
IBM T. J. Watson Research
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31-348-432-794
EMail: wijnen@vnet.ibm.com
Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge MA 02138
Phone: +1-617-495-3864
EMail: sob@harvard.edu
Приложение A
A. Некоторые альтернативы тестирования
IESG обсудила ряд моделей взаимодействия и тестирования при формулировании
этой спецификации. Следующий список не является исчерпывающим перечнем
альтернатив, но охватывает основные правдоподобные модели, рассмотренные
в ходе обсуждения.
A.1 Базовое сравнение объектов
Предположим наличие требуемых двух генетически не связанных реализаций
MIB в агенте SNMP и станции управления SNMP, которые могут выполнять
«MIB Dump» (извлечение полного набора типов и значений объектов MIB из
реализации агента). Извлеките MIB Dump из каждой реализации и сравните
два дампа, чтобы проверить, что обе предоставляют полный набор
обязательных и необязательных объектов и что отдельные объекты имеют
правильные типы.
A.2 Тестирование «стимул/реакция»
Действуйте как в A.1, но дополнительно всесторонне протестируйте два
элемента (сети), содержащих реализации агента, чтобы проверить, что все
объекты MIB отражают правдоподобные значения в эксплуатационных условиях.
Ещё более строгая трактовка потребовала бы, чтобы объекты MIB в двух
элементах сети изменялись идентично при одинаковом стимуле. Хотя это
проверяло бы информацию «только для чтения» или «мониторинга», полученную
от расположенных под ней средств инструментирования, важно отметить, что
такие средства инструментирования фактически являются *приложением*,
которое использует MIB, и не являются частью самой MIB.
A.3 Тестирование полного покрытия
Эта модель доводит понятие тестирования «стимул/реакция» до его логического
предела. MIB рассматривается как API, и к MIB применяется понятие полного
покрытия тестирования из программной инженерии. Это предполагает
прохождение всех путей причинной семантики и проверку того, что все объекты
корректно меняют состояние во всех случаях. Снова отметим, что
испытывается и оценивается значительно больше, чем определение MIB.
Полное заявление об авторских правах
Copyright (C) The Internet Society (1998). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться другим
лицам, а производные работы, комментирующие или иным образом объясняющие
его либо содействующие его реализации, могут подготавливаться,
копироваться, публиковаться и распространяться, полностью или частично,
без ограничений какого бы то ни было рода, при условии, что приведённое
выше уведомление об авторских правах и этот абзац включены во все такие
копии и производные работы. Однако сам этот документ не может изменяться
каким бы то ни было образом, например путём удаления уведомления об
авторских правах или ссылок на Internet Society либо другие интернет-
организации, за исключением случаев, когда это необходимо для разработки
интернет-стандартов, при которой должны соблюдаться процедуры авторских
прав, определённые в Процессе интернет-стандартизации, или когда это
требуется для его перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не
будут отозваны Internet Society либо её правопреемниками или
цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ
КОНКРЕТНОЙ ЦЕЛИ.