idnits 2.17.1 draft-ietf-mmusic-ice-options-registry-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5245, updated by this document, for RFC5378 checks: 2003-10-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 12, 2011) is 4726 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) == Outdated reference: A later version (-08) exists of draft-ietf-avtcore-ecn-for-rtp-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft Ericsson 4 Updates: 5245 (if approved) C. Perkins 5 Intended status: Standards Track University of Glasgow 6 Expires: November 13, 2011 May 12, 2011 8 IANA Registry for Interactive Connectivity Establishment (ICE) Options 9 draft-ietf-mmusic-ice-options-registry-02 11 Abstract 13 It has been identified that Interactive Connectivity Establishment 14 (ICE) RFC5245 is missing a registry for ICE options. This document 15 defines this missing IANA registry and updates RFC5245. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 13, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. ICE Options . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 "Interactive Connectivity Establishment (ICE): A Protocol for Network 65 Address Translator (NAT) Traversal for Offer/Answer" [RFC5245] 66 defines a concept of ICE Options. However, the ICE RFC fails to 67 create an IANA registry for ICE options. As one ICE option is under 68 specification in [I-D.ietf-avtcore-ecn-for-rtp], there is now a need 69 to create the registry. 71 RFC 5245 says: "ICE provides for extensibility by allowing an offer 72 or answer to contain a series of tokens that identify the ICE 73 extensions used by that agent. If an agent supports an ICE 74 extension, it MUST include the token defined for that extension in 75 the ice-options attribute." 77 Thus, as future extensions are defined, these ICE options needs to be 78 registered with IANA to ensure non-conflicting identification. The 79 ICE options identifiers are used in signalling between the ICE 80 endpoints to negotiate extension support. RFC 5245 defines one 81 method of signalling these ICE options, using SDP with Offer/Answer 82 [RFC3264]. 84 This document updates the ICE specification [RFC5245] to define the 85 "Interactive Connectivity Establishment (ICE) Options" registry. 87 2. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 3. IANA Considerations 95 This document defines a registry "Interactive Connectivity 96 Establishment (ICE) Options" for ICE options that can be used in SDP 97 "ice-options" attribute or other signalling parameters carrying the 98 ICE options. 100 3.1. ICE Options 102 An ICE option identifier MUST fulfill the ABNF [RFC5234] syntax for 103 "ice-option-tag" as specified in [RFC5245]. This syntax is 104 reproduced here for simplicity, but the authoritative definition is 105 in the ICE RFC: 106 ice-option-tag = 1*ice-char 107 ice-char = ALPHA / DIGIT / "+" / "/" 108 ICE options are of unlimited length by the syntax, however they are 109 RECOMMENDED to be no longer than 20 characters. This is to reduce 110 message sizes and allow for efficient parsing. 112 Registration of an ICE option in the "Interactive Connectivity 113 Establishment (ICE) Options" registry is done using the Specification 114 Required policy as defined in "Guidelines for Writing an IANA 115 Considerations Section in RFCs" [RFC5226]. 117 A registration request MUST include the following information: 119 o The ICE option identifier to be registered 121 o Name, Email and Address of contact person for the registration 123 o Organization or individuals having the change control 125 o Short description of the ICE extension to which the option relates 127 o Reference(s) to the specification defining the ICE option and the 128 related extensions 130 This document registers no ICE option. 132 4. Security Considerations 134 As this document defines an IANA registry for an already existing 135 concept there are no new security considerations. 137 5. Acknowledgements 139 The authors would like to thank the people having reviewed the draft 140 and provided feedback, Flemming Andreasen, Mykyta Yevstifeyev, Amanda 141 Baber and Brian Carpenter. 143 6. References 145 6.1. Normative References 147 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 148 Requirement Levels", BCP 14, RFC 2119, March 1997. 150 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 151 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 152 May 2008. 154 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 155 Specifications: ABNF", STD 68, RFC 5234, January 2008. 157 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 158 (ICE): A Protocol for Network Address Translator (NAT) 159 Traversal for Offer/Answer Protocols", RFC 5245, 160 April 2010. 162 6.2. Informative References 164 [I-D.ietf-avtcore-ecn-for-rtp] 165 Westerlund, M., Johansson, I., Perkins, C., and K. 166 Carlberg, "Explicit Congestion Notification (ECN) for RTP 167 over UDP", draft-ietf-avtcore-ecn-for-rtp-01 (work in 168 progress), March 2011. 170 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 171 with Session Description Protocol (SDP)", RFC 3264, 172 June 2002. 174 Authors' Addresses 176 Magnus Westerlund 177 Ericsson 178 Farogatan 6 179 SE-164 80 Kista 180 Sweden 182 Phone: +46 10 714 82 87 183 Email: magnus.westerlund@ericsson.com 185 Colin Perkins 186 University of Glasgow 187 School of Computing Science 188 Glasgow G12 8QQ 189 United Kingdom 191 Email: csp@csperkins.org