Internet-Draft Harvard U. Editor March Intellectual Property Rights in IETF Technology. <draft-ietf-ipr-technology-rights-02.

Size: px
Start display at page:

Download "Internet-Draft Harvard U. Editor March Intellectual Property Rights in IETF Technology. <draft-ietf-ipr-technology-rights-02."

Transcription

1 Network Working Group S. Bradner Internet-Draft Harvard U. Editor March 2003 Status of this Memo Intellectual Property Rights in IETF Technology <draft-ietf-ipr-technology-rights-02.txt> This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at Abstract The IETF policies about intellectual property rights (IPR), such as patent rights, claimed relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as complete information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and with RFC XXXY, replaces RFC 10 of RFC [ note to RFC editor - replace XXXY with number of IETF SUB ] 1. Introduction Portions Copyright (C) The Internet Society (2002) Bradner [Page 1]

2 It is becoming increasingly common for IETF working groups to have to deal with claims of intellectual property rights, such as patent rights, with regards to technology under discussion in the working group. These claims can come at any point in the IETF process from before the first Internet Draft has been submitted to after a RFC has been published and the working group has been closed down. The claims can come from people submitting technical proposals as Internet Drafts, on mailing lists or at meetings, from other people participating in the working group or from third parties who find out that the work is going or has gone on. The claims can be based on granted patents or on patent applications. In some cases IPR claims can be disingenuous, made to affect the standards process rather than to inform. RFC 2026 section 10 established three basic principles regarding the IETF dealing with claims of intellectual property rights: a/ the IETF will make no determination about the validity of any particular IPR claim b/ the IETF following normal processes can decide to use technology for which IPR claims have been made if it decides that such a use is warranted c/ in order for the working group and the rest of the IETF to have the information needed to make an informed decision about the use of a particular technology, all those contributing to, and/or otherwise participating in, the working group s discussions (whether in person, or electronically via , or via other means) must disclose the existence of any IPR claim of the participant, the participant s employer or others represented by the participant (if any) that they believe would be necessary to implement the technology required. by the specific I-Ds or RFCs under discussion by the working group, subject to the reasonable and personal knowledge of the person making the disclosure (no patent search is required). In the years since RFC 2026 was published there have been a number of times when the exact intent of Section 10 has been the subject of vigorous debate within the IETF community. The aim of this document is to clarify various ambiguities in Section 10 of [RFC 2026] that led to these debates and to amplify the policy in order to clarify what the IETF is, or should be, doing. Section 2, 3 and 4 of this document address the intellectual property issues previously covered by Section 10 of RFC Section 5 defines the terms used in this memo, and sections 6 thru 12 then explain the rationale for these provisions, including some of the clarifications that have been understood since the adoption of RFC The rules and procedures set out in this document are not Bradner [Page 2]

3 intended to substantially modify or alter the IETF s current policy toward IPR in the context of the IETF standards process. They are intended to clarify and fill in procedural gaps. A companion document [IETF SUB] deals with rights (such as copyrights and trademarks) in the documents that are submitted to the IETF, including the right of IETF and its participants to publish and create derivative works of those documents. This document is not intended to address those issues. This document is not intended as legal advice. Readers are advised to consult their own legal advisors if they would like a legal interpretation of their rights or the rights of the IETF in any contributions they make. 2. Contributions in the IETF 2.1. General Policy In all matters of intellectual property rights, the intent is to benefit the Internet community and the public at large, while respecting the legitimate rights of others Rights and Permissions All Contributions By submission of a contribution, each person actually submitting the contribution, and each named co-contributor, is deemed to agree to the following terms and conditions, on his/her own behalf, and on behalf of the organizations the contributor represents (if any) when submitting the contribution. If the contribution is an Internet Draft this agreement must be acknowledged by including in the header of the contribution one of the statements in section 3.2 of [IETF SUB]. A. The contributor represents that he or she has disclosed the existence of any and all intellectual property rights which cover or may cover the technology, specifications or standards described in the contribution that (1) are owned, controlled or enforceable by the contributor or his or her employer, or any affiliate thereof, and (2) are personally and reasonably known to the contributor. The contributor does not represent that he or she personally knows of all potentially pertinent intellectual property rights owned or claimed by the his or her employer (if any) or by third parties. B. The contributor represents that there are no limits to the contributor s ability to make the grants, acknowledgments and Bradner [Page 3]

4 agreements above that are personally and reasonably known to the contributor. 3. IETF Actions (A) When any intellectual property are known, or claimed, with respect to any technology, specification, or standard described in an IETF document, and such intellectual property rights are brought to the attention of the IESG, the IESG shall not publish the IETF document without including in the document a note indicating the existence of such intellectual property rights, or claimed intellectual property rights. (B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any claimed IPR to any IETF technology, specification or standard, and will take no position on the validity or scope of any such intellectual property claims. (C) Where the IESG has been informed of claimed intellectual property rights under (A), the IETF Executive Director shall request from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant specification(s), all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to an Implementing Technology under royalty-free terms or, if that is not available, under reasonable, non-discriminatory terms unless such a statement has already been submitted. The Working Group proposing the use of the technology with respect to which the intellectual property rights are claimed may assist the IETF Executive Director in this effort. The results of this procedure shall not, in themselves, block advancement of a specification along the standards track. A working group may take into consideration the results of this procedure in evaluating the technology and the IESG may defer approval when a delay may facilitate obtaining such assurances. The results will, however, be recorded by the IETF Executive Director, and be made available. The IESG may also direct that a summary of the results be placed on- line. 3.1 Determination of Reasonable and Non-discriminatory Terms The IESG will not make any explicit determination that the assurance of reasonable and non-discriminatory terms for the use of an Implementing Technology has been fulfilled in practice. It will instead use the normal requirements for the advancement of Internet Standards to verify that the terms for use are reasonable. If the two unrelated implementations of the specification that are required Bradner [Page 4]

5 to advance from Proposed Standard to Draft Standard have been produced by different organizations or individuals or if the "significant implementation and successful operational experience" required to advance from Draft Standard to Standard has been achieved the IESG will presume that the terms are reasonable and to some degree, non-discriminatory. Note that this also covers the case where multiple implementers have concluded that no licensing is required. This presumption may be challenged at any time, including during the Last-Call period by sending to the IESG. 4. Notices to be included in all contributions for publication The following notices will be added to all standards track RFCs by the RFC Editor. (A) Disclaimer of validity: "The IETF takes no position regarding the validity or scope of any intellectual property 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 IETF s procedures with respect to rights in IETF documents can be found in RFC XX. [note to RFC Editor - replace XX with the number of this document] Copies of IPR statements made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a royalty-free 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 (B) The IETF encourages all interested parties to bring to its attention, at the earliest possible time, the existence of any intellectual property rights pertaining to Internet Standards. For this purpose, each standards document shall include the following invitation: "The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Secretariat at iesgsecretary@ietf.org." Bradner [Page 5]

6 5. Definitions 5.1 contribution: in the context of this memo, a contribution to the IETF is any submission intended by the contributor for publication as an Internet Draft or RFC and any statements made within the context of an IETF process. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function 5.2 IETF document: RFCs and Internet-Drafts. 5.3 IPR or intellectual property rights: means any proprietary, intellectual or industrial property rights, including, but not limited to, patent, copyright, trade secret, design, utility model, invention registration, database and data rights, whether such rights arise from a registration or renewal thereof, or an application therefore, in each case anywhere in the world. 5.4 Implementing Technology: means a technology which implements an IETF specification or standard. 6. Disclosures This section discusses who must make disclosures, how to make a disclosure, what a disclosure must include and when disclosures must be made. 6.1 Who must make a disclosure? IPR claimed by contributors to the IETF Anyone who contributes text, ideas, or technology to the IETF that includes IPR which meets the conditions in section 6.6 and that is personally and reasonably known to the contributor must disclose the IPR. This requirement specifically includes contributions that are made by any means including electronic or spoken comments. A disclosure should also be made if the revised contribution negates a previous IPR disclosure. Bradner [Page 6]

7 Contributors must disclose IPR claims meeting the description in this section, there are no exceptions to this rule IPR claimed in contributions by others Anyone who is participating in an IETF discussion about someone else s contribution which the individual believes includes IPR meeting the conditions of section 6.6 must make an IPR disclosure. Failure to provide such a disclosure is subject to the restrictions described in section IPR claims known by a third party Under section 4(B) of this document third parties that have information about IPR claims of others that may cover IETF contributions are encouraged to notify the IETF by sending an message to iesg-secretary@ietf.org. Such a notice should be sent as soon as possible after the third party realizes the connection. A third party is defined as someone who knows of IPR claims but who does not meet the conditions in section The timing of providing disclosure Timely IPR disclosure is important because working groups need to have as much information as they can while they are evaluating alternative solutions Timing of disclosure about a contribution described in section The person or the organization which claims the IPR must submit an IPR disclosure at the same time that the contribution is made unless there is already a disclosure on file which will cover the claim and the new contribution. For example, if the contribution is an update to one for which an IPR disclosure has already been made and the applicability of the disclosure is not changed by the new contribution, then no new disclosure is required. But if the contribution is a new one or is one which changes an existing contribution such that the revised contribution would be covered by new or different IPR claims then a disclosure must be made. If a contributor learns of IPR claims that meet the requirements of section 6.6, for example a new patent application or the discovery of a relevant patent in a patent portfolio, after the submission of a contribution, a disclosure must be made by the contributor or the IPR claimant as soon as reasonably possible after learning of the IPR claim Timing of disclosure about a contribution described in section The disclosure must be made as soon as reasonably possible after the IPR claims become personally and reasonably known to the IETF Bradner [Page 7]

8 participant. 6.3 How must a disclosure be made? IPR disclosures are made by sending an message to iesgsecretary@ietf.org. It is also a good idea to send a copy of the disclosure to the mailing list of the relevant working group. 6.4 What must be in a disclosure? The disclosure should list the numbers of any issued or published patents and indicate whether the claim is based on unpublished patent applications. The disclosure should also list the specific IETF documents or activity affected. An Internet-Draft must be referenced by specific version number. In addition, if an Internet-Draft includes multiple parts and it is not reasonably apparent which part of such Internet-Draft is alleged to be covered by the claims of a disclosed patent or patent application, the discloser should identify the sections of the Internet-Draft that are alleged to be so covered. If a disclosure was made on the basis of a patent application then a new disclosure must be made when the patent is granted or denied. The new disclosure must include the patent number and, if the granted patent differs from the application, must state any differences in applicability to the IETF work. Note that the requirement for an IPR disclosure is not satisfied by the inclusion of a blanket statement of possible IPR on every contribution. This is the case because the aim of the disclosure requirement is to provide information about specific IPR claims against specific technology under discussion in the IETF. The requirement is also not satisfied by a blanket statement of willingness to license all potential IPR under fair and nondiscriminatory terms for the same reason. The requirement for an IPR disclosure is met by a blanket statement of the availability of royalty-free licensing of any possible essential IPR. 6.5 What rights must be detailed in a disclosure? Since IPR disclosures will be used by IETF working groups during their evaluation of alternative technical solutions, an IPR disclosure should include information about licensing of the IPR in case implementation of the technology described in the final RFC is judged to require a license. Specifically, it should indicate whether, upon approval by the IETF of the relevant Internet standards track specification(s), all persons will be able to obtain the right to implement, use, distribute and exercise other rights with respect to an Implementing Technology under royalty-free or openly specified, reasonable, non-discriminatory terms. 6.6 When is a disclosure required? Bradner [Page 8]

9 Except for third party disclosures (which are encouraged under section 6.1.3), disclosures are required whenever the IPR in question is owned or licensed, directly or indirectly, by the individual or his/her employer or sponsor (if any) or such persons otherwise have the right to license or enforce, and a license under any claims of the patent or patent application would be required to practice the technology disclosed in the IETF document. 6.7 Call for IPR disclosures Notwithstanding the above, an explicit "Call for IPR disclosures" must accompany a working group last call (if a working group Last- Call is used to judge working group consensus - see [RFC 2418] section 7.4) and an IETF Last-Call (See [RFC 2026] section ) where one is issued. This "Call for IPR disclosures" is used to request that anyone who knows of relevant IPR let the Working Group or IESG (whichever issued the Last-Call) about the IPR. 7. What does "personally and reasonably known" mean? The phrase "personally and reasonably known" is used above. It should be read to refer to something the individual knows personally or, because of the job the individual holds, would reasonably be expected to know. This wording is used to indicate that an organization cannot purposely keep an individual in the dark about patents or patent applications just to avoid the disclosure requirement. But this requirement should not be interpreted as requiring the IETF contributor or participant (or his or her represented organization, if any) to perform a patent search to find applicable IPR. 8. Failure to provide notice There are cases where individuals are not permitted by their employers or by other factors to disclose the existence or substance of patent applications or other IPR claims. Since disclosure is required for anyone submitting documents or participating in IETF discussions, a person who does not disclose IPR claims for this, or any other reason, must not participate in these IETF activities with respect to technologies that he or she personally and reasonably knows to be covered by an IPR claim which he or she is not permitted to disclose. Participating in IETF discussions about a technology without disclosing relevant IPR that is personally and reasonably known to the individual is a violation of IETF process. 9. Evaluating alternative technologies in IETF working groups Bradner [Page 9]

10 In general, IETF working groups prefer technologies with no known IPR claims or, for technologies with claims against them, an offer of royalty-free licensing. But IETF working groups have the discretion to adopt technology with a commitment of fair and non-discriminatory terms, or even with no licensing commitment, if they feel that this technology is superior enough to alternatives with fewer IPR claims or free licensing to outweigh the potential cost of the licenses. Over the last few years the IETF has adopted stricter requirements for some security technologies. It has become common to have a mandatory-to-implement security technology in IETF technology specifications. This is to ensure that there will be at least one common security technology present in all implementations of such a specification that can be use in all cases. This does not limit the specification from including other security technologies, the use of which could be negotiated between implementations. An IETF consensus has developed that no mandatory-to-implement security should be specified in an IETF specification unless it has no known IPR claims against it or a royalty-free license is available to implementers of the specification unless there is a very good reason to do so. This limitation does not extend to other security technologies in the same specification if they are not listed as mandatory-to- implement. It should also be noted that the absence of IPR disclosures is not the same thing as the knowledge that there will be no IPR claims in the future. People or organizations not currently involved in the IETF. People or organizations that discover IPR they feel to be relevant in their patent portfolios can make IPR claims at any time. It should also be noted that the validity and enforceability of any IPR may be challenged for legitimate reasons, and the mere existence of an IPR claim should not automatically be taken to mean that the underlying IPR is valid and enforceable. Although the IETF can make no actual determination of validity or applicability of any particular IPR claim, it is reasonable that a working group will rely on their own opinions of the applicability or validity of intellectual property rights in their evaluation of alternative technologies. 10. Change control for technologies The IETF must have change control over the technology described in any standards track documents in order to fix problems that may be discovered or to produce other derivative works. Submissions to the IETF in which the submitters do not grant change control to the IETF must include the appropriate Internet Draft statement from [IETF SUB] section 3.2. Bradner [Page 10]

11 In some cases the developer of patented or otherwise controlled technology may decide to hand over to the IETF the right to evolve the technology (a.k.a "change control"). The implementation of an agreement between the IETF and the developer of the technology can be complex. (See [RFC 1790] and [RFC 2339] for examples.) Note that an IETF standards track document can make normative reference to proprietary technology in some cases, for example, when making parameter assignments or encapsulations. (e.g., "parameter value 1234 refers to proprietary technology A" or "proprietary technology B can be encapsulated using the techniques described in RFC XYZ.") 11. Licensing requirements to advance standards track documents [RFC 2026] section states: "If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process." A key word in this text is "required." The mere existence of an IPR claim does not necessarily mean that licenses are actually required in order to implement the technology. Section of this document should be taken to cover the case where there are multiple implementations and but none of the implementers have felt that they needed to license the technology and there have are no indications that the IPR claimant will try to enforce its claim. 12. Mention of IPR claims in IETF documents Submissions to the IETF where there are known IPR claims must include the appropriate text from section 4 above. They should not contain any mention of specific claims. All specific IPR disclosures must be submitted as described in section 6. Specific IPR disclosures should not be in the affected documents because the reader could be mislead. The inclusion of a particular IPR claim in an IETF document could be interpreted to mean that the IETF has formed an opinion on the validity of the IPR claim. The reader could also be mislead to think that the included IPR claims are the only IPR claims the IETF has received concerning the document. Readers should always refer to the on-line web page to get a full list of IPR claims and disclosures received by the IETF. 13. Security Considerations This memo relates to IETF process, not any particular technology. There are security considerations when adopting any technology, whether IPR- protected or not. A working group should take those security considerations into account as one part of evaluating the technology, just as IPR is one part, but they are not issues of Bradner [Page 11]

12 security with IPR procedures. 14. References 14.1 Normative references [RFC 2026] Bradner, S. (ed), "The Internet Standards Process -- Revision 3", RFC 2026, October 1996 [RFC 2418] Bradner, S. (ed), "Working Group Guidelines and Procedures", RFC 2518, September 1998 [IETF SUB] work in progress: draft-iprwg-submission-00.txt 15. Acknowledgements The editor would like to acknowledge the help of the IETF ipr Working Group and, in particular the help of Jorge Contreras of Hale and Dorr for his careful legal reviews of this and other IETF IPR-related and process documents. The editor would also like to thank Valerie See for her extensive comments and suggestions. 16. Editors Address Scott Bradner Harvard University 29 Oxford St. Cambridge MA, Full copyright statement: Copyright (C) The Internet Society (2003). Except as set forth below, authors retain all their rights. 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 rights in submissions defined in the Internet Standards process must be followed, or as required to translate it into languages other than Bradner [Page 12]

13 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 CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS (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. 18. change log (note to RFC Editor - remove this section prior to publication) version 00 to version 01 sec 1 b - add "following normal processes" sec 1 c - reword sec add "if the contribution is an Internet Draft" sec 6 - largely reworked sec added call for IPR with WG & IETF last calls sec 7 - add "or participates in a working group discussion".br sec 8 - add "or other factors" sec 14 - redo security considerations sec 15 - added acknowledgements sec 18 - added change log version 01 to version 02 fix miscellaneous typos throughout document swap personally and reasonably change "IPR claim" to "IPR disclosure" a number of places abstract - note update of rfc 2026 sec 1 - remove ISOC sec 1(c) - reword - remove implication disclose of 3rd party IPR sec reword - remove 3rd party IPR holders sec 3 (C) - added royalty-free - removed "standards track" remove text about implementations did not add "implicit" because that is just what the IESG is doing remove "openly specified" sec added note about no licensing case sec 4 - change so RFC Editor adds IPR statements tweak 4(A) so 4(C) could be removed & make it generic to IETF documents sec 5.1 & included definitions from copyright ID Bradner [Page 13]

14 sec last sentence - reword sec append sec sec reword sec tweak wording sec replace - add royalty-free add granted patent applications sec 6.5 1st pp - replace - add royalty-free remove example classes sec replace sec 7 - tweak last sentence sec 9 - tweak wording add security RF requirement sec remove unneeded references Bradner [Page 14]

BCP: 79 March 2005 Obsoletes: 3668 Updates: 2028, 2026 Category: Best Current Practice. Intellectual Property Rights in IETF Technology

BCP: 79 March 2005 Obsoletes: 3668 Updates: 2028, 2026 Category: Best Current Practice. Intellectual Property Rights in IETF Technology Network Working Group S. Bradner, Ed. Request for Comments: 3979 Harvard University BCP: 79 March 2005 Obsoletes: 3668 Updates: 2028, 2026 Category: Best Current Practice Status of this Memo Intellectual

More information

Request for Comments: 3905 Category: Informational September A Template for IETF Patent Disclosures and Licensing Declarations

Request for Comments: 3905 Category: Informational September A Template for IETF Patent Disclosures and Licensing Declarations Network Working Group V. See, Ed. Request for Comments: 3905 Microsoft Category: Informational September 2004 A Template for IETF Patent Disclosures and Licensing Declarations Status of this Memo This

More information

Part A: Adoption and general aspects of IPR policy

Part A: Adoption and general aspects of IPR policy Analysis of the IPR policy of IETF This analysis is a supplement to A study of IPR policies and practices of a representative group of Standards Developing Organizations worldwide, prepared by Rudi Bekkers

More information

J. Contreras, Ed. Updates: 2026 November 2008 Category: Best Current Practice

J. Contreras, Ed. Updates: 2026 November 2008 Category: Best Current Practice Network Working Group S. Bradner, Ed. Request for Comments: 5378 Harvard University BCP: 78 J. Contreras, Ed. Obsoletes: 3978, 4748 WilmerHale Updates: 2026 November 2008 Category: Best Current Practice

More information

Request for Comments: 3932 October 2004 BCP: 92 Updates: 3710, 2026 Category: Best Current Practice

Request for Comments: 3932 October 2004 BCP: 92 Updates: 3710, 2026 Category: Best Current Practice Network Working Group H. Alvestrand Request for Comments: 3932 October 2004 BCP: 92 Updates: 3710, 2026 Category: Best Current Practice Status of this Memo The IESG and RFC Editor Documents: Procedures

More information

Request for Comments: 3934 Updates: 2418 October 2004 BCP: 94 Category: Best Current Practice

Request for Comments: 3934 Updates: 2418 October 2004 BCP: 94 Category: Best Current Practice Network Working Group M. Wasserman Request for Comments: 3934 ThingMagic Updates: 2418 October 2004 BCP: 94 Category: Best Current Practice Updates to RFC 2418 Regarding the Management of IETF Mailing

More information

SIP Forum Copyrights and Trademark Rights in Contributions Policy

SIP Forum Copyrights and Trademark Rights in Contributions Policy 733 Turnpike Street Suite 192 North Andover, MA 01845 USA Tel: +1-718-548-7245 Fax: +1-484-952-2470 SIP Forum Copyrights and Trademark Rights in Contributions Policy Document number: GA-17 [sf-admin-copyrightpolicy-v1.0]

More information

Request for Comments: 4633 Category: Experimental August 2006

Request for Comments: 4633 Category: Experimental August 2006 Network Working Group S. Hartman Request for Comments: 4633 MIT Category: Experimental August 2006 Status of This Memo Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing

More information

IETF TRUST. Legal Provisions Relating to IETF Documents. Approved November 6, Effective Date: November 10, 2008

IETF TRUST. Legal Provisions Relating to IETF Documents. Approved November 6, Effective Date: November 10, 2008 IETF TRUST Legal Provisions Relating to IETF Documents Approved November 6, 2008 Effective Date: November 10, 2008 1. Background The IETF Trust was formed on December 15, 2005, for, among other things,

More information

IETF TRUST. Legal Provisions Relating to IETF Documents. February 12, Effective Date: February 15, 2009

IETF TRUST. Legal Provisions Relating to IETF Documents. February 12, Effective Date: February 15, 2009 IETF TRUST Legal Provisions Relating to IETF Documents February 12, 2009 Effective Date: February 15, 2009 1. Background The IETF Trust was formed on December 15, 2005, for, among other things, the purpose

More information

Expires: October 9, 2005 April 7, 2005

Expires: October 9, 2005 April 7, 2005 DHC B. Volz Internet-Draft Cisco Systems, Inc. Expires: October 9, 2005 April 7, 2005 Status of this Memo DHCPv6 Relay Agent Remote ID Option draft-ietf-dhc-dhcpv6-remoteid-00.txt By submitting this Internet-Draft,

More information

Network Working Group. Category: Standards Track <draft-aboba-radius-iana-03.txt> 30 March 2003 Updates: RFC IANA Considerations for RADIUS

Network Working Group. Category: Standards Track <draft-aboba-radius-iana-03.txt> 30 March 2003 Updates: RFC IANA Considerations for RADIUS Network Working Group INTERNET-DRAFT Category: Standards Track 30 March 2003 Updates: RFC 2865 B. Aboba Microsoft IANA Considerations for RADIUS This document is an Internet-Draft

More information

Expires in six months 24 October 2004 Obsoletes: RFC , , 3377, 3771

Expires in six months 24 October 2004 Obsoletes: RFC , , 3377, 3771 INTERNET-DRAFT Editor: Kurt D. Zeilenga Intended Category: Standard Track OpenLDAP Foundation Expires in six months 24 October 2004 Obsoletes: RFC 2251-2256, 2829-2830, 3377, 3771 Lightweight Directory

More information

Network Working Group. Intended status: Standards Track Columbia U. Expires: March 5, 2009 September 1, 2008

Network Working Group. Intended status: Standards Track Columbia U. Expires: March 5, 2009 September 1, 2008 Network Working Group O. Boyaci Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia U. Expires: March 5, 2009 September 1, 2008 RTP Payload Format for Portable Network Graphics (PNG)

More information

Network Working Group Internet-Draft August 2005 Expires: February 2, Atom Link No Follow draft-snell-atompub-feed-nofollow-00.

Network Working Group Internet-Draft August 2005 Expires: February 2, Atom Link No Follow draft-snell-atompub-feed-nofollow-00. Network Working Group J. Snell Internet-Draft August 2005 Expires: February 2, 2006 Status of this Memo Atom Link No Follow draft-snell-atompub-feed-nofollow-00.txt By submitting this Internet-Draft, each

More information

Network Working Group Internet-Draft August 2005 Expires: February 2, Atom Link No Follow draft-snell-atompub-feed-nofollow-03.

Network Working Group Internet-Draft August 2005 Expires: February 2, Atom Link No Follow draft-snell-atompub-feed-nofollow-03. Network Working Group J. Snell Internet-Draft August 2005 Expires: February 2, 2006 Status of this Memo Atom Link No Follow draft-snell-atompub-feed-nofollow-03.txt By submitting this Internet-Draft, each

More information

Network Working Group Internet-Draft January 25, 2006 Expires: July 29, Feed Rank draft-snell-atompub-feed-index-05.txt. Status of this Memo

Network Working Group Internet-Draft January 25, 2006 Expires: July 29, Feed Rank draft-snell-atompub-feed-index-05.txt. Status of this Memo Network Working Group J. Snell Internet-Draft January 25, 2006 Expires: July 29, 2006 Status of this Memo Feed Rank draft-snell-atompub-feed-index-05.txt By submitting this Internet-Draft, each author

More information

Network Working Group. Obsoletes: draft-ietf-dhc-new-opt-msg-00.txt June 2000 Expires December 2000

Network Working Group. Obsoletes: draft-ietf-dhc-new-opt-msg-00.txt June 2000 Expires December 2000 Network Working Group R. Droms INTERNET-DRAFT Bucknell University Obsoletes: draft-ietf-dhc-new-opt-msg-00.txt June 2000 Expires December 2000 Procedure for Defining New DHCP Options and Message Types

More information

Jabber, Inc. August 20, 2004

Jabber, Inc. August 20, 2004 Network Working Group Internet-Draft Expires: February 18, 2005 P. Saint-Andre Jabber Software Foundation J. Hildebrand Jabber, Inc. August 20, 2004 Transporting Atom Notifications over the Extensible

More information

Category: Best Current Practice February Early IANA Allocation of Standards Track Code Points

Category: Best Current Practice February Early IANA Allocation of Standards Track Code Points Network Working Group Request for Comments: 4020 BCP: 100 Category: Best Current Practice K. Kompella Juniper Networks A. Zinin Alcatel February 2005 Status of This Memo Early IANA Allocation of Standards

More information

XDI Requirements and Use Cases

XDI Requirements and Use Cases 1 2 3 XDI Requirements and Use Cases Working Draft 01, April 19 th 2004 4 5 6 7 8 9 10 11 12 13 14 Document identifier: xdi-requirements-and-use-cases-document-04 Location: Editors: [Editors listed here]

More information

Network Working Group Request for Comments: December 2004

Network Working Group Request for Comments: December 2004 Network Working Group Request for Comments: 3967 BCP: 97 Category: Best Current Practice R. Bush IIJ T. Narten IBM Corporation December 2004 Status of this Memo Clarifying when Standards Track Documents

More information

Expires: February 25, 2004 August 27, Using the NETCONF Configuration Protocol over Secure Shell (SSH) draft-wasserman-netconf-over-ssh-00.

Expires: February 25, 2004 August 27, Using the NETCONF Configuration Protocol over Secure Shell (SSH) draft-wasserman-netconf-over-ssh-00. Network Working Group M. Wasserman Internet-Draft Wind River Expires: February 25, 2004 August 27, 2003 Using the NETCONF Configuration Protocol over Secure Shell (SSH) draft-wasserman-netconf-over-ssh-00.txt

More information

OIX DDP. Open-IX Document Development Process draft July 2017

OIX DDP. Open-IX Document Development Process draft July 2017 OIX DDP Open-IX Document Development Process draft 04 11 July 2017 Table 1 - Version History Version Date Author Description d01 7 May 2017 Chris Grundemann Initial Draft d02 21 May 2017 Chris Grundemann

More information

Request for Comments: 2711 Category: Standards Track BBN October 1999

Request for Comments: 2711 Category: Standards Track BBN October 1999 Network Working Group Request for Comments: 2711 Category: Standards Track C. Partridge BBN A. Jackson BBN October 1999 IPv6 Router Alert Option Status of this Memo This document specifies an Internet

More information

Category: Standards Track October 2006

Category: Standards Track October 2006 Network Working Group C. Perkins Request for Comments: 4636 Nokia Research Center Category: Standards Track October 2006 Status of This Memo Foreign Agent Error Extension for Mobile IPv4 This document

More information

Updates: 2710 September 2003 Category: Standards Track. Source Address Selection for the Multicast Listener Discovery (MLD) Protocol

Updates: 2710 September 2003 Category: Standards Track. Source Address Selection for the Multicast Listener Discovery (MLD) Protocol Network Working Group B. Haberman Request for Comments: 3590 Caspian Networks Updates: 2710 September 2003 Category: Standards Track Status of this Memo Source Address Selection for the Multicast Listener

More information

Intended status: Standards Track August 15, 2008 Expires: February 16, 2009

Intended status: Standards Track August 15, 2008 Expires: February 16, 2009 Network Working Group J. Gregorio, Ed. Internet-Draft Google Intended status: Standards Track August 15, 2008 Expires: February 16, 2009 Status of this Memo AtomPub Multipart Media Resource Creation draft-gregorio-atompub-multipart-03

More information

Network Working Group Internet-Draft October 27, 2007 Intended status: Experimental Expires: April 29, 2008

Network Working Group Internet-Draft October 27, 2007 Intended status: Experimental Expires: April 29, 2008 Network Working Group J. Snell Internet-Draft October 27, 2007 Intended status: Experimental Expires: April 29, 2008 Status of this Memo Atom Publishing Protocol Feature Discovery draft-snell-atompub-feature-12.txt

More information

Intended status: Informational. B. Wyman October 2, 2007

Intended status: Informational. B. Wyman October 2, 2007 Network Working Group Internet-Draft Intended status: Informational Expires: April 4, 2008 P. Saint-Andre XMPP Standards Foundation J. Hildebrand Jabber, Inc. B. Wyman October 2, 2007 Transporting Atom

More information

Network Working Group Request for Comments: 4424 February 2006 Updates: 4348 Category: Standards Track

Network Working Group Request for Comments: 4424 February 2006 Updates: 4348 Category: Standards Track Network Working Group S. Ahmadi Request for Comments: 4424 February 2006 Updates: 4348 Category: Standards Track Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband

More information

Ecma International Policy on Submission, Inclusion and Licensing of Software

Ecma International Policy on Submission, Inclusion and Licensing of Software Ecma International Policy on Submission, Inclusion and Licensing of Software Experimental TC39 Policy This Ecma International Policy on Submission, Inclusion and Licensing of Software ( Policy ) is being

More information

Network Working Group. Updates: 3463, 4468, 4954 June 2008 Category: Best Current Practice. A Registry for SMTP Enhanced Mail System Status Codes

Network Working Group. Updates: 3463, 4468, 4954 June 2008 Category: Best Current Practice. A Registry for SMTP Enhanced Mail System Status Codes Network Working Group T. Hansen Request for Comments: 5248 AT&T Laboratories BCP: 138 J. Klensin Updates: 3463, 4468, 4954 June 2008 Category: Best Current Practice A Registry for SMTP Enhanced Mail System

More information

Network Working Group. Category: Informational. Harvard University G. Parsons. Nortel Networks. October 1998

Network Working Group. Category: Informational. Harvard University G. Parsons. Nortel Networks. October 1998 Network Working Group Request for Comments: 2436 Category: Informational R. Brett Nortel Networks S. Bradner Harvard University G. Parsons Nortel Networks October 1998 Status of this Memo Collaboration

More information

Request for Comments: 4680 Updates: 4346 September 2006 Category: Standards Track

Request for Comments: 4680 Updates: 4346 September 2006 Category: Standards Track Network Working Group S. Santesson Request for Comments: 4680 Microsoft Updates: 4346 September 2006 Category: Standards Track Status of This Memo TLS Handshake Message for Supplemental Data This document

More information

Network Working Group. Category: Informational SPARTA, Inc. S. Crocker Shinkuro Inc. S. Krishnaswamy SPARTA, Inc. August 2007

Network Working Group. Category: Informational SPARTA, Inc. S. Crocker Shinkuro Inc. S. Krishnaswamy SPARTA, Inc. August 2007 Network Working Group Request for Comments: 4986 Category: Informational H. Eland Afilias Limited R. Mundy SPARTA, Inc. S. Crocker Shinkuro Inc. S. Krishnaswamy SPARTA, Inc. August 2007 Requirements Related

More information

draft-ietf-sip-info-method-02.txt February 2000 The SIP INFO Method Status of this Memo

draft-ietf-sip-info-method-02.txt February 2000 The SIP INFO Method Status of this Memo HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:53:57 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 15 Feb 2000 17:03:00 GMT ETag: "3239a5-465b-38a986c4" Accept-Ranges: bytes Content-Length: 18011 Connection:

More information

E. Lewis ARIN September 23, KEY RR Secure Entry Point Flag draft-ietf-dnsext-keyrr-key-signing-flag-09. Status of this Memo

E. Lewis ARIN September 23, KEY RR Secure Entry Point Flag draft-ietf-dnsext-keyrr-key-signing-flag-09. Status of this Memo DNS Extensions Internet-Draft Expires: March 23, 2004 O. Kolkman RIPE NCC J. Schlyter E. Lewis ARIN September 23, 2003 Status of this Memo KEY RR Secure Entry Point Flag draft-ietf-dnsext-keyrr-key-signing-flag-09

More information

Network Working Group. BCP: 83 March 2004 Category: Best Current Practice. A Practice for Revoking Posting Rights to IETF Mailing Lists

Network Working Group. BCP: 83 March 2004 Category: Best Current Practice. A Practice for Revoking Posting Rights to IETF Mailing Lists Network Working Group M. Rose Request for Comments: 3683 Dover Beach Consulting, Inc. BCP: 83 March 2004 Category: Best Current Practice A Practice for Revoking Posting Rights to IETF Mailing Lists Status

More information

Network Working Group. Category: Informational April A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC)

Network Working Group. Category: Informational April A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC) Network Working Group C. Reed Request for Comments: 5165 Open Geospatial Consortium Category: Informational April 2008 Status of This Memo A Uniform Resource Name (URN) Namespace for the Open Geospatial

More information

Intended status: Standards Track Expires: August 28, 2008 Hitachi A. Kobayashi NEC Corp. M. Stiemerling (Ed.) NEC Europe Ltd.

Intended status: Standards Track Expires: August 28, 2008 Hitachi A. Kobayashi NEC Corp. M. Stiemerling (Ed.) NEC Europe Ltd. MMUSIC Internet-Draft Intended status: Standards Track Expires: August 28, 2008 T. Ura K. Oku NTT H. Harada Hitachi A. Kobayashi NEC Corp. M. Stiemerling (Ed.) NEC Europe Ltd. February 25, 2008 Status

More information

Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol

Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol Internet Engineering Task Force INTERNET-DRAFT draft-ietf-sipping-aaa-req-02.ps SIP WG J. Loughney, G. Camarillo Nokia, Ericsson February 5, 2003 Expires: August, 2003 Authentication, Authorization and

More information

Category: Standards Track September MIB Textual Conventions for Uniform Resource Identifiers (URIs)

Category: Standards Track September MIB Textual Conventions for Uniform Resource Identifiers (URIs) Network Working Group D. McWalter, Ed. Request for Comments: 5017 Data Connection Ltd Category: Standards Track September 2007 MIB Textual Conventions for Uniform Resource Identifiers (URIs) Status of

More information

EMPLOYER CONTRIBUTION AGREEMENT

EMPLOYER CONTRIBUTION AGREEMENT EMPLOYER CONTRIBUTION AGREEMENT This Employer Contribution Agreement ( Agreement ) is entered into by and between, your successors and assigns ( You ) and Oracle America, Inc. ( Oracle ) as of the date

More information

Network Working Group Request for Comments: 3563 Category: Informational July 2003

Network Working Group Request for Comments: 3563 Category: Informational July 2003 Network Working Group A. Zinin Request for Comments: 3563 Alcatel Category: Informational July 2003 Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6)

More information

Deployment Profile Template Version 1.0 for WS-Reliability 1.1

Deployment Profile Template Version 1.0 for WS-Reliability 1.1 Deployment Profile Template Version 1.0 for WS-Reliability 1.1 Committee Draft 11 April 2007 URIs: This Version: http://docs.oasis-open.org/wsrm/profile/wsr-deployment-profile-template-cd.pdf Latest Version:

More information

Category: Standards Track December 2003

Category: Standards Track December 2003 Network Working Group R. Droms, Ed. Request for Comments: 3646 Cisco Systems Category: Standards Track December 2003 Status of this Memo DNS Configuration options for Dynamic Host Configuration Protocol

More information

Network Working Group. Category: Standards Track Juniper Networks August 2008

Network Working Group. Category: Standards Track Juniper Networks August 2008 Network Working Group Request for Comments: 5291 Category: Standards Track E. Chen Cisco Systems Y. Rekhter Juniper Networks August 2008 Status of This Memo Outbound Route Filtering Capability for BGP-4

More information

Updates: 2409 May 2005 Category: Standards Track. Algorithms for Internet Key Exchange version 1 (IKEv1)

Updates: 2409 May 2005 Category: Standards Track. Algorithms for Internet Key Exchange version 1 (IKEv1) Network Working Group P. Hoffman Request for Comments: 4109 VPN Consortium Updates: 2409 May 2005 Category: Standards Track Algorithms for Internet Key Exchange version 1 (IKEv1) Status of This Memo This

More information

Category: Standards Track June Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP) Status of This Memo

Category: Standards Track June Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP) Status of This Memo Network Working Group K. Zeilenga Request for Comments: 4529 OpenLDAP Foundation Category: Standards Track June 2006 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP)

More information

Category: Standards Track June 2006

Category: Standards Track June 2006 Network Working Group K. Zeilenga Request for Comments: 4527 OpenLDAP Foundation Category: Standards Track June 2006 Lightweight Directory Access Protocol (LDAP) Read Entry Controls Status of This Memo

More information

Request for Comments: 3861 Category: Standards Track August 2004

Request for Comments: 3861 Category: Standards Track August 2004 Network Working Group J. Peterson Request for Comments: 3861 NeuStar Category: Standards Track August 2004 Address Resolution for Instant Messaging and Presence Status of this Memo This document specifies

More information

Request for Comments: 4315 December 2005 Obsoletes: 2359 Category: Standards Track. Internet Message Access Protocol (IMAP) - UIDPLUS extension

Request for Comments: 4315 December 2005 Obsoletes: 2359 Category: Standards Track. Internet Message Access Protocol (IMAP) - UIDPLUS extension Network Working Group M. Crispin Request for Comments: 4315 December 2005 Obsoletes: 2359 Category: Standards Track Internet Message Access Protocol (IMAP) - UIDPLUS extension Status of This Memo This

More information

Category: Standards Track March Extensible Provisioning Protocol (EPP) Transport Over TCP

Category: Standards Track March Extensible Provisioning Protocol (EPP) Transport Over TCP Network Working Group S. Hollenbeck Request for Comments: 3734 VeriSign, Inc. Category: Standards Track March 2004 Extensible Provisioning Protocol (EPP) Transport Over TCP Status of this Memo This document

More information

Request for Comments: May 2007

Request for Comments: May 2007 Network Working Group Request for Comments: 4863 Category: Standards Track L. Martini G. Swallow Cisco Systems, Inc. May 2007 Wildcard Pseudowire Type Status of This Memo This document specifies an Internet

More information

Request for Comments: 3764 Category: Standards Track April enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record

Request for Comments: 3764 Category: Standards Track April enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record Network Working Group J. Peterson Request for Comments: 3764 NeuStar Category: Standards Track April 2004 enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record Status of this

More information

Network Working Group. Category: Standards Track August Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option

Network Working Group. Category: Standards Track August Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option Network Working Group B. Volz Request for Comments: 4649 Cisco Systems, Inc. Category: Standards Track August 2006 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option Status

More information

Category: Standards Track October 2006

Category: Standards Track October 2006 Network Working Group Request for Comments: 4681 Updates: 4346 Category: Standards Track S. Santesson A. Medvinsky J. Ball Microsoft October 2006 TLS User Mapping Extension Status of This Memo This document

More information

Request for Comments: Category: Standards Track January 2008

Request for Comments: Category: Standards Track January 2008 Network Working Group W. Segmuller Request for Comments: 5231 B. Leiba Obsoletes: 3431 IBM T.J. Watson Research Center Category: Standards Track January 2008 Status of This Memo Sieve Email Filtering:

More information

Network Working Group. February 2005

Network Working Group. February 2005 Network Working Group Request for Comments: 4014 Category: Standards Track R. Droms J. Schnizlein Cisco Systems February 2005 Status of This Memo Remote Authentication Dial-In User Service (RADIUS) Attributes

More information

Network Working Group Request for Comments: 4143 Category: Standards Track Brandenburg November 2005

Network Working Group Request for Comments: 4143 Category: Standards Track Brandenburg November 2005 Network Working Group Request for Comments: 4143 Category: Standards Track K. Toyoda PCC D. Crocker Brandenburg November 2005 Status of This Memo Facsimile Using Internet Mail (IFAX) Service of ENUM This

More information

TCP Maintenance and Minor Extensions (tcpm) Intended status: Standards Track Expires: May 1, 2009 October 28, 2008

TCP Maintenance and Minor Extensions (tcpm) Intended status: Standards Track Expires: May 1, 2009 October 28, 2008 TCP Maintenance and Minor F. Gont Extensions (tcpm) UTN/FRH Internet-Draft A. Yourtchenko Intended status: Standards Track Cisco Expires: May 1, 2009 October 28, 2008 Status of this Memo On the implementation

More information

Request for Comments: 5010 Category: Standards Track Cisco Systems, Inc. September 2007

Request for Comments: 5010 Category: Standards Track Cisco Systems, Inc. September 2007 Network Working Group Request for Comments: 5010 Category: Standards Track K. Kinnear M. Normoyle M. Stapp Cisco Systems, Inc. September 2007 The Dynamic Host Configuration Protocol Version 4 (DHCPv4)

More information

Request for Comments: K. Norrman Ericsson June 2006

Request for Comments: K. Norrman Ericsson June 2006 Network Working Group Request for Comments: 4563 Category: Standards Track E. Carrara KTH V. Lehtovirta K. Norrman Ericsson June 2006 The Key ID Information Type for the General Extension Payload in Multimedia

More information

Network Working Group. Cisco Systems June 2007

Network Working Group. Cisco Systems June 2007 Network Working Group Request for Comments: 4937 Category: Informational P. Arberg Redback Networks V. Mammoliti Cisco Systems June 2007 Status of This Memo IANA Considerations for PPP over Ethernet (PPPoE)

More information

Network Working Group. November Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)

Network Working Group. November Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) Network Working Group Request for Comments: 3396 Updates: 2131 Category: Standards Track T. Lemon Nominum, Inc. S. Cheshire Apple Computer, Inc. November 2002 Status of this Memo Encoding Long Options

More information

OpenFlow Trademark Policy

OpenFlow Trademark Policy Introduction OpenFlow Trademark Policy This document outlines the Open Networking Foundation s ( ONF ) policy for the trademarks and graphic logos that we use to identify the OpenFlow specification and

More information

TECHNICAL REPORT TR-027. SNMP-based ADSL LINE MIB. Issue: 1.0 Issue Date: September The Broadband Forum. All rights reserved.

TECHNICAL REPORT TR-027. SNMP-based ADSL LINE MIB. Issue: 1.0 Issue Date: September The Broadband Forum. All rights reserved. TECHNICAL REPORT Issue: 1.0 Issue Date: September 1999 The Broadband Forum. All rights reserved. Notice The Broadband Forum is a non-profit corporation organized to create guidelines for broadband network

More information

OCTOSHAPE SDK AND CLIENT LICENSE AGREEMENT (SCLA)

OCTOSHAPE SDK AND CLIENT LICENSE AGREEMENT (SCLA) OCTOSHAPE SDK AND CLIENT LICENSE AGREEMENT (SCLA) This is a License Agreement (the "Agreement") for certain code (the Software ) owned by Akamai Technologies, Inc. ( Akamai ) that is useful in connection

More information

Video Services Forum Rules of Procedure

Video Services Forum Rules of Procedure Rules and procedures for compliance with the VSF IPR Policy January 17, 2017 Introduction This document is intended to assist Video Services Forum ( VSF ) chairpersons, members and staff in taking the

More information

RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update draft-ietf-dkim-rfc4871-errata-03-01dc

RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update draft-ietf-dkim-rfc4871-errata-03-01dc Network Working Group D. Crocker, Editor Internet Draft Brandenburg InternetWorking April 2, 2009 Updates: RFC4871 (if approved) Intended status: Standards Track

More information

Network Working Group Request for Comments: 5235 January 2008 Obsoletes: 3685 Category: Standards Track

Network Working Group Request for Comments: 5235 January 2008 Obsoletes: 3685 Category: Standards Track Network Working Group C. Daboo Request for Comments: 5235 January 2008 Obsoletes: 3685 Category: Standards Track Sieve Email Filtering: Spamtest and Virustest Extensions Status of This Memo This document

More information

Category: Standards Track October Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)

Category: Standards Track October Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4) Network Working Group J. Littlefield Request for Comments: 3925 Cisco Systems, Inc. Category: Standards Track October 2004 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version

More information

Request for Comments: 5208 Category: Informational May 2008

Request for Comments: 5208 Category: Informational May 2008 Network Working Group B. Kaliski Request for Comments: 5208 EMC Category: Informational May 2008 Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 Status

More information

Ecma International Policy on Submission, Inclusion and Licensing of Software

Ecma International Policy on Submission, Inclusion and Licensing of Software Ecma International Policy on Submission, Inclusion and Licensing of Software Experimental TC39 Policy This Ecma International Policy on Submission, Inclusion and Licensing of Software ( Policy ) is being

More information

Request for Comments: 5079 Category: Standards Track December Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)

Request for Comments: 5079 Category: Standards Track December Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Network Working Group J. Rosenberg Request for Comments: 5079 Cisco Category: Standards Track December 2007 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) Status of This Memo This

More information

INTERNET-DRAFT DTLS over DCCP February 6, DTLS over DCCP

INTERNET-DRAFT DTLS over DCCP February 6, DTLS over DCCP DTLS over DCCP Internet Draft T. Phelan Document: draft-ietf-dccp-dtls-05.txt Sonus Networks Expires: August 2008 February 6, 2008 Intended status: Proposed Standard Datagram Transport Layer Security (DTLS)

More information

Use and Interpretation of HTTP Version Numbers

Use and Interpretation of HTTP Version Numbers Network Working Group Request for Comments: 2145 Category: Informational J. Mogul DEC R. Fielding UC Irvine J. Gettys DEC H. Frystyk MIT/LCS May 1997 Use and Interpretation of HTTP Version Numbers Status

More information

OASIS - Artifact naming guidelines

OASIS - Artifact naming guidelines OASIS - Artifact naming guidelines Working Draft 06, 9 July 2004 Document identifier: Location: http://www.oasis-open.org/apps/org/workgroup/tab/documents.php Editor: Tim Moses Contributors: William Cox

More information

MERIDIANSOUNDINGBOARD.COM TERMS AND CONDITIONS

MERIDIANSOUNDINGBOARD.COM TERMS AND CONDITIONS MERIDIANSOUNDINGBOARD.COM TERMS AND CONDITIONS Introduction This document sets forth the terms and conditions ("Terms and Conditions") governing your use of the MeridianHealth.com Web site ("Web Site")

More information

Network Working Group Request for Comments: August Address-Prefix-Based Outbound Route Filter for BGP-4

Network Working Group Request for Comments: August Address-Prefix-Based Outbound Route Filter for BGP-4 Network Working Group Request for Comments: 5292 Category: Standards Track E. Chen S. Sangli Cisco Systems August 2008 Status of This Memo Address-Prefix-Based Outbound Route Filter for BGP-4 This document

More information

Network Working Group. Category: Standards Track February SIEVE Filtering: Spamtest and VirusTest Extensions

Network Working Group. Category: Standards Track February SIEVE  Filtering: Spamtest and VirusTest Extensions Network Working Group C. Daboo Request for Comments: 3685 Cyrusoft International, Inc. Category: Standards Track February 2004 SIEVE Email Filtering: Spamtest and VirusTest Extensions Status of this Memo

More information

Intended Category: Standards Track Expires March 2006 September 2005

Intended Category: Standards Track Expires March 2006 September 2005 INTERNET-DRAFT S. Santesson (Microsoft) Intended Category: Standards Track Expires March 2006 September 2005 Internet X.509 Public Key Infrastructure Subject Alternative Name for expression of service

More information

Category: Experimental June 2006

Category: Experimental June 2006 Network Working Group K. Zeilenga Request for Comments: 4531 OpenLDAP Foundation Category: Experimental June 2006 Lightweight Directory Access Protocol (LDAP) Turn Operation Status of This Memo This memo

More information

Category: Standards Track Microsoft May 2004

Category: Standards Track Microsoft May 2004 Network Working Group Request for Comments: 3770 Category: Standards Track R. Housley Vigil Security T. Moore Microsoft May 2004 Status of this Memo Certificate Extensions and Attributes Supporting Authentication

More information

Category: Standards Track Juniper Networks E. Rosen Cisco Systems, Inc. August MPLS Upstream Label Assignment and Context-Specific Label Space

Category: Standards Track Juniper Networks E. Rosen Cisco Systems, Inc. August MPLS Upstream Label Assignment and Context-Specific Label Space Network Working Group Request for Comments: 5331 Category: Standards Track R. Aggarwal Juniper Networks Y. Rekhter Juniper Networks E. Rosen Cisco Systems, Inc. August 2008 MPLS Upstream Label Assignment

More information

Category: Standards Track Cisco Systems, Inc January The Secure Shell (SSH) Session Channel Break Extension

Category: Standards Track Cisco Systems, Inc January The Secure Shell (SSH) Session Channel Break Extension Network Working Group Request for Comments: 4335 Category: Standards Track J. Galbraith VanDyke Software P. Remaker Cisco Systems, Inc January 2006 The Secure Shell (SSH) Session Channel Break Extension

More information

Recommendations for LXI systems containing devices supporting different versions of IEEE 1588

Recommendations for LXI systems containing devices supporting different versions of IEEE 1588 Recommendations for LXI systems containing devices supporting different versions of IEEE 1588 Revision 1.0 December 15, 2008 Edition Page 1 of 9 Notice of Rights All rights reserved. This document is the

More information

Request for Comments: 5179 Category: Standards Track May 2008

Request for Comments: 5179 Category: Standards Track May 2008 Network Working Group N. Williams Request for Comments: 5179 Sun Category: Standards Track May 2008 Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for

More information

October Network News Transfer Protocol (NNTP) Extension for Streaming Feeds

October Network News Transfer Protocol (NNTP) Extension for Streaming Feeds Network Working Group Request for Comments: 4644 Updates: 2980 Category: Standards Track J. Vinocur Cornell University K. Murchison Carnegie Mellon University October 2006 Network News Transfer Protocol

More information

OASIS Specification Document Template Usage

OASIS Specification Document Template Usage OASIS Specification Document Template Usage Working Draft, October 18, 2004 Document Identifier: oasis-spectools-1.0-word-sample-draft-01.doc OASIS Identifier: [OASIS document number] Location: Persistent:

More information

Network Working Group Request for Comments: 3937 Category: Informational October 2004

Network Working Group Request for Comments: 3937 Category: Informational October 2004 Network Working Group M. Steidl Request for Comments: 3937 IPTC Category: Informational October 2004 A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC)

More information

Network Working Group Request for Comments: 4869 Category: Informational May Suite B Cryptographic Suites for IPsec. Status of This Memo

Network Working Group Request for Comments: 4869 Category: Informational May Suite B Cryptographic Suites for IPsec. Status of This Memo Network Working Group Request for Comments: 4869 Category: Informational L. Law J. Solinas NSA May 2007 Status of This Memo Suite B Cryptographic Suites for IPsec This memo provides information for the

More information

Updates: 2535 November 2003 Category: Standards Track

Updates: 2535 November 2003 Category: Standards Track Network Working Group B. Wellington Request for Comments: 3655 O. Gudmundsson Updates: 2535 November 2003 Category: Standards Track Status of this Memo Redefinition of DNS Authenticated Data (AD) bit This

More information

Test Assertions for the SCA Assembly Model Version 1.1 Specification

Test Assertions for the SCA Assembly Model Version 1.1 Specification Test Assertions for the SCA Assembly Model Version 1.1 Specification Committee Draft 03 10 August 2010 Specification URIs: This Version: http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-test-assertions-cd03.html

More information

September The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry. Status of This Memo

September The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry. Status of This Memo Network Working Group Request for Comments: 5341 Updates: 3966 Category: Standards Track C. Jennings Cisco Systems V. Gurbani Bell Laboratories, Alcatel-Lucent September 2008 The Internet Assigned Number

More information

Ericsson D. Willis. Cisco Systems. April 2006

Ericsson D. Willis. Cisco Systems. April 2006 Network Working Group Request for Comments: 4453 Category: Informational J. Rosenberg Cisco Systems G. Camarillo, Ed. Ericsson D. Willis Cisco Systems April 2006 Status of This Memo Requirements for Consent-Based

More information

Network Working Group Request for Comments: Category: Best Current Practice January 2004

Network Working Group Request for Comments: Category: Best Current Practice January 2004 Network Working Group R. Bush Request for Comments: 3681 IIJ BCP: 80 R. Fink Category: Best Current Practice January 2004 Status of this Memo Delegation of E.F.F.3.IP6.ARPA This document specifies an Internet

More information

Category: Standards Track Cisco Systems, Inc. March 2005

Category: Standards Track Cisco Systems, Inc. March 2005 Network Working Group Request for Comments: 3993 Category: Standards Track R. Johnson T. Palaniappan M. Stapp March 2005 Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay

More information

Network Working Group. Category: Standards Track June 2005

Network Working Group. Category: Standards Track June 2005 Network Working Group P. Jones Request for Comments: 4102 Cisco Systems, Inc. Category: Standards Track June 2005 Status of This Memo Registration of the text/red MIME Sub-Type This document specifies

More information