О документе
Рабочая группа по сетевым вопросам C. Heard, ред.
Запрос комментариев: 4181 Сентябрь 2005
BCP: 111
Категория: Лучшая современная практика
Руководство для авторов и рецензентов MIB-документов
1. Введение
Некоторое время назад IESG ввела политику, требующую экспертного
рецензирования спецификаций IETF на пути стандартизации, содержащих
MIB-модули. Эти рецензирования были установлены, чтобы обеспечить
следование такими спецификациями сложившейся практике документирования
IETF и соответствие содержащихся в них MIB-модулей определённым
общепринятым стандартам качества, включая (но не ограничиваясь этим)
соблюдение всех синтаксических и семантических требований SMIv2
(STD 58) [RFC2578] [RFC2579] [RFC2580], применимых к «стандартным»
MIB-модулям. Цель настоящего меморандума — документировать
рекомендации, которым следуют при таких рецензированиях.
Обратите внимание, что рекомендации настоящего меморандума не
предназначены для изменения требований или запретов (в смысле «ДОЛЖЕН
(MUST)», «НЕ ДОЛЖЕН (MUST NOT)», «ДОЛЖЕН (SHALL)» или «НЕ ДОЛЖЕН
(SHALL NOT)», как определено в RFC 2119 [RFC2119]) существующих BCP
или интернет-стандартов, кроме случаев, когда эти требования или
запреты неоднозначны либо противоречивы. В исключительных случаях,
когда существуют неоднозначности или противоречия, настоящий
меморандум документирует текущее общепринятое толкование. В некоторых
случаях рекомендации настоящего меморандума действительно изменяют
рекомендации (в смысле «СЛЕДУЕТ (SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)»,
«РЕКОМЕНДУЕТСЯ (RECOMMENDED)» или «НЕ РЕКОМЕНДУЕТСЯ (NOT RECOMMENDED)»,
как определено в RFC 2119) существующих BCP или интернет-стандартов.
Это было сделано там, где практический опыт показал неоптимальность
опубликованных рекомендаций. Кроме того, настоящий меморандум содержит
рекомендации по выбору определённых вариантов SMIv2 (в смысле «МОЖЕТ
(MAY)» или «НЕОБЯЗАТЕЛЬНО (OPTIONAL)», как определено в RFC 2119) в
случаях, когда имеется консенсус относительно предпочтительного подхода.
Хотя некоторые рекомендации настоящего меморандума не применимы к
MIB-документам, не относящимся к пути стандартизации или не являющимся
документами IETF, авторам и рецензентам этих документов следует
рассмотреть возможность использования тех из них, которые применимы.
Рецензенты и авторы должны знать, что некоторые рекомендации настоящего
меморандума не применимы к MIB-модулям, переведённым в SMIv2 из SMIv1
(STD 16) [RFC1155] [RFC1212] [RFC1215].
2. Терминология
Ключевые слова «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН (MUST NOT)», «ДОЛЖЕН
(REQUIRED)», «ДОЛЖЕН (SHALL)», «НЕ ДОЛЖЕН (SHALL NOT)», «СЛЕДУЕТ
(SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)», «РЕКОМЕНДУЕТСЯ (RECOMMENDED)»,
«НЕ РЕКОМЕНДУЕТСЯ (NOT RECOMMENDED)», «МОЖЕТ (MAY)» и «НЕОБЯЗАТЕЛЬНО
(OPTIONAL)», когда они используются в рекомендациях настоящего
меморандума, должны толковаться так, как описано в RFC 2119 [RFC2119].
Термины «MIB-модуль» и «информационный модуль» используются в
настоящем меморандуме взаимозаменяемо. В используемом здесь смысле оба
термина относятся к любому из трёх типов информационных модулей,
определённых в разделе 3 RFC 2578 [RFC2578].
Термин «стандартный», когда он приводится в кавычках, используется в
том же смысле, что и в документах SMIv2 [RFC2578] [RFC2579] [RFC2580].
В частности, он используется для обозначения требований, которые эти
документы предъявляют к «стандартным» модулям или «стандартным»
объектам.
3. Общие рекомендации по документированию
В общем случае к спецификациям IETF на пути стандартизации, содержащим
MIB-модули, предъявляются те же требования, что и к RFC IETF на пути
стандартизации (см. [RFC2223bis]), хотя имеются некоторые различия. В
частности, поскольку рассматриваемая версия будет Internet-Draft,
уведомления на титульной странице ДОЛЖНЫ (MUST) соответствовать
требованиям http://www.ietf.org/ietf/1id-guidelines.txt, а не
требованиям [RFC2223bis]. Кроме того, поскольку рассматриваемая
спецификация, как ожидается, будет представлена в IESG, она ДОЛЖНА
(MUST) соответствовать определённым требованиям, которые не обязательно
применимы к RFC; подробности см. в http://www.ietf.org/ID-Checklist.html.
В разделе 4 [RFC2223bis] перечислены разделы, которые могут
существовать в RFC. Разделы, начиная с аннотации, могут также
присутствовать в Internet-Draft; см. http://www.ietf.org/ID-Checklist.html.
«Основная часть меморандума» требуется всегда и в MIB-документе
ДОЛЖНА (MUST) содержать по меньшей мере следующее:
o раздел стандартного текста MIB
o повествовательные разделы
o раздел определений
o раздел «Соображения безопасности»
o раздел «Соображения IANA»
o раздел ссылок
Далее приведены рекомендации по разделам.
3.1. Раздел стандартного текста MIB
Этот раздел ДОЛЖЕН (MUST) содержать дословную копию последней
утверждённой стандартной формулировки Internet-Standard Management
Framework, доступной в сети по адресу
http://www.ops.ietf.org/mib-boilerplate.html.
3.2. Повествовательные разделы
Повествовательная часть ДОЛЖНА (MUST) включать обзорный раздел,
описывающий область и сферу применения MIB-модулей, определённых
спецификацией, и определяющий взаимосвязь (если таковая имеется) этих
MIB-модулей с другими стандартами, особенно со стандартами, содержащими
другие MIB-модули. Повествовательная часть СЛЕДУЕТ (SHOULD) включать
один или несколько разделов для краткого описания структуры MIB-модулей,
определённых спецификацией.
Если MIB-модули, определённые спецификацией, импортируют определения
из других MIB-модулей (кроме определённых в документах SMIv2
[RFC2578] [RFC2579] [RFC2580]) или всегда реализуются совместно с
другими MIB-модулями, то эти факты ДОЛЖНЫ (MUST) быть отмечены в
обзорном разделе, равно как и любые специальные толкования объектов в
других MIB-модулях. Например, так называемые MIB-модули, специфичные
для среды, всегда реализуются совместно с IF-MIB [RFC2863] и ДОЛЖНЫ
(REQUIRED) документировать, как используются определённые объекты в
IF-MIB. Кроме того, MIB-модули, специфичные для среды, которые полагаются
на ifStackTable [RFC2863] и ifInvStackTable [RFC2864] для поддержания
информации о конфигурации и мультиплексировании подуровней интерфейса,
ДОЛЖНЫ (MUST) содержать описание модели уровней.
3.3. Раздел определений
Этот раздел содержит MIB-модуль(и), определённые спецификацией. Эти
MIB-модули ДОЛЖНЫ (MUST) быть написаны на SMIv2 [RFC2578] [RFC2579]
[RFC2580]; SMIv1 [RFC1155] [RFC1212] [RFC1215] имеет статус «НЕ
СЛЕДУЕТ (NOT RECOMMENDED)» [RFC3410] и более не приемлем в MIB-модулях
IETF.
Рекомендации по использованию SMIv2 см. в разделе 4.
3.4. Раздел «Соображения безопасности»
Каждая спецификация, определяющая один или несколько MIB-модулей,
ДОЛЖНА (MUST) содержать раздел, рассматривающий соображения безопасности,
относящиеся к этим модулям. Этот раздел ДОЛЖЕН (MUST) быть составлен по
образцу последнего утверждённого шаблона (доступного по адресу
http://www.ops.ietf.org/mib-security.html). В частности, доступные для
записи MIB-объекты, злоупотребление которыми могло бы вызвать особенно
серьёзные нарушения, ДОЛЖНЫ (MUST) быть явно перечислены по именам, а
связанные с ними риски безопасности ДОЛЖНЫ (MUST) быть изложены; аналогично,
доступные для чтения MIB-объекты, содержащие особенно чувствительную
информацию или вызывающие существенные опасения в отношении
конфиденциальности, ДОЛЖНЫ (MUST) быть явно перечислены по именам, а
причины чувствительности/опасений в отношении конфиденциальности ДОЛЖНЫ
(MUST) быть объяснены. Если для определённой категории MIB-объектов
отсутствуют риски/уязвимости, этот факт ДОЛЖЕН (MUST) быть явно указан.
Отсутствие упоминания конкретной категории MIB-объектов не будет
приравнено к утверждению об отсутствии рисков/уязвимостей в этой категории;
напротив, оно будет расценено как упущение и приведёт к возвращению
документа автору для исправления. Помните, что цель состоит не в
бездумном копировании текста из шаблона, а в обдумывании и оценке
рисков/уязвимостей с последующим изложением/документированием результата
этой оценки.
3.5. Раздел «Соображения IANA»
Чтобы соответствовать политике IESG, изложенной в
http://www.ietf.org/ID-Checklist.html, каждый Internet-Draft,
представляемый IESG для публикации, ДОЛЖЕН (MUST) содержать раздел
«Соображения IANA». Требования к этому разделу различаются в зависимости
от того, какие действия требуются от IANA.
3.5.1. Документы, создающие новое пространство имён
Если Internet-Draft определяет новое пространство имён, которым должна
управлять IANA, то документ ДОЛЖЕН (MUST) включать раздел «Соображения
IANA», соответствующий рекомендациям, установленным в RFC 2434 [RFC2434],
в котором указано, как должно управляться это пространство имён.
Пространства имён, определяемые документами MIB, обычно состоят из диапазона значений некоторого типа (как правило, перечисляемого INTEGER), определяемого TEXTUAL-CONVENTION (TC), либо из набора административно определённых значений OBJECT IDENTIFIER (OID). В каждом случае определения размещаются в автономных модулях MIB, поддерживаемых IANA. Эти поддерживаемые IANA модули MIB отделены от модулей MIB, определённых в спецификациях на пути стандартизации, чтобы новые назначения можно было выполнять без повторной публикации RFC на пути стандартизации. Примеры поддерживаемых IANA модулей MIB включают IANAifType-MIB (http://www.iana.org/assignments/ianaiftype-mib), который определяет пространство имён, используемое IF-MIB [RFC2863], и IANA-RTPROTO-MIB (http://www.iana.org/assignments/ianaiprouteprotocol-mib), который определяет пространство имён, используемое IPMROUTE-STD-MIB [RFC2932].
Текущая практика для таких случаев состоит в том, чтобы включать подробный раздел IANA Considerations, соответствующий RFC 2434, в предложение DESCRIPTION вызова MODULE-IDENTITY в каждом поддерживаемом IANA модуле MIB, а в разделе IANA Considerations документа MIB, определяющего пространства имён, ссылаться на URL соответствующих модулей. Пример см. в RFC 2932 [RFC2932]. Это создаёт проблему «курицы и яйца» для документов MIB, ещё не опубликованных как RFC, поскольку соответствующие поддерживаемые IANA модули MIB ещё не будут существовать. Принятый выход из этой дилеммы состоит в том, чтобы включать первоначальное содержимое каждого поддерживаемого IANA модуля MIB в ненормативный раздел первоначального выпуска документа, определяющего пространство имён; пример см. в [RFC1573], который
описывает первоначальную версию IANAifType-MIB. Этот материал обычно исключается из последующих обновлений документа, поскольку поддерживаемые IANA модули тогда доступны в сети (ср. [RFC2863]).
Рецензенты проектов документов MIB, к которым применимы эти соображения, ДОЛЖНЫ (MUST) проверить, что раздел IANA Considerations, предложенный для публикации в RFC, присутствует и содержит указатели на надлежащие поддерживаемые IANA модули MIB. Рецензенты Internet-Drafts, содержащих предлагаемое первоначальное содержимое поддерживаемых IANA модулей MIB, также ДОЛЖНЫ (MUST) проверить, что предложения DESCRIPTION вызовов MODULE-IDENTITY содержат раздел IANA Considerations, соответствующий руководству RFC 2434.
3.5.2. Документы, требующие назначений в существующих пространствах имён
Если Internet-Draft требует от IANA обновить существующий реестр до публикации в качестве RFC, то раздел IANA Considerations в проекте ДОЛЖЕН (MUST) документировать этот факт. Документы MIB, содержащие первоначальную версию модуля MIB, обычно требуют, чтобы IANA назначила значение OBJECT IDENTIFIER для значения MODULE-IDENTITY модуля MIB и, возможно, также выполнила другие назначения. Internet-Drafts, содержащие такие модули MIB, ДОЛЖНЫ (MUST) содержать раздел IANA Considerations, в котором указаны реестры, подлежащие обновлению, дескрипторы, которым назначаются значения OBJECT IDENTIFIER, и поддеревья, в которых должны распределяться значения. Текст СЛЕДУЕТ (SHOULD) составить так, чтобы после публикации он служил для документирования назначений OBJECT IDENTIFIER. Например, для Internet-Draft, содержащего единственный модуль MIB с дескриптором MODULE-IDENTITY powerEthernetMIB, которому должно быть назначено значение в поддереве 'mib-2', уместно было бы следующее:
Модуль MIB в этом документе использует следующие назначенные IANA
значения OBJECT IDENTIFIER, зарегистрированные в реестре SMI Numbers:
Дескриптор значение OBJECT IDENTIFIER
---------- ---------------------------
powerEthernetMIB { mib-2 XXX }
Примечание редактора (подлежит удалению до публикации): IANA
предлагается назначить значение для "XXX" в поддереве 'mib-2'
и зарегистрировать назначение в реестре SMI Numbers. После
выполнения назначения RFC Editor предлагается заменить
"XXX" (здесь и в модуле MIB) назначенным значением и удалить
это примечание.
Обратите особое внимание: до официального назначения IANA проект документа ДОЛЖЕН (MUST) использовать заполнители (такие как указанное выше «XXX»), а не фактические номера. Пример того, как это делается в проекте модуля MIB, см. в разделе 4.5.
3.5.3. Документы без запросов к IANA
Если Internet-Draft не направляет IANA никаких запросов, то этот факт ДОЛЖЕН (MUST) быть задокументирован в разделе IANA Considerations. Когда Internet-Draft содержит обновление ранее опубликованного модуля MIB, он, как правило, не требует никаких действий со стороны IANA, но может наследовать из RFC, содержащего предыдущую версию модуля MIB, раздел IANA Considerations, документирующий существующие назначения. В таких случаях проект ДОЛЖЕН (MUST) содержать примечание (подлежащее удалению до публикации), прямо указывающее, что от IANA ничего не требуется. Например, проект, содержащий обновлённую версию POWER-ETHERNET-MIB [RFC3621], может включать раздел IANA Considerations следующего вида:
Модуль MIB в этом документе использует следующие назначенные IANA
значения OBJECT IDENTIFIER, зарегистрированные в реестре SMI Numbers:
Дескриптор значение OBJECT IDENTIFIER
---------- ---------------------------
powerEthernetMIB { mib-2 105 }
Примечание редактора (подлежит удалению до публикации): этот проект
не направляет IANA дополнительных запросов.
Если Internet-Draft не направляет IANA никаких запросов и не имеется существующих назначений, которые необходимо документировать, то подходящий текст для проекта мог бы быть приблизительно следующим:
Этот документ не требует действий IANA.
3.6. Разделы ссылок
Раздел 4.7f [RFC2223bis] устанавливает требования к разделам ссылок в RFC; http://www.ietf.org/ID-Checklist.html устанавливает те же требования для Internet-Drafts. В частности, ДОЛЖНЫ (MUST) существовать отдельные списки нормативных и информационных ссылок, каждый в отдельном разделе. Оформление СЛЕДУЕТ (SHOULD) оформлению недавно опубликованных RFC.
Стандартный шаблонный текст MIB, доступный по адресу http://www.ops.ietf.org/mib-boilerplate.html, включает списки нормативных и информационных ссылок, которые ДОЛЖНЫ (MUST) присутствовать во всех спецификациях IETF, содержащих модули MIB.
Если элементы из других модулей MIB появляются в операторе IMPORTS раздела Definitions, то спецификации, содержащие эти модули MIB, ДОЛЖНЫ (MUST) быть включены в список нормативных ссылок. Когда элементы импортируются из поддерживаемого IANA модуля MIB, соответствующая нормативная ссылка ДОЛЖНА (SHALL) указывать на сетевую версию этого модуля MIB. Политика RFC Editor состоит в том, что все ссылки должны цитироваться в тексте; такие цитаты ДОЛЖНЫ (MUST) появляться в обзорном разделе, где необходимо упомянуть документы, содержащие импортированные определения (кроме уже упомянутых в шаблонном тексте MIB) (ср. раздел 3.2).
В общем случае каждая нормативная ссылка СЛЕДУЕТ (SHOULD) указывать на самую последнюю версию рассматриваемой спецификации.
3.7. Уведомления об авторском праве
Документы IETF MIB ДОЛЖНЫ (MUST) содержать уведомления об авторском праве и отказ от ответственности, указанные в разделах 5.4 и 5.5 RFC 3978 [RFC3978]. Авторы и рецензенты ДОЛЖНЫ (MUST) проверять, что в эти уведомления внесён правильный год. Кроме того, предложение DESCRIPTION вызова MODULE-IDENTITY каждого модуля MIB, который появится в опубликованном RFC, ДОЛЖНО (MUST) содержать указатель на уведомления об авторском праве в RFC. Шаблон, пригодный для включения в Internet-Draft и подходящий для модулей MIB, кроме тех, которые будут поддерживаться IANA, приведён ниже:
DESCRIPTION
" [ ... ]
Copyright (C) The Internet Society (date). This version
of this MIB module is part of RFC yyyy; see the RFC
itself for full legal notices."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
Шаблон, пригодный для модулей MIB, которые будут поддерживаться IANA, приведён ниже:
DESCRIPTION
" [ ... ]
Copyright (C) The Internet Society (date). The initial
version of this MIB module was published in RFC yyyy;
for full legal notices see the RFC itself. Supplementary
information may be available at:
http://www.ietf.org/copyrights/ianamib.html."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
В каждом случае вместо слова "date" должен быть указан текущий год.
3.8. Раздел интеллектуальной собственности
Раздел 5 RFC 3979 [RFC3979] содержит уведомление о правах интеллектуальной собственности или иных правах, которое должно присутствовать во всех RFC IETF. Дословная копия этого уведомления СЛЕДУЕТ (SHOULD) присутствовать в каждом документе IETF MIB.
4. Руководство по использованию SMIv2
В общем случае модули MIB в спецификациях IETF на пути стандартизации ДОЛЖНЫ (MUST) соответствовать всем синтаксическим и семантическим требованиям SMIv2 [RFC2578] [RFC2579] [RFC2580], применимым к «стандартным» модулям MIB, и, за исключением указанных ниже случаев, СЛЕДУЕТ (SHOULD) соответствовать рекомендациям SMIv2. Руководство в этом разделе предназначено для дополнения документов SMIv2 следующими способами:
o документировать текущую общепринятую интерпретацию в случаях, когда
эти документы содержат неоднозначности или противоречия;
o обновлять рекомендации в этих документах, которые практический опыт
показал устаревшими или иным образом неоптимальными;
o предоставлять руководство по выбору вариантов SMIv2 в случаях, когда
существует консенсус относительно предпочтительного подхода.
4.1. Имена модулей
Раздел 3 RFC 2578 устанавливает правила для имён модулей. В частности, обратите внимание, что имена «стандартных» модулей ДОЛЖНЫ (MUST) быть уникальными, ДОЛЖНЫ (MUST) соответствовать синтаксическим правилам раздела 3 RFC 2578 и НЕ ДОЛЖНЫ (MUST NOT) изменяться при пересмотре модуля MIB (см. также раздел 10 RFC 2578).
СЛЕДУЕТ (RECOMMENDED), чтобы имена модулей были мнемоническими. Предлагаемые соглашения об именовании см. в приложении C.
4.2. Дескрипторы, имена TC и метки
Разделы 3.1, 7.1.1 и 7.1.4 RFC 2578, а также раздел 3 RFC 2579 рекомендуют, чтобы дескрипторы и имена, связанные с вызовами макросов, и метки, связанные с перечисляемыми значениями INTEGER и BITS, имели длину не более 32 символов, но требуют, чтобы их длина не превышала 64 символов.
Ограничение дескрипторов, имён TC и меток 32 символами часто противоречит рекомендации, чтобы они были мнемоническими, и (для дескрипторов и имён TC) требованию, чтобы они были уникальными (см. раздел 3.1 RFC 2578 и раздел 3 RFC 2579). Консенсус текущего пула рецензентов MIB заключается в том, что рекомендацию SMIv2 ограничивать дескрипторы, имена TC и метки 32 символами СЛЕДУЕТ (SHOULD) отложить в пользу ясности и уникальности и что автоматизированным инструментам, таким как компиляторы MIB, НЕ СЛЕДУЕТ (SHOULD NOT) по умолчанию выдавать предупреждения о нарушении этой рекомендации.
Обратите внимание, что нарушения ограничения в 64 символа НЕ ДОЛЖНЫ (MUST NOT) игнорироваться; они ДОЛЖНЫ (MUST) рассматриваться как ошибки.
Предлагаемые соглашения об именовании дескрипторов и TC см. в приложении C.
4.3. Иерархия именования
Раздел 4 RFC 2578 описывает поддеревья идентификаторов объектов, поддерживаемые IANA, и устанавливает способы использования этих поддеревьев. В частности, поддерево mgmt { iso 3 6 1 2 } используется для идентификации «стандартных» объектов IETF, тогда как поддерево experimental { iso 3 6 1 3 } используется для идентификации объектов, находящихся в разработке IETF. Объекты ДОЛЖНЫ (REQUIRED) перемещаться из поддерева experimental в поддерево mgmt, когда модуль MIB входит на путь стандартизации IETF.
Опыт показал, что непрактично перемещать объекты из одного поддерева в другое, как только эти объекты получили широкомасштабное использование в эксплуатационной среде. Поэтому любой объект, предназначенный для развёртывания в эксплуатационной среде, НЕ ДОЛЖЕН (MUST NOT) регистрироваться в поддереве experimental независимо от статуса стандартизации этого объекта. Поддерево experimental следует использовать только для объектов, предназначенных для ограниченного экспериментального развёртывания. Такие объекты обычно определяются в Experimental RFC.
Примечание: термин «объект» в используемом здесь значении и в разделе 4 RFC 2578 следует толковать широко — как любую конструкцию, приводящую к регистрации OBJECT IDENTIFIER. Список таких конструкций установлен в разделе 3.6 RFC 2578.
4.4. Оператор IMPORTS
Раздел 3.2 RFC 2578 устанавливает, какие символы должны импортироваться, а также перечисляет некоторые предопределённые символы, которые не должны импортироваться.
Общее требование состоит в том, что если используется внешний символ, отличный от предопределённого типа ASN.1 или конструкции BITS, то он ДОЛЖЕН (MUST) быть упомянут в операторе IMPORTS модуля. Слова «внешний объект» в первом абзаце этого раздела могут создавать
впечатление, что такие символы ограничены теми, которые ссылаются на определения объектов, но это не так, как должны прояснить последующие абзацы.
Обратите внимание, что исключения из этого общего требования предоставлены разделами 5.4.3 и 6.5.2 RFC 2580 для дескрипторов объектов, фигурирующих в предложении OBJECT оператора MODULE-COMPLIANCE или в предложении VARIATION оператора AGENT-CAPABILITIES. Некоторые компиляторы MIB также предоставляют исключения для дескрипторов уведомлений, фигурирующих в предложении VARIATION, и для дескрипторов групп объектов и групп уведомлений, на которые ссылаются предложения MANDATORY-GROUPS, GROUP или INCLUDES, хотя RFC 2580 (по-видимому, вследствие упущения) не упоминает эти случаи. Исключения иногда рассматриваются как бесполезные, поскольку они делают правила IMPORTS более сложными, а межмодульные зависимости — менее очевидными, чем они были бы в противном случае. Поэтому внешние символы, на которые ссылаются операторы соответствия и операторы возможностей, МОГУТ (MAY) быть перечислены в операторе IMPORTS; если это сделано, это СЛЕДУЕТ (SHOULD) делать последовательно.
Наконец, хотя SMI этого не запрещает, считается плохим стилем импортировать неиспользуемые символы, и MIB-модули на пути стандартов НЕ ДОЛЖНЫ (SHOULD NOT) этого делать.
4.5. Вызов MODULE-IDENTITY
Раздел 3 RFC 2578 требует, чтобы все MIB-модули SMIv2 начинались ровно с одного вызова макроса MODULE-IDENTITY. Этот вызов ДОЛЖЕН (MUST) располагаться непосредственно после оператора IMPORTS.
В разделе 5 RFC 2578 описано, как используются различные предложения. Следующие дополнительные рекомендации применяются ко всем MIB-модулям, над которыми IETF осуществляет контроль изменений:
- Если модуль был разработан рабочей группой IETF, то предложение
ORGANIZATION ДОЛЖНО (MUST) указывать полное наименование рабочей
группы, а предложение CONTACT-INFO ДОЛЖНО (MUST) включать сведения
о списке рассылки рабочей группы. Предложение CONTACT-INFO также
СЛЕДУЕТ (SHOULD) снабжать указателем на веб-страницу рабочей группы.
- Предложение REVISION ДОЛЖНО (MUST) присутствовать для каждой
редакции MIB-модуля, а время UTC наиболее позднего предложения
REVISION ДОЛЖНО (MUST) совпадать со временем предложения
LAST-UPDATED. Предложение DESCRIPTION, связанное с каждой редакцией,
ДОЛЖНО (MUST) указывать, в каком RFC появилась эта редакция, и
СЛЕДУЕТ (SHOULD) предоставлять список всех существенных изменений.
При пересмотре MIB-модуля времена UTC во всех предложениях REVISION
СЛЕДУЕТ (SHOULD) обновлять с использованием четырёхзначного
обозначения года.
- Значение, присваиваемое дескриптору MODULE-IDENTITY, ДОЛЖНО (MUST)
быть уникальным и (для MIB-модулей IETF на пути стандартов)
СЛЕДУЕТ (SHOULD) располагаться под поддеревом mgmt [RFC2578]. Чаще
всего это будет значение, назначенное IANA непосредственно под
mib-2 [RFC2578], хотя для MIB-модулей, специфичных для среды передачи
и расширяющих IF-MIB [RFC2863], принято использовать назначенное IANA
значение под transmission [RFC2578]. В прошлом некоторые рабочие
группы IETF выполняли собственные назначения из поддеревьев,
делегированных им IANA, но эта практика оказалась проблематичной и
НЕ СЛЕДУЕТ (NOT RECOMMENDED) её применять.
Пока MIB-модуль находится в разработке, номер RFC, в котором он в конечном итоге будет опубликован, обычно неизвестен и должен быть внесён RFC Editor до публикации. Подходящая форма предложения REVISION, применимого к разрабатываемой версии, могла бы выглядеть примерно следующим образом:
REVISION "200212132358Z" -- 13 декабря 2002 г.
DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: замените yyyy фактическим номером RFC и удалите это примечание
Обратите внимание, что после публикации RFC предложение REVISION присутствует только для опубликованных версий MIB-модуля, а не для промежуточных версий, существовавших только в виде Internet-Drafts. Таким образом, черновая версия MIB-модуля ДОЛЖНА (MUST) содержать только одно новое предложение REVISION, охватывающее все изменения после последней опубликованной версии (если таковая имеется).
Когда начальная версия MIB-модуля находится в разработке, значение, присваиваемое дескриптору MODULE-IDENTITY, будет неизвестно, если используется значение, назначаемое IANA, поскольку назначение производится непосредственно перед публикацией в качестве RFC. Принятая форма оператора MODULE-IDENTITY в черновых версиях такого модуля выглядит примерно следующим образом:
<descriptor> MODULE-IDENTITY
[ ... ]
::= { <subtree> XXX }
-- RFC Ed.: замените XXX номером, назначенным IANA, и удалите это примечание
где <descriptor> — любой дескриптор, выбранный для модуля, а <subtree> — поддерево, под которым должен быть зарегистрирован модуль (например, mib-2 или transmission). Обратите внимание, что XXX необходимо временно заменить числом, чтобы модуль мог скомпилироваться.
Особо отметим: до официального назначения IANA черновой документ ДОЛЖЕН (MUST) использовать заполнитель (такой как «XXX» выше), а не фактический номер. Если в процессе разработки желательны пробные реализации, то у IANA может быть получено назначение под поддеревом 'experimental' (см. раздел 4.3).
4.6. Текстовые соглашения и определения объектов
4.6.1. Использование типов данных
4.6.1.1. INTEGER, Integer32, Gauge32 и Unsigned32
32-битные целочисленные типы данных INTEGER, Integer32, Gauge32 и Unsigned32 описаны в разделе 2 RFC 2578 и дополнительно разъяснены в разделах 7.1.1, 7.1.7 и 7.1.11 RFC 2578. Следующие рекомендации применяются при выборе одного из этих типов данных для определения объекта или текстового соглашения:
- Для перечислений с целочисленными значениями:
- INTEGER ДОЛЖЕН (REQUIRED) использоваться; Integer32, Unsigned32 и Gauge32
НЕ ДОЛЖНЫ (MUST NOT) использоваться.
Обратите внимание, что RFC 2578 рекомендует (но не требует), чтобы перечисления с целочисленными значениями начинались с 1 и нумеровались последовательно. Этой рекомендации СЛЕДУЕТ (SHOULD) придерживаться, если только нет обоснованной причины поступить иначе, например для соответствия значениям внешних данных или указания особых случаев, и любое такое использование для особого случая СЛЕДУЕТ (SHOULD) чётко документировать. Пример см. в TC InetAddressType [RFC4001].
Хотя SMI допускает, чтобы предложения DEFVAL для перечислений с целочисленными значениями задавали значение по умолчанию либо меткой, либо числовым значением, форма с меткой предпочтительна, поскольку все примеры в RFC 2578 имеют такую форму, а некоторые инструменты не принимают числовую форму.
- Если диапазон значений находится в пределах от -2147483648 до 2147483647 (включительно) и возможны отрицательные значения, то:
- Integer32 СЛЕДУЕТ (RECOMMENDED) использовать;
- INTEGER допустим;
- Unsigned32 и Gauge32 НЕ ДОЛЖНЫ (MUST NOT) использоваться.
- Если диапазон значений находится в пределах от 0 до 4294967295 (включительно), а значение моделируемой информации может увеличиться выше максимального значения или уменьшиться ниже минимального значения, то:
- Gauge32 СЛЕДУЕТ (RECOMMENDED) использовать;
- Unsigned32 допустим;
- INTEGER и Integer32 НЕ ДОЛЖНЫ (MUST NOT) использоваться, если
возможны значения больше 2147483647.
- Если диапазон значений находится в пределах от 0 до 4294967295 (включительно), возможны значения больше 2147483647, а значение моделируемой информации не увеличивается выше максимального значения и не уменьшается ниже минимального значения, то:
- Unsigned32 СЛЕДУЕТ (RECOMMENDED) использовать;
- Gauge32 допустим;
- INTEGER и Integer32 НЕ ДОЛЖНЫ (MUST NOT) использоваться.
- Если диапазон значений находится в пределах от 0 до 2147483647 (включительно), а значение моделируемой информации не увеличивается выше максимального значения и не уменьшается ниже минимального значения, то:
- Unsigned32 СЛЕДУЕТ (RECOMMENDED) использовать;
- INTEGER, Integer32 и Gauge32 допустимы.
- Для объектов с целочисленными значениями, фигурирующих в предложении INDEX, или для TC с целочисленными значениями, которые будут использоваться в индексном столбце:
- Unsigned32 с диапазоном, исключающим ноль, СЛЕДУЕТ (RECOMMENDED)
использовать для большинства индексных объектов. Допустимо включать
ноль в диапазон, когда он семантически значим или используется как
значение индекса для уникальной строки с особыми свойствами. Такое
использование СЛЕДУЕТ (SHOULD) чётко документировать в предложении
DESCRIPTION.
- Integer32 или INTEGER с неотрицательным диапазоном допустимы.
Опять же, ноль СЛЕДУЕТ (SHOULD) исключать из диапазона, кроме
случаев, когда он семантически значим или используется как значение
индекса для уникальной строки с особыми свойствами, и в таких случаях
использование СЛЕДУЕТ (SHOULD) чётко документировать в предложении
DESCRIPTION.
- Использование Gauge32 допустимо для индексных объектов, обладающих
семантикой gauge.
Приведённые выше рекомендации объединяют как правила использования целочисленных типов данных, так и правила INDEX из раздела 7.7 RFC 2578 вплоть до и включая пункт (1), а также предпоследний абзац на странице 28.
Иногда внешним переменным будет необходимо представлять значения индексного объекта — например, ifIndex [RFC2863]. В таких случаях авторам модуля, содержащего этот объект, СЛЕДУЕТ (SHOULD) рассмотреть определение TC, таких как InterfaceIndex и/или InterfaceIndexOrZero [RFC2863].
Обратите внимание, что INTEGER является предопределённым типом ASN.1 и НЕ ДОЛЖЕН (MUST NOT) присутствовать в операторе IMPORTS модуля, тогда как Integer32, Gauge32 и Unsigned32 определены SNMPv2-SMI и ДОЛЖНЫ (MUST) импортироваться из этого модуля, если используются.
4.6.1.2. Counter32 и Counter64
Counter32 и Counter64 имеют специальную семантику, описанную соответственно в разделах 7.1.6 и 7.1.10 RFC 2578. Определения объектов ДОЛЖНЫ (MUST) (а текстовые соглашения СЛЕДУЕТ (SHOULD)) соблюдать эту семантику. Это означает следующее:
- Допустимо использовать Counter32/64 для счётчиков, которые могут/будут
сбрасываться при повторной инициализации подсистемы управления или при
возникновении других необычных/нерегулярных событий (например,
счётчики, поддерживаемые на линейной карте, могут сбрасываться при
сбросе линейной карты). Однако если возможно возникновение таких других
необычных/нерегулярных событий, предложение DESCRIPTION ДОЛЖНО (MUST)
указывать это и ДОЛЖНО (MUST) описывать эти другие необычные/нерегулярные
события с достаточной подробностью, чтобы приложение управления могло
определить, произошёл ли сброс с момента последнего опроса счётчика.
СЛЕДУЕТ (RECOMMENDED) предоставить индикатор разрыва непрерывности,
описанный в разделах 7.1.6 и 7.1.10 RFC 2578. Пример такого индикатора
разрыва непрерывности см. в объекте ifCounterDiscontinuityTime в IF-MIB
[RFC2863].
- НЕ допускается указывать в предложении DESCRIPTION Counter32/64, что
существует требование, по которому при разрыве непрерывности счётчик
ДОЛЖЕН (MUST) сбрасываться в ноль или в какое-либо другое конкретное
значение.
- НЕ допускается указывать в предложении DESCRIPTION Counter32/64, что
существует требование, по которому он ДОЛЖЕН (MUST) сбрасываться в
какое-либо конкретное время/при конкретном событии (например, в полночь).
- НЕ допускается, чтобы один менеджер запрашивал у агента сброс значений
счётчика(-ов) в ноль, и Counter32/64 — неподходящий синтаксис для
«счётчиков», которые регулярно сами сбрасываются в ноль. Для последних
лучше определить или использовать текстовые соглашения, такие как
приведённые в RFC 3593 [RFC3593] или RFC 3705 [RFC3705].
Раздел 7.1.10 RFC 2578 устанавливает требование для «стандартных» MIB-модулей: тип Counter64 может использоваться только в том случае, если моделируемая информация переполнилась бы менее чем за один час при использовании вместо него типа Counter32. Теперь, когда SNMPv3 является стандартом Интернета, а SNMPv1 имеет исторический статус (сведения о статусе см. в http://www.rfc-editor.org/rfcxx00.html, а обоснование — в [RFC3410]), нет причин продолжать применять это ограничение. В дальнейшем «стандартные» MIB-модули МОГУТ (MAY) использовать тип Counter64, когда это имеет смысл, и ДОЛЖНЫ (MUST) использовать
Counter64, если моделируемая информация переполнилась бы менее чем за один час при использовании вместо него типа Counter32. Также обратите внимание, что более не существует требования определять аналоги Counter32 для каждого объекта Counter64, хотя делать это всё ещё разрешается.
Также существуют тесно связанные текстовые соглашения ZeroBasedCounter32 и ZeroBasedCounter64, определённые в RMON2-MIB [RFC2021] и HCNUM-TC [RFC2856] соответственно.
Единственное различие между TC ZeroBasedCounter32/64 и Counter32/64 состоит в их начальном значении; в момент времени X, где X — их минимальное время до переполнения после их создания, поведение ZeroBasedCounter32/64 становится в точности таким же, как у Counter32/64. Следовательно, предыдущие абзацы/правила применяются не только к Counter32/64, но и к TC ZeroBasedCounter32/64.
4.6.1.3. CounterBasedGauge64
К сожалению, SMIv2 не предоставляет 64-разрядных целочисленных базовых типов. Для восполнения этого упущения в HCNUM-TC [RFC2856] определено текстовое соглашение CounterBasedGauge64. Это TC использует Counter64 в качестве базового типа, но отбрасывает специальную семантику счётчика, что допускается общепринятым толкованием раздела 3.3 RFC 2579. Оно наследует все синтаксические ограничения этого типа, что означает, что его НЕ ДОЛЖНО (MUST NOT) быть возможно уточнить посредством подтипизации, а объекты, определённые с его использованием, НЕ ДОЛЖНЫ (MUST NOT) появляться в предложении INDEX, НЕ ДОЛЖНЫ (MUST NOT) иметь предложение DEFVAL и ДОЛЖНЫ (MUST) иметь MAX-ACCESS со значением read-only или accessible-for-notify.
Это TC СЛЕДУЕТ (SHOULD) использовать для определений объектов, которым требуется 64-разрядный беззнаковый тип данных с семантикой gauge. Если необходим 64-разрядный беззнаковый тип данных с иной семантикой, то ДОЛЖНО (MUST) использоваться другое TC, основанное на Counter64, поскольку одно TC не может уточнять другое (см. раздел 3.5 RFC 2579).
4.6.1.4. OCTET STRING
Тип OCTET STRING описан в разделе 7.1.2 RFC 2578. Он представляет произвольные двоичные или текстовые данные, длина которых составляет от 0 до 65535 октетов включительно. Объекты и TC, чей SYNTAX имеет этот тип, СЛЕДУЕТ (SHOULD) снабжать ограничением размера, когда фактические границы строже, чем ограничения, налагаемые SMI. Это особенно верно для индексных объектов. Однако обратите внимание, что ограничения размера НЕ СЛЕДУЕТ (SHOULD NOT) налагать произвольно, поскольку SMI не допускает их последующего изменения.
Существует ряд стандартных TC, удовлетворяющих некоторым из наиболее распространённых требований к специализированным типам OCTET STRING. В частности, SNMPv2-TC [RFC2579] содержит TC DisplayString, PhysAddress, MacAddress и DateAndTime; SNMP-FRAMEWORK-MIB [RFC3411] содержит TC SnmpAdminString; а SYSAPPL-MIB [RFC2287] содержит TC Utf8String и LongUtf8String. Когда стандартное TC предоставляет требуемую семантику, его СЛЕДУЕТ (SHOULD) использовать в предложении SYNTAX объекта вместо OCTET STRING или эквивалентного TC, определённого локально.
Обратите внимание, что OCTET STRING — предопределённый тип ASN.1 и НЕ ДОЛЖЕН (MUST NOT) присутствовать в операторе IMPORTS модуля.
4.6.1.5. OBJECT IDENTIFIER
Тип OBJECT IDENTIFIER описан в разделе 7.1.3 RFC 2578. Его экземпляры представляют административно назначенные имена. Обратите внимание, что как SMI, так и протокол SNMP ограничивают экземпляры этого типа 128 подидентификаторами и требуют, чтобы каждый подидентификатор находился в диапазоне от 0 до 4294967295 включительно. Подтипизация не допускается.
Назначение значений OBJECT IDENTIFIER состоит в предоставлении авторитетной идентификации либо некоторого типа элемента, либо конкретного экземпляра некоторого типа элемента. Среди элементов, которые могут быть идентифицированы таким образом, — определения в модулях MIB, созданные посредством конструкций MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE и AGENT-CAPABILITIES; а также посредством экземпляров объектов, определённых в модулях MIB, протоколах, языках, спецификациях, типах интерфейсов, аппаратном и программном обеспечении. Для некоторых таких применений существуют иные возможности, например OCTET STRING или перечислимые значения INTEGER. Тип OBJECT IDENTIFIER СЛЕДУЕТ (SHOULD) использовать вместо альтернатив, когда множество идентификационных значений должно быть независимо расширяемым без необходимости в реестре, обеспечивающем централизованную координацию.
Существует ряд стандартных TC, удовлетворяющих некоторым из наиболее распространённых требований к специализированным типам OBJECT IDENTIFIER. В частности, SNMPv2-TC [RFC2579] содержит TC AutonomousType, VariablePointer и RowPointer. Когда стандартное TC предоставляет требуемую семантику, его СЛЕДУЕТ (SHOULD) использовать в предложении SYNTAX объекта вместо OBJECT IDENTIFIER или эквивалентного TC, определённого локально.
Обратите внимание, что OBJECT IDENTIFIER — предопределённый тип ASN.1 и НЕ ДОЛЖЕН (MUST NOT) присутствовать в операторе IMPORTS модуля.
4.6.1.6. Конструкция BITS
Конструкция BITS описана в разделе 7.1.4 RFC 2578. Она представляет перечисление именованных битов. Позиции битов в TC или определении объекта, чей SYNTAX имеет этот тип, ДОЛЖНЫ (MUST) начинаться с 0 и СЛЕДУЕТ (SHOULD) быть непрерывными.
Обратите внимание, что конструкция BITS определяется макросами, которые её используют, и поэтому НЕ ДОЛЖНА (MUST NOT) присутствовать в операторе IMPORTS модуля.
4.6.1.7. IpAddress
Тип IpAddress, описанный в разделе 7.1.5 RFC 2578, НЕ СЛЕДУЕТ (SHOULD NOT) использовать в новых модулях MIB. Вместо него СЛЕДУЕТ (SHOULD) использовать текстовые соглашения InetAddress/InetAddressType [RFC4001].
4.6.1.8. TimeTicks
Тип TimeTicks описан в разделе 7.1.8 RFC 2578. Он представляет время в сотых долях секунды между двумя эпохами, приведённое по модулю 2^32. Его НЕ ДОЛЖНО (MUST NOT) быть возможно уточнить посредством подтипизации, а предложение DESCRIPTION любого объекта или TC, чей SYNTAX имеет этот тип, ДОЛЖНО (MUST) идентифицировать опорные эпохи.
Тип TimeTicks НЕ СЛЕДУЕТ (SHOULD NOT) использовать непосредственно в определениях объектов, которые являются снимками sysUpTime [RFC3418]. TC TimeStamp [RFC2579] уже передаёт требуемую семантику, и вместо TimeTicks СЛЕДУЕТ (SHOULD) использовать его.
4.6.1.9. TruthValue
TC TruthValue определено в SNMPv2-TC [RFC2579]. Это перечислимый тип INTEGER, принимающий значения true(1) и false(2).
Это TC СЛЕДУЕТ (SHOULD) использовать в предложении SYNTAX определений объектов, которым требуется булев тип. Модули MIB НЕ СЛЕДУЕТ (SHOULD NOT) использовать перечислимые типы INTEGER или определять TC, дублирующие его семантику.
4.6.1.10. Другие типы данных
Существует ряд стандартных TC, удовлетворяющих некоторым из наиболее распространённых требований к специализированным типам данных. Некоторые были упомянуты выше, а приложение B содержит частичный список, включающий их, а также некоторые другие, несколько более специализированные. Версию этого списка в Интернете, обновляемую по мере разработки новых TC, можно найти по адресу http://www.ops.ietf.org/mib-common-tcs.html.
Всякий раз, когда стандартное TC уже передаёт требуемую семантику, его СЛЕДУЕТ (SHOULD) использовать в определении объекта вместо соответствующего базового типа или TC, определённого локально. Это особенно верно для TC, определённых в SNMPv2-TC [RFC2579] и SNMP-FRAMEWORK-MIB [RFC3411], поскольку они являются стандартами Интернета, и поэтому продвижение по пути стандартизации модулей, ссылающихся на них, не будет задерживаться из-за таких ссылок.
Авторы модулей MIB должны знать, что перечислимые TC INTEGER или BITS в некоторых случаях могут быть расширены дополнительными перечислимыми значениями или дополнительными позициями битов. Когда импортированное TC, которое может быть расширено таким образом, используется для определения объекта, в который может выполняться запись или который служит индексом в таблице read-create, то множество значений или позиций битов, которое необходимо поддерживать, СЛЕДУЕТ (SHOULD) указать либо в предложении DESCRIPTION объекта, либо в предложении OBJECT в заявлении (заявлениях) о соответствии модуля MIB. Это можно сделать явным перечислением требуемых значений или позиций битов либо указанием, что реализация может поддерживать выбранное ею подмножество значений или позиций битов.
4.6.2. Предложения DESCRIPTION и REFERENCE
Трудно переоценить важность точного и недвусмысленного предложения DESCRIPTION для всех объектов и TC. Предложение DESCRIPTION содержит инструкции, которые реализаторы будут использовать для реализации объекта, и если они недостаточны или неоднозначны, то качество реализации пострадает. Вероятно, важнейшая отдельная задача рецензента MIB состоит в обеспечении того, чтобы предложения DESCRIPTION были достаточно ясными и недвусмысленными для создания взаимодействующих реализаций.
Очень распространённая проблема — увидеть определение объекта, например, 'stdMIBPoofpoofCounter', с предложением DESCRIPTION, которое лишь гласит «Число poofpoof», не указывая, что такое 'poofpoof'. В таких случаях НАСТОЯТЕЛЬНО СЛЕДУЕТ (RECOMMENDED) либо предоставить хотя бы минимальное объяснение, либо включить предложение REFERENCE, указывающее на определение 'poofpoof'.
Для объектов read-write (кроме столбцов в таблицах read-create, которые имеют чётко определённые свойства сохраняемости) СЛЕДУЕТ (RECOMMENDED), чтобы предложение DESCRIPTION указывало, что происходит со значением после перезагрузки агента. Среди возможностей: значение остаётся неизменным, возвращается к чётко определённому значению по умолчанию или результат зависит от реализации.
4.6.3. Предложение DISPLAY-HINT
Предложение DISPLAY-HINT используется в TC для предоставления приложению управления необязывающей подсказки о том, как может отображаться значение экземпляра объекта, определённого с синтаксисом в TC. Его наличие необязательно.
Хотя приложения управления обычно по умолчанию используют десятичный формат ("d") для целочисленных TC, не являющихся перечислениями, и шестнадцатеричный формат ("1x:" или "1x " или "1x_") для TC строк октетов, когда предложение DISPLAY-HINT отсутствует, следует отметить, что SMIv2 фактически не задаёт никаких значений по умолчанию. Авторы MIB должны знать, что ясная подсказка предоставляется приложениям только при наличии предложения DISPLAY-HINT.
4.6.4. Определения концептуальных таблиц
Разделы 7.1.12 и 7.1.12.1 RFC 2578 задают правила определения концептуальных таблиц, а разделы 7.7, 7.8 и 7.8.1 RFC 2578 задают правила индексирования концептуальных таблиц. К таким определениям применяются следующие рекомендации:
- Для концептуальных строк:
- Если строка является расширением строки в некоторой другой таблице, то ДОЛЖНО (MUST) использоваться предложение AUGMENTS, если отношение является отношением «один к одному», и ДОЛЖНО (MUST) использоваться предложение INDEX, если отношение является разреженным. В последнем случае предложение INDEX СЛЕДУЕТ (SHOULD) сделать идентичным предложению исходной таблицы.
- Если строка является элементом таблицы расширения — то есть если нескольким экземплярам строк соответствует один экземпляр строки в некоторой другой таблице, — то ДОЛЖНО (MUST) использоваться предложение INDEX, а первыми упомянутыми элементами СЛЕДУЕТ (SHOULD) сделать индексы той другой таблицы, перечисленные в том же порядке.
- Если в предложении INDEX присутствуют объекты, внешние по отношению к строке, то предложение DESCRIPTION концептуальной строки ДОЛЖНО (MUST) задавать, как эти объекты используются при идентификации экземпляров её столбцовых объектов, и, в частности, ДОЛЖНО (MUST) задавать, для каких значений этих индексных объектов концептуальная строка может существовать.
- Использование ключевого слова IMPLIED НЕ СЛЕДУЕТ (NOT RECOMMENDED) для любого индексного объекта, который может появиться в предложении INDEX таблицы расширения. Поскольку это ключевое слово может быть связано только с последним объектом в предложении INDEX, оно не может быть связано с тем же индексным объектом в первичной таблице и таблице расширения. Это приведёт к различию порядка сортировки в первичной таблице и любых таблицах расширения. Как следствие, реализация не сможет повторно использовать код индексирования из первичной таблицы в таблицах расширения, а структуры данных, предназначенные для расширения, на деле, возможно, придётся дублировать. Разработчикам, испытывающим желание использовать IMPLIED, следует учитывать, что получающийся порядок сортировки редко соответствует ожиданиям пользователей, особенно для строк, включающих как прописные, так и строчные буквы, и он не учитывает язык или локаль пользователя.
- Если поддерживается динамическое создание и/или удаление строк приложениями управления, то:
- СЛЕДУЕТ (SHOULD) иметься один столбцовый объект со значением SYNTAX RowStatus [RFC2579] и значением MAX-ACCESS read-create. Этот объект называется столбцом состояния концептуальной строки. Все остальные столбцовые объекты ДОЛЖНЫ (MUST) иметь значение MAX-ACCESS read-create, read-only, accessible-for-notify или not-accessible; значение MAX-ACCESS read-write не допускается.
- Либо ДОЛЖЕН (MUST) быть один столбцовый объект со значением SYNTAX StorageType [RFC2579] и значением MAX-ACCESS read-create, либо предложение DESCRIPTION объекта строки (элемента таблицы) ДОЛЖНО (MUST) задавать, что происходит с динамически созданными строками после перезапуска агента.
- Если сам агент также может создавать и/или удалять строки, то условия, при которых это может происходить, ДОЛЖНЫ (MUST) быть ясно документированы в предложении DESCRIPTION объекта строки.
- Для концептуальных строк, включающих столбец состояния:
- Предложение DESCRIPTION столбца состояния ДОЛЖНО (MUST) задавать, какие столбцовые объекты (если таковые имеются) должны быть установлены в допустимые значения до того, как строка может быть активирована. Если какие-либо объекты в каскадных таблицах должны быть заполнены связанными данными до того, как строка может быть активирована, то это также ДОЛЖНО (MUST) быть задано.
- Предложение DESCRIPTION столбца состояния ДОЛЖНО (MUST) указывать,
возможно ли изменять другие столбцы в той же
концептуальной строке, когда значение состояния равно active(1).
Обратите внимание, что во многих случаях будет возможно изменять
некоторые доступные для записи столбцы, когда строка активна, но не
другие. В таких случаях предложение DESCRIPTION для каждого доступного
для записи столбца СЛЕДУЕТ (SHOULD) указывать, можно ли изменять этот
столбец, когда строка активна, а предложение DESCRIPTION для столбца
состояния СЛЕДУЕТ (SHOULD) указывать, что возможность изменения других
столбцов, когда значение состояния равно active(1), определена в
предложениях DESCRIPTION для этих столбцов (а не перечислять изменяемые
столбцы по отдельности).
- Для концептуальных строк, включающих столбец StorageType:
- Предложение DESCRIPTION столбца StorageType ДОЛЖНО (MUST) указывать,
какие столбчатые объекты read-write или read-create в строках
permanent(4) агент должен, как минимум, допускать к записи.
Обратите внимание, что RFC 2578, раздел 7.8, требует, чтобы время жизни
экземпляра концептуальной строки, которая AUGMENTS базовую строку, было тем
же, что и у соответствующего экземпляра базовой строки. Отсюда следует, что
в дополняющей строке нет необходимости в столбце RowStatus или StorageType,
если такой столбец уже присутствует в базовой строке.
Полные требования к TC RowStatus и StorageType приведены в RFC 2579, в
предложениях DESCRIPTION для этих TC.
4.6.5. Значения OID, назначенные объектам
В RFC 2578, разделе 7.10, определены правила назначения значений OBJECT
IDENTIFIER (OID) определениям OBJECT-TYPE. В частности:
- Концептуальная таблица ДОЛЖНА (MUST) иметь ровно один подчинённый объект,
которым является концептуальная строка. OID, назначенный концептуальной
строке, ДОЛЖЕН (MUST) быть получен добавлением субидентификатора "1" к
OID, назначенному концептуальной таблице.
- Концептуальная строка имеет столько подчинённых объектов, сколько в строке
столбцов; ДОЛЖЕН (MUST) быть как минимум один. OID, назначенный каждому
столбчатому объекту, ДОЛЖЕН (MUST) быть получен добавлением ненулевого
субидентификатора, уникального в пределах строки, к OID, назначенному
концептуальной строке.
- Столбчатый или скалярный объект НЕ ДОЛЖЕН (MUST NOT) иметь каких-либо
подчинённых объектов.
- Последний субидентификатор OID, назначенного любому объекту (будь то
таблица, строка, столбец или скаляр), НЕ ДОЛЖЕН (MUST NOT) быть равен
нулю. Обратите внимание, что субидентификаторы промежуточных узлов МОГУТ
(MAY) быть равны нулю.
- OID, назначенный определению объекта, НЕ ДОЛЖЕН (MUST NOT) также
назначаться другому определению, приводящему к регистрации OID. В RFC
2578, разделе 3.6, перечислены конструкции, создающие регистрации OID.
Хотя это специально не требуется SMI, принято (и настоятельно
СЛЕДУЕТ (RECOMMENDED)), чтобы определения объектов не регистрировались
ниже определений групп, утверждений соответствия, утверждений возможностей
или определений уведомлений. Также принято (и настоятельно
СЛЕДУЕТ (RECOMMENDED)), чтобы определения групп, утверждения
соответствия,
утверждения возможностей и определения уведомлений не регистрировались ниже
определений объектов. См. в Приложении D схему назначения OID, использовать
которую СЛЕДУЕТ (RECOMMENDED).
4.6.6. Ограничения длины OID и индексирование таблиц
Как определено в RFC 2578, разделе 3.5, все OID ограничены 128
субидентификаторами. Хотя это вряд ли вызовет проблемы при административных
назначениях, это накладывает некоторые ограничения на индексирование таблиц.
Это верно потому, что ограничение длины также применяется к OID экземпляров
объектов, а они состоят из конкатенации «базового» OID, назначенного в
определении объекта, и компонентов индекса. Когда таблица имеет несколько
индексов таких типов, как OCTET STRING или OBJECT IDENTIFIER, которые
разрешаются в несколько субидентификаторов, предел в 128 субидентификаторов
может быть быстро достигнут.
Несмотря на неудобство, предел в 128 субидентификаторов не является чем-то,
что можно игнорировать. Помимо того, что он устанавливается SMI, он также
устанавливается SNMP (см. последний абзац раздела 4.1 RFC 3416 [RFC3416]).
Отсюда следует, что любая таблица с достаточным числом компонентов
индексирования, чтобы нарушить этот предел, не может быть прочитана или
записана с использованием SNMP и поэтому непригодна к использованию.
Следовательно, при проектировании таблицы ДОЛЖЕН (MUST) учитываться предел в
128 субидентификаторов. СЛЕДУЕТ (RECOMMENDED), чтобы все документы MIB
явно указывали любые ограничения на длины компонентов индекса, которые
программное обеспечение управления должно соблюдать. Это может быть сделано
либо включением ограничений SIZE для компонентов индекса, либо указанием
применимых ограничений в предложении DESCRIPTION концептуальной строки или в
окружающей документации.
4.7. Определения уведомлений
В RFC 2578, разделе 8, определены правила для определений уведомлений.
В частности:
- Недоступные объекты НЕ ДОЛЖНЫ (MUST NOT) присутствовать в предложении
OBJECTS.
- Для каждого типа объекта, упомянутого в предложении OBJECTS, предложение
DESCRIPTION ДОЛЖНО (MUST) указывать, какой экземпляр объекта должен
присутствовать в передаваемом уведомлении, и ДОЛЖНО (MUST) указывать
передаваемую информацию/смысл.
- Значение OBJECT IDENTIFIER (OID), назначенное каждому типу уведомления,
ДОЛЖНО (MUST) иметь предпоследний субидентификатор, равный нулю, чтобы
было возможно преобразовать определение уведомления SMIv2 в определение
ловушки SMIv1 и обратно без потери информации (см. раздел 2.1.2
[RFC3584]) и чтобы цепочка многоязычных прокси могла преобразовать
ловушку SNMPv2 в ловушку SNMPv1 и обратно без потери информации (см.
раздел 3 [RFC3584]). Кроме того,
OID, назначенный определению уведомления, НЕ ДОЛЖЕН (MUST NOT) также
назначаться другому определению, приводящему к регистрации OID. В RFC
2578, разделе 3.6, перечислены конструкции, создающие регистрации OID.
Хотя это специально не требуется SMI, принято (и настоятельно
СЛЕДУЕТ (RECOMMENDED)), чтобы определения уведомлений не
регистрировались ниже определений групп, утверждений соответствия,
утверждений возможностей или определений объектов (последнее особенно
неразумно, поскольку может привести к тому, что экземпляр объекта и
определение уведомления будут совместно использовать один и тот же OID).
Также принято (и настоятельно СЛЕДУЕТ (RECOMMENDED)), чтобы OID,
назначенные типам уведомлений, были листовыми OID (то есть чтобы не было
регистраций OID, подчинённых определению уведомления). См. в Приложении D
схему назначения OID, использовать которую СЛЕДУЕТ (RECOMMENDED).
Во многих случаях уведомления будут запускаться внешними событиями, и иногда
эти внешние события смогут происходить с настолько высокой частотой, что
отправка уведомления для каждого случая перегрузит сеть. В таких случаях
ДОЛЖЕН (MUST) быть предусмотрен механизм ограничения частоты, с которой
уведомление может генерироваться. Обычный метод состоит в требовании, чтобы
генератор уведомлений использовал ограничение частоты — то есть в требовании,
чтобы он генерировал не более одного уведомления для каждого источника
события в любом заданном интервале времени длительностью T. Период
ограничения частоты T МОЖЕТ (MAY) быть настраиваемым, в таком случае он
указывается в объекте MIB, или он МОЖЕТ (MAY) быть фиксированным, в таком
случае он указывается в определении уведомления. Примеры метода
фиксированного интервала времени можно найти в SNMP-REPEATER-MIB [RFC2108] и
в ENTITY-MIB [RFC4133].
4.8. Утверждения соответствия
В RFC 2580, разделах 3, 4 и 5, определены правила для групп соответствия и
утверждений соответствия. В частности:
- Каждый объект со значением MAX-ACCESS, отличным от "not-accessible",
ДОЛЖЕН (MUST) содержаться по крайней мере в одной группе объектов.
- Каждое уведомление ДОЛЖНО (MUST) содержаться по крайней мере в одной
группе уведомлений.
- Для каждого «стандартного» модуля MIB ДОЛЖНО (MUST) быть определено по
крайней мере одно утверждение соответствия. Оно может находиться либо в
этом модуле MIB, либо в сопутствующем модуле MIB.
При написании утверждений соответствия есть несколько моментов, которые
легко упустить:
- Группа объектов или группа уведомлений, которая не упомянута ни в
предложении MANDATORY-GROUPS, ни в каком-либо предложении GROUP утверждения
MODULE-COMPLIANCE, является безусловно необязательной относительно этого
утверждения соответствия. Альтернативный способ указать, что группа
объектов или группа уведомлений необязательна, — упомянуть её в
предложении GROUP, предложение DESCRIPTION которого указывает, что группа
необязательна. Последний метод СЛЕДУЕТ (RECOMMENDED) применять (для
необязательных групп, относящихся к утверждению соответствия), чтобы было
ясно, что необязательный статус предусмотрен намеренно, а не является
результатом упущения.
- Если имеются какие-либо объекты со значением MAX-ACCESS read-write или
read-create, для которых нет предложения OBJECT, указывающего MIN-ACCESS
read-only, то реализации должны поддерживать доступ на запись к этим
объектам, чтобы соответствовать этому утверждению MODULE-COMPLIANCE. Этот
факт иногда застаёт авторов модулей MIB врасплох. Столкнувшись с такими
случаями, рецензентам СЛЕДУЕТ (SHOULD) проверить, что именно это авторы
намеревались указать, поскольку часто это не так.
- С другой стороны, авторам модулей MIB следует знать, что, хотя утверждение
соответствия только для чтения достаточно для поддержки совместимых
приложений мониторинга, оно недостаточно для поддержки совместимых
приложений конфигурирования. Метод, обычно используемый в модулях MIB,
предназначенных для поддержки и мониторинга, и конфигурирования, состоит
в предоставлении как утверждения соответствия только для чтения, так и
полного утверждения соответствия. Хороший пример приводится в
DIFFSERV-MIB [RFC3289]. Авторам СЛЕДУЕТ (SHOULD) рассмотреть использование
этого метода, когда он применим.
Иногда авторы модулей MIB захотят указать, что соответствующая реализация
должна поддерживать только подмножество значений, допускаемых предложением
SYNTAX объекта. Для доступных объектов это может быть сделано либо указанием
требуемых значений в предложении DESCRIPTION объекта, либо предоставлением
предложения OBJECT с уточнённым SYNTAX в утверждении соответствия. Последний
метод СЛЕДУЕТ (RECOMMENDED) применять в большинстве случаев и ДОЛЖЕН
(REQUIRED) применяться, если имеется несколько утверждений соответствия с
требуемыми разными подмножествами значений. DIFFSERV-MIB [RFC3289]
иллюстрирует этот момент. Утверждение diffServMIBFullCompliance содержит
следующее предложение OBJECT. (См. раздел 4.8.1, «Примечание относительно
этих примеров и RFC 2578».)
OBJECT diffServDataPathStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
тогда как утверждение diffServMIBReadOnlyCompliance содержит следующее:
OBJECT diffServDataPathStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the only status that
needs to be supported."
Нельзя сделать это для недоступных объектов индекса, поскольку они не могут
присутствовать в группах объектов и не могут упоминаться в предложениях
OBJECT. Однако существуют ситуации, в которых может быть желательно указать,
что реализация обязана поддерживать только подмножество возможных значений
некоторого индекса в таблице read-create. В таких случаях требования ДОЛЖНЫ
(MUST) быть указаны либо в предложении DESCRIPTION объекта индекса
(СЛЕДУЕТ (RECOMMENDED), если имеется только одно подмножество значений),
либо в предложении DESCRIPTION утверждения MODULE-COMPLIANCE (ДОЛЖНО
(REQUIRED) быть указано здесь, если подмножество значений уникально для
утверждения соответствия).
Во многих случаях модуль MIB всегда реализуется совместно с одним или несколькими другими модулями MIB. Этот факт ДОЛЖЕН (REQUIRED) быть отмечен в сопроводительной документации (см. раздел 3.2 выше), а также СЛЕДУЕТ (SHOULD) отметить его в соответствующих утверждениях соответствия. В случаях, когда конкретное утверждение соответствия, например, в модуле MIB A требует полной реализации некоторого другого модуля MIB B, РЕКОМЕНДУЕМЫЙ (RECOMMENDED) подход состоит в том, чтобы включить утверждение об этом в клаузу DESCRIPTION утверждения (утверждений) соответствия в модуле MIB A. Однако также возможно, что модуль MIB A может иметь требования, отличающиеся от требований, выраженных каким-либо утверждением соответствия модуля B, — например, модуль A может не требовать ни одной из безусловно обязательных групп объектов из модуля B, но требовать обязательной реализации группы объектов из модуля B, которая является обязательной лишь при определённых условиях относительно утверждения (утверждений) соответствия в модуле B. В таких случаях РЕКОМЕНДУЕМЫЙ (RECOMMENDED) подход состоит в том, чтобы утверждение (утверждения) соответствия в модуле A формально задавало требования относительно модуля B посредством надлежащих клауз MODULE, MANDATORY-GROUPS, GROUP и OBJECT. Примером служат утверждения соответствия в DIFFSERV-MIB [RFC3289], в которых ifCounterDiscontinuityGroup из IF-MIB [RFC2863] указан как обязательная группа. Эта группа недостаточна для выполнения какого-либо утверждения соответствия IF-MIB и является условно обязательной в текущем утверждении соответствия IF-MIB ifCompliance3.
4.8.1. Примечание относительно этих примеров и RFC 2578
Существовали разногласия относительно того, разрешены ли уточнения синтаксиса, ограничивающие перечисления (раздел 9 RFC 2578), с TC, как показано в примерах выше, либо они разрешены только с базовыми типами INTEGER и BITS, как следует из строгого прочтения RFC 2578. Приблизительный консенсус редакторов документов SMIv2 и нынешнего сообщества рецензентов MIB состоит в том, что они должны быть разрешены с TC. Авторам модулей MIB следует учитывать, что некоторые компиляторы MIB придерживаются строгого прочтения RFC 2578 и требуют заменять TC его базовым типом (INTEGER или BITS), когда перечисления уточняются. Такое использование является законным и встречается в некоторых старых модулях MIB, таких как IF-MIB [RFC2863].
4.9. Редакции модулей MIB
Раздел 10 RFC 2578 задаёт общие правила, применяемые всякий раз при пересмотре модуля MIB. В частности:
- Вызов MODULE-IDENTITY ДОЛЖЕН (MUST) быть обновлён, чтобы включать сведения о редакции. В частности, значение клаузы LAST-UPDATED ДОЛЖНО (MUST) быть установлено равным времени редакции, ДОЛЖНА (MUST) быть добавлена клауза REVISION с тем же временем UTC и связанная с ней клауза DESCRIPTION, описывающая изменения, а вся устаревшая информация в существующих клаузах DESCRIPTION, ORGANIZATION и CONTACT-INFO ДОЛЖНА (MUST) быть заменена актуальной информацией. Дополнительные требования, применимые к модулям MIB, находящимся под контролем изменений IETF, см. в разделе 4.5 выше.
- С другой стороны, имя модуля НЕ ДОЛЖНО (MUST NOT) изменяться (кроме исправления типографических ошибок), существующие определения (даже устаревшие) НЕ ДОЛЖНЫ (MUST NOT) удаляться из модуля MIB, а дескрипторы и значения OBJECT IDENTIFIER, связанные с существующими определениями, НЕ ДОЛЖНЫ (MUST NOT) изменяться или назначаться повторно.
Важно отметить, что цель запрета некоторых видов изменений — обеспечить совместимость пересмотренного модуля MIB с развёрнутыми реализациями, основанными на предыдущих версиях модуля. У этого требования обратной совместимости есть два различных аспекта. Один — совместимость «по проводу» реализаций агента и менеджера, основанных на разных редакциях модуля MIB. Другой — совместимость «при компиляции» с модулями MIB, импортирующими определения из пересмотренного модуля MIB. Правила, запрещающие изменять или повторно назначать значения OBJECT IDENTIFIER, необходимы для обеспечения совместимости «по проводу»; правила против изменения имён модулей или дескрипторов либо удаления устаревших определений необходимы для обеспечения совместимости при компиляции.
Раздел 10.2 RFC 2578 задаёт правила, применимые к редакциям определений объектов. Следующие рекомендации исправляют некоторые ошибки в этих правилах и вносят некоторые уточнения:
- Пункт (1) разрешает изменять метки именованных чисел и именованных битов в клаузах SYNTAX типа перечислимого INTEGER или BITS. Это может нарушить совместимость при компиляции, поскольку эти метки могут использоваться клаузами DEFVAL в модулях, импортирующих определения затронутых объектов. Поэтому метки именованных чисел и именованных битов НЕ ДОЛЖНЫ (MUST NOT) изменяться при пересмотре модулей MIB IETF (кроме исправления типографических ошибок), и им НЕ СЛЕДУЕТ (SHOULD NOT) изменяться при пересмотре корпоративных модулей MIB.
- Хотя это специально не разрешено пунктами (1)–(8), обычно считается приемлемым добавлять ограничения диапазона к клаузе SYNTAX объекта с целочисленным значением при условии, что ограничения лишь делают явными некоторые ограничения значений, неявно содержащиеся в определении объекта. Наиболее распространённый пример — вспомогательный объект с SYNTAX INTEGER или Integer32 без ограничения диапазона. Поскольку вспомогательному объекту не разрешено принимать отрицательные значения, добавление ограничения диапазона (0..2147483647) никоим образом не может привести к какому-либо изменению «по проводу» и не вызовет проблем совместимости при компиляции с корректно написанным модулем MIB. Такое изменение СЛЕДУЕТ (SHOULD) рассматривать рецензенту как редакционное, а не как семантическое изменение. Аналогично, удаление ограничения диапазона или размера из определения объекта, когда это ограничение диапазона или размера обеспечивается базовым типом данных, СЛЕДУЕТ (SHOULD) рассматривать рецензенту как редакционное изменение.
Раздел 10.3 RFC 2578 задаёт правила, применимые к редакциям определений уведомлений. Уточнения или исправления не требуются.
Раздел 5 RFC 2579 задаёт правила, применимые к редакциям определений текстовых соглашений. Следующая рекомендация исправляет ошибку в этих правилах:
- Пункт (1) разрешает изменять метки именованных чисел и именованных битов в клаузах SYNTAX типа перечислимого INTEGER или BITS. Это может нарушить совместимость при компиляции, поскольку эти метки могут использоваться клаузами DEFVAL в модулях, импортирующих определения затронутых TC. Поэтому метки именованных чисел и именованных битов НЕ ДОЛЖНЫ (MUST NOT) изменяться при пересмотре модулей MIB IETF (кроме исправления типографических ошибок), и им НЕ СЛЕДУЕТ (SHOULD NOT) изменяться при пересмотре корпоративных модулей MIB.
Раздел 7.1 RFC 2580 задаёт правила, применимые к редакциям групп соответствия. Два пункт стоит повторить:
- Объекты и уведомления НЕ ДОЛЖНЫ (MUST NOT) добавляться в существующую группу объектов или группу уведомлений либо удаляться из неё. Это может вызвать сбой компиляции или, что хуже, незаметное изменение смысла утверждения соответствия либо утверждения возможностей, ссылающегося на эту группу.
- Статус группы соответствия не зависит от статуса её членов. Таким образом, текущая группа МОЖЕТ (MAY) ссылаться на устаревшие объекты или уведомления. В некоторых случаях это может быть желательным: например, набор широко развёрнутых объектов или уведомлений может быть признан устаревшим при их замене более актуальным набором определений, но содержащие их группы соответствия могут оставаться текущими, чтобы поощрять продолжение реализации устаревших объектов и уведомлений.
Раздел 7.2 RFC 2580 задаёт правила, применимые к редакциям утверждений соответствия. Следующие рекомендации исправляют упущение в этих правилах и подчёркивают один важный момент:
- RFC 2580 следовало бы (но он этого не делает) рекомендовать добавление в утверждение соответствия клаузы OBJECT, задающей поддержку исходного набора значений, когда перечислимый объект INTEGER или объект BITS, на который ссылается утверждение соответствия, получает добавленные перечисления или именованные биты, при условии, что такая клауза ещё отсутствует и что действующее значение MIN-ACCESS равно read-write или read-create. Это необходимо, чтобы избежать незаметного изменения смысла утверждения соответствия. Авторам и рецензентам модулей MIB СЛЕДУЕТ (SHOULD) следить за этим, чтобы такие клаузы OBJECT добавлялись, когда это необходимо. Обратите внимание, что это не всегда возможно сделать, поскольку затронутые утверждения соответствия могут находиться в модулях, отличных от того, который содержит пересмотренное определение (пересмотренные определения).
- Статус утверждения соответствия не зависит от статуса его членов. Таким образом, текущее утверждение соответствия МОЖЕТ (MAY) ссылаться на устаревшие группы объектов или группы уведомлений. В некоторых случаях это может быть желательным: например, набор широко развёрнутых групп объектов или уведомлений может быть признан устаревшим при их замене более актуальным набором определений, но утверждения соответствия, ссылающиеся на них, могут оставаться текущими, чтобы поощрять продолжение реализации устаревших групп.
Раздел 7.3 RFC 2580 задаёт правила, применимые к редакциям утверждений возможностей. Следующая рекомендация исправляет упущение в этих правилах:
- RFC 2580 следовало бы (но он этого не делает) рекомендовать добавление в утверждение возможностей клауз VARIATION, задающих поддержку исходного набора значений, когда перечислимым объектам INTEGER или объектам BITS, на которые ссылается утверждение возможностей, добавляются перечисления, при условии, что такие клаузы ещё отсутствуют. Это необходимо, чтобы избежать незаметного изменения смысла утверждения возможностей.
В некоторых исключительных ситуациях стоимость строгого соблюдения правил SMIv2, регулирующих редакции модулей MIB, может превышать выгоду. В таких случаях от правил можно отказаться, но, когда это делается, как изменение, так и его обоснование ДОЛЖНЫ (MUST) быть тщательно документированы. Один пример приведён в разделе 3.1.5 RFC 2863, где документируется семантическое изменение, внесённое в ifIndex при переходе от MIB-II [RFC1213] к IF-MIB [RFC2863], и даётся подробное обоснование этого изменения. Другой пример приведён в клаузе REVISION SONET-MIB [RFC2558], где документируется повышение MAX-ACCESS нескольких объектов до read-write при добавлении MIN-ACCESS read-only для совместимости с предыдущей версией [RFC1595].
Авторам и рецензентам может быть полезно использовать инструменты, способные перечислять различия между двумя редакциями модуля MIB. Дополнительную информацию см. по адресу http://www.ops.ietf.org/mib-review-tools.html.
5. Благодарности
Большая часть материала об использовании типов данных была основана на материалах, предоставленных Бертом Вейнненом при содействии Кейта Макклогри, Дэвида Т. Перкинса и Юргена Шёнвельдера. Значительная часть другого материала об использовании SMIv2 была взята из неопубликованного руководства для авторов и рецензентов MIB Юргена Шёнвельдера. Некоторые рекомендации в этих руководящих принципах основаны на материале из онлайн-списка исправлений SMIv2 по адресу http://www.ibr.cs.tu-bs.de/ietf/smi-errata/. Благодарности Франку Штраусу и Юргену Шёнвельдеру за ведение этого списка, а также участникам, предоставившим для него материал. Наконец, выражается благодарность следующим лицам, чьи комментарии к предыдущим версиям этой записки содержали много ценных предложений по дополнениям, уточнениям и исправлениям: Andy Bierman, Bob Braden, Michelle Cotton, David Harrington, Harrie Hazewinkel, Dinakaran Joseph, Michael Kirkham, Keith McCloghrie, David T. Perkins, Randy Presuhn, Dan Romascanu, Juergen Schoenwaelder, Frank Strauss, Dave Thaler и Bert Wijnen.
6. Соображения безопасности
Реализация и развёртывание модуля MIB в системе могут привести к рискам безопасности, которые иначе не существовали бы. Авторам и рецензентам документов, определяющих модули MIB, важно обеспечить полное соответствие этих документов руководящим принципам по адресу http://www.ops.ietf.org/mib-security.html, чтобы все такие риски были надлежащим образом раскрыты.
7. Соображения IANA
Этот документ затрагивает IANA постольку, поскольку описывает, что должно присутствовать в разделе «Соображения IANA» документа MIB, но не требует, чтобы IANA обновляла какой-либо существующий реестр или создавала какой-либо новый реестр.
Приложение A: Контрольный список проверки MIB
Цель обзора MIB состоит в проверке модуля MIB как на техническую корректность, так и на соответствие требованиям IETF к документации. Следующий контрольный перечень может быть полезен при рассмотрении проекта документа:
1.) Шаблонный текст I-D — убедитесь, что проект содержит требуемый шаблонный текст Internet-Draft (см. http://www.ietf.org/ietf/1id-guidelines.txt), включая соответствующее положение, разрешающее публикацию в качестве RFC, и что шаблонный текст I-D не содержит ссылок или номеров разделов.
2.) Аннотация — убедитесь, что аннотация не содержит ссылок, не имеет номера раздела и что её содержание соответствует рекомендациям в http://www.ietf.org/ietf/1id-guidelines.txt.
3.) Шаблонный текст MIB — убедитесь, что проект содержит последнюю утверждённую формулировку о SNMP Network Management Framework с веб-сайта области OPS (http://www.ops.ietf.org/mib-boilerplate.html).
4.) Раздел «Соображения безопасности» — убедитесь, что проект использует последний утверждённый шаблон с веб-сайта области OPS (http://www.ops.ietf.org/mib-security.html) и что приведённые там рекомендации соблюдены.
5.) Раздел «Соображения IANA» — этот раздел должен всегда присутствовать. Если проект не требует действий со стороны IANA, убедитесь, что это явно отмечено. Если проект требует назначения значений OID, убедитесь, что раздел «Соображения IANA» содержит информацию, указанную в разделе 3.5 настоящих рекомендаций. Если проект содержит начальную версию модуля, сопровождаемого IANA, убедитесь, что вызов MODULE-IDENTITY содержит инструкции по сопровождению, соответствующие требованиям RFC 2434. В последнем случае раздел «Соображения IANA», который будет включён в RFC, ДОЛЖЕН (MUST) содержать указатель на фактический модуль, сопровождаемый IANA.
6.) Ссылки — убедитесь, что ссылки надлежащим образом разделены на нормативные и информационные, что RFC 2119 включён как нормативная ссылка, если в документе используется определённая в нём терминология, что присутствуют все ссылки, требуемые шаблонным текстом, что все модули MIB, содержащие импортируемые элементы, процитированы как нормативные ссылки и что все цитаты указывают на наиболее актуальные RFC, если только нет веской причины поступить иначе (например, допустимо включить информационную ссылку на предыдущую версию спецификации, чтобы помочь объяснить функцию, включённую для обратной совместимости).
7.) Уведомления об авторских правах — убедитесь, что проект содержит сокращённое уведомление об авторских правах в клаузе DESCRIPTION каждого вызова MODULE-IDENTITY и что в конце документа он содержит полное уведомление об авторских правах и отказ от ответственности, указанные в разделах 5.4 и 5.5 RFC 3978. Убедитесь, что во всех датах авторских прав указан правильный год.
8.) Уведомление об IPR — если проект не содержит дословной копии уведомления об IPR, указанного в разделе 5 RFC 3979, рекомендуйте включить уведомление об IPR.
9.) Прочие вопросы — проверьте наличие любых вопросов, упомянутых в http://www.ietf.org/ID-Checklist.html, которые не охвачены в других местах.
10.) Техническое содержание — проверьте фактическое техническое содержание на соответствие рекомендациям этого документа. При проверке синтаксических ошибок рекомендуется использовать компилятор MIB; дополнительную информацию см. в http://www.ops.ietf.org/mib-review-tools.html. Однако проверка правильности синтаксиса — лишь часть работы. Не менее важно фактически прочитать документ MIB с точки зрения потенциального реализатора. Особенно важно проверить, что клаузы DESCRIPTION достаточно ясны и недвусмысленны, чтобы можно было создать совместимые реализации.
Приложение B: Часто используемые текстовые соглашения
Следующие TC определены в SNMPv2-TC [RFC2579]:
DisplayString OCTET STRING (SIZE (0..255))
PhysAddress OCTET STRING
MacAddress OCTET STRING (SIZE (6))
TruthValue enumerated INTEGER
TestAndIncr INTEGER (0..2147483647)
AutonomousType OBJECT IDENTIFIER
VariablePointer OBJECT IDENTIFIER
RowPointer OBJECT IDENTIFIER
RowStatus enumerated INTEGER
TimeStamp TimeTicks
TimeInterval INTEGER (0..2147483647)
DateAndTime OCTET STRING (SIZE (8 | 11))
StorageType enumerated INTEGER
TDomain OBJECT IDENTIFIER
TAddress OCTET STRING (SIZE (1..255))
Примечание 1. InstancePointer устарел и НЕ ДОЛЖЕН (MUST NOT) использоваться.
Примечание 2. DisplayString не поддерживает интернационализированный текст. Он
НЕ ДОЛЖЕН (MUST NOT) использоваться для объектов, которые должны содержать
интернационализированный текст (что всегда имеет место, если
объект предназначен для использования людьми [RFC2277]). Разработчикам
СЛЕДУЕТ (SHOULD) рассмотреть использование SnmpAdminString, Utf8String или
LongUtf8String для таких объектов.
Примечание 3. TDomain и TAddress НЕ СЛЕДУЕТ (SHOULD NOT) использовать в новых модулях MIB.
Вместо них СЛЕДУЕТ (SHOULD) использовать TC TransportDomain, TransportAddressType и
TransportAddress (определённые в TRANSPORT-ADDRESS-MIB
[RFC3419]).
Следующий TC определён в SNMP-FRAMEWORK-MIB [RFC3411]:
SnmpAdminString OCTET STRING (SIZE (0..255))
Следующие TC определены в SYSAPPL-MIB [RFC2287]:
Utf8String OCTET STRING (SIZE (0..255))
LongUtf8String OCTET STRING (SIZE (0..1024))
Следующие TC определены в INET-ADDRESS-MIB [RFC4001]:
InetAddressType enumerated INTEGER
InetAddress OCTET STRING (SIZE (0..255))
InetAddressPrefixLength Unsigned32 (0..2040)
InetPortNumber Unsigned32 (0..65535))
InetAutonomousSystemNumber Unsigned32
InetScopeType enumerated INTEGER
InetZoneIndex Unsigned32
InetVersion enumerated INTEGER
Следующие TC определены в TRANSPORT-ADDRESS-MIB [RFC3419]:
TransportDomain OBJECT IDENTIFIER
TransportAddressType enumerated INTEGER
TransportAddress OCTET STRING (SIZE (0..255))
Следующий TC определён в RMON2-MIB [RFC2021]:
ZeroBasedCounter32 Gauge32
Следующие TC определены в HCNUM-TC [RFC2856]:
ZeroBasedCounter64 Counter64
CounterBasedGauge64 Counter64
Следующие TC определены в IF-MIB [RFC2863]:
InterfaceIndex Integer32 (1..2147483647)
InterfaceIndexOrZero Integer32 (0..2147483647)
Следующие TC определены в ENTITY-MIB [RFC4133]:
PhysicalIndex Integer32 (1..2147483647)
PhysicalIndexOrZero Integer32 (0..2147483647)
Следующие TC определены в PerfHist-TC-MIB [RFC3593]:
PerfCurrentCount Gauge32
PerfIntervalCount Gauge32
PerfTotalCount Gauge32
Следующие TC определены в HC-PerfHist-TC-MIB [RFC3705]:
HCPerfValidIntervals Integer32 (0..96)
HCPerfInvalidIntervals Integer32 (0..96)
HCPerfTimeElapsed Integer32 (0..86399)
HCPerfIntervalThreshold Unsigned32 (0..900)
HCPerfCurrentCount Counter64
HCPerfIntervalCount Counter64
HCPerfTotalCount Counter64
Приложение C: Предлагаемые соглашения об именовании
Авторы и рецензенты модулей IETF MIB нередко находили следующие соглашения об именовании полезными в прошлом, и авторам новых модулей IETF MIB настоятельно рекомендуется рассмотреть их соблюдение.
- Имя модуля следует оформлять как XXX-MIB (либо XXX-TC-MIB для модуля, содержащего только TC), где XXX — уникальный префикс (обычно полностью прописными буквами с дефисами в качестве разделителей), не используемый ни одним существующим модулем. Например, модуль для управления оптическими интерфейсами [RFC3591] использует префикс OPT-IF и имеет имя модуля OPT-IF-MIB.
- Дескриптор, связанный с вызовом MODULE-IDENTITY, следует оформлять как xxxMIB, xxxMib или xxxMibModule, где xxx — вариант XXX в смешанном регистре, начинающийся со строчной буквы и без дефисов. Например, OPT-IF-MIB использует префикс optIf, а дескриптор, связанный с его вызовом MODULE-IDENTITY, — optIfMibModule.
- Другие дескрипторы в модуле MIB следует начинать с того же префикса xxx. OPT-IF-MIB использует префикс optIf для всех дескрипторов.
- Имена TC, специфичных для модуля MIB, и имена типов SEQUENCE, используемых в определениях концептуальных таблиц, следует начинать с префикса Xxx, совпадающего с xxx, но с начальной буквой, заменённой на прописную. OPT-IF-MIB использует префикс OptIf в именах TC и типов SEQUENCE.
- Дескриптор, связанный с концептуальной таблицей, следует оформлять как xxxZzzTable; дескриптор, связанный с соответствующей концептуальной строкой, — как xxxZzzEntry; имя связанного типа SEQUENCE — как XxxZzzEntry; а дескрипторы, связанные с подчинёнными столбцовыми объектами, — как xxxZzzSomeotherName. Пример из OPT-IF-MIB — таблица OTMn. Дескриптор объекта таблицы — optIfOTMnTable, дескриптор объекта строки — optIfOTMnEntry, имя связанного типа SEQUENCE — OptIfOTMnEntry, а дескрипторы столбцовых объектов — optIfOTMnOrder, optIfOTMnReduced, optIfOTMnBitRates, optIfOTMnInterfaceType, optIfOTMnTcmMax и optIfOTMnOpticalReach.
- При использовании сокращений их следует использовать последовательно. Непоследовательного использования, такого как
xxxYyyDestAddr
xxxZzzDstAddr
следует избегать.
Приложение D: Предлагаемая структура OID
Как отмечено в разделе 5.6 RFC 2578, обычной практикой является использование значения вызова MODULE-IDENTITY в качестве поддерева, в котором определяются другие значения OBJECT IDENTIFIER, назначенные в модуле. Это, разумеется, оставляет открытым вопрос о том, как OID назначаются в этом поддереве. Одна схема назначения, получившая признание — и СЛЕДУЕТ (RECOMMENDED) использовать её, если нет конкретной причины её не использовать, — заключается в наличии трёх отдельных ветвей непосредственно под значением MODULE-IDENTITY, предназначенных соответственно для определений уведомлений, определений объектов и определений соответствия, а также в дополнительном разделении ветви соответствия на отдельные подветви для утверждений о соответствии и групп объектов/уведомлений. Эта структура показана ниже; соглашения об именовании соответствуют изложенным в приложении C. Числа в скобках — это субидентификаторы, назначенные ветвям.
xxxMIB
|
+-- xxxNotifications(0)
+-- xxxObjects(1)
+-- xxxConformance(2)
|
+-- xxxCompliances(1)
+-- xxxGroups(2)
При использовании этой схемы значения определений уведомлений назначаются непосредственно под узлом xxxNotifications. Это гарантирует, что каждый OID, назначенный определению уведомления, имеет предпоследний субидентификатор, равный нулю, что ТРЕБУЕТСЯ (REQUIRED) разделом 4.7 выше. Другие подветви могут иметь дополнительную подструктуру, но фактически не требуется никакой подструктуры сверх указанной в разделе 4.6.5 выше.
Один из примеров модуля MIB, назначения OID в котором следуют этой схеме, — POWER-ETHERNET-MIB [RFC3621].