idnits 2.17.1 draft-ietf-mmusic-sdp-bfcp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 29, 2005) is 6717 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 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3280 (ref. '5') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3850 (ref. '6') (Obsoleted by RFC 5750) == Outdated reference: A later version (-06) exists of draft-ietf-xcon-bfcp-05 == Outdated reference: A later version (-06) exists of draft-ietf-mmusic-comedia-tls-05 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sdp-new-25 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: June 2, 2006 November 29, 2005 6 Session Description Protocol (SDP) Format for Binary Floor Control 7 Protocol (BFCP) Streams 8 draft-ietf-mmusic-sdp-bfcp-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 2, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document specifies how to describe BFCP streams in SDP session 42 descriptions. User agents using the offer/answer model to establish 43 BFCP streams use this format in their offers and their answers. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Fields in the 'm' Line . . . . . . . . . . . . . . . . . . . . 3 50 4. Floor Control Server Determination . . . . . . . . . . . . . . 4 51 5. The 'confid' and 'userid' SDP Attributes . . . . . . . . . . . 6 52 6. Association between Streams and Floors . . . . . . . . . . . . 6 53 7. TCP Connection Management . . . . . . . . . . . . . . . . . . 7 54 8. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 7 55 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 57 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 11.1. Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP' SDP 59 'proto' values . . . . . . . . . . . . . . . . . . . . . 9 60 11.2. Registration of the SDP 'floorctrl' Attribute . . . . . . 10 61 11.3. Registration of the SDP 'confid' Attribute . . . . . . . 10 62 11.4. Registration of the SDP 'userid' Attribute . . . . . . . 10 63 11.5. Registration of the SDP 'floorid' Attribute . . . . . . . 11 64 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 65 13. Normative References . . . . . . . . . . . . . . . . . . . . . 11 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 As discussed in the BFCP (Binary Floor Control Protocol) 72 specification [8], a given BFCP client needs a set of data in order 73 to establish a BFCP connection to a floor control server. These data 74 include the transport address of the server, the conference 75 identifier, and the user identifier. 77 One way for clients to obtain this information consists of using an 78 offer/answer [4] exchange. This document specifies how to encode 79 this information in the SDP session descriptions which are part of 80 such an offer/answer exchange. 82 User agents typically use the offer/answer model to establish a 83 number of media streams of different types. Following this model, a 84 BFCP connection is described as any other media stream by using an 85 SDP 'm' line, possibly followed by a number of attributes encoded in 86 'a' lines. 88 2. Terminology 90 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 91 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 92 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 93 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 94 compliant implementations. 96 3. Fields in the 'm' Line 98 This Section describes how to generate an 'm' line for a BFCP stream. 100 According to the SDP specification [11], the 'm' line format is the 101 following: 103 m= ... 105 The media field MUST have a value of "application". 107 The port field is set following the rules in [7]. Depending on the 108 value of the 'setup' attribute (disccused in Section 7), the port 109 field contains the port the remote endpoint will initiate its TCP 110 connection to, or is irrelevant (i.e., the endpoint will initiate the 111 connection towards the remote endpoint) and should be set to a value 112 of 9, which is the discard port. Since BFCP only runs on top of TCP, 113 the port is always a TCP port. A port field value of zero has the 114 standard SDP meaning (i.e., rejection of the media stream). 116 We define two new values for the transport field: TCP/BFCP and TCP/ 117 TLS/BFCP. The former is used when BFCP runs directly on top of TCP 118 and the latter is used when BFCP runs on top of TLS, which in turn 119 runs on top of TCP. 121 The fmt (format) list is ignored for BFCP. The fmt list of BFCP m 122 lines SHOULD contain a single "*" character. 124 The following is an example of an 'm' line for a BFCP connection: 126 m=application 50000 TCP/TLS/BFCP * 128 4. Floor Control Server Determination 130 When two endpoints establish a BFCP stream, they need to determine 131 which of them acts as a floor control server. The most common 132 scenario consists of a client establishing a BFCP stream with 133 conference server that acts as the floor control server. Floor 134 control server determination is straight forward because one endpoint 135 can only act as a client and the other can only act as a floor 136 control server. 138 However, there are scenarios where both endpoints could act as a 139 floor control server. For example, is a two-party session that 140 involves an audio stream and a shared whiteboard, the endpoints need 141 to decide which party will be acting as the floor control server. 143 Furthermore, there are situations where both the offerer and the 144 answerer act as both clients and floor control servers in the same 145 session. For example, in a two-party session that involves an audio 146 stream and a shared whiteboard, one party acts as the floor control 147 server for the audio stream and the other acts as the floor control 148 server for the shared whiteboard. 150 We define the 'floorctrl' SDP media-level attribute to perform floor 151 control determination. Its Augmented BNF syntax [2] is: 153 floor-control-attribute = "a=floorctrl:" role *(SP role) 154 role = "c-only" / "s-only" / "c-s" 156 The offerer includes this attribute to state all the roles it would 157 be willing to perform: 159 c-only: The offerer would be willing to only act as a floor control 160 client. 161 s-only: The offerer would be willing to only act as a floor control 162 server. 163 c-s: The offerer would be willing to act both as a floor control 164 client and as a floor control server. 166 If an 'm' line in an offer contains a 'floorctrl' attribute, the 167 answerer MUST include one in the corresponding 'm' line in the 168 answer. The answerer includes this attribute to state which role the 169 answerer will perform. That is, the answerer chooses one of the 170 roles the offerer is willing to perform and generates an answer with 171 the corresponding role for the answerer. Table 1 shows the 172 corresponding roles for an answerer depending on the offerer's role. 174 +---------+----------+ 175 | Offerer | Answerer | 176 +---------+----------+ 177 | c-only | s-only | 178 | s-only | c-only | 179 | c-s | c-s | 180 +---------+----------+ 182 Table 1: Roles 184 The following are the description of the roles when chosen by an 185 answere:. 187 c-only: The answerer will act as a floor control client. 188 Consequently, the offerer will act as a floor control server. 189 s-only: The answerer will act as a floor control server. 190 Consequently, the offerer will act as a floor control client. 191 c-s: The answerer will act both as a floor control client and as a 192 floor control server. Consequently, the offerer will also act 193 both as a floor control client and as a floor control server as 194 well. 196 Endpoints which use the offer/answer model to establish BFCP 197 connections MUST support the 'floorctrl' attribute. A floor control 198 server acting as an offerer or as an answerers SHOULD include this 199 attribute in its session descriptions. 201 If the 'floorctrl' attribute is not used in an offer/answer exchange, 202 by default the offerer and the answerer will act as a floor control 203 client and as a floor control server respectively. 205 The following is an example of a 'floorctrl' attribute in an offer. 206 When this attribute appears in an answer, it only carries one role: 208 a=floorctrl:c-only s-only c-s 210 5. The 'confid' and 'userid' SDP Attributes 212 We define the 'confid' and the 'userid' SDP media-level attributes. 213 These attributes attributes are used by a floor control server to 214 provide a client with a conference ID and a user ID respectively. 215 Their Augmented BNF syntax [2] is: 217 confid-attribute = "a=confid:" conference-id 218 conference-id = token 220 userid-attribute = "a=userid:" user-id 221 user-id = token 223 The confid and the userid attributes carry the integer representation 224 of a conference ID and a user ID respectively. 226 Endpoints which use the offer/answer model to establish BFCP 227 connections MUST support the confid and the userid attributes. A 228 floor control server acting as an offerer or as an answerers SHOULD 229 include these attributes in its session descriptions. 231 6. Association between Streams and Floors 233 We define the floorid SDP media-level attribute. Its Augmented BNF 234 syntax [2] is: 236 floor-id-attribute = "a=floorid:" token [" mstrm:" token *(SP token)] 238 The floorid attribute is used in BFCP 'm' lines. It defines a floor 239 identifier and, possibly, associates it with one or more media 240 streams. The token representing the floor ID is the integer 241 representation of the Floor ID to be used in BFCP. The token 242 representing the media stream is a pointer to the media stream, which 243 is identified by an SDP label attribute [9] 245 Endpoints which use the offer/answer model to establish BFCP 246 connections MUST support the 'floorid' and the 'label' attributes. A 247 floor control server acting as an offerer or as an answerer SHOULD 248 include these attributes in its session descriptions. 250 7. TCP Connection Management 252 The management of the TCP connection used to transport BFCP is 253 performed using the 'setup' and 'connection' attributes as defined in 254 [7]. 256 The 'setup' attribute indicates which of the endpoints (client or 257 floor control server) initiates the TCP connection. The 'connection' 258 attribute handles TCP connection reestablishment. 260 The BFCP specification [8] describes a number of situations when the 261 TCP connection between a client and the floor control server needs to 262 be reestablished. However, that specification does not describe the 263 reestablishment process because this process depends on how the 264 connection was established in the first place. BFCP entities using 265 the offer/answer model follow the following rules. 267 When the existing TCP connection is reseted following the rules in 268 [8], the client SHOULD generate an offer towards the floor control 269 server in order to reestablish the connection. If a TCP connection 270 cannot deliver a BFCP message and times out, the entity that 271 attempted to send the message (i.e., the one that detected the TCP 272 timeout) SHOULD generate an offer in order to reestablish the TCP 273 connection. 275 Endpoints which use the offer/answer model to establish BFCP 276 connections MUST support the 'setup' and the 'connection' attributes. 278 8. Authentication 280 When a BFCP connection is established using the offer/answer model, 281 it is assumed that the offerer and the answerer authenticate each 282 other using some mechanism. Once this mutual authentication takes 283 place, all the offerer and the answerer need to make sure is that the 284 entity they are receiving BFCP messages from is the same as the one 285 that generated the previous offer or answer. 287 When SIP is used to perform an offer/answer exchange, the initial 288 mutual authentication takes place at the SIP level. Additionally, 289 SIP uses S/MIME [6] to provide an integrity protected channel with 290 optional confidentiality for the offer/answer exchange. BFCP takes 291 advantage of this integrity protected offer/answer exchange to 292 perform authentication. Within the offer/answer exchange, the 293 offerer and the answerer exchange the fingerprints of their self- 294 signed certificates. These self-signed certificates are then used to 295 establish the TLS connection that will carry BFCP traffic between the 296 offerer and the answerer. 298 BFCP clients and floor control servers follow the rules in [10] 299 regarding certificate choice and presentation. This implies that 300 unless a 'fingerprint' attribute is included in the session 301 description, the certificate provided at the TLS-level MUST either be 302 directly signed by one of the other party's trust anchors or be 303 validated using a certification path that terminates at one of the 304 other party's trust anchors [5]. Endpoints which use the offer/ 305 answer model to establish BFCP connections MUST support the 306 'fingerprint' attribute and SHOULD include it in their session 307 descriptions. 309 When TLS is used, once the underlaying TCP connection is established, 310 the answerer acts as the TLS server regardless of its role (passive 311 or active) in the TCP establishment procedure. 313 9. Examples 315 For the purpose of brevity, the main portion of the session 316 description is omitted in the examples, which only show 'm' lines and 317 their attributes. 319 The following is an example of an offer sent by a conference server 320 to a client. 322 m=application 50000 TCP/TLS/BFCP * 323 a=setup:passive 324 a=connection:new 325 a=fingerprint:SHA-1 \ 326 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 327 a=floorctrl:s-only 328 a=confid:4321 329 a=userid:1234 330 a=floorid:1 m-stream:10 331 a=floorid:2 m-stream:11 332 m=audio 50002 RTP/AVP 0 333 a=label:10 334 m=video 50004 RTP/AVP 31 335 a=label:11 337 Note that due to RFC formatting conventions, this document splits SDP 338 across lines whose content would exceed 72 characters. A backslash 339 character marks where this line folding has taken place. This 340 backslash and its trailing CRLF and whitespace would not appear in 341 actual SDP content. 343 The following is the answer returned by the client. 345 m=application 9 TCP/TLS/BFCP * 346 a=setup:active 347 a=connection:new 348 a=fingerprint:SHA-1 \ 349 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 350 a=floorctrl:c-only 351 m=audio 55000 RTP/AVP 0 352 m=video 55002 RTP/AVP 31 354 10. Security Considerations 356 The BFCP [8], SDP [11], and the offer/answer [4] specifications 357 discuss security issues related to BFCP, SDP, and the offer/answer 358 respectively. In addition, [7] and [10] discuss security issues 359 related to the establishment of TCP and TLS connections using an 360 offer/answer model. 362 BFCP assumes an initial integrity-protected channel used to exchange 363 self-signed certificates between a client and the floor control 364 server. For session descriptions carried in SIP [3], S/MIME [6] is 365 the natural choice to provide such a channel. 367 11. IANA Considerations 369 The following sections instruct the IANA to perform a set of actions. 371 11.1. Registration of the 'TCP/BFCP' and 'TCP/TLS/BFCP' SDP 'proto' 372 values 374 This section instructs the IANA to register the following two new 375 values for the SDP 'proto' field under the Session Description 376 Protocol (SDP) Parameters registry: 378 +--------------+-----------+ 379 | Value | Reference | 380 +--------------+-----------+ 381 | TCP/BFCP | RFCxxxx | 382 | TCP/TLS/BFCP | RFCxxxx | 383 +--------------+-----------+ 385 Table 2: Values for the SDP 'proto' field 387 [Note to the RFC editor: please, replace RFCxxxx with the RFC number 388 that this document will be assigned.] 390 11.2. Registration of the SDP 'floorctrl' Attribute 392 This section instructs the IANA to register the following SDP att- 393 field under the Session Description Protocol (SDP) Parameters 394 registry: 396 Contact name: Gonzalo.Camarillo@ericsson.com 398 Attribute name: floorctrl 400 Long-form attribute name: Floor Control 402 Type of attribute Media level 404 Subject to charset: No 406 Purpose of attribute: The 'floorctrl' attribute is used to perform 407 floor control server determination. 409 Allowed attribute values: 1*("c-only" / "s-only" / "c-s") 411 11.3. Registration of the SDP 'confid' Attribute 413 This section instructs the IANA to register the following SDP att- 414 field under the Session Description Protocol (SDP) Parameters 415 registry: 417 Contact name: Gonzalo.Camarillo@ericsson.com 419 Attribute name: confid 421 Long-form attribute name: Conference Identifier 423 Type of attribute Media level 425 Subject to charset: No 427 Purpose of attribute: The 'confid' attribute carries the integer 428 representation of a Conference ID. 430 Allowed attribute values: A token 432 11.4. Registration of the SDP 'userid' Attribute 434 This section instructs the IANA to register the following SDP att- 435 field under the Session Description Protocol (SDP) Parameters 436 registry: 438 Contact name: Gonzalo.Camarillo@ericsson.com 440 Attribute name: userid 442 Long-form attribute name: User Identifier 444 Type of attribute Media level 446 Subject to charset: No 448 Purpose of attribute: The 'userid' attribute carries the integer 449 representation of a User ID. 451 Allowed attribute values: A token 453 11.5. Registration of the SDP 'floorid' Attribute 455 This section instructs the IANA to register the following SDP att- 456 field under the Session Description Protocol (SDP) Parameters 457 registry: 459 Contact name: Gonzalo.Camarillo@ericsson.com 461 Attribute name: floorid 463 Long-form attribute name: Floor Identifier 465 Type of attribute Media level 467 Subject to charset: No 469 Purpose of attribute: The 'floorid' attribute associates a floor 470 with one or more media streams. 472 Allowed attribute values: Tokens 474 12. Acknowledgments 476 Joerg Ott, Keith Drage, Alan Johnston, Eric Rescorla, Roni Even, and 477 Oscar Novo provided useful ideas for this document. 479 13. Normative References 481 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 482 Levels", BCP 14, RFC 2119, March 1997. 484 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 485 Specifications: ABNF", RFC 2234, November 1997. 487 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 488 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 489 Session Initiation Protocol", RFC 3261, June 2002. 491 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 492 Session Description Protocol (SDP)", RFC 3264, June 2002. 494 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 495 Public Key Infrastructure Certificate and Certificate 496 Revocation List (CRL) Profile", RFC 3280, April 2002. 498 [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 499 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, 500 July 2004. 502 [7] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the 503 Session Description Protocol (SDP)", RFC 4145, September 2005. 505 [8] Camarillo, G., "The Binary Floor Control Protocol (BFCP)", 506 draft-ietf-xcon-bfcp-05 (work in progress), July 2005. 508 [9] Levin, O. and G. Camarillo, "The SDP (Session Description 509 Protocol) Label Attribute", 510 draft-ietf-mmusic-sdp-media-label-01 (work in progress), 511 January 2005. 513 [10] Lennox, J., "Connection-Oriented Media Transport over the 514 Transport Layer Security (TLS) Protocol in the Session 515 Description Protocol (SDP)", draft-ietf-mmusic-comedia-tls-05 516 (work in progress), September 2005. 518 [11] Handley, M., "SDP: Session Description Protocol", 519 draft-ietf-mmusic-sdp-new-25 (work in progress), July 2005. 521 Author's Address 523 Gonzalo Camarillo 524 Ericsson 525 Hirsalantie 11 526 Jorvas 02420 527 Finland 529 Email: Gonzalo.Camarillo@ericsson.com 531 Intellectual Property Statement 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; nor does it represent that it has 538 made any independent effort to identify any such rights. Information 539 on the procedures with respect to rights in RFC documents can be 540 found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use of 545 such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository at 547 http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at 553 ietf-ipr@ietf.org. 555 Disclaimer of Validity 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 560 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 561 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 562 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 565 Copyright Statement 567 Copyright (C) The Internet Society (2005). This document is subject 568 to the rights, licenses and restrictions contained in BCP 78, and 569 except as set forth therein, the authors retain all their rights. 571 Acknowledgment 573 Funding for the RFC Editor function is currently provided by the 574 Internet Society.