idnits 2.17.1 draft-westerlund-mmusic-ice-options-registry-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5245, but the abstract doesn't seem to mention this, which it should. 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 (November 19, 2010) is 4907 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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: May 23, 2011 November 19, 2010 8 IANA Registry for Interactive Connectivity Establishment (ICE) Options 9 draft-westerlund-mmusic-ice-options-registry-01 11 Abstract 13 It has been identified that Interactive Connectivity Establishment 14 (ICE) is missing a registry for ICE options. This document defines 15 this missing IANA registry. 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 May 23, 2011. 34 Copyright Notice 36 Copyright (c) 2010 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 there has come into 68 existence at least one ICE option, there is need to create the 69 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 end- 80 points to negotiate extension support. RFC 5245 defines one method 81 of signaling these ICE options, using SDP with Offer/Answer 82 [RFC3264]. 84 2. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 3. IANA Considerations 92 This document defines a registry for ICE options that can be used in 93 SDP "ice-options" attribute or other signalling parameters carrying 94 the ICE options. 96 3.1. ICE Options 98 An ICE option identifier MUST fulfill the ABNF [RFC5234] syntax for 99 "ice-option-tag" as specified in [RFC5245]. This syntax is reproduce 100 here for simplicity, but the authoritative definition is in the ICE 101 RFC: 102 ice-option-tag = 1*ice-char 103 ice-char = ALPHA / DIGIT / "+" / "/" 105 ICE options are of unlimited length by the syntax, however they are 106 recommended to be no longer than 20 characters. This is to reduce 107 message sizes and allow for efficient parsing. 109 Registration of an ICE option is done using the Specification 110 Required policy as defined in "Guidelines for Writing an IANA 111 Considerations Section in RFCs" [RFC5226]. 113 A registration request MUST include the following information: 115 o Name of contact person for the registration 117 o Email and Address of the Contact person 119 o Organization or individuals having the change control 121 o The ICE option identifier 123 o Short description of the ICE extension 125 o Reference(s) to the specification defining the ICE option and the 126 related extensions 128 4. Security Considerations 130 As this document defines an IANA registry for an already existing 131 concept there are no new security considerations. 133 5. Acknowledgements 135 6. References 137 6.1. Normative References 139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 140 Requirement Levels", BCP 14, RFC 2119, March 1997. 142 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 143 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 144 May 2008. 146 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 147 Specifications: ABNF", STD 68, RFC 5234, January 2008. 149 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 150 (ICE): A Protocol for Network Address Translator (NAT) 151 Traversal for Offer/Answer Protocols", RFC 5245, 152 April 2010. 154 6.2. Informative References 156 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 157 with Session Description Protocol (SDP)", RFC 3264, 158 June 2002. 160 Authors' Addresses 162 Magnus Westerlund 163 Ericsson 164 Farogatan 6 165 SE-164 80 Kista 166 Sweden 168 Phone: +46 10 714 82 87 169 Email: magnus.westerlund@ericsson.com 171 Colin Perkins 172 University of Glasgow 173 School of Computing Science 174 Glasgow G12 8QQ 175 United Kingdom 177 Email: csp@csperkins.org