Advancement of MIB specifications on the IETF Standards Track
RFC 2438 устанавливает процесс, по которому IESG определяет, удовлетворяет ли спецификация SNMP Management Information Base (MIB) требованиям для продвижения далее статуса Proposed Standard. Для такого продвижения должны быть подтверждены как минимум две генетически неродственные (независимые) взаимодействующие реализации, а также поддержка всех объектов и опций MIB; целью является также проверка ясности спецификации и исключение невостребованных возможностей. Документ принимает прагматичный подход: у предлагаемой к продвижению спецификации должен быть один или несколько advocates, способных убедительно обосновать выполнение этих требований; рекомендация сопровождается отчётом о реализациях, обычно включающим базовое сопоставление объектов, а не исчерпывающие испытания полного покрытия или «стимул—отклик». Достаточность отчёта определяют директора соответствующей области IETF, а в период IETF Last-Call это решение может быть оспорено.
Рабочая группа 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 было показано
корректное взаимодействие по меньшей мере двух генетически не связанных
реализаций со всеми возможностями и опциями. Для этого требования есть
две различные причины.
Первая причина состоит в проверке того, что текст спецификации
достаточно ясен и точен. Это демонстрируется тем, что несколько групп,
реализующих спецификацию, использовали её для создания взаимодействующих
реализаций.
O'Dell, et. al. Лучшая современная практика [Страница 1]
RFC 2438 Продвижение спецификаций MIB Октябрь 1998
Вторая причина состоит в предотвращении чрезмерного числа опций и
«разрастания функциональности». Это достигается требованием
взаимодействующей реализации всех возможностей, включая опции. Если
опция не включена по меньшей мере в две различные взаимодействующие
реализации, можно с уверенностью предположить, что она не была признана
полезной и должна быть удалена, прежде чем спецификация сможет быть
продвинута.
В случае спецификации протокола, определяющей «биты в канале», которыми
обмениваются исполняющиеся автоматы состояний, понятие
«взаимодействия» достаточно интуитивно: реализации должны успешно
«разговаривать друг с другом», обмениваясь «битами в канале» при
использовании всех возможностей и опций.
В случае спецификации базы управляющей информации SNMP (MIB) то, что
именно образует «взаимодействие», менее очевидно. Этот документ
определяет, как IESG решила оценивать «взаимодействие спецификаций MIB»
в контексте Процесса интернет-стандартизации IETF.
Существует ряд правдоподобных толкований взаимодействия спецификаций
MIB; многие из них обоснованны, но имеют весьма разные затраты и
сложности реализации.
Цель состоит в том, чтобы обеспечить достижение двух целей — ясности
спецификации и оценки возможностей — посредством такого толкования
понятия взаимодействия спецификаций MIB, которое уравновешивает
сложность тестирования и практичность.
4. О природе спецификаций MIB
По сравнению с протоколами «автоматов состояний», которые сосредоточены
на процедурных спецификациях, спецификация MIB намного в большей степени
ориентирована на данные. Обобщая чрезмерно, в типичной спецификации MIB
совокупность спецификаций типов данных и экземпляров значительно
превосходит по числу процедурную или причинную семантику между объектами.
Центральный вопрос заключается в том, что спецификация MIB не существует
сама по себе; она образует интерфейс доступа к расположенным под ней
средствам инструментирования. Без средств инструментирования MIB имеет
форму, но не имеет значений. Вместе с большим числом объектов даже в
простой спецификации MIB это приводит к тому, что спецификация MIB по
виду и ощущению больше похожа на API или словарь, чем на протокол
автомата состояний.
Важно различать оценку взаимодействия приложений, которые могут
использовать MIB или взаимодействовать с ними, и самих MIB. Достаточно
очевидно, что к таким приложениям может быть применено тестирование
«чёрного ящика» и что этот подход обладает определённой зрелостью в
практике программной инженерии. Спецификация MIB, с другой стороны,
нелегко поддаётся планам тестирования чёрного ящика.
O'Dell, et. al. Лучшая современная практика [Страница 2]
RFC 2438 Продвижение спецификаций MIB Октябрь 1998
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 будет обеспечение
исходных причин для взаимодействующих реализаций, то есть того, что текст
спецификации ясен и недвусмысленен, а возможности спецификации, не
получившие поддержки, удалены.
O'Dell, et. al. Лучшая современная практика [Страница 3]
RFC 2438 Продвижение спецификаций MIB Октябрь 1998
Отчёт о реализации будет размещён на веб-странице 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.
O'Dell, et. al. Лучшая современная практика [Страница 4]
RFC 2438 Продвижение спецификаций MIB Октябрь 1998
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
O'Dell, et. al. Лучшая современная практика [Страница 5]
RFC 2438 Продвижение спецификаций MIB Октябрь 1998
Приложение 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.
O'Dell, et. al. Лучшая современная практика [Страница 6]
RFC 2438 Продвижение спецификаций MIB Октябрь 1998
Полное заявление об авторских правах
Copyright (C) The Internet Society (1998). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться другим
лицам, а производные работы, комментирующие или иным образом объясняющие
его либо содействующие его реализации, могут подготавливаться,
копироваться, публиковаться и распространяться, полностью или частично,
без ограничений какого бы то ни было рода, при условии, что приведённое
выше уведомление об авторских правах и этот абзац включены во все такие
копии и производные работы. Однако сам этот документ не может изменяться
каким бы то ни было образом, например путём удаления уведомления об
авторских правах или ссылок на Internet Society либо другие интернет-
организации, за исключением случаев, когда это необходимо для разработки
интернет-стандартов, при которой должны соблюдаться процедуры авторских
прав, определённые в Процессе интернет-стандартизации, или когда это
требуется для его перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не
будут отозваны Internet Society либо её правопреемниками или
цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE
ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНО ВЫРАЖЕННЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ ЛЮБЫЕ
ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ
КОНКРЕТНОЙ ЦЕЛИ.
O'Dell, et. al. Лучшая современная практика [Страница 7]
Network Working Group M. O'Dell
Request for Comments: 2438 UUNET Technologies
BCP: 27 H. Alvestrand
Category: Best Current Practice Maxware
B. Wijnen
IBM T. J. Watson Research
S. Bradner
Harvard University
October 1998
Advancement of MIB specifications on the IETF Standards Track
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
2. Abstract
The Internet Standards Process [1] requires that all IETF Standards
Track specifications must have "multiple, independent, and
interoperable implementations" before they can be advanced beyond
Proposed Standard status. This document specifies the process which
the IESG will use to determine if a MIB specification document meets
these requirements. It also discusses the rationale for this
process.
3. The Nature of the Problem
The Internet Standards Process [1] requires that for an IETF
specification to advance beyond the Proposed Standard level, at least
two genetically unrelated implementations must be shown to
interoperate correctly with all features and options. There are two
distinct reasons for this requirement.
The first reason is to verify that the text of the specification is
adequately clear and accurate. This is demonstrated by showing that
multiple implementation efforts have used the specification to
achieved interoperable implementations.
O'Dell, et. al. Best Current Practice [Page 1]
RFC 2438 Advancement of MIB specifications October 1998
The second reason is to discourage excessive options and "feature
creep". This is accomplished by requiring interoperable
implementation of all features, including options. If an option is
not included in at least two different interoperable implementations,
it is safe to assume that it has not been deemed useful and must be
removed before the specification can advance.
In the case of a protocol specification which specifies the "bits on
the wire" exchanged by executing state machines, the notion of
"interoperability" is reasonably intuitive - the implementations must
successfully "talk to each other", exchanging "bits on the wire",
while exercising all features and options.
In the case of an SNMP Management Information Base (MIB)
specification, exactly what constitutes "interoperation" is less
obvious. This document specifies how the IESG has decided to judge
"MIB specification interoperability" in the context of the IETF
Standards Process.
There are a number of plausible interpretations of MIB specification
interoperability, many of which have merit but which have very
different costs and difficulties in realization.
The aim is to ensure that the dual goals of specification clarity and
feature evaluation have been met using an interpretation of the
concept of MIB specification interoperability that strikes a balance
between testing complexity and practicality.
4. On The Nature of MIB specifications
Compared to "state machine" protocols which focus on procedural
specifications, a MIB specification is much more data oriented. To
over-generalize, in a typical MIB specification the collection of
data type and instance specifications outnumbers inter-object
procedural or causal semantics by a significant amount.
A central issue is that a MIB specification does not stand alone; it
forms the access interface to the instrumentation underneath it.
Without the instrumentation, a MIB has form but no values. Coupled
with the large number of objects even in a simple MIB specification,
a MIB specification tends to have more of the look and feel of an API
or a dictionary than a state machine protocol.
It is important to distinguish between assessing the interoperability
of applications which may use or interact with MIBs, and the MIBs
themselves. It is fairly obvious that "black-box testing" can be
O'Dell, et. al. Best Current Practice [Page 2]
RFC 2438 Advancement of MIB specifications October 1998
applied to such applications and that the approach enjoys a certain
maturity in the software engineering arts. A MIB specification, on
the other hand is not readily amenable to black box test plans.
5. Discussion and Recommended Process
In order to meet their obligations under the IETF Standards Process,
the Operations and Management Area Directors and the IESG must be
convinced that each MIB specification advanced to Draft Standard or
Internet Standard status is clearly written, that there are the
required multiple interoperable implementations, and that all options
have been implemented. There are multiple ways to achieve this goal.
Appendix A lists some testing approaches that could be used when
attempting to document multiple implementations.
The Full Coverage or Stimulus-Response approaches are very through,
and would increase confidence that the requirement has been met, if
applied. However, experience in real-world software engineering
makes it clear that such confidence comes at an extremely high price;
even with the most exhaustive testing, it is often not clear what
precisely has been demonstrated by such testing. We believe that
both of those standards of evidence are materially beyond what can be
reasonably accomplished in an operational sense, and achieving the
requisite semantic specifications are even more unlikely.
Therefore, the Operations and Management Area and the IESG have
adopted a more pragmatic approach to determining the suitability of a
MIB specification for advancement on the standards track beyond
Proposed Standard status. Each MIB specification suggested for
advancement must have one or more advocates who can make a convincing
argument that the MIB specification meets the multiple implementation
and feature support requirements of the IETF Standards Process. The
specific way to make the argument is left to the advocate, but will
normally include reports that basic object comparison testing has
been done.
Thus any recommendation for the advancement of a MIB specification
must be accompanied by an implementation report, as is the case with
all requests for the advancement of IETF specifications. The
implementation report must include the reasons why the IESG should
believe that there are multiple implementations of the MIB
specification in question and that the all of the MIB objects in the
specification to be advanced are supported in more than one
implementation. But note that the prime concern of the IESG will be
that the underlying reasons for the interoperable implementations are
met, i.e., that the text of the specification is clear and
unambiguous, and that features of the specification which have not
garnered support have been removed.
O'Dell, et. al. Best Current Practice [Page 3]
RFC 2438 Advancement of MIB specifications October 1998
The implementation report will be placed on the IETF web page along
with the other pre-advancement implementation reports and will be
specifically referred to in the IETF Last-Call. As with all such
implementation reports, the determination of adequacy is made by the
Area Director(s) of the relevant IETF Area. This determination of
adequacy can be challenged during the Last-Call period.
6. Security Considerations
Some may view this policy as possibly leading to a reduction in the
level of confidence people can have in MIB specifications but the O&M
Area Directors and the IESG feel that it will adequately ensure a
reasonable evaluation of the level of clarity of MIB specifications
and to ensure that unused options can be identified and removed
before the advancement of a specification.
Good, clearly written MIB specifications can be of great assistance
in the management of the Internet and other networks and thus assist
in the reduction of some types of security threats.
8. References
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
O'Dell, et. al. Best Current Practice [Page 4]
RFC 2438 Advancement of MIB specifications October 1998
9. Authors' Addresses
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
O'Dell, et. al. Best Current Practice [Page 5]
RFC 2438 Advancement of MIB specifications October 1998
Appendix A
A. Some Testing Alternatives
The IESG debated a number of interoperability and testing models in
formulating this specification. The following list is not an
exhaustive enumeration of the alternatives, but it does capture the
major plausible models which were examined in the course of the
discussion.
A.1 Basic Object Comparison
Assume the requisite two genetically unrelated implementations of the
MIB in an SNMP agent and an SNMP management station which can do a
"MIB Dump" (extract the complete set of MIB object types and values
from the agent implementation). Extract a MIB Dump from each
implementation and compare the two dumps to verify that both provide
the complete set of mandatory and optional objects and that the
individual objects are of the correct types.
A.2 Stimulus/Response Testing
Proceed as in A.1, but in addition, comprehensively exercise the two
(network) elements containing the agent implementations to verify
that all the MIB objects reflect plausible values in operational
conditions. An even stricter interpretation would require that the
MIB objects in the two network elements track identically given the
identical stimulus. While this would test "read-only" or
"monitoring" information obtained from the underlying
instrumentation, it is important to observe that such instrumentation
is actually an *application* which uses the MIB and is not part of
the MIB itself.
A.3 Full Coverage Testing
This model extends the notion of Stimulus/Response Testing to its
logical extreme. The MIB is viewed as an API and the software
engineering notion of full coverage testing is applied to a MIB.
This involves exercising all paths through the causal semantics and
verifying that all objects change state correctly in all cases.
Again, note that much more than the MIB definition is being exercised
and evaluated.
O'Dell, et. al. Best Current Practice [Page 6]
RFC 2438 Advancement of MIB specifications October 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
O'Dell, et. al. Best Current Practice [Page 7]