Guide for Internet Standards Writers
RFC 2360 устанавливает рекомендации по подготовке документов стандартов Интернета, чтобы они были связными, недвусмысленными и легко интерпретируемыми. Документ ориентирован на повышение вероятности совместимой работы нескольких реализаций протокола, но не гарантирует совместимость. Он охватывает описание протокола, безопасность, уровни требований, варианты протокола, обработку поведения вне спецификации, IANA, управление сетью, масштабируемость, стабильность, интернационализацию и представление технической информации. Руководство следует использовать совместно с RFC 2223 или его обновлением; отдельные рекомендации могут не подходить для некоторых ситуаций.
Network Working Group G. Scott, редактор
Request for Comments: 2360 Defense Information Systems Agency
BCP: 22 June 1998
Категория: Лучшая современная практика
Руководство для авторов интернет-стандартов
Статус этого меморандума
Этот документ определяет Лучшую современную практику Интернета для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этого меморандума не ограничено.
Уведомление об авторском праве
Copyright (C) The Internet Society (1998). Все права защищены.
Аннотация
Этот документ представляет собой руководство для авторов интернет-
стандартов. В нём определены характеристики, делающие стандарты
согласованными, однозначными и простыми для толкования. Кроме того, в
нём выделяются способы употребления, которые, как считается, в прошлом
приводили к неясным спецификациям и, как следствие, к несовместимым
интерпретациям. Эти руководящие указания следует использовать вместе с
RFC 2223, "Instructions to RFC Authors".
Содержание
1 Введение . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Общие руководящие указания . . . . . . . . . . . . . . . . . 2
2.1 Обсуждение безопасности . . . . . . . . . . . . . . . . . . . 3
2.2 Описание протокола . . . . . . . . . . . . . . . . . . . . 4
2.3 Целевая аудитория . . . . . . . . . . . . . . . . . . . . . 5
2.4 Уровень детализации . . . . . . . . . . . . . . . . . . . . 5
2.5 Журналы изменений . . . . . . . . . . . . . . . . . . . . . 6
2.6 Версии протокола . . . . . . . . . . . . . . . . . . . . . 6
2.7 История решений . . . . . . . . . . . . . . . . . . . . . 6
2.8 Реакция на поведение вне спецификации . . . . . . . . . . . 6
2.9 Либеральное/консервативное правило . . . . . . . . . . . . 7
2.10 Обработка параметров протокола . . . . . . . . . . . . . . 8
2.11 Указание уровней требований . . . . . . . . . . . . . . . . 9
2.12 Соглашения о нотации . . . . . . . . . . . . . . . . . . . . 9
2.13 Соображения IANA . . . . . . . . . . . . . . . . . . . . 10
2.14 Соображения по управлению сетью . . . . . . . . . . . . . 10
2.15 Соображения по масштабируемости . . . . . . . . . . . . . . 10
2.16 Стабильность сети . . . . . . . . . . . . . . . . . . . . 11
2.17 Интернационализация . . . . . . . . . . . . . . . . . . . . 11
Scott Лучшая современная практика [Страница 1]
RFC 2360 Руководство для авторов интернет-стандартов June 1998
2.18 Глоссарий . . . . . . . . . . . . . . . . . . . . . . . 11
3 Специальные руководящие указания . . . . . . . . . . . . . 12
3.1 Диаграммы пакетов . . . . . . . . . . . . . . . . . . . . 12
3.2 Сводные таблицы . . . . . . . . . . . . . . . . . . . . . 13
3.3 Описания конечных автоматов . . . . . . . . . . . . . . . . 13
4 Контрольный список документа . . . . . . . . . . . . . . . 15
5 Соображения безопасности . . . . . . . . . . . . . . . . 16
6 Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Благодарности . . . . . . . . . . . . . . . . . . . . . . 18
8 Адрес редактора . . . . . . . . . . . . . . . . . . . . . 18
9 Приложение . . . . . . . . . . . . . . . . . . . . . . . . 19
10 Полное заявление об авторском праве . . . . . . . . . . . 20
1 Введение
Этот документ представляет собой руководство для авторов интернет-
стандартов. Он предлагает руководящие указания по написанию документа
категории standards track с ясностью, точностью и полнотой. Эти
руководящие указания основаны как на прежнем успешном, так и на
неуспешном опыте IETF по подготовке спецификаций. Эти руководящие
указания следует использовать вместе с RFC 2223, "Instructions to RFC
Authors", либо его обновлением. Следует отметить, что некоторые
руководящие указания могут не применяться в определённых ситуациях.
Цель состоит в повышении вероятности взаимодействия нескольких
реализаций протокола. Написание спецификаций в соответствии с этими
руководящими указаниями не гарантирует совместимости. Однако признанным
препятствием для создания совместимых реализаций протокола являются
неясные спецификации.
Хорошо написанные спецификации протоколов принесут пользу многим.
У разработчиков реализаций будет больше возможностей соответствовать
спецификации протокола. Тестировщики протокола смогут использовать
спецификацию для вывода однозначных утверждений, поддающихся проверке.
Покупатели и пользователи протокола будут лучше понимать его
возможности.
Для получения дополнительной информации о процессе стандартизации
протоколов и процедур обратитесь к BCP 9/RFC 2026, "The Internet
Standards Process -- Revision 3". Кроме того, некоторые соображения по
проектированию протоколов приведены в RFC 1958, "Architectural
Principles of the Internet".
2 Общие руководящие указания
Важно, чтобы несколько читателей и разработчиков реализаций стандарта
одинаково понимали документ. Для этого информация должна быть упорядоченной
и подробной. Ниже приведены общие руководящие указания, предназначенные
для помощи в подготовке такого документа. IESG может потребовать, чтобы
все или некоторые из следующих разделов присутствовали в документе
Scott Лучшая современная практика [Страница 2]
RFC 2360 Руководство для авторов интернет-стандартов June 1998
категории standards track.
2.1 Обсуждение безопасности
Чтобы Интернет мог полностью реализовать свой потенциал в коммерческих,
государственных и личных делах, он должен обеспечивать пользователям
уверенность в том, что передача их информации защищена от
несанкционированного изменения или компрометации. Хорошо написанные
разделы безопасности в документах категории standards track могут помочь
сформировать требуемый уровень уверенности. Прежде всего, новые протоколы
и практики НЕ ДОЛЖНЫ (MUST NOT) ухудшать общую безопасность Интернета.
Значительная угроза для Интернета исходит от лиц, которые мотивированы и
способны использовать обстоятельства, события или уязвимости системы для
причинения вреда. Кроме того, преднамеренное или непреднамеренное
поведение пользователя может сделать систему уязвимой для атаки или
эксплуатации. Вред может варьироваться от нарушения или отказа в
предоставлении сетевой службы до повреждения пользовательских систем.
Помимо этого, раскрытие информации может предоставить средства для атаки
другой системы либо раскрыть модели поведения, которые могут быть
использованы для причинения вреда отдельному лицу, организации или сети.
Это вызывает особую озабоченность в стандартах, определяющих часть базы
управляющей информации (MIB).
Авторы стандартов должны принять, что указанный ими протокол будет
подвергаться атакам. Они несут ответственность за определение возможных
атак и за подробное описание характера атак в документе. В противном
случае они должны убедительно доказать, что атака нереалистична в
конкретной среде, и ограничить использование протокола этой средой.
После того как в документе исчерпывающе определены риски безопасности,
которым подвержен протокол, авторы должны сформулировать и подробно
описать защиту от этих атак. Они должны обсудить применяемые меры
противодействия либо риск, который пользователь принимает, используя
протокол. Меры противодействия могут предоставляться механизмом протокола
или основываться на внешних механизмах. Авторам следует знать о
существующих механизмах безопасности и повторно использовать их, если это
практически осуществимо. Когда используется криптографический алгоритм,
протокол СЛЕДУЕТ (SHOULD) писать так, чтобы в будущем допускалась его
замена другим алгоритмом. Наконец, авторам следует обсудить подсказки или
руководящие указания по реализации, например способы работы с
недостоверными данными или одноранговыми системами.
Меры безопасности будут влиять на среду, в которой они используются.
Возможно, пользователи теперь будут ограничены в том, что они могут делать
в Интернете, либо столкнутся со снижением скорости обслуживания. Следует
обсудить влияние мер безопасности на использование и производительность
протокола.
Scott Лучшая современная практика [Страница 3]
RFC 2360 Руководство для авторов интернет-стандартов June 1998
Обсуждение безопасности может быть сосредоточено в разделе документа
«Соображения безопасности» либо распределено по всему документу там, где
оно относится к отдельным частям спецификации. Преимущество второго
подхода состоит в том, что он обеспечивает включение безопасности как
неотъемлемой части разработки протокола, а не как последующей или
второстепенной работы. Если безопасность обсуждается по всему документу,
раздел «Соображения безопасности» ДОЛЖЕН (MUST) содержать сводное изложение
и ссылки на соответствующие разделы спецификации. Это обеспечит, что меры
безопасности протокола будут акцентированы как для разработчика
реализации, так и для пользователя.
В разделе «Соображения безопасности» может быть уместно обсудить
невыбранный путь. По различным причинам могут существовать несколько
механизмов безопасности, которые не были выбраны: из-за стоимости или
сложности реализации либо неэффективности для данной сетевой среды.
Перечисляя неиспользованные механизмы и причины этого, редакторы могут
продемонстрировать, что рабочая группа (WG) протокола уделила безопасности
необходимое внимание. Кроме того, это предоставляет пользователям
протокола информацию, необходимую им для рассмотрения того, подходит ли
один из невыбранных механизмов лучше для их конкретных требований.
Документ, предоставляющий дальнейшие рекомендации по темам безопасности,
находится в разработке. Авторам следует получить экземпляр завершённого
RFC, чтобы он помог им подготовить часть стандарта, посвящённую
безопасности.
Наконец, больше не приемлемо, чтобы разделы «Соображения безопасности»
состояли исключительно из утверждений о том, что безопасность не была
рассмотрена при подготовке стандарта.
Некоторые примеры разделов «Соображения безопасности» приведены в STD
33/RFC 1350, STD 51/RFC 1662 и STD 53/RFC 1939. RFC 2316, "Report of the
IAB Security Architecture Workshop", предоставляет дополнительную
информацию по этой теме.
2.2 Описание протокола
Документы категории standards track должны включать описание протокола.
Это описание должно охватывать назначение протокола, предполагаемые
функции, предоставляемые им службы, а также сферу, обстоятельства или
любые особые соображения использования протокола.
Авторы спецификации протокола будут располагать большим объёмом знаний о
причинах существования протокола. Однако читатель с большей вероятностью
будет обладать общими знаниями и опытом в области сетей, а не экспертными
знаниями о конкретном протоколе. Объяснение его назначения и использования
даст читателю точку отсчёта для
Scott Лучшая современная практика [Страница 4]
RFC 2360 Руководство для авторов интернет-стандартов June 1998
понимания протокола и того, какое место он занимает в Интернете. STD
54/RFC 2328 был рекомендован рабочей группе STDGUIDE как хороший пример
этого в его разделе "Protocol Overview".
Общее описание протокола также должно предоставлять информацию о
взаимоотношениях между различными сторонами протокола. Это можно сделать,
показав типичные последовательности пакетов.
Это также относится к алгоритмам, используемым протоколом. Необходимо
подробное описание алгоритмов или ссылка на доступные источники, в которых
приведено такое описание.
2.3 Целевая аудитория
RFC создавались для множества различных целей — от технических до
административных. В документах, написанных как стандарты, следует ясно
указывать предполагаемую аудиторию, например проектировщиков,
разработчиков реализаций, тестировщиков, персонал службы поддержки,
преподавателей, конечных пользователей или иных лиц. Если документ
адресован нескольким аудиториям, необходимо определить раздел для каждой
аудитории. Цель состоит в том, чтобы помочь читателю обнаружить и
сосредоточиться на том, ради чего он обратился к документу, и избежать
того, что он может счесть запутывающим, отвлекающим или излишним.
2.4 Уровень детализации
Автору следует рассмотреть, какой уровень описательной детализации лучше
всего передаёт замысел протокола. У краткого текста есть несколько
преимуществ. Он облегчает чтение документа. Такой текст уменьшает
вероятность противоречий между разными частями спецификации. Читатель
может без труда определить требуемые механизмы протокола в стандарте.
Кроме того, он облегчает выявление требований к реализации протокола.
Недостаток кратких описаний состоит в том, что читатель может не до конца
понять обоснование протокола и поэтому сделать предположения, которые
приведут к ошибкам реализации.
Более длинные описания могут потребоваться для объяснения назначения,
фона, обоснования, опыта реализации либо для предоставления учебной
информации. Это помогает читателю понять протокол. Однако развёрнутый
текст таит несколько опасностей. В таком тексте сложно или запутанно
находить требования протокола. Один и тот же механизм может иметь
несколько описаний, что ведёт к неверному толкованию или противоречию.
Наконец, его сложнее понять; это важно, поскольку английский не является
родным языком для многих читателей стандартов IETF по всему миру.
Scott Лучшая современная практика [Страница 5]
RFC 2360 Руководство для авторов интернет-стандартов June 1998
Один из подходов состоит в разделении стандарта на разделы: один кратко
описывает протокол, тогда как другой раздел содержит пояснительный текст.
STD 3/RFC 1122/RFC 1123 и STD 54/RFC 2328 предоставляют примеры этого
метода.
2.5 Журналы изменений
По мере продвижения документа по пути стандартизации — от Proposed к Draft, от Draft к Full либо при циклическом изменении уровня — в него будут вноситься изменения вследствие лучшего понимания протокола или опыта реализации. Чтобы помочь разработчикам реализаций отслеживать вносимые изменения, требуется журнал, показывающий, что изменилось по сравнению с предыдущей версией спецификации (см. Appendix).
2.6 Версии протокола
Часто стандарт задаёт новую версию существующего протокола. В таком случае авторам следует подробно описать различия между предыдущей и новой версиями. Это должно включать обоснование изменений, например опыт реализации, изменения технологии, реакцию на пользовательский спрос и т. д.
2.7 История принятия решений
При разработке стандартов достижение консенсуса требует принятия трудных решений. Эти решения принимаются в ходе обсуждений рабочей группы или на основе опыта реализации. Включив основания для спорного решения, автор может предотвратить повторное возвращение к этим разногласиям в будущем, когда первоначальные участники уже перейдут к другим делам. Кроме того, знание «почему» столь же полезно разработчику реализации, как и описание «как». Например, невыбранная альтернатива могла быть проще в реализации, поэтому включение причин, стоящих за выбором, может удержать будущих разработчиков реализаций от нестандартных упрощений.
2.8 Реакция на поведение вне спецификации
Полезно подробное описание действий, предпринимаемых в случае поведения, отклоняющегося от спецификации или выходящего за её пределы. Это область, в которой разработчики реализаций часто расходятся во мнениях о надлежащей реакции. Задав общую реакцию, автор стандарта может снизить риск возникновения конфликтов между различными реализациями.
Стандарту следует описывать реакции на явно запрещённое поведение или поведение вне границ, определённых спецификацией. Возможны два подхода к таким случаям: отбрасывание либо вызов механизмов обработки ошибок. Если выбрано отбрасывание, может потребоваться подробно описать дальнейшую судьбу отброшенного объекта.
Scott Best Current Practice [Page 6]
RFC 2360 Guide for Internet Standards Writers June 1998
Например, считать отброшенные кадры никогда не полученными либо сбросить состояние существующего соединения или смежности.
Спецификация должна описывать действия, предпринимаемые при исчерпании критически важного ресурса или превышении предела масштабирования производительности. Это необходимо для случаев, когда существует риск ухудшения состояния сети или эксплуатационного отказа. В таких случаях необходимо согласованное поведение реализаций.
2.9 Правило либеральности/консервативности
Правило, впервые сформулированное в STD 5/RFC 791 и признанное полезным для устойчивости реализации и совместимости:
«Будь либерален в том, что принимаешь,
и консервативен в том, что отправляешь».
Или устанавливайте ограничения на то, что передаёт протокол, но будьте способны обработать любую мыслимую полученную ошибку. При применении этого подхода в протоколах пути стандартизации настоятельно рекомендуется осторожность. В прошлом он приводил к конфликтам между поставщиками при сбоях совместимости. Отправитель обвиняет получателя в недостаточной либеральности, а получатель обвиняет отправителя в недостаточной консервативности. Поэтому автор обязан предоставить подробное описание поведения при отправке и приёме.
Чтобы избежать путаницы между этими двумя аспектами, рекомендуется, чтобы авторы стандартов отдельно задавали поведение при отправке и приёме. Описание приёма потребует наибольшей детализации. Ожидается, что реализации продолжат работу независимо от полученной ошибки. Поэтому действия, предпринимаемые для достижения этого результата, необходимо изложить в спецификации протокола. Авторам стандартов следует заботиться о достижении такого уровня взаимодействия, который ограничивает нарушение работы сети, а не только о том, как выжить в сети. Появление неопределённой информации или условий не должно вызывать отказ сети или хоста. Для этого требуется специфицировать, как пытаться принять большую часть пакетов. Доступны два подхода: использовать как можно больше содержимого пакета либо вызывать процедуры обработки ошибок. Автору следует указать границу, определяющую, когда применять каждый из подходов.
Следует рассмотреть случай протокола маршрутизации, в котором принятие ошибочной информации может вызвать отказ сети. Для таких протоколов спецификации следует идентифицировать пакеты, которые могут иметь различные интерпретации, и предписывать их полное отклонение либо характер попытки извлечь из них некоторую информацию. Например, обновления маршрутизации, содержащие больше данных, чем показывает число кортежей.
Scott Best Current Practice [Page 7]
RFC 2360 Guide for Internet Standards Writers June 1998
Авторам протокола следует рассмотреть, можно ли принять некоторые завершающие данные как дополнительные маршруты либо отклонить весь пакет как подозрительный, поскольку он не соответствует требованиям.
2.10 Обработка опций протокола
Спецификации с множеством необязательных возможностей повышают сложность реализации и вероятность появления несовместимых реализаций. Опасность состоит в том, что различные реализации могут задавать сочетания опций, не способные взаимодействовать друг с другом.
По мере продвижения документа по пути стандартизации опыт реализации должен определять необходимость каждой опции. Реализация должна показать, следует ли сделать опцию обязательной частью протокола или оставить её опцией. Если опция не реализована по мере продвижения документа, её необходимо удалить из протокола до того, как он достигнет статуса draft standard.
Поэтому опции должны присутствовать в протоколе только для удовлетворения реального требования. Например, опции могут поддерживать будущую расширяемость протокола, определённый рынок, например финансовую отрасль, или конкретную сетевую среду, например сеть, ограниченную малой пропускной способностью. Их не должны включать как средство «откупиться» от мнения меньшинства. Отсутствие необязательного элемента не должно иметь последствий для совместимости реализации, в которой он отсутствует.
Один из возможных подходов — документировать опции протокола в отдельной спецификации. Это сохраняет основную спецификацию протокола чистой и ясно показывает, что опции не требуются для реализации протокола. Независимо от того, представлены ли они в спецификации или в отдельном документе, текст должен обсуждать полные последствия как использования опции, так и отказа от неё, а также основания для выбора любого из этих вариантов. В рамках этого автору необходимо рассмотреть и описать, как опции используются вместе с другими протоколами. Текст также должен задавать условия по умолчанию для всех опций. Для опций проверки безопасности условием по умолчанию является включённое состояние.
Иногда в протоколе присутствуют взаимоисключающие опции. То есть реализация одной необязательной возможности исключает реализацию другой необязательной возможности. Для ясности автору необходимо указать, когда реализовывать одну или другую, каков эффект выбора одной вместо другой и с какими проблемами может столкнуться разработчик реализации или пользователь.
Scott Best Current Practice [Page 8]
RFC 2360 Guide for Internet Standards Writers June 1998
Выбор одной или другой опции не должен иметь последствий для совместимости между несколькими реализациями.
2.11 Обозначение уровней требований
BCP 14/RFC 2119, «Key words for use in RFCs to Indicate Requirement Level», определяет несколько слов, необходимых для написания документа пути стандартизации. Редакторы документов пути стандартизации не должны отклоняться от приведённых в нём определений, поскольку они предназначены для указания требований совместимости или ограничения потенциально вредного поведения. Написание этих слов прописными буквами является принятой нормой и может помочь выявить непреднамеренное или необоснованное требование. Эти слова использовались в нескольких RFC; первыми примерами были STD 3/RFC 1122/RFC 1123.
2.12 Соглашения о нотации
Нотации формального синтаксиса могут использоваться для определения сложных понятий протокола или типов данных, а также для задания значений этих типов данных. Это позволяет записать протокол, не заботясь о том, как построена реализация или как тип данных представлен при передаче. Спецификация упрощается, поскольку её можно представить в виде «аксиом», которые будут доказаны реализацией.
На формальную спецификацию используемого синтаксиса следует ссылаться в тексте стандарта. Любые расширения, подмножества, изменения или исключения из этого формального синтаксиса следует определять в самом стандарте.
STD 11/RFC 822 даёт пример этого. В RFC 822 (раздел 2 и Appendix D) метаязык Backus-Naur Form (BNF) был расширен, чтобы сделать его представление компактнее и проще для понимания. Другой пример — STD 16/RFC 1155 (раздел 3.2), в котором определено подмножество Abstract Syntax Notation One (ASN.1).
Автору протокола пути стандартизации необходимо рассмотреть несколько вопросов, прежде чем использовать нотацию формального синтаксиса. Может ли существующая машина разобрать используемый язык формальной спецификации? Если синтаксического анализатора не существует, достаточно ли информации предоставлено в спецификации для создания такого анализатора? Если нет, то, вероятно, читателю не хватит информации, чтобы решить, что означает эта нотация. Кроме того, автору следует помнить, что синтаксис, разбираемый машиной, часто нечитаем для людей и может чрезмерно увеличить объём спецификации. Поэтому синтаксические нотации не могут заменить ясно написанное описание протокола.
Scott Best Current Practice [Page 9]
RFC 2360 Guide for Internet Standards Writers June 1998
2.13 Соображения IANA
Широкое использование сообществом Интернета протоколов пути стандартизации требует назначения уникальных значений полям параметров. Рабочая группа IETF не имеет полномочий назначать эти значения для разработанного ею протокола. Internet Assigned Numbers Authority (IANA) является центральным органом, назначающим уникальные значения параметров для интернет-протоколов. Авторам разрабатываемого протокола необходимо согласовать с IANA правила и процедуры управления пространством номеров. Эта координация должна быть завершена до подачи Internet Draft на путь стандартизации.
Готовится документ, обсуждающий вопросы, связанные с политикой назначения идентификаторов, и рекомендации по конкретному тексту для поручения IANA его администрирования. Авторам стандартов следует получить его копию, когда он будет окончательно оформлен как RFC.
Для дополнительной информации о назначении параметров и текущих назначениях авторы могут ссылаться на STD 2, RFC 1700, «Assigned Numbers» (http://www.iana.org).
2.14 Соображения управления сетью
Когда это уместно, каждому стандарту необходимо обсуждать, как управлять специфицируемым протоколом. Этому процессу управления следует быть совместимым с текущим стандартным протоколом управления IETF. Кроме того, MIB должна быть определена в стандарте или сопроводительном документе. MIB должна быть совместима с текущей Structure of Management Information (SMI) и разбираться с помощью такого инструмента, как SMICng. Там, где управление или MIB не требуется, этому разделу стандарта следует объяснять, почему это не относится к протоколу.
2.15 Соображения масштабируемости
Стандарту следует установить ограничения масштаба использования, например десятки миллионов сеансов, гигабиты в секунду и т. д., а также ограничения используемых ресурсов, например времени кругового прохождения, вычислительных ресурсов и т. д. Это важно, поскольку устанавливает способность сети обслуживать число пользователей и сложность их взаимоотношений. STD 53/RFC 1939 содержит пример такого раздела. Если это неприменимо к протоколу, следует включить объяснение причин.
Scott Best Current Practice [Page 10]
RFC 2360 Guide for Internet Standards Writers June 1998
2.16 Стабильность сети
Стандарту следует обсуждать взаимосвязь между топологией сети и поведением сходимости. В рамках этого следует идентифицировать любую топологию, которая могла бы быть проблемной для протокола. Кроме того, спецификации следует рассмотреть любые возможные дестабилизирующие события и средства, с помощью которых протокол противостоит им или восстанавливается после них. Цель состоит в обеспечении того, чтобы сеть своевременно стабилизировалась после изменения и чтобы сочетание ошибок или событий не ввергло сеть в хаос. В качестве примера STD 34/RFC 1058 содержит разделы, в которых рассматривается, как этот протокол обрабатывает последствия изменения топологии.
Очевидный случай, к которому это применимо, — протокол маршрутизации. Однако динамическое поведение, влияющее на сеть, может быть и у прикладного протокола. Например, протокол обмена сообщениями может внезапно выгрузить в сеть большое число сообщений. Поэтому редакторам прикладного протокола потребуется рассмотреть возможные воздействия на стабильность сети и поведение сходимости.
2.17 Интернационализация Когда-то Интернет имел географические границы и был только англоязычным. Сейчас Интернет распространяется на международном уровне. Поэтому данные обмениваются на различных языках и в различных наборах символов. Чтобы соответствовать требованиям международного Интернета, стандарт ДОЛЖЕН (MUST) соответствовать политикам, изложенным в BCP 18/RFC 2277, "IETF Policy on Character Sets and Languages".
2.18 Глоссарий
Каждый RFC на пути стандартизации следует снабжать глоссарием, поскольку слова могут иметь много значений. Определяя любые вводимые новые слова, автор может избежать путаницы или введения в заблуждение реализаторов. Определение следует приводить при первом появлении слова в тексте спецификации протокола, а также в отдельном разделе глоссария.
Вероятно, определение протокола будет опираться на множество слов, часто используемых в документах IETF. Все авторы ДОЛЖНЫ (MUST) знать общепринятые определения этих часто употребляемых слов. FYI 18/RFC 1983, "Internet Users' Glossary", содержит определения, относящиеся к Интернету. Авторам настоятельно не рекомендуется отклоняться от этих определений. Если обстоятельства требуют отклонения, автору следует указать, что он изменяет общепринятое определение, и обосновать необходимость этого. Изменённое определение ДОЛЖНО (MUST) быть включено в раздел «Глоссарий».
Scott Best Current Practice [Page 11]
RFC 2360 Guide for Internet Standards Writers June 1998
Если автор использует слово в его общепринятом значении, ей не требуется включать определение в глоссарий. Как минимум FYI 18/RFC 1983 следует указывать как источник.
3 Специальные рекомендации
Ниже приведены рекомендации по представлению конкретной технической информации в стандартах.
3.1 Диаграммы пакетов
Большинство протоколов канального, сетевого и транспортного уровней содержат описания пакетов. Диаграммы пакетов, включённые в стандарт, весьма полезны читателю. Предпочтительная форма диаграмм пакетов — последовательность длинных слов в сетевом порядке байтов, где каждое слово располагается на странице горизонтально, а нумерация битов приведена сверху:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
В случаях, когда пакет в значительной степени выровнен по байтам, а не по словам (например, при использовании полей переменной длины с границами по байтам), отображайте диаграммы пакетов в формате шириной в байт. Автор может использовать блоки разной высоты для коротких и длинных слов, а также разорванные блоки для полей переменной длины:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
Scott Best Current Practice [Page 12]
RFC 2360 Guide for Internet Standards Writers June 1998
3.2 Сводные таблицы
Спецификации некоторых протоколов особенно объёмны и иногда занимают сто или более страниц. В таких случаях включение сводной таблицы может уменьшить риск несоответствия реализации из-за недосмотра. Сводная таблица перечисляет, какие характеристики протокола являются обязательными, необязательными или запрещёнными. Сводные таблицы не гарантируют соответствия, но помогают реализатору проверить, что он учёл все характеристики протокола.
Сводная таблица будет состоять как минимум из четырёх (4) столбцов: характеристика протокола, ссылка на раздел, статус и ссылки/сноски. Автор может добавить столбцы, если они дополнительно объясняют или уточняют протокол.
В столбце «Характеристика протокола» перечислите характеристики протокола, например командное слово. Мы рекомендуем группировать серии связанных транзакций под описательными заголовками, например RECEPTION.
Ссылка на раздел направляет реализатора к разделу, абзацу или странице, где характеристика протокола подробно описана.
Статус указывает, является ли характеристика обязательной, необязательной или запрещённой. Автор может использовать либо отдельный столбец для каждого варианта, либо один столбец с соответствующими кодами. Чтобы избежать путаницы, эти коды необходимо определить в начале сводной таблицы. Возможные коды статуса:
M - must or mandatory
MN - must not
O - optional
S - should
SN - should not
X - prohibited
В столбце «Ссылки/сноски» авторы могут указывать другие RFC, которые необходимо учитывать при реализации данной характеристики протокола, или любые сноски, необходимые для дальнейшего пояснения реализации.
STD 3/RFC 1122/RFC 1123 содержит примеры сводных таблиц.
3.3 Описания конечных автоматов
Удобный способ представления поведения протокола — модель конечного автомата. То есть протокол может быть описан последовательностью состояний, возникающих вследствие команды, операции или транзакции. Модели конечных автоматов определяют переменные и константы, устанавливающие состояние, события, вызывающие переходы состояний, и действия, являющиеся результатом этих переходов. Благодаря этим моделям возможно понимание динамической работы протокола как последовательности переходов состояний, происходящих для любого заданного события. Переходы состояний можно детализировать диаграммами, таблицами или временными шкалами.
Scott Best Current Practice [Page 13]
RFC 2360 Guide for Internet Standards Writers June 1998
Обратите внимание, что модели конечных автоматов никогда не должны заменять подробное текстовое описание спецификации. Они дополняют текст. В случае конфликта спецификация протокола должна всегда иметь преимущественную силу.
При использовании диаграммы переходов состояний показывайте каждое возможное состояние протокола в виде блока, соединённого дугами переходов состояний. Автору следует помечать каждую дугу событием, вызывающим переход, и в скобках — любыми действиями, выполняемыми при переходе. STD 5/RFC 1112 содержит пример такой диаграммы. Поскольку ASCII-текст является предпочтительным форматом хранения RFC, возможны только простые диаграммы. Таблицы могут обобщать более сложные или более обширные переходы состояний.
В таблице переходов состояний разные события перечисляются вертикально, а разные состояния — горизонтально. Форма «действие/новое состояние» представляет переходы состояний и действия. Запятые разделяют несколько действий, а последующие строки используются по мере необходимости. Если это существенно, авторам следует представлять несколько действий в порядке, в котором они должны быть выполнены. Буквы после состояния обозначают поясняющую сноску. Дефис ('-') обозначает недопустимый переход. STD 51/RFC 1661 содержит пример такой таблицы переходов состояний. Начальные столбцы и строки этой таблицы приведены ниже в качестве примера:
| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
STD 18/RFC 904 также представляет переходы состояний в табличном формате. Однако он перечисляет переходы в форме n/a, где n — следующее состояние, а a представляет действие. Предпочтителен метод из RFC 1661, поскольку новое состояние логически следует за действием. Кроме того, Appendix C RFC 904 моделирует переходы как декартово произведение двух конечных автоматов. Это более сложное представление, которое может быть трудно понять читателям, не знакомым с таким форматом. Мы рекомендуем авторам представлять таблицы так, как определено в предыдущем абзаце.
Scott Best Current Practice [Page 14]
RFC 2360 Guide for Internet Standards Writers June 1998
Последний способ представления изменений состояний — временная шкала. Две стороны временной шкалы представляют машины, участвующие в обмене. Автор перечисляет состояния, в которые входят машины по мере продвижения времени (вниз), с внешней стороны временной шкалы. Внутри временной шкалы показывайте действия, вызывающие переходы состояний. Пример:
client server
| |
| | LISTEN
SYN_SENT |----------------------- |
| \ syn j |
| ----------------->| SYN_RCVD
| |
| ------------------|
| syn k, ack j+1 / |
ESTABLISHED |<---------------------- |
| |
4 Контрольный список документа
Ниже приведён контрольный список, основанный на приведённых выше рекомендациях, который можно применить к документу:
o Идентифицирует ли он риски безопасности? Предусмотрены ли меры противодействия для каждой потенциальной атаки? Детально ли описано влияние мер безопасности на эксплуатационную среду?
o Объясняет ли он назначение протокола или процедуры? Рассмотрены ли предполагаемые функции и услуги? Описано ли, как он соотносится с существующими протоколами?
o Учитывает ли он вопросы масштабирования и стабильности?
o Были ли процедуры назначения номеров скоординированы с IANA?
o Рассматривает ли он управление определяемым протоколом? Определена ли MIB?
o Определена ли целевая аудитория?
o Ссылается ли он на алгоритмы, используемые в протоколе, или объясняет их?
o Приводит ли он диаграммы пакетов в рекомендуемой форме, если это применимо?
o Имеется ли журнал изменений?
o Описывает ли он отличия от предыдущих версий, если это применимо?
o Отделяет ли он пояснительные части документа от требований?
o Приводит ли он примеры работы протокола?
Scott Best Current Practice [Page 15]
RFC 2360 Guide for Internet Standards Writers June 1998
o Указывает ли он поведение при некорректной работе других реализаций?
o Разграничивает ли он, какие пакеты следует принимать для обработки, а какие следует игнорировать?
o Если приведено несколько описаний требования, определяет ли он одно из них как обязательное?
o Сколько необязательных возможностей он определяет? Разделяет ли он их на классы вариантов?
o Были ли все комбинации вариантов или классов вариантов проверены на несовместимость?
o Объясняет ли он обоснование и применение вариантов?
o Были ли все обязательные и необязательные требования идентифицированы и задокументированы принятыми ключевыми словами, определяющими уровни требований Интернета?
o Соответствует ли он действующим политикам IETF по интернационализации?
o Используются ли рекомендуемые значения распространённых терминов Интернета?
o Если нет, приведены ли новые или изменённые определения терминов в глоссарии?
5 Соображения безопасности
Этот документ не определяет протокол или процедуру, которые могли бы быть подвержены атаке. Он устанавливает рекомендации относительно информации, которую следует включать в RFC, представляемые на путь стандартизации. В области безопасности авторы стандартов IETF призваны чётко определять угрозы, с которыми сталкивается протокол, и то, предоставляет или не предоставляет протокол пользователю гарантии безопасности.
6 Ссылки
[RFC 791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791
September 1981.
[RFC 904] Mills, D., "Exterior Gateway Protocol formal
specification", RFC 904, April 1984.
[RFC 1058] Hedrick, C., "Routing Information Protocol", STD 34,
RFC 1058, June 1988.
[RFC 1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC 1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
Scott Best Current Practice [Page 16]
RFC 2360 Guide for Internet Standards Writers June 1998
[RFC 1123] Braden, R., "Requirements for Internet hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
[RFC 1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992.
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. [RFC 1662] Simpson, W., "PPP in HLDC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. (http://www.iana.org)
[RFC 1939] Meyers, J., and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983,
August 1996.
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC 2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Language", RFC 2277, January 1998.
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
Scott Best Current Practice [Страница 17]
RFC 2360 Guide for Internet Standards Writers June 1998
7 Благодарности
Peter Desnoyers и Art Mellor начали работу над этим документом.
Другие участники, внесшие вклад:
Bernard Aboba
Harald T. Alvestrand
Fred Baker
Scott Bradner
Brian Carpenter
Robert Elz
Dirk Fieldhouse
Dale Francisco
Gary Malkin
Neal McBurnett
Thomas Narten
Craig Partridge
Vern Paxson
Mike O'Dell
Henning Schulzrinne
Kurt Starsinic
James Watt
8 Адрес редактора
Gregor D. Scott
Director, Defense Information Systems Agency
ATTN: JIEO-JEBBC
Ft. Monmouth, NJ 07703-5613
USA
Phone: (732) 427-6856
Fax: (732) 532-0853
EMail: scottg@ftm.disa.mil
Scott Best Current Practice [Страница 18]
RFC 2360 Guide for Internet Standards Writers June 1998
9 Приложение
ИЗМЕНЕНИЯ ПО СРАВНЕНИЮ С ЧЕРНОВИКОМ -06
Следующие изменения были внесены после рассмотрения IESG:
Ссылки на RFC 1543 были заменены ссылками на RFC 2223, который сделал его устаревшим.
В разделе 2.1 «export control» было исключено как допустимая причина
не выбирать механизм безопасности. Кроме того, были удалены
неоднозначные или противоречивые предложения.
В разделе 2.1 была добавлена ссылка на RFC 2315 как на дополнительный источник
информации.
Раздел 2.5 был изменён, чтобы подчеркнуть назначение Change Log —
помогать разработчикам реализаций.
Раздел IANA Considerations (2.13) был переписан, чтобы подчеркнуть,
что документ с руководящими указаниями IANA находится в разработке, но
его следует использовать, когда он станет доступен.
Раздел 3.4 Character Sets был удалён и заменён разделом 2.17
Internationalization.
Были внесены исправления орфографии и грамматики.
ИЗМЕНЕНИЯ ПО СРАВНЕНИЮ С ЧЕРНОВИКОМ -05
В раздел 2.13 было добавлено предложение, указывающее на ожидающий публикации документ,
который дополнительно рассматривает вопросы IANA. Текущим черновиком этого
документа является draft-iesg-iana-considerations-02.txt. Было удалено положение,
утверждавшее, что IANA установила политики назначения, поскольку оно,
по-видимому, противоречило цели упомянутого ID.
В текст и раздел ссылок были добавлены заполнители для номера BCP и RFC.
Был добавлен новый раздел (2.5), требующий журналов изменений по мере
продвижения документов по пути стандартизации.
Ссылки на RFC 2044 были заменены ссылками на RFC 2279, который сделал его устаревшим.
Были внесены исправления орфографии и грамматики.
ИЗМЕНЕНИЯ ПО СРАВНЕНИЮ С ЧЕРНОВИКОМ -04
Был обновлён абзац, указывающий на ожидающий публикации документ,
который дополнительно рассматривает безопасность.
Scott Best Current Practice [Страница 19]
RFC 2360 Guide for Internet Standards Writers June 1998
10 Полное заявление об авторском праве
Copyright (C) The Internet Society (1998). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, содержащие комментарии к нему, иным
образом объясняющие его или содействующие его реализации, могут
подготавливаться, копироваться, публиковаться и распространяться полностью
или частично без каких-либо ограничений, при условии, что приведённое выше
уведомление об авторском праве и этот абзац включаются во все такие копии
и производные работы. Однако сам этот документ не может быть изменён
каким-либо образом, например путём удаления уведомления об авторском праве
или ссылок на The Internet Society либо другие организации Интернета, кроме
случаев, когда это необходимо для разработки стандартов Интернета, при
которой должны соблюдаться процедуры в отношении авторских прав, определённые
процессом Internet Standards, или когда это требуется для его перевода на
языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и не будут
отозваны The Internet Society, её правопреемниками или цессионариями.
Этот документ и содержащаяся в нём информация предоставляются на условиях
«КАК ЕСТЬ» («AS IS»), И THE INTERNET SOCIETY И THE INTERNET ENGINEERING
TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ
ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ КОНКРЕТНОЙ ЦЕЛИ.
Scott Best Current Practice [Страница 20]
Network Working Group G. Scott, Editor
Request for Comments: 2360 Defense Information Systems Agency
BCP: 22 June 1998
Category: Best Current Practice
Guide for Internet Standards Writers
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.
Abstract
This document is a guide for Internet standard writers. It defines
those characteristics that make standards coherent, unambiguous, and
easy to interpret. In addition, it singles out usage believed to
have led to unclear specifications, resulting in non-interoperable
interpretations in the past. These guidelines are to be used with
RFC 2223, "Instructions to RFC Authors".
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2 General Guidelines . . . . . . . . . . . . . . . . . . . . . 2
2.1 Discussion of Security . . . . . . . . . . . . . . . . . . . 3
2.2 Protocol Description . . . . . . . . . . . . . . . . . . . 4
2.3 Target Audience . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Protocol Versions . . . . . . . . . . . . . . . . . . . . . 6
2.7 Decision History . . . . . . . . . . . . . . . . . . . . . 6
2.8 Response to Out of Specification Behavior . . . . . . . . . 6
2.9 The Liberal/Conservative Rule . . . . . . . . . . . . . . . 7
2.10 Handling of Protocol Options . . . . . . . . . . . . . . . 8
2.11 Indicating Requirement Levels . . . . . . . . . . . . . . . 9
2.12 Notational Conventions . . . . . . . . . . . . . . . . . . . 9
2.13 IANA Considerations . . . . . . . . . . . . . . . . . . . 10
2.14 Network Management Considerations . . . . . . . . . . . . 10
2.15 Scalability Considerations . . . . . . . . . . . . . . . . 10
2.16 Network Stability . . . . . . . . . . . . . . . . . . . . 11
2.17 Internationalization . . . . . . . . . . . . . . . . . . . 11
Scott Best Current Practice [Page 1]
RFC 2360 Guide for Internet Standards Writers June 1998
2.18 Glossary . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Specific Guidelines . . . . . . . . . . . . . . . . . . . 12
3.1 Packet Diagrams . . . . . . . . . . . . . . . . . . . . . 12
3.2 Summary Tables . . . . . . . . . . . . . . . . . . . . . 13
3.3 State Machine Descriptions . . . . . . . . . . . . . . . . 13
4 Document Checklist . . . . . . . . . . . . . . . . . . . . 15
5 Security Considerations . . . . . . . . . . . . . . . . . 16
6 References . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18
8 Editor's Address . . . . . . . . . . . . . . . . . . . . . 18
9 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . 19
10 Full Copyright Statement . . . . . . . . . . . . . . . . . 20
1 Introduction
This document is a guide for Internet standard writers. It offers
guidelines on how to write a standards-track document with clarity,
precision, and completeness. These guidelines are based on both
prior successful and unsuccessful IETF specification experiences.
These guidelines are to be used with RFC 2223, "Instructions to RFC
Authors", or its update. Note that some guidelines may not apply in
certain situations.
The goal is to increase the possibility that multiple implementations
of a protocol will interoperate. Writing specifications to these
guidelines will not guarantee interoperability. However, a
recognized barrier to the creation of interoperable protocol
implementations is unclear specifications.
Many will benefit from having well-written protocol specifications.
Implementers will have a better chance to conform to the protocol
specification. Protocol testers can use the specification to derive
unambiguous testable statements. Purchasers and users of the
protocol will have a better understanding of its capabilities.
For further information on the process for standardizing protocols
and procedures please refer to BCP 9/RFC 2026, "The Internet
Standards Process -- Revision 3". In addition, some considerations
for protocol design are given in RFC 1958, "Architectural Principles
of the Internet".
2 General Guidelines
It is important that multiple readers and implementers of a standard
have the same understanding of a document. To this end, information
should be orderly and detailed. The following are general guidelines
intended to help in the production of such a document. The IESG may
require that all or some of the following sections appear in a
Scott Best Current Practice [Page 2]
RFC 2360 Guide for Internet Standards Writers June 1998
standards track document.
2.1 Discussion of Security
If the Internet is to achieve its full potential in commercial,
governmental, and personal affairs, it must assure users that their
information transfers are free from tampering or compromise. Well-
written security sections in standards-track documents can help
promote the confidence level required. Above all, new protocols and
practices must not worsen overall Internet security.
A significant threat to the Internet comes from those individuals who
are motivated and capable of exploiting circumstances, events, or
vulnerabilities of the system to cause harm. In addition, deliberate
or inadvertent user behavior may expose the system to attack or
exploitation. The harm could range from disrupting or denying
network service, to damaging user systems. Additionally, information
disclosure could provide the means to attack another system, or
reveal patterns of behavior that could be used to harm an individual,
organization, or network. This is a particular concern with
standards that define a portion of the Management Information Base
(MIB).
Standards authors must accept that the protocol they specify will be
subject to attack. They are responsible for determining what attacks
are possible, and for detailing the nature of the attacks in the
document. Otherwise, they must convincingly argue that attack is not
realistic in a specific environment, and restrict the use of the
protocol to that environment.
After the document has exhaustively identified the security risks the
protocol is exposed to, the authors must formulate and detail a
defense against those attacks. They must discuss the applicable
countermeasures employed, or the risk the user is accepting by using
the protocol. The countermeasures may be provided by a protocol
mechanism or by reliance on external mechanisms. Authors should be
knowledgeable of existing security mechanisms, and reuse them if
practical. When a cryptographic algorithm is used, the protocol
should be written to permit its substitution with another algorithm
in the future. Finally, the authors should discuss implementation
hints or guidelines, e.g., how to deal with untrustworthy data or
peer systems.
Security measures will have an impact within the environment that
they are used. Perhaps users will now be constrained on what they
can do in the Internet, or will experience degradation in the speed
of service. The effects the security measures have on the protocol's
use and performance should be discussed.
Scott Best Current Practice [Page 3]
RFC 2360 Guide for Internet Standards Writers June 1998
The discussion of security can be concentrated in the Security
Considerations section of the document, or throughout the document
where it is relevant to particular parts of the specification. An
advantage of the second approach is that it ensures security is an
integral part of the protocol's development, rather than something
that is a follow-on or secondary effort. If security is discussed
throughout the document, the Security Considerations section must
summarize and refer to the appropriate specification sections. This
will insure that the protocol's security measures are emphasized to
implementer and user both.
Within the Security Considerations section, a discussion of the path
not taken may be appropriate. There may be several security
mechanisms that were not selected for a variety of reasons: cost or
difficulty of implementation, or ineffectiveness for a given network
environment. By listing the mechanisms they did not use and the
reasons, editors can demonstrate that the protocol's WG gave security
the necessary thought. In addition, this gives the protocol's users
the information they need to consider whether one of the non-selected
mechanisms would be better suited to their particular requirements.
A document giving further guidance on security topics is in
development. Authors should obtain a copy of the completed RFC to
help them prepare the security portion of the standard.
Finally, it is no longer acceptable that Security Considerations
sections consist solely of statements to the effect that security was
not considered in preparing the standard.
Some examples of Security Considerations sections are found in STD
33/RFC 1350, STD 51/RFC 1662, and STD 53/RFC 1939. RFC 2316, "Report
of the IAB Security Architecture Workshop", provides additional
information in this topic area.
2.2 Protocol Description
Standards track documents must include a description of the protocol.
This description must address the protocol's purpose, intended
functions, services it provides, and, the arena, circumstances, or
any special considerations of the protocol's use.
The authors of a protocol specification will have a great deal of
knowledge as to the reason for the protocol. However, the reader is
more likely to have general networking knowledge and experience,
rather than expertise in a particular protocol. An explanation of
it's purpose and use will give the reader a reference point for
Scott Best Current Practice [Page 4]
RFC 2360 Guide for Internet Standards Writers June 1998
understanding the protocol, and where it fits in the Internet. The
STD 54/RFC 2328 was recommended to the STDGUIDE working group as
providing a good example of this in its "Protocol Overview" section.
The protocol's general description must also provide information on
the relationship between the different parties to the protocol. This
can be done by showing typical packet sequences.
This also applies to the algorithms used by a protocol. A detailed
description of the algorithms or citation of readily available
references that give such a description is necessary.
2.3 Target Audience
RFCs have been written with many different purposes, ranging from the
technical to the administrative. Those written as standards should
clearly identify the intended audience, for example, designers,
implementers, testers, help desk personnel, educators, end users, or
others. If there are multiple audiences being addressed in the
document, the section for each audience needs to be identified. The
goal is to help the reader discover and focus on what they have
turned to the document for, and avoid what they may find confusing,
diverting, or extraneous.
2.4 Level of Detail
The author should consider what level of descriptive detail best
conveys the protocol's intent. Concise text has several advantages.
It makes the document easier to read. Such text reduces the chance
for conflict between different portions of the specification. The
reader can readily identify the required protocol mechanisms in the
standard. In addition, it makes it easier to identify the
requirements for protocol implementation. A disadvantage of concise
descriptions is that a reader may not fully comprehend the reasoning
behind the protocol, and thus make assumptions that will lead to
implementation errors.
Longer descriptions may be necessary to explain purpose, background,
rationale, implementation experience, or to provide tutorial
information. This helps the reader understand the protocol. Yet,
several dangers exist with lengthy text. Finding the protocol
requirements in the text is difficult or confusing. The same
mechanism may have multiple descriptions, which leads to
misinterpretation or conflict. Finally, it is more difficult to
comprehend, a consideration as English is not the native language of
the many worldwide readers of IETF standards.
Scott Best Current Practice [Page 5]
RFC 2360 Guide for Internet Standards Writers June 1998
One approach is to divide the standard into sections: one describing
the protocol concisely, while another section consists of explanatory
text. The STD 3/RFC 1122/RFC 1123 and STD 54/RFC 2328 provides
examples of this method.
2.5 Change Logs
As a document moves along the standards track, from Proposed to Draft
or Draft to Full, or cycles in level, it will undergo changes due to
better understanding of the protocol or implementation experience. To
help implementers track the changes being made a log showing what has
changed from the previous version of the specification is required
(see Appendix).
2.6 Protocol Versions
Often the standard is specifying a new version of an existing
protocol. In such a case, the authors should detail the differences
between the previous version and the new version. This should
include the rationale for the changes, for example, implementation
experience, changes in technology, responding to user demand, etc.
2.7 Decision History
In standards development, reaching consensus requires making
difficult choices. These choices are made through working group
discussions or from implementation experience. By including the
basis for a contentious decision, the author can prevent future
revisiting of these disagreements when the original parties have
moved on. In addition, the knowledge of the "why" is as useful to an
implementer as the description of "how". For example, the
alternative not taken may have been simpler to implement, so
including the reasons behind the choice may prevent future
implementers from taking nonstandard shortcuts.
2.8 Response to Out of Specification Behavior
A detail description of the actions taken in case of behavior that is
deviant from or exceeds the specification is useful. This is an area
where implementers often differ in opinion as to the appropriate
response. By specifying a common response, the standard author can
reduce the risk that different implementations will come in to
conflict.
The standard should describe responses to behavior explicitly
forbidden or out of the boundaries defined by the specification. Two
possible approaches to such cases are discarding, or invoking error-
handling mechanisms. If discarding is chosen, detailing the
Scott Best Current Practice [Page 6]
RFC 2360 Guide for Internet Standards Writers June 1998
disposition may be necessary. For instance, treat dropped frames as
if they were never received, or reset an existing connection or
adjacency state.
The specification should describe actions taken when a critical
resource or a performance-scaling limit is exceeded. This is
necessary for cases where a risk of network degradation or
operational failure exists. In such cases, a consistent behavior
between implementations is necessary.
2.9 The Liberal/Conservative Rule
A rule, first stated in STD 5/RFC 791, recognized as having benefits
in implementation robustness and interoperability is:
"Be liberal in what you accept, and
conservative in what you send".
Or establish restrictions on what a protocol transmits, but be able
to deal with every conceivable error received. Caution is urged in
applying this approach in standards track protocols. It has in the
past lead to conflicts between vendors when interoperability fails.
The sender accuses the receiver of failing to be liberal enough, and
the receiver accuses the sender of not being conservative enough.
Therefore, the author is obligated to provide extensive detail on
send and receive behavior.
To avoid any confusion between the two, recommend that standard
authors specify send and receive behavior separately. The
description of reception will require the most detailing. For
implementations are expected to continue operating regardless of
error received. Therefore, the actions taken to achieve that result,
need to be laid out in the protocol specification. Standard authors
should concern themselves on achieving a level of cooperation that
limits network disruption, not just how to survive on the network.
The appearance of undefined information or conditions must not cause
a network or host failure. This requires specification on how to
attempt acceptance of most of the packets. Two approaches are
available, either using as much of the packet's content as possible,
or invoking error procedures. The author should specify a dividing
line on when to take which approach.
A case for consideration is that of a routing protocol, where
acceptance of flawed information can cause network failure. For
protocols such as this, the specification should identify packets
that could have different interpretations and mandate that they be
rejected completely or the nature of the attempt to recover some
information from them. For example, routing updates that contain
Scott Best Current Practice [Page 7]
RFC 2360 Guide for Internet Standards Writers June 1998
more data than the tuple count shows. The protocol authors should
consider whether some trailing data can be accepted as additional
routes, or to reject the entire packet as suspect because it is non-
conformant.
2.10 Handling of Protocol Options
Specifications with many optional features increase the complexity of
the implementation and the chance of non-interoperable
implementations. The danger is that different implementations may
specify some combination of options that are unable to interoperate
with each other.
As the document moves along the standard track, implementation
experience shall determine the need for each option. Implementation
shall show whether the option should be a mandatory part of the
protocol or remain an option. If an option is not implemented as the
document advances, it must be removed from the protocol before it
reaches draft standard status.
Therefore, options shall only be present in a protocol to address a
real requirement. For example, options can support future
extensibility of the protocol, a particular market, e.g., the
financial industry, or a specific network environment, e.g., a
network constrained by limited bandwidth. They shall not be included
as a means to "buy-off" a minority opinion. Omission of the optional
item shall have no interoperability consequences for the
implementation that does so.
One possible approach is to document protocol options in a separate
specification. This keeps the main protocol specification clean and
makes it clear that the options are not required to implement the
protocol. Regardless of whether they appear within the specification
or in a separate document, the text shall discuss the full
implications of either using the option or not, and the case for
choosing either course. As part of this, the author needs to
consider and describe how the options are used alongside other
protocols. The text must also specify the default conditions of all
options. For security checking options the default condition is on
or enabled.
There are occasions when mutually exclusive options appear within the
protocol. That is, the implementation of an optional feature
precludes the implementation of the other optional feature. For
clarity, the author needs to state when to implement one or the
other, what the effect of choosing one over the other is, and what
Scott Best Current Practice [Page 8]
RFC 2360 Guide for Internet Standards Writers June 1998
problems the implementer or user may face. The choice of one or the
other options shall have no interoperability consequences between
multiple implementations.
2.11 Indicating Requirement Levels
The BCP 14/RFC 2119, "Key words for use in RFCs to Indicate
Requirement Level", defines several words that are necessary for
writing a standards track document. Editors of standards track
documents must not deviate from the definitions provided as they are
intended to identify interoperability requirements or limit
potentially harmful behavior. The capitalization of these words is
the accepted norm, and can help in identifying an unintentional or
unreasonable requirement. These words have been used in several RFCs
the first instances being STD 3/RFC 1122/RFC 1123.
2.12 Notational Conventions
Formal syntax notations can be used to define complicated protocol
concepts or data types, and to specify values of these data types.
This permits the protocol to be written without concern on how the
implementation is constructed, or how the data type is represented
during transfer. The specification is simplified because it can be
presented as "axioms" that will be proven by implementation.
The formal specification of the syntax used should be referenced in
the text of the standard. Any extensions, subsets, alterations, or
exceptions to that formal syntax should be defined within the
standard.
The STD 11/RFC 822 provides an example of this. In RFC 822 (Section
2 and Appendix D) the Backus-Naur Form (BNF) meta-language was
extended to make its representation smaller and easier to understand.
Another example is STD 16/RFC 1155 (Section 3.2) where a subset of
the Abstract Syntax Notation One (ASN.1) is defined.
The author of a standards track protocol needs to consider several
things before they use a formal syntax notation. Is the formal
specification language being used parseable by an existing machine?
If no parser exists, is there enough information provided in the
specification to permit the building of a parser? If not, it is
likely the reader will not have enough information to decide what the
notation means. In addition, the author should remember machine
parseable syntax is often unreadable by humans, and can make the
specification excessive in length. Therefore, syntax notations
cannot take the place of a clearly written protocol description.
Scott Best Current Practice [Page 9]
RFC 2360 Guide for Internet Standards Writers June 1998
2.13 IANA Considerations
The common use of the Internet standard track protocols by the
Internet community requires that unique values be assigned to
parameter fields. An IETF WG does not have the authority to assign
these values for the protocol it developed. The Internet Assigned
Numbers Authority (IANA) is the central authority for the assignment
of unique parameter values for Internet protocols. The authors of a
developing protocol need to coordinate with the IANA the rules and
procedures to manage the number space. This coordination needs to be
completed prior to submitting the Internet Draft to the standards
track.
A document is in preparation that discusses issues related to
identifier assignment policy and guidelines on specific text to task
IANA with its administration. Standard authors should obtain a copy
of it when it is finalized as an RFC.
For further information on parameter assignment and current
assignments, authors can reference STD 2, RFC 1700, "Assigned
Numbers" (http://www.iana.org).
2.14 Network Management Considerations
When relevant, each standard needs to discuss how to manage the
protocol being specified. This management process should be
compatible with the current IETF Standard management protocol. In
addition, a MIB must be defined within the standard or in a companion
document. The MIB must be compatible with current Structure of
Management Information (SMI) and parseable using a tool such as
SMICng. Where management or a MIB is not necessary this section of
the standard should explain the reason it is not relevant to the
protocol.
2.15 Scalability Considerations
The standard should establish the limitations on the scale of use,
e.g., tens of millions of sessions, gigabits per second, etc., and
establish limits on the resources used, e.g., round trip time,
computing resources, etc. This is important because it establishes
the ability of the network to accommodate the number of users and the
complexity of their relations. The STD 53/RFC 1939 has an example of
such a section. If this is not applicable to the protocol, an
explanation of why not should be included.
Scott Best Current Practice [Page 10]
RFC 2360 Guide for Internet Standards Writers June 1998
2.16 Network Stability
A standard should discuss the relationship between network topology
and convergence behavior. As part of this, any topology that would
be troublesome for the protocol should be identified. Additionally,
the specification should address any possible destabilizing events,
and means by which the protocol resists or recovers from them. The
purpose is to insure that the network will stabilize, in a timely
fashion, after a change, and that a combination of errors or events
will not plunge the network into chaos. The STD 34/RFC 1058, as an
example, has sections which discuss how that protocol handles the
affects of changing topology.
The obvious case this would apply to is a routing protocol. However,
an application protocol could also have dynamic behavior that would
affect the network. For example, a messaging protocol could suddenly
dump a large number of messages onto the network. Therefore, editors
of an application protocol will have to consider possible impacts to
network stability and convergence behavior.
2.17 Internationalization
At one time the Internet had a geographic boundary and was English
only. The Internet now extends internationally. Therefore, data is
interchanged in a variety of languages and character sets. In order
to meet the requirements of an international Internet, a standard
must conform to the policies stated in BCP 18/RFC 2277, "IETF Policy
on Character Sets and Languages".
2.18 Glossary
Every standards track RFC should have a glossary, as words can have
many meanings. By defining any new words introduced, the author can
avoid confusing or misleading the implementers. The definition
should appear on the word's first appearance within the text of the
protocol specification, and in a separate glossary section.
It is likely that definition of the protocol will rely on many words
frequently used in IETF documents. All authors must be knowledgeable
of the common accepted definitions of these frequently used words.
FYI 18/RFC 1983, "Internet Users' Glossary", provides definitions
that are specific to the Internet. Any deviation from these
definitions by authors is strongly discouraged. If circumstances
require deviation, an author should state that he is altering the
commonly accepted definition, and provide rationale as to the
necessity of doing so. The altered definition must be included in
the Glossary section.
Scott Best Current Practice [Page 11]
RFC 2360 Guide for Internet Standards Writers June 1998
If the author uses the word as commonly defined, she does not have to
include the definition in the glossary. As a minimum, FYI 18/RFC
1983 should be referenced as a source.
3 Specific Guidelines
The following are guidelines on how to present specific technical
information in standards.
3.1 Packet Diagrams
Most link, network, and transport layer protocols have packet
descriptions. Packet diagrams included in the standard are very
helpful to the reader. The preferred form for packet diagrams is a
sequence of long words in network byte order, with each word
horizontal on the page and bit numbering at the top:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In cases where a packet is strongly byte-aligned rather than word-
aligned (e.g., when byte-boundary variable-length fields are used),
display packet diagrams in a byte-wide format. The author can use
different height boxes for short and long words, and broken boxes for
variable-length fields:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
Scott Best Current Practice [Page 12]
RFC 2360 Guide for Internet Standards Writers June 1998
3.2 Summary Tables
The specifications of some protocols are particularly lengthy,
sometimes covering a hundred pages or more. In such cases, the
inclusion of a summary table can reduce the risk of conformance
failure by an implementation through oversight. A summary table
itemizes what in a protocol is mandatory, optional, or prohibited.
Summary tables do not guarantee conformance, but serve to assist an
implementer in checking that they have addressed all protocol
features.
The summary table will consist of, as a minimum, four (4) columns:
Protocol Feature, Section Reference, Status, and
References/Footnotes. The author may add columns if they further
explain or clarify the protocol.
In the Protocol Feature column, list the protocol's characteristics,
for example, a command word. We recommend grouping series of related
transactions under descriptive headers, for example, RECEPTION.
Section reference directs the implementer to the section, paragraph,
or page that describes the protocol feature in detail.
Status indicates whether the feature is mandatory, optional, or
prohibited. The author can use either a separate column for each
possibility, or a single column with appropriate codes. These codes
need to be defined at the start of the summary table to avoid
confusion. Possible status codes:
M - must or mandatory
MN - must not
O - optional
S - should
SN - should not
X - prohibited
In the References/Footnotes column authors can point to other RFCs
that are necessary to consider in implementing this protocol feature,
or any footnotes necessary to explain the implementation further.
The STD 3/RFC 1122/RFC 1123 provides examples of summary tables.
3.3 State Machine Descriptions
A convenient method of presenting a protocol's behavior is as a
state-machine model. That is, a protocol can be described by a
series of states resulting from a command, operation, or transaction.
State-machine models define the variables and constants that
Scott Best Current Practice [Page 13]
RFC 2360 Guide for Internet Standards Writers June 1998
establish a state, the events that cause state transitions and the
actions that result from those transitions. Through these models, an
understanding of the protocol's dynamic operation as sequence of
state transitions that occur for any given event is possible. State
transitions can be detailed by diagrams, tables, or time lines.
Note that state-machine models are never to take the place of
detailed text description of the specification. They are adjuncts to
the text. The protocol specification shall always take precedence in
the case of a conflict.
When using a state transition diagram, show each possible protocol
state as a box connected by state transition arcs. The author should
label each arc with the event that causes the transition, and, in
parentheses, any actions taken during the transition. The STD 5/RFC
1112 provides an example of such a diagram. As ASCII text is the
preferred storage format for RFCs, only simple diagrams are possible.
Tables can summarize more complex or extensive state transitions.
In a state transition table, the different events are listed
vertically and the different states are listed horizontally. The
form, action/new state, represents state transitions and actions.
Commas separate multiple actions, and succeeding lines are used as
required. The authors should present multiple actions in the order
they must be executed, if relevant. Letters that follow the state
indicate an explanatory footnote. The dash ('-') indicates an
illegal transition. The STD 51/RFC 1661 provides an example of such
a state transition table. The initial columns and rows of that table
follow as an example:
| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
The STD 18/RFC 904 also presents state transitions in table format.
However, it lists transitions in the form n/a, where n is the next
state and a represents the action. The method in RFC 1661 is
preferred as new state logically follows action. In addition, RFC
904's Appendix C models transitions as the Cartesian product of two
state machines. This is a more complex representation that may be
Scott Best Current Practice [Page 14]
RFC 2360 Guide for Internet Standards Writers June 1998
difficult to comprehend for those readers that are unfamiliar with
the format. We recommend that authors present tables as defined in
the previous paragraph.
A final method of representing state changes is by a time line. The
two sides of the time line represent the machines involved in the
exchange. The author lists the states the machines enter as time
progresses (downward) along the outside of time line. Within the
time line, show the actions that cause the state transitions. An
example:
client server
| |
| | LISTEN
SYN_SENT |----------------------- |
| \ syn j |
| ----------------->| SYN_RCVD
| |
| ------------------|
| syn k, ack j+1 / |
ESTABLISHED |<---------------------- |
| |
4 Document Checklist
The following is a checklist based on the above guidelines that can
be applied to a document:
o Does it identify the security risks? Are countermeasures for each
potential attack provided? Are the effects of the security
measures on the operating environment detailed?
o Does it explain the purpose of the protocol or procedure? Are the
intended functions and services addressed? Does it describe how it
relates to existing protocols?
o Does it consider scaling and stability issues?
o Have procedures for assigning numbers been coordinated with IANA?
o Does it discuss how to manage the protocol being specified? Is a
MIB defined?
o Is a target audience defined?
o Does it reference or explain the algorithms used in the protocol?
o Does it give packet diagrams in recommended form, if applicable?
o Is there a change log?
o Does it describe differences from previous versions, if
applicable?
o Does it separate explanatory portions of the document from
requirements?
o Does it give examples of protocol operation?
Scott Best Current Practice [Page 15]
RFC 2360 Guide for Internet Standards Writers June 1998
o Does it specify behavior in the face of incorrect operation by
other implementations?
o Does it delineate which packets should be accepted for processing
and which should be ignored?
o If multiple descriptions of a requirement are given, does it
identify one as binding?
o How many optional features does it specify? Does it separate them
into option classes?
o Have all combinations of options or option classes been examined
for incompatibility?
o Does it explain the rationale and use of options?
o Have all mandatory and optional requirements be identified and
documented by the accepted key words that define Internet
requirement levels?
o Does it conform to the current internationalization policies of
the IETF?
o Are the recommended meanings for common Internet terms used?
o If not, are new or altered definitions for terms given in a
glossary?
5 Security Considerations
This document does not define a protocol or procedure that could be
subject to an attack. It establishes guidelines for the information
that should be included in RFCs that are to be submitted to the
standards track. In the area of security, IETF standards authors are
called on to define clearly the threats faced by the protocol and the
way the protocol does or does not provide security assurances to the
user.
6 References
[RFC 791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791
September 1981.
[RFC 904] Mills, D., "Exterior Gateway Protocol formal
specification", RFC 904, April 1984.
[RFC 1058] Hedrick, C., "Routing Information Protocol", STD 34,
RFC 1058, June 1988.
[RFC 1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC 1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.
Scott Best Current Practice [Page 16]
RFC 2360 Guide for Internet Standards Writers June 1998
[RFC 1123] Braden, R., "Requirements for Internet hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
March 1992.
[RFC 1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33,
RFC 1350, July 1992.
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC 1662] Simpson, W., "PPP in HLDC-like Framing", STD 51, RFC 1662,
July 1994.
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, October 1994. (http://www.iana.org)
[RFC 1939] Meyers, J., and M. Rose, "Post Office Protocol - Version
3", STD 53, RFC 1939, May 1996.
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983,
August 1996.
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC 2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and
Language", RFC 2277, January 1998.
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
Scott Best Current Practice [Page 17]
RFC 2360 Guide for Internet Standards Writers June 1998
7 Acknowledgments
Peter Desnoyers and Art Mellor began the work on this document.
Others that contributed were:
Bernard Aboba
Harald T. Alvestrand
Fred Baker
Scott Bradner
Brian Carpenter
Robert Elz
Dirk Fieldhouse
Dale Francisco
Gary Malkin
Neal McBurnett
Thomas Narten
Craig Partridge
Vern Paxson
Mike O'Dell
Henning Schulzrinne
Kurt Starsinic
James Watt
8 Editor's Address
Gregor D. Scott
Director, Defense Information Systems Agency
ATTN: JIEO-JEBBC
Ft. Monmouth, NJ 07703-5613
USA
Phone: (732) 427-6856
Fax: (732) 532-0853
EMail: scottg@ftm.disa.mil
Scott Best Current Practice [Page 18]
RFC 2360 Guide for Internet Standards Writers June 1998
9 Appendix
CHANGES FROM DRAFT -06
The following changes were made following IESG review:
References to RFC 1543 were changed to RFC 2223 that obsoleted it.
In section 2.1, "export control" was dropped as a valid reason for
not selecting a security mechanism. In addition, ambiguous or
conflicting sentences were removed.
In section 2.1 reference made to RFC 2315 as an additional source of
information.
Section 2.5 was changed to highlight the Change Log's purpose as
assistance to implementers.
The IANA Considerations section (2.13) was rewritten to highlight
that the IANA guidelines document is work in progress but should be
used when it becomes available.
Section 3.4 Character Sets was deleted and replaced by section 2.17
Internationalization.
Spelling and grammar corrections were made.
CHANGES FROM DRAFT -05
A sentence pointing to a pending document that further addresses IANA
considerations was added to section 2.13. The current draft of that
document is draft-iesg-iana-considerations-02.txt. A clause stating
that the IANA established the assignment policies was removed since it
appeared to conflict with the intent of the referenced ID.
Placeholders for the BCP and RFC number have been added to the text
and reference section.
A new section (2.5) requiring change logs as documents progress along
the standards track was added.
References to RFC 2044 were changed to RFC 2279 that obsoleted it.
Spelling and grammar corrections were made.
CHANGES FROM DRAFT -04
A paragraph pointing to a pending document that further addresses
security was updated.
Scott Best Current Practice [Page 19]
RFC 2360 Guide for Internet Standards Writers June 1998
10 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.
Scott Best Current Practice [Page 20]