Internet Engineering Task Force (IETF)                         A. Farrel
Request for Comments: 7221                              Juniper Networks
Category: Informational                                  D. Crocker, Ed.
ISSN: 2070-1721                              Brandenburg InternetWorking
                                                              April 2014
Internet Engineering Task Force (IETF)                         A. Farrel
Request for Comments: 7221                              Juniper Networks
Category: Informational                                  D. Crocker, Ed.
ISSN: 2070-1721                              Brandenburg InternetWorking
                                                              April 2014

Handling of Internet-Drafts by IETF Working Groups




The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.


Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2014 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents


   1. Introduction ....................................................2
      1.1. What Is a WG Draft? ........................................3
      1.2. Working Group Authority and Consensus ......................4
      1.3. Questions Considered in This Document ......................5
   2. Adoption Sequence ...............................................6
      2.1. Common Steps ...............................................6
      2.2. Criteria for Adoption ......................................6
   3. Authors/Editors .................................................8
   4. Document History and Stability ..................................8
   5. Some Issues for Consideration ..................................10
      5.1. Individual I-Ds under WG Care .............................10
      5.2. WG Drafts Can Become Individual Drafts ....................11
      5.3. Competing Drafts ..........................................11
   6. Security Considerations ........................................13
   7. Acknowledgements ...............................................13
   8. Informative References .........................................13
   1. Introduction ....................................................2
      1.1. What Is a WG Draft? ........................................3
      1.2. Working Group Authority and Consensus ......................4
      1.3. Questions Considered in This Document ......................5
   2. Adoption Sequence ...............................................6
      2.1. Common Steps ...............................................6
      2.2. Criteria for Adoption ......................................6
   3. Authors/Editors .................................................8
   4. Document History and Stability ..................................8
   5. Some Issues for Consideration ..................................10
      5.1. Individual I-Ds under WG Care .............................10
      5.2. WG Drafts Can Become Individual Drafts ....................11
      5.3. Competing Drafts ..........................................11
   6. Security Considerations ........................................13
   7. Acknowledgements ...............................................13
   8. Informative References .........................................13
1. Introduction
1. 介绍

The productive output of an IETF working group (WG) is documents, as mandated by the working group's charter. Working groups develop these documents based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication. The discussion applies only to the IETF and does not cover IRTF groups, where practices vary widely.


Within the general constraints of formal IETF process and the specific constraints of a working group's charter, there can be considerable freedom in the adoption and development of drafts. As with most IETF activities, the ultimate arbiter of such choices is working group agreement, within the constraints of its charter. As with most working group management, this agreement might be explicit or implicit, depending upon the efficiencies that the group deems appropriate.


NOTE: This document is intentionally non-normative. It is meant as a guide to common practice, rather than as a formal definition of what is permissible.


1.1. What Is a WG Draft?
1.1. 什么是工作组草案?

Working group drafts are documents that are subject to IETF working group revision control, with advancement for publication as an RFC requiring rough consensus in the working group and then in the broader IETF. Creation or adoption of a draft by a working group -- as well as substantive changes to the document -- need to represent working group rough consensus.


Documents under development in the IETF community are distributed as Internet-Drafts (I-Ds) [RFC2026] [ID-Info]. Working groups use this mechanism for producing their official output, per Section 7.2 of [RFC2418] and Section 6.3 of [Tao]. The common convention for identifying an I-D formally under the ownership of a working group is by the inclusion of "ietf" in the second field of the I-D filename and the working group name in the third field, per Section 7 of [ID-Guidelines]. That is:




In contrast, individual submissions are drafts being created and pursued outside of a working group, although a working group might choose to adopt the draft later, as discussed below. Anyone is free to create an individual submission at any time. Such documents are typically distinguished through the use of the author/editor's last name, in the style of:




(Also see Section 5.1 for an elaboration on this naming.)


Responsibility for direct revision of a working group I-D is assigned to its editors and authors. See Section 3 for discussion about their selection and role.


1.2. Working Group Authority and Consensus
1.2. 工作组的权威和共识

A premise of the IETF is that, within a working group, it is the working group itself that has final authority over the content of its documents, within the constraints of the working group's charter. No individual has special authority for the content. The Chairs assign document authors/editors and can formulate design teams, but the content of working group documents is always, ultimately, subject to working group approval. Approval is described in terms of the IETF's "rough consensus" construct, which is the prime example of the IETF's preference for pragmatics over niceties. Unanimous agreement is always desirable, but more approximate (rough) agreement will suffice, as long as it is clear and strong.


Other than for selection of document authors/editors, as discussed in Section 3, working group decision-making about document management is subject to normal IETF rough consensus rules. Useful descriptions of this process for a working group are in Section 3.3 of [RFC2418] and Section 4.2 of [Tao]. Discussion of the nature of rough consensus can be found in [Consensus].


In terms of the IETF's formal rough consensus processes, the working group explicitly develops, modifies, reviews, and approves document content, according to overt rough consensus. For difficult topics and/or difficult working group dynamics, this laborious process really is essential. Its diligence validates progress at each step along the way. However, working groups often handle simpler matters more simply, such as allowing a Chair to assert the likely agreement and then merely call for objections. Ultimately, the mode of working group decision-making is determined by the comfort and engagement of the working group with the way the decisions are being made.


At times, a document author/editor can appear to have considerable authority over content, but this is (merely) for efficiency. That is, the Chairs can permit authors and editors to proceed with an implied (default) working group agreement, as long as the working group is comfortable with that mode. Of course, the benefit in the mode is efficiency, but its risk is failure to retain or verify actual consensus among the working group participants. When a working group is operating in the mode of active, direct author/ editor content development, an easy validation method is simply to have Chairs query the working group when a new document version appears, asking for comments and concerns.


In general, when it is not completely obvious what the opinion of the working group is, Working Group Chairs can poll the working group to find out. As with any other consensus question, the form in which it is asked can make a difference. In particular, a general 'yes/no' question often is not as helpful as asking supporters and detractors of a draft -- or of the decision under consideration -- to provide their reasons, not merely their preferences. In effect, this treats the matter of consensus as an ongoing discussion. Ideally, the discussion can produce changes in the document or in participant views, or both.


1.3. Questions Considered in This Document
1.3. 本文件审议的问题

The purpose of this document is to discuss the criteria and sequence typically followed when adopting and developing a formal IETF working group document. Therefore, this document considers the following questions that are particularly relevant to Working Group Chairs who are charged with running the process:


* How do Working Group Chairs decide which drafts to adopt and when?

* 工作组主席如何决定何时通过哪些草案?

* Is it necessary to poll the working group explicitly, and what does a working group poll look like?

* 是否有必要明确投票给工作组?工作组投票是什么样的?

* How do Working Group Chairs make the decision?

* 工作组主席如何作出决定?

* What are the process steps the working group will choose to use, for an I-D to become a WG I-D?

* 工作组将选择使用哪些流程步骤,使I-D成为工作组I-D?

* Are there any special cases?

* 有什么特殊情况吗?

* Can a document be created as a WG I-D from scratch?

* 文档是否可以从头创建为工作组ID?

* How can competing drafts be handled?

* 如何处理竞争性草案?

* Can an individual I-D be under the care of a WG?

* 个人身份证是否可以由工作组保管?

* Can a WG I-D become an individual I-D?

* 工作组身份证明是否可以成为个人身份证明?

2. Adoption Sequence
2. 采用顺序
2.1. Common Steps
2.1. 常见步骤

When there is interest in adopting a document as a new working group document, the Chairs often:


1. Remind current draft owners that they are transferring change control for the document to the IETF. (This is a particularly significant point for a document covered by proprietary interests, because it typically entails a negotiation between the current owners and the IETF, including a formal agreement.)

1. 提醒当前草稿所有者,他们正在将文档的更改控制转移到IETF。(这对于专有权益所涵盖的文档来说尤其重要,因为它通常需要当前所有者和IETF之间的协商,包括正式协议。)

2. Check for known IPR that needs to be disclosed, using some technique like those described in [RFC6702].

2. 使用[RFC6702]中描述的技术检查需要披露的已知知识产权。

3. Obtain working group rough consensus.

3. 获得工作组的大致共识。

4. Choose document editors.

4. 选择文档编辑器。

5. Instruct authors to post the WG I-D.

5. 指导作者发布工作组ID。

6. Approve posting [Approval].

6. 批准发布[批准]。

7. Ensure that the non-working group version of the draft is marked as being replaced by this working group version.

7. 确保草案的非工作组版本标记为被此工作组版本替换。

8. Encourage everyone to enjoy the ensuing working group discussion...

8. 鼓励大家享受接下来的工作组讨论。。。

2.2. Criteria for Adoption
2.2. 收养标准

No formal specification for working group 'adoption' of a draft exists; the current document is meant to provide a description of common activities for this, but again note that it is not normative.


There are some basic considerations when deciding to adopt a draft:


* Is there a charter milestone that explicitly calls for such a document?

* 是否有明确要求此类文件的宪章里程碑?

* Is the topic of the I-D within scope for the working group?

* I-D的主题是否在工作组的范围内?

* Is the purpose of the draft sufficiently clear?

* 草案的目的是否足够明确?

* Does the document provide an acceptable platform for continued effort by the working group?

* 该文件是否为工作组的持续努力提供了一个可接受的平台?

* What are the process or technical objections to adoption of the draft?

* 通过草案的过程或技术异议是什么?

* Is the draft likely to be completed in a timely manner?

* 草案是否可能及时完成?

* Does the intended status of the document seem reasonable to the working group?

* 工作组认为该文件的预期状态合理吗?

* If not already in scope, is a simple modification to the charter feasible and warranted?

* 如果还不在范围之内,那么对《宪章》进行简单的修改是否可行?

* Does the draft carry known intellectual property rights issues?

* 草案是否包含已知的知识产权问题?

* Is there strong working group support for working on the draft?

* 工作组是否大力支持起草该草案?

Adoption has some basic pragmatics:


Rough consensus: Working group agreement to adopt is not required to be unanimous [RFC2418].


Initial, not final: The writing quality is not required to be "ready for publication", although writing quality can be a problem and does need explicit attention; although not mandatory, it is good practice to check whether a new working group draft passes [IDNITS].


Adoption, not approval: The document is not required to already contain a complete and/or sufficient solution, although of course this can be helpful. Equally, adoption by a working group does not guarantee publication of the document as an RFC.


Group, not Chairs: Concerning the draft, the position of the Working Group Chairs has no special authority, except to assess working group consensus.


REMINDER: Once a working group adopts a draft, the document is owned by the working group and can be changed however the working group decides, within the bounds of IETF process and the working group charter. Absent explicit agreement, adopting a document does not automatically mean that the working group has agreed to all of its content. So a working group (or its charter) might explicitly dictate the basis for retaining, removing, or modifying some or all of a draft's content, technical details, or the like. However, in the absence of such constraints, it is worth having the adoption process include a sub-process of gathering working group concerns about the existing draft and flagging them explicitly.


3. Authors/Editors
3. 作者/编辑

Document authors/editors are chosen by the Working Group Chairs. Document editors are described in Section 6.3 of [RFC2418]. Authors and editors are described in [RFC-Auth-Ed].

文件作者/编辑由工作组主席选择。[RFC2418]第6.3节介绍了文档编辑器。作者和编辑在[RFC Auth Ed]中进行了描述。

NOTE: In this document, the terms 'author' and 'editor' are meant interchangeably. Within the IETF, the distinction between an 'author' and an 'editor' is, at best, subjective. A simplistic rule of thumb is that editors tend to do the mechanics of incorporating working group detail, whereas authors tend to create the detail, subject to working group approval. That is, one role is more active with the content, and the other is more passive. It is a responsibility of the Working Group Chairs to ensure that document authors make modifications in accord with working group rough consensus. Authors/editors are solely chosen by the Chairs -- although the views of the working group should be considered -- and are subject to replacement for a variety of reasons, as the Chairs see fit.


For existing documents that are being adopted by a working group, there is a special challenge in the selection of document editors. Because the document has already had editors, the question "Are the same people appropriate for continuing the task?" is asked. Sometimes the answer is yes, but this is not automatic. The process within an IETF working group can be quite different from the process that created previous versions. This well might make it appropriate to select one or more new editors, either as additions to the editor team or as primary pen-holders (effectively reclassifying the previous team as coauthors).


If the original editors are to continue in their role, the Chairs might want to ensure that the editors understand IETF working group process; it is likely to be quite different from the process that developed earlier versions of the document. If additional or new editors are assigned, the transition can be discussed, including its reasons; this is best done as soon as possible.


4. Document History and Stability
4. 文件历史与稳定性

Working group charters sometimes specify an initial set of existing documents to use as a basis of the working group's activities. That 'basis' can vary considerably, from simple input to working group discussion, all the way to an advanced draft adopted by the working group and subject only to minimal changes. The role of a document should be explicitly stated in the charter.


Within the scope of its charter, a working group is free to create new documents. It is not required that all drafts start as the effort of an individual. Of course, the criteria for brand new documents are likely to be the same as for those imported into the working group, with the additional and obvious requirement that the Working Group Chairs will need to appoint authors/editors before any work can progress. Note that, from time to time, a working group will form a design team to produce the first version of a working group draft. Design teams are discussed in Section 6.5 of [RFC2418].


Work that is brought to the IETF has different levels of completeness and maturity, and different timings for having achieved those levels. When the IETF charters a group and includes existing material, the charter can cast the role of that material in very different ways. It can treat it as:


* no more than a set of ideas, to be used or ignored;

* 不超过一套想法,可以使用或忽略;

* a basic design, with all of the actual details still fluid;

* 基本设计,所有实际细节仍然流畅;

* a rough draft, subject to extensive revision;

* 粗略的草案,需要进行广泛的修订;

* a solid specification that merely needs review, refinement, and maybe enhancement;

* 一个可靠的规范,只需要审查、完善,甚至可能需要改进;

* a deployed technology that is best served by trying to protect its installed base, but with some tolerance for changes that affect interoperability;

* 一种已部署的技术,最好是通过保护其安装基础,但对影响互操作性的更改有一定的容忍度;

* a deployed technology for which protecting the installed base is essential, including retention of core interoperability.

* 对已部署的技术而言,保护已安装的基础至关重要,包括保留核心互操作性。

These suggest a wide range of possible constraints on working group effort. Technology is brought to the IETF at different points of maturity along its life cycle, and the nature of the technology can have widely varying utility in developing an Internet standard.


When technology is brand new, with at most some prototypes done as proofs of concept, then significant changes to the specification will not necessarily add much to the development and deployment costs. However, when the technology is already part of a mature and extensive operational deployment, any changes that are incompatible are likely to be problematic for that market and can hinder adoption of the changes overall. For example, immediately after the development investment is made -- and especially when there has been considerable initial deployment but there is still room for quite a bit more -- the installed and potential base might not take kindly to disruptive standards work that undermines their recent investment.


Conversely, even a deployed technology with a solid base might be inappropriate to deploy at Internet scale, and while a document specifying such a technology might serve as a good starting point on which to base a new specification, undermining of the deployed base might be completely appropriate.


In reflecting upon the basis for adopting an existing draft and the way it will be used by the working group, it is important to consider the document's place in its life cycle, the needs of any installed base, and the applicability of the draft's technology, when deciding on the constraints to impose on document development. It will all depend on the constraints of the charter and the analysis of the working group.


5. Some Issues for Consideration
5. 供审议的一些问题
5.1. Individual I-Ds under WG Care
5.1. 工作组护理下的个人I-D

Sometimes, a working group facilitates a draft but does not own it or formally adopt it. These are "individual" drafts [Individual].


As noted in Section 1.1 and reinforced in [ID-Guidelines], the convention for identifying an I-D formally under the ownership of a working group is by following the naming convention:




By contrast, documents that are still under the control of their authors are known as "individual" I-Ds. When these documents are intended for consideration by a specific working group, the convention is that the document uses the naming convention as follows, where the second element is the last name of one of the principal authors.




Having the working group name following the personal name allows tools to associate these drafts with the working group, even though the filename identifies them as the work of individuals.


The working group can choose to apply any of its normal, internal working group process management mechanisms to an individual I-D. However, matters of ownership, working group final approval, and the like are all subject to negotiation amongst the document authors, working group, and Area Directors.


This is a rare situation, and Working Group Chairs can be assured that the Area Directors will want to understand why the document could not be adopted and owned by the working group.


5.2. WG Drafts Can Become Individual Drafts
5.2. 工作组草稿可以成为单独草稿

A working group is not obligated to retain documents it has adopted. Sometimes working group efforts conclude that a draft is no longer appropriate for working group effort. If a working group drops a draft, then anyone is permitted to pursue it as an Individual or Independent Submission, subject to the document's existing copyright constraints.


5.3. Competing Drafts
5.3. 竞争草案

Engineering for interesting topics often produces competing, interesting proposals. The reasons can be technical aesthetics, engineering trade-offs, architectural differences, company economics, and the like. Although it is far more comfortable to entertain only one proposal, a working group is free to pursue more than one. Often this is necessary until a clear preference develops. Sometimes, multiple versions are formally published, absent consensus among the alternatives.


It is appealing to ask authors of competing proposals to find a way to merge their work. Where it makes sense to do this, it can produce a single, strong specification. The detailed discussions to merge are often better held in a design team than amidst the dynamics of an open working group mailing list. The working group has ultimate authority over any decisions, but it is not required that it be involved in all the discussions.


On the other hand, some differences cannot be resolved, and attempting a merge can produce a weaker result. An example of this problem of conflicting design goals is discussed in [Heli-Sub], noting:

另一方面,一些差异无法解决,尝试合并可能会产生较弱的结果。[Heli Sub]中讨论了设计目标冲突问题的一个例子,注意:

"Helicopters are great, and so are submarines. The problem is that if you try to build one vehicle to perform two fundamentally different jobs, you're going to get a vehicle that does neither job well."


Various management efforts can facilitate the handling of competing proposals. Some examples include:


* Developing a requirements document that is independent of specific proposals; this can highlight features that are deemed essential and distinguish them from features that are of secondary importance, and can facilitate a discussion about features without reference to specific proposals.

* 制定独立于具体提案的需求文件;这可以突出显示被认为是必要的特征,并将其与次要特征区分开来,并且可以在不参考具体提案的情况下促进对特征的讨论。

* Developing a comparison table of the proposals; this can aid understanding of their differences.

* 编制提案对照表;这有助于理解他们之间的差异。

* Discussing the relative importance and effects of having one proposal, versus multiple; this can focus people's efforts at compromise and encourage a willingness to choose a single proposal.

* 讨论一个提案相对于多个提案的相对重要性和影响;这可以将人们的努力集中在妥协上,并鼓励人们愿意选择一个方案。

The problem of competing drafts can be particularly painful when it arises in either of two circumstances:


* If a second proposal appears as a new draft, just as the Chairs were ready to poll the working group on adoption of the draft containing the first proposal, then the authors of the first proposal could feel affronted. It does not follow that the second draft was written to be difficult or derail the first: it might even include better ideas. So it is best not to disregard it. However, automatically asking the authors to merge their work will not necessarily produce a more solid solution and will not guarantee faster progress. This situation will be a judgement call in each case, and it might help to ask the working group for their opinion: shall the working group adopt one document as a starting point and fold in the ideas from the second under the control of consensus, or shall the working group wait until the authors of both documents have reached agreement?

* 如果第二项提案以新草案的形式出现,正如主席们准备就通过载有第一项提案的草案向工作组投票一样,那么第一项提案的作者可能会感到受到冒犯。这并不是说第二稿写得很难,也不是说第一稿脱轨:它甚至可能包含更好的想法。因此,最好不要忽视它。然而,自动要求作者合并他们的工作并不一定会产生更坚实的解决方案,也不能保证更快的进展。在每一种情况下,这种情况都将是一种判断,请工作组发表意见可能会有所帮助:工作组是以一份文件为起点,在协商一致的基础上采纳第二份文件的观点,还是等到两份文件的作者达成一致意见后再作决定?

* If the working group has already adopted an I-D on a specific topic, the posting of a new individual I-D on the same topic could be seen as an attack on the working group processes or decisions. However, posting an I-D is often a good way to put new ideas into concrete form, for public consideration and discussion. The Working Group Chairs will want to encourage the working group to consider the new proposal. Shall it be adopted and entirely replace the current working group draft? Shall the new ideas be incorporated into the work of the working group through the normal editorial process? Shall the working group adopt a second competing solution? Or shall the new draft be rejected and not adopted by the working group?

* 如果工作组已经就某一特定主题采用了个人识别码,那么就同一主题发布新的个人识别码可能被视为对工作组流程或决定的攻击。然而,发布ID通常是将新想法转化为具体形式的好方法,供公众考虑和讨论。工作组主席希望鼓励工作组考虑这项新建议。是否应予以通过并完全取代目前的工作组草案?这些新想法是否应通过正常的编辑程序纳入工作组的工作?工作组是否应通过第二个相互竞争的解决方案?或者,新的草案是否应被否决而不被工作组通过?

6. Security Considerations
6. 安全考虑

Beyond the credibility of the IETF, this document raises no security concerns.


7. Acknowledgements
7. 致谢

This document was developed from an IETF tutorial given by A. Farrel at an IETF Working Group Chairs lunch [Farrel-Chairs]. L. Anderson contributed useful comments.


8. Informative References
8. 资料性引用

[Approval] IETF, "IETF Internet-Draft Initial Version Approval Tracker", (IETF Datatracker), < cgi-bin/wg/wg_init_rev_approval.cgi>.

[批准]IETF,“IETF互联网初稿批准跟踪程序”(IETF数据跟踪程序)< cgi bin/wg/wg_init_rev_approval.cgi>。

[Consensus] Resnick, P., "On Consensus and Humming in the IETF", Work in Progress, April 2014.


[Farrel-Chairs] Farrel, A., "What is a Working Group ID (and when to adopt one)", (IETF 78 WG chairs lunch Material), July 2010, <>.

[Farrel主席]Farrel,A.,“什么是工作组ID(以及何时采用)”,(IETF 78工作组主席午餐材料),2010年7月<>.

[Heli-Sub] Rose, M., "On Helicopters and Submarines", ACM Queue - Instant Messaging, Vol. 1, Issue 8, Page 10, <>.

[Heli Sub]Rose,M.,“直升机和潜艇上”,ACM队列-即时消息,第1卷,第8期,第10页<>.

[ID-Guidelines] Housley, R., Ed., "Guidelines to Authors of Internet-Drafts", December 2010, <>.


[ID-Info] Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs) submitted for RFC publication", May 2009, <>.


[IDNITS] IETF, "IDNITS Tool", 2013, <>.


[Individual] IESG, "Guidance on Area Director Sponsoring of Documents", March 2007, < ad-sponsoring-docs.html>.

[个人]IESG,“关于区域主任赞助文件的指导”,2007年3月< 广告赞助文档.html>。

[RFC-Auth-Ed] RFC Editor, "RFC Editorial Guidelines and Procedures -- Author Overload", 2014, <>.


[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026]Bradner,S.,“互联网标准过程——第3版”,BCP 9,RFC 2026,1996年10月。

[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.

[RFC2418]Bradner,S.,“IETF工作组指南和程序”,BCP 25,RFC 2418,1998年9月。

[RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules", RFC 6702, August 2012.

[RFC6702]Polk,T.和P.Saint Andre,“促进遵守知识产权(IPR)披露规则”,RFC 67022012年8月。

[Tao] Hoffman, P., Ed., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", 2012, <>.


Authors' Addresses


Adrian Farrel Juniper Networks

Adrian Farrel Juniper Networks


Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA


   Phone: +1.408.246.8253
   Phone: +1.408.246.8253