A Model for IETF Process Experiments
RFC 3933 определяет промежуточный подход к изменению процессов IETF между неформальными решениями IESG и полным процессом разработки стандартов. Сначала подготавливается Internet-Draft с явно указанным сроком прекращения действия, обычно не превышающим одного года после принятия; если IESG считает предложение правдоподобным и потенциально полезным, инициируется четырёхнедельный IETF Last Call. После Last Call IESG повторно оценивает предложение и, если признаёт эксперимент уместным, подготавливается второй I-D; затем документ и эксперимент объявляются, эксперимент начинается, а документ направляется на публикацию как Experimental RFC. К окончанию или до окончания срока IESG либо перерабатывает документ в BCP RFC на основе практического опыта, либо процедура прекращает действие. Эксперименты могут ограничиваться отдельными областями или рабочими группами; IESG СЛЕДУЕТ проявлять должную осторожность, чтобы изменения не снижали качество рассмотрения безопасности протоколов, либо обеспечивать, чтобы предложения экспериментов содержали механизмы раннего обнаружения и исправления такого ухудшения.
Network Working Group J. Klensin
Request for Comments: 3933 S. Dawkins
BCP: 93 November 2004
Category: Best Current Practice
A Model for IETF Process Experiments
Статус этого меморандума
Этот документ определяет Internet Best Current Practices для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение этого меморандума не ограничено.
Уведомление об авторском праве
Copyright (C) The Internet Society (2004).
Аннотация
За последние десять лет IETF разрабатывала изменения процесса одним
из двух способов: объявлением со стороны IESG, иногда основанным на
неформальных соглашениях при ограниченном участии сообщества и его
осведомлённости, и формальным использованием того же механизма,
который применяется для спецификации протоколов. Первый механизм
часто оказывался слишком облегчённым, второй — слишком громоздким.
Этот документ определяет промежуточный подход к системе внесения
изменений в процесс IETF, который в значительной степени опирается на
модель «предложить и провести эксперимент, оценить эксперимент, а
затем установить постоянные процедуры на основе опыта эксплуатации»,
а не на ранее предпринимавшиеся подходы.
Содержание
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Предпосылки и спецификация . . . . . . . . . . . . . . . . . . 2
3. Вопросы безопасности . . . . . . . . . . . . . . . . . . . . 5
4. Благодарности . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Нормативная ссылка . . . . . . . . . . . . . . . . . . . 5
5.2. Информационные ссылки . . . . . . . . . . . . . . . . . 5
6. Адреса авторов . . . . . . . . . . . . . . . . . . . . . . . 6
Полное заявление об авторском праве . . . . . . . . . . . . . 7
Klensin & Dawkins Best Current Practice [Page 1]
RFC 3933 A Model for IETF Process Experiments November 2004
1. Введение
Этот документ определяет промежуточный подход к системе внесения
изменений в процесс IETF, который в значительной степени опирается на
модель «предложить и провести эксперимент, оценить эксперимент, а
затем установить постоянные процедуры на основе опыта эксплуатации»,
а не на ранее предпринимавшиеся подходы.
2. Предпосылки и спецификация
После изменений 1992 года, задокументированных в [RFC1396], IETF
использует два механизма для изменений процесса.
1. IESG по собственной инициативе приняла ряд процедурных изменений
и неформально документировала их, используя широкую свободу
усмотрения, неявно предоставленную ей [RFC2026]. Это обеспечивало
облегчённый механизм изменений, но эта облегчённость имела свою
цену: иногда согласованность с более широким сообществом IETF была
недостаточной.
2. IETF также использовала процесс разработки стандартов протоколов
[RFC2026], чтобы определить заинтересованное сообщество, провести
один или несколько BoF, сформулировать устав рабочей группы,
обсудить предлагаемые изменения в сообществе, выработать
обще-IETF-консенсус по изменениям и опубликовать (обычно)
спецификации Best Current Practice. Это обеспечивало полное
участие сообщества, но также имело свою цену в гибкости. IETF не
часто изменяет свои формальные процессы (уточнения IPR в
[RFC3667, RFC3668] являются первыми документированными изменениями
[RFC2026] с 1996 года), и сообщество по понятным причинам неохотно
постоянно изменяет или расширяет формально принятые процессы
непроверенными новыми процедурами.
Между обновлениями процесса BCP и неформальными соглашениями
существует промежуточный вариант. Этот документ определяет
упорядочивание и формализацию неформальных механизмов IESG,
перечисленных выше в пункте 1, как средство продвижения процедурных
изменений, которые могут оказаться ценными.
Описанные здесь механизмы расширяют набор инструментов IESG для
постоянного решения вопросов процесса. Они дополняют существующие
инструменты, а не пытаются заменить их единственной «серебряной
пулей». Выбор использования процедуры, изложенной в этом документе,
или других механизмов, доступных IESG и сообществу — нынешних или
будущих — остаётся в руках IESG. Если IESG не будет разумно
пользоваться этим усмотрением, этот документ не предоставляет
дополнительных средств правовой защиты.
Klensin & Dawkins Best Current Practice [Page 2]
RFC 3933 A Model for IETF Process Experiments November 2004
Некоторые истолковывали текущие процедуры как предоставляющие IESG
все возможности, изложенные здесь. Если это верно, данный документ
лишь поощряет IESG использовать этот тип механизма чаще, отдавая ему
предпочтение перед менее упорядоченными механизмами, и более явно
документировать свои действия и решения.
Эта спецификация разрешает и поощряет IESG принимать и вводить
«эксперименты с процессами» посредством следующей процедуры:
1. Составляется I-D с описанием предлагаемой новой или изменённой
процедуры. Желательно, но не обязательно, заявление о проблеме,
которую, как ожидается, удастся решить (намерение состоит в том,
чтобы сохранить твёрдые требования к такому эксперименту настолько
облегчёнными, насколько возможно). Аналогично, конкретные
экспериментальные или оценочные критерии, хотя и крайне желательны,
не обязательны — для некоторых ожидаемых нами изменений процесса
будет как адекватно, так и достаточно, чтобы IESG по окончании
периода sunset пришла к выводу, что сообщество в целом считает
положение дел лучшим (или худшим). I-D должен указывать явный срок
истечения действия («sunset»), который, как правило, не превышает
одного года после принятия.
2. Если IESG считает предложение правдоподобным и правдоподобно
полезным, инициируется четырёхнедельный IETF Last Call. IESG может
устанавливать любые процедуры, которые сочтёт нужными для принятия
такого решения и для предотвращения атак отказа в обслуживании,
исходящих от большого числа ложных или несущественных предложений.
В частности, она может установить процедуру, требующую определённого
числа одобрений или одобрений определённого типа, прежде чем IESG
рассмотрит предложение. Однако от IESG ожидается понимание того,
что процедуры или процессы рецензирования, действующие как механизм
существенных задержек, не соответствуют намерению этой
спецификации.
3. По завершении Last Call IESG повторно оценивает правдоподобность и
уместность предложения. Если она заключает, что предлагаемый
эксперимент уместен, создаётся второй I-D (либо IESG, либо
первоначальными авторами по рекомендации IESG), который устраняет
любые вопросы определений, выявленные в ходе Last Call, и который
явно определяет вопросы, поднятые в ходе Last Call, и отвечает на
них.
4. Затем объявляются документ и эксперимент, эксперимент начинается,
а документ направляется для публикации как Experimental RFC.
Klensin & Dawkins Best Current Practice [Page 3]
RFC 3933 A Model for IETF Process Experiments November 2004
IESG прямо уполномочена использовать этот механизм (основанный на
Experimental RFC) для получения опыта применения предлагаемых
изменений в спецификациях BCP. Нет требования утверждать спецификацию
BCP для эксперимента до того, как будет установлена ценность
эксперимента.
Разумеется, IESG могла бы прийти к выводу «плохая идея» на любой
стадии этого процесса и отказаться от эксперимента. Она могла бы
рекомендовать публикацию экспериментального документа с обсуждением
того, почему это была плохая идея, но не обязана это делать. В
приведённом выше списке намеренно не уточняется, откуда берутся I-D:
на первом и/или третьем этапах могли бы использоваться WG, группа
проектирования, индивидуальный вклад, редакционная группа или иной
механизм, но никаких конкретных механизмов не требуется, и IESG прямо
разрешено формировать такие предложения внутри себя.
В каждом случае ожидается, что решение IESG продолжать (или не
продолжать) процедурный эксперимент либо предпринимать ведущие к нему
шаги будет отражать её суждение о наличии приблизительного консенсуса
в сообществе. Это суждение может быть обжаловано обычными процедурами,
но IESG и сообществу напоминают, что экспериментальная попытка
опробовать что-либо в течение фиксированного периода обычно является
лучшим инженерным подходом, чем продолжительное философское
обсуждение без какого-либо опыта, который его подтверждает.
Ничто из вышесказанного не следует истолковывать как требование
обще-IETF-попытки для какого-либо конкретного эксперимента с процессом.
Предложение такого эксперимента может определять выбранные области,
выбранные рабочие группы, рабочие группы, соответствующие некоторым
конкретным критериям (например, созданные после определённого времени
или имеющие установленный возраст), либо может быть конкретным иными
способами.
К окончанию срока истечения действия («sunset») или до него IESG либо
пересмотрела бы (либо обеспечила бы пересмотр) документ в BCP RFC,
либо процедура прекратила бы действие и, предположительно, не была бы
снова опробована, если только что-либо радикально не изменилось бы.
Документ, описывающий, почему эксперимент оказался успешным или
неудачным, был бы желателен, но реалистично не мог бы быть требованием.
Если процедура переходила в BCP, BCP отражал бы то, что мы назвали бы
«опытом эксплуатации» в реальном мире.
Мы отмечаем, что если процедуры, которые IESG приняла (и процедурные
исключения, которые она сделала) за последнее десятилетие, являются
законными, то IESG имеет полномочия ввести указанные здесь изменения,
самозапустив этот процесс.
Klensin & Dawkins Best Current Practice [Page 4]
RFC 3933 A Model for IETF Process Experiments November 2004
3. Вопросы безопасности
Этот документ определяет механизм развития процедур IETF. Он не
поднимает и не рассматривает какие-либо относящиеся к конкретным
протоколам вопросы безопасности. При рассмотрении экспериментальных
изменений процедур IESG, разумеется, следует проявлять должную
осторожность, чтобы такие изменения не снижали качество
рецензирования и рассмотрения безопасности протоколов или, по крайней
мере, чтобы предложения экспериментов с процессом содержали механизмы
раннего обнаружения и исправления на случай ухудшения качества.
4. Благодарности
Первая редакция этого документа значительно выиграла от предложений
и комментариев Avri Doria, Margaret Wasserman и Harald Alvestrand, а
также от обсуждений с General Area Directorate и на её открытом
заседании во время IETF 59. После обсуждения в списке рассылки
значительный объём пояснительного материала был удалён в отдельный
документ для текущей версии.
Первая версия этого документа была размещена как Internet Draft 7
февраля 2004 года.
5. Ссылки
5.1. Нормативные ссылки
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
5.2. Информационные ссылки
[RFC1396] Crocker, S., "The Process for Organization of Internet
Standards Working Group (POISED)", RFC 1396, January 1993.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
Klensin & Dawkins Best Current Practice [Page 5]
RFC 3933 A Model for IETF Process Experiments November 2004
6. Адреса авторов
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Spencer Dawkins
1547 Rivercrest Blvd.
Allen, TX 75002
USA
Phone: +1 469 330 3616
EMail: spencer@mcsr-labs.org
Klensin & Dawkins Best Current Practice [Page 6]
RFC 3933 A Model for IETF Process Experiments November 2004
Полное заявление об авторском праве
Copyright (C) The Internet Society (2004).
Этот документ подлежит действию прав, лицензий и ограничений,
содержащихся в BCP 78 и на www.rfc-editor.org, и, кроме случаев,
установленных в них, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются на
условиях «КАК ЕСТЬ», и вкладчик, организация, которую он или она
представляет либо которой спонсируется (если таковая имеется), The
Internet Society и The Internet Engineering Task Force отказываются
от всех гарантий, явных или подразумеваемых, включая, помимо прочего,
любую гарантию того, что использование содержащейся здесь информации
не нарушит каких-либо прав, или любые подразумеваемые гарантии
товарной пригодности или пригодности для определённой цели.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма
каких-либо прав интеллектуальной собственности или других прав,
которые могут заявляться как относящиеся к реализации или
использованию технологии, описанной в этом документе, либо
относительно степени, в которой какая-либо лицензия по таким правам
может быть или не быть доступна; она также не заявляет, что
предпринимала какие-либо независимые усилия для выявления таких прав.
Информацию о процедурах ISOC в отношении прав на документы ISOC можно
найти в BCP 78 и BCP 79.
Копии раскрытий IPR, сделанных Секретариату IETF, и любые заверения о
лицензиях, которые будут предоставлены, либо результат попытки
получить общую лицензию или разрешение на использование таких прав
собственности разработчиками или пользователями этой спецификации
можно получить из онлайнового репозитория IPR IETF по адресу
http://www.ietf.org/ipr.
IETF приглашает любую заинтересованную сторону довести до его сведения любые авторские права, патенты или заявки на патенты либо другие права собственности, которые могут распространяться на технологию, которая может потребоваться для реализации этого стандарта. Просьба направлять эту информацию в IETF по адресу ietf-
ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется Internet Society.
Klensin & Dawkins Лучшая современная практика [Страница 7]
Network Working Group J. Klensin
Request for Comments: 3933 S. Dawkins
BCP: 93 November 2004
Category: Best Current Practice
A Model for IETF Process Experiments
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 (2004).
Abstract
The IETF has designed process changes over the last ten years in one
of two ways: announcement by the IESG, sometimes based on informal
agreements with limited community involvement and awareness, and
formal use of the same mechanism used for protocol specification.
The first mechanism has often proven to be too lightweight, the
second too heavyweight.
This document specifies a middle-ground approach to the system of
making changes to IETF process, one that relies heavily on a "propose
and carry out an experiment, evaluate the experiment, and then
establish permanent procedures based on operational experience" model
rather than those previously attempted.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background and Specification . . . . . . . . . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative Reference. . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
Klensin & Dawkins Best Current Practice [Page 1]
RFC 3933 A Model for IETF Process Experiments November 2004
1. Introduction
This document specifies a middle-ground approach to the system of
making changes to IETF process, one that relies heavily on a "propose
and carry out an experiment, evaluate the experiment, and then
establish permanent procedures based on operational experience" model
rather than those previously attempted.
2. Background and Specification
Since the 1992 changes documented in [RFC1396], the IETF has used two
mechanisms for process changes.
1. IESG has adopted a number of procedural changes on its own
initiative and documented them informally, utilizing the wide
discretion implicitly granted to them by [RFC2026]. This provided
a lightweight mechanism for change, but the lightness came with a
cost: There was sometimes too little alignment with the larger
IETF community.
2. The IETF has also used the [RFC2026] protocol standards
development process to identify a community of interest, hold one
or more BoFs, charter a working group, discuss proposed changes
within the community, develop IETF-wide consensus on the changes,
and publish (usually) Best Current Practice specifications. This
provided full community involvement but also came with a cost in
flexibility. The IETF does not change its formal processes often
(the IPR clarifications in [RFC3667, RFC3668] are the first
documented changes to [RFC2026] since 1996), and the community is
understandably reluctant to permanently alter or extend formally
adopted processes with untried new procedures.
There is a middle ground between BCP process updates and informal
agreements. This document specifies regularizing and formalizing the
informal IESG mechanisms listed in 1 above as a means of moving
forward with procedural changes that might prove valuable.
The mechanisms outlined here add to the IESG's range of tools for
dealing with process issues on an ongoing basis. They supplement the
existing tools rather than attempting to replace them with a single
"magic bullet". The choice of using the procedure outlined in this
document or other mechanisms available to the IESG and the community
-- present or future -- remains in the IESG's hands. If the IESG
does not exercise this discretion wisely, this document provides no
additional remedies.
Klensin & Dawkins Best Current Practice [Page 2]
RFC 3933 A Model for IETF Process Experiments November 2004
Some have interpreted the current procedures as giving the IESG all
of the capabilities outlined here. If this were true, this document
only encourages the IESG to use this type of mechanism more
frequently in preference to less streamlined ones, and to more
explicitly document its actions and decisions.
This specification permits and encourages the IESG to adopt and
institute "process experiments" by using the following procedure:
1. An I-D is written describing the proposed new or altered
procedure. A statement of the problem expected to be resolved is
desirable but not required (the intent is to keep the firm
requirements for such an experiment as lightweight as possible).
Similarly, specific experimental or evaluative criteria, although
highly desirable, are not required -- for some of the process
changes we anticipate, having the IESG reach a conclusion at the
end of the sunset period that the community generally believes
things to be better (or worse) will be both adequate and
sufficient. The I-D must state an explicit "sunset" timeout
typically, not to exceed one year after adoption.
2. If the IESG believes the proposal is plausible and plausibly
useful, a four-week IETF Last Call is initiated. The IESG can
institute whatever procedures it wishes to make this determination
and to avoid denial of service attacks from large numbers of
spurious or unimportant proposals. In particular, they might
institute a procedure requiring a number of endorsements, or
endorsements of a particular type, before the IESG considers the
proposal. The IESG is, however, expected to understand that
procedures or review processes that act as a mechanism for
significant delays do not fall within the intent of this
specification.
3. At the conclusion of the Last Call, the IESG reevaluates the
plausibility and appropriateness of the proposal. If they
conclude that the proposed experiment is appropriate, a second I-D
is generated (either by the IESG or by the original authors with
IESG advice) that cleans up any definitional issues exposed in the
Last Call and that explicitly identifies and responds to issues
raised during the Last Call.
4. The document and experiment are then announced, the experiment is
begun, and the document is forwarded for publication as an
Experimental RFC.
Klensin & Dawkins Best Current Practice [Page 3]
RFC 3933 A Model for IETF Process Experiments November 2004
The IESG is explicitly authorized to use this mechanism (based on
Experimental RFCs) to gain experience with proposed changes to BCP
specifications. There is no requirement to approve a BCP
specification for the experiment until the experiment is found to
have value.
The IESG could, of course, reach a "bad idea" conclusion at any stage
in this process and abandon the experiment. It might recommend
publication of the experimental document, with a discussion of why it
was a bad idea, but is not required to do so. The list above is
deliberately vague about where the I-Ds come from: a WG, design team,
individual contribution, editing group, or other mechanism could be
used in the first and/or third steps, but no specific mechanisms are
required, and the IESG is explicitly permitted to generate such
proposals internally.
In each case, the IESG's decision to go forward (or not) with a
procedural experiment, or the steps leading up to one, is expected to
reflect their judgment of the existence of rough consensus in the
community. That judgment may be appealed using the usual procedures,
but the IESG and the community are reminded that an experimental
attempt to try something for a fixed period is typically a better
engineering approach than extended philosophical discussion without
any experience to back it up.
Nothing above is to be construed as requiring an IETF-wide attempt
for any given process experiment. A proposal for such an experiment
may specify selected areas, selected working groups, working groups
meeting some specific criteria (e.g., those created after a
particular time or of a specified age), or be specific in other ways.
At or before the end of the "sunset" timeout, the IESG would either
revise (or cause to be revised) the document into a BCP RFC or the
procedure would expire and, presumably, not be tried again unless
something changed radically. A document describing why the
experiment had succeeded or failed would be desirable but could not,
realistically, be a requirement. If the procedure went to BCP, the
BCP would reflect what we would call "operational experience" in the
real world.
We note that, if the procedures the IESG has adopted (and the
procedural exceptions it has made) over the last decade are
legitimate, then the IESG has the authority to institute the changes
specified here by bootstrapping this process.
Klensin & Dawkins Best Current Practice [Page 4]
RFC 3933 A Model for IETF Process Experiments November 2004
3. Security Considerations
This document specifies a mechanism for evolving IETF procedures. It
does not raise or consider any protocol-specific security issues. In
considering experimental changes to procedures, the IESG should, of
course, exercise due caution that such changes not reduce the quality
of security review and consideration for protocols or, at least, that
the process experiment proposals contain early detection and
correction mechanisms should quality deterioration occur.
4. Acknowledgements
The first revision of this document benefited significantly from
suggestions and comments from Avri Doria, Margaret Wasserman, and
Harald Alvestrand, and from discussions with the General Area
Directorate and at its open meeting during IETF 59. After mailing
list discussion, considerable explanatory material was removed to a
separate document for the current version.
The first version of this document was posted as an Internet Draft on
February 7, 2004.
5. References
5.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
5.2. Informative References
[RFC1396] Crocker, S., "The Process for Organization of Internet
Standards Working Group (POISED)", RFC 1396, January 1993.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
Klensin & Dawkins Best Current Practice [Page 5]
RFC 3933 A Model for IETF Process Experiments November 2004
6. Authors' Addresses
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Spencer Dawkins
1547 Rivercrest Blvd.
Allen, TX 75002
USA
Phone: +1 469 330 3616
EMail: spencer@mcsr-labs.org
Klensin & Dawkins Best Current Practice [Page 6]
RFC 3933 A Model for IETF Process Experiments November 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and at www.rfc-editor.org, and except as set
forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC's procedures with respect to rights in ISOC Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Klensin & Dawkins Best Current Practice [Page 7]