Полный русский перевод · RFC3818

RFC3818 · Соображения IANA для протокола Point-to-Point Protocol (PPP)

IANA Considerations for the Point-to-Point Protocol (PPP)

Карточка документа · Архив принятого перевода · Официальный источник

Рабочая группа сети                                      V. Schryver
Запрос комментариев: 3818                         Rhyolite Software
BCP: 88                                                        Июнь 2004
Категория: Лучшая современная практика

       Соображения IANA для протокола Point-to-Point Protocol (PPP)

Этот документ устанавливает лучшую современную практику Интернета для
   интернет-сообщества и запрашивает обсуждение и предложения по
   улучшениям. Распространение этого меморандума не ограничено.

Авторское право (C) The Internet Society (2004).

Устав рабочей группы расширений Point-to-Point Protocol (PPP)
   (pppext) включает обязанность «активно продвигать наиболее полезные
   расширения PPP до полного стандарта, одновременно защищаясь от
   дальнейших усовершенствований сомнительной ценности». В поддержку этого
   устава выделение номеров протоколов PPP и других назначаемых номеров
   больше не будет осуществляться по принципу «первый пришёл — первый
   обслужен».

Протокол Point-to-Point (PPP, RFC 1661 [1]) является зрелым протоколом
   с большим числом подпротоколов, инкапсуляций и иных расширений. Основной
   протокол, как и его расширения, задействует множество пространств имён,
   в которых необходимо назначать значения.
   http://www.iana.org/assignments/ppp-numbers содержит список пространств
   адресов и их текущих назначений.

   Исторически начальные значения в новых пространствах имён часто
   выбирались в RFC, создающих эти пространства имён. IANA выполняла
   последующие назначения в соответствии с политикой «первый пришёл —
   первый обслужен». Этот меморандум изменяет эту политику для некоторых
   пространств адресов PPP.

   Большинство пространств имён PPP находятся в состоянии покоя, но
   некоторые продолжают привлекать предлагаемые расширения. Расширения PPP
   были определены в RFC со статусом «Informational» и поэтому не подлежат
   рецензированию. Эти расширения обычно требуют значений, назначаемых в
   одном или нескольких пространствах имён PPP. Установление требования
   «консенсуса IETF» для этих выделений обеспечит рассмотрение предложений.

Термины «пространство имён», «назначенное значение» и «регистрация»
   используются здесь в значениях, определённых в BCP 26 [2]. Политики
   «первый пришёл — первый обслужен» и «консенсус IETF», используемые здесь,
   также имеют значения, определённые в BCP 26.

Для назначения новых значений в следующих пространствах адресов требуется
   консенсус IETF, обычно достигаемый через рабочую группу расширений
   Point-to-Point Protocol (pppext):

                PPP DLL PROTOCOL NUMBERS
                PPP LCP AND IPCP CODES
                PPP LCP CONFIGURATION OPTION TYPES
                PPP CCP CONFIGURATION OPTION TYPES
                PPP CHAP AUTHENTICATION ALGORITHMS
                PPP LCP FCS-ALTERNATIVES
                PPP MULTILINK ENDPOINT DISCRIMINATOR CLASS
                PPP LCP CALLBACK OPERATION FIELDS
                PPP BRIDGING CONFIGURATION OPTION TYPES
                PPP BRIDGING MAC TYPES
                PPP BRIDGING SPANNING TREE
                PPP IPCP CONFIGURATION OPTION TYPES
                PPP IPV6CP CONFIGURATION OPTIONS
                PPP IP-Compression-Protocol Types

Этот меморандум касается вопросов процесса, а не протокола.

[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
       RFC 1661, July 1994.

   [2] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

Vernon Schryver
   Rhyolite Software
   2482 Lee Hill Drive
   Boulder, Colorado 80302

   EMail: vjs@rhyolite.com

Авторское право (C) The Internet Society (2004). Этот документ подпадает
   под права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением
   предусмотренного в нём, авторы сохраняют все свои права.

   Этот документ и содержащаяся в нём информация предоставляются на условиях
   «КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ
   КОТОРОЙ СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), THE INTERNET SOCIETY И
   INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ
   ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО
   ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ,
   И ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ
   ОПРЕДЕЛЁННОЙ ЦЕЛИ.

IETF не занимает позиции относительно действительности или объёма каких-либо
   прав интеллектуальной собственности либо иных прав, которые могут быть
   заявлены как относящиеся к реализации или использованию технологии,
   описанной в этом документе, или относительно того, может ли быть или не
   может быть доступна какая-либо лицензия на основании таких прав; также IETF
   не заявляет, что предпринимала какие-либо независимые усилия по выявлению
   таких прав. Информацию о процедурах в отношении прав в документах RFC можно
   найти в BCP 78 и BCP 79.

   Копии раскрытий IPR, сделанных Секретариату IETF, и любые заверения о
   лицензиях, которые будут предоставлены, либо результат попытки получить
   общую лицензию или разрешение на использование таких прав собственности
   разработчиками или пользователями этой спецификации можно получить из
   онлайнового репозитория IPR IETF по адресу
   http://www.ietf.org/ipr.

   IETF предлагает любой заинтересованной стороне довести до её сведения любые
   авторские права, патенты или заявки на патенты либо иные права собственности,
   которые могут охватывать технологию, которая может потребоваться для
   реализации этого стандарта. Просьба направлять информацию в IETF по адресу
   ietf-
   ipr@ietf.org.

Финансирование функции RFC Editor в настоящее время предоставляется
   The Internet Society.