idnits 2.17.1 draft-groves-megaco-pkgereg-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 -- 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 25, 2009) is 5448 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'H248amm1' -- Obsolete informational reference (is this intentional?): RFC 3525 (Obsoleted by RFC 5125) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Groves 2 Internet Draft NTEC Australia 3 Intended status: BCP Y. Lin 4 Expires: November 2009 Huawei 5 May 25, 2009 7 H.248/MEGACO Registration Procedures 8 draft-groves-megaco-pkgereg-04.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on October 25, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your 41 rights and restrictions with respect to this document. 43 Abstract 45 This document updates the H.248/MEGACO IANA Package Registration 46 procedures in order to better describe the Package registration 47 process and to provide a more formal review and feedback process. 49 Table of Contents 51 1. Introduction ................................................. 2 52 2. Conventions used in this document ............................ 4 53 3. Formal Syntax ................................................ 4 54 4. Security Considerations ...................................... 4 55 5. IESG Expert Reviewer Considerations .......................... 5 56 5.1. Appointment of the IESG H.248/MEGACO Expert ............. 5 57 5.2. Package Registration Procedure .......................... 6 58 5.3. Error Code Registration Procedure ....................... 8 59 5.4. ServiceChange Reason Registration Procedure ............. 9 60 5.5. Profile Name Registration Procedure ..................... 9 61 6. IANA Considerations ......................................... 10 62 6.1. New IANA Package Registration .......................... 10 63 6.2. IANA Error Code Registration ........................... 11 64 6.3. IANA ServiceChange Reason Registration ................. 11 65 6.4. IANA Profile Name Registration ......................... 12 66 7. References .................................................. 13 67 7.1. Normative References ................................... 13 68 7.2. Informative References ................................. 13 69 8. Acknowledgments ............................................. 13 70 Authors' Addresses ............................................. 13 72 1. Introduction 74 Since the initial development of H.248/MEGACO a number of 75 organizations have made use of the H.248/MEGACO protocol Package 76 mechanism in order to allow a certain function to be controlled by 77 H.248/MEGACO. The H.248/MEGACO package mechanism was in part 78 introduced to allow organizations who had an in depth knowledge in a 79 particular functional area to independently produce a package on this 80 functionality. This acknowledged the fact that neither the IETF 81 MEGACO Working Group nor the ITU-T Study Group 16 possessed in depth 82 knowledge in all areas. Whilst this approach has been successful in 83 the number and range of packages produced, in some cases these 84 Packages were/are not fully aligned with H.248/MEGACO principles. 86 Once a Package has been published and registered it is problematic to 87 rectify any issues. 89 The introduction of problems/inconsistencies was in part caused by 90 the fact that the Packages were not fully reviewed by H.248/MEGACO 91 experts. In fact the IANA H.248/MEGACO registration process did not 92 actually specify that an in depth review should take place. 94 The current H.248/MEGACO Package registration process was defined 95 when ITU-T Study Group 16 and the IETF Megaco Working Groups were 96 both active in Megaco/H.248 standardization and produced nearly all 97 the registered Packages. Packages were reviewed in the IETF MEGACO 98 Working Group and the Working Group chair was the IESG appointed 99 expert in charge of the review of the requests for H.248 Package 100 registration. This meant that H.248 Packages underwent an informal 101 review before being registered. However this has changed. 103 The current situation is that now the IETF Megaco working group is 104 disbanded and new H.248/MEGACO development typically occurs through 105 Question 3 of ITU-T Study Group 16 (not withstanding email discussion 106 on the IETF MEGACO mailing list). This move to ITU-T defined 107 Recommendations is discussed in [RFC5125]. 109 Given this situation, it is appropriate that the H.248/Package 110 definition and IANA registration rules are updated to introduce a 111 formal review step before the Package registration process is 112 completed and ideally before the Package is published. This process 113 would only be applicable to public Packages. 115 As part of the Package development process Package developers are 116 encouraged to send their Package for review to the ITU-T Study Group 117 Question Rapporteur responsible for the H.248 sub-series (Question 3 118 of Study Group 16 at the time of writing). When registering the 119 Package with IANA, package developers are required to send a copy of 120 the package for review by the IESG appointed expert. It is 121 recommended to register the Package before final approval by the 122 group in question in order to solicit feedback on the quality of 123 their Package. Where ever possible this review will be done in 124 conjunction with other H.248/MEGACO experts (e.g. in Q.3/16 and/or 125 the MEGACO mailing list). 127 The existing IANA Package registration process is a two step process. 128 When Packages are first registered they receive the status of "In 129 Progress (IP)". This allows Package developers to request a PackageID 130 before the document is fully approved. When the document is approved 131 then a change of status to "Final", may be requested. The new 132 procedure introduces the step that the IESG appointed expert is 133 consulted before a change of status is made. If the Package has been 134 reviewed and is acceptable then the status may be changed to "Final". 135 However if the package has not been provided for review or it has 136 outstanding comments then the status SHALL remain at "IP". 138 The goal of the updated text is to define a process that provides a 139 timely technical review of packages to ensure that H.248/MEGACO 140 packages are of good quality and minimize duplication. 142 The "Error Code", "ServiceChange Reason" and "Profile Name" 143 registration procedures have been included for completeness and to 144 make explicit the role of the IESG reviewer. These procedures align 145 with the considerations documented in [H.248amm1] and with [RFC3525] 146 (with the exception of Profile Names which did not appear in this 147 version). 149 2. Conventions used in this document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 3. Formal Syntax 157 The following syntax specification uses the augmented Backus-Naur 158 Form (BNF) as described in RFC-5234 [RFC5234]. 160 Text encoded PackageIDs shall conform to the "PackageName" encoding 161 in H.248.1 [H248amm1] Annex B. Repeated below for convienience: 163 PackageName = NAME 165 NAME = ALPHA *63(ALPHA / DIGIT / "_") 167 Note: A digit is not allowed as the first character of a package 168 name. 170 4. Security Considerations 172 Updating the IANA H.248/MEGACO package registration procedures has no 173 additional security implications. Security for the H.248/MEGACO 174 protocol over IP transports is discussed in H.248.1 section 10 175 [H.248amm1]. 177 As of this date there have been no recorded security issues arising 178 out of the registration or use of packages. Whilst packages may 179 define extra procedures and code points these are done within the 180 framework of the core H.248.1 specification. It is not possible to 181 update the H.248.1 core protocol through a package specification. The 182 use of the H.248.1 core protocol is agreed between a MGC and a MG. 183 H.248 ServiceChange procedures establish a H.248 control association 184 between the MGC and MG. To establish an association there must be a 185 level of trust between the MGC and MG. In the context of this control 186 (and trust) association the elements 187 (properties/signals/events/statistics) from the Packages are conveyed 188 between the MGC and MG. An MGC or MG will only act upon elements that 189 it knows. If it does not understand a PackageID or package element 190 then an error response is returned only in the context of the control 191 association. 193 If a malicious Package Specification is implemented in a MGC or MG it 194 would be unlikely to cause problems. As H.248 is a master slave 195 protocol, if the malicious package was implemented in the MGC and not 196 the MG there would be no action because the MG would not understand 197 the PackageID (and elements). If the malicious package was 198 implemented on the MG there would be no effect because the MGC would 199 never command the MG to use it. If the malicious package was 200 implemented in both the MGC and MG then there's a wider non-H.248 201 issue that someone has managed to install software on both the MGC 202 and the MG. It is highly unlikely for such a person to ask IANA for a 203 PackageID when they could use any one they want. 205 Therefore it is in this respect that updates to the IANA H.248/MEGACO 206 package registration procedures are deemed to have no additional 207 security impacts. 209 Requesters and the Expert reviewer should ensure that the package 210 does not introduce any additional security issues. Requesters for 211 public packages for a particular standards development organization 212 must be authorized by that organization to request a Package 213 registration. 215 5. IESG Expert Reviewer Considerations 217 For public registered Packages, Error Codes, ServiceChangeReasons and 218 Profile Names review by an Expert reviewer is required before IANA 219 performs a registration. Private Packages do not require the same 220 level of review. The sections below outline the considerations for 221 Expert review. 223 5.1. Appointment of the IESG H.248/MEGACO Expert 225 The IESG shall remain responsible for allocating the H.248/MEGACO 226 expert. It is recommended that this person be involved in ongoing 227 H.248/MEGACO development. As such it is recommended that 228 identification of the IESG expert be done in consultation with the 229 ITU-T Study Group/Question responsible for the H.248 sub-series of 230 Recommendations, Q.3/16 at the time of writing. 232 5.2. Package Registration Procedure 234 Package requesters are encouraged to review their work against 235 H.248.1 section 12 [H.248amm1] "Package Definition" and are 236 encouraged to use the "Package Definition Template" provided in 237 H.248.1 Appendix II. 239 The process for registering a public Package is deemed to be 240 "specification required" as per [RFC5226]. As such once the initial 241 checks occur Package requesters for public packages under development 242 shall send the package text to IANA. They are also encouraged to send 243 the package to the ITU-T Question/Study Group responsible for the 244 H.248 sub-series of Recommendations (Q.3/16 at the time of writing) 245 for review. Updated contact information can be found in the latest 246 version of the H.248 Sub-series Implementors' Guide. This should 247 occur as soon as practicable after the rough draft of the definition 248 is completed and at least before the package is approved in order to 249 ensure the package is consistent with H.248 methodologies and package 250 design principles. 252 In order to register private packages, a specification is not 253 required but is encouraged. 255 Package requesters are encouraged to request registration as early as 256 practicable in the design process, to reserve a binary ID. Binary 257 IDs shall be published in the document defining the package. 259 Once the initial or final request for a Package registration is 260 received by IANA it will be forwarded to the IESG appointed Expert 261 for review. During the review the input package and details will be 262 compared to the Package template for completeness, as well as being 263 compared against protocol syntax and procedures. It will be compared 264 against existing work to see that it does not duplicate existing 265 functionality. It will be reviewed to see that any potential security 266 issues are addressed. The Expert reviewer will then work towards a 267 resolution of any issues with the Package requester. The IESG 268 appointed Expert may complete the review in consultation with other 269 H.248 experts (i.e. Currently Question 3 of ITU-T Study Group 16 and 270 via email to IETF Megaco email list). If the package is deemed 271 suitable, the IESG appointed Expert shall issue a statement 272 indicating approval, copied to IANA. 274 The IESG Expert Reviewer will ensure the following considerations are 275 met to register a package with the IANA: 277 1) A unique string name, unique serial number and version number is 278 registered for each package. The string name is used as the PackageID 279 for text encoding. The serial number is used as the PackageID for 280 binary encoding. Public packages MUST be given serial numbers in the 281 range 0x0001 to 0x7fff. Private packages MUST be given serial 282 numbers in the range 0x8000 to 0xffff. Serial number 0 is reserved. 283 The unique string name and unique serial number MAY either be 284 requested by the package requester or if not requested, assigned by 285 the IANA. 287 2) The package requester shall provide a contact name, and an email 288 and postal addresses for that contact. The contact information shall 289 be updated by the defining organization as necessary. 291 3) The public package requester shall provide a reference to a 292 document that describes the package, which should be public: 294 a) The document shall specify the version of the package that it 295 describes. 297 b) If the document is public, it should be located on a public web 298 server and should have a stable URL. The site should provide a 299 mechanism to provide comments and appropriate responses should be 300 returned. 302 c) If the document is not public, it must be made available for 303 review by the IESG appointed Expert (without requiring an NDA) at the 304 time of the application. 306 Note: The document does not have to be publicly available at the time 307 of the registration request, however the document shall be provided 308 and available for review by the IESG appointed Expert. Once approved 309 by a standards body the package SHOULD be made publicly available 310 however the package MAY remain not public. 312 For private packages a contact email address for the package 313 registration shall be provided. 315 4) Packages registered by other than recognized standards bodies 316 shall have a minimum package name length of 8 characters. 318 5) Package names are allocated on a first come-first served basis if 319 all other conditions are met. 321 Status - "In Progress" indicates that the package has not been fully 322 reviewed and approved therefore may contain errors or may not be 323 consistent with H.248 principles. "Final" indicates that the Package 324 has been reviewed and approved and is stable. New packages shall be 325 registered with a status of "IP". Once the Package has been finalized 326 (i.e. approved according to the procedures of the Package Requester's 327 Organisation)they should contact IANA in order to update the status 328 to "Final". 330 Once the IESG Appointed Expert has determined that the registration 331 is appropriate they will advise the IANA to register the Package. 333 The IANA will assign a serial number to each package meeting the 334 conditions of registration (except for an update of an existing 335 package, which retains the serial number of the package it is 336 updating), in consecutive order of registration. 338 5.3. Error Code Registration Procedure 340 Error Code requesters shall send a request to the IANA to register 341 the error code. Documentation addressing the considerations below 342 shall be provided (i.e. Specification required as per [RFC5226]). The 343 IANA shall then forward the request to the IESG appointed Expert for 344 review. 346 The following considerations shall be met to register an error code 347 with IANA: 349 1) An error number and a one-line (80-character maximum) string are 350 registered for each error. 352 2) A complete description of the conditions under which the error is 353 detected shall be included in a publicly available document. The 354 description shall be sufficiently clear to differentiate the error 355 from all other existing error codes. 357 3) The document should be available on a public web server and should 358 have a stable URL. 360 4) Error numbers registered by recognized standards bodies shall have 361 3- or 4-character error numbers. 363 5) Error numbers registered by all other organizations or individuals 364 shall have 4-character error numbers. 366 6) Only the organization or individual that originally defined it (or 367 their successors or assigns) can modify an error number definition. 368 If the modification leads to a change in the error code number, error 369 code name or error string the Error Code modifier shall send a 370 request to IANA to register the update. This request shall be treated 371 as a new error code request which will involve an Expert review. 373 Once the IESG Appointed Expert has determined that the registration 374 is appropriate they will advise the IANA to register the Package. 376 5.4. ServiceChange Reason Registration Procedure 378 ServiceChange Reason requesters shall send a request to the IANA to 379 register the ServiceChange Reason. Documentation addressing the 380 considerations below shall be provided (i.e. Specification required 381 as per [RFC5226]). The IANA shall then forward the request to the 382 IESG appointed Expert for review. 384 The following considerations shall be met to register ServiceChange 385 reason with IANA: 387 1) A one-phrase, 80-character maximum, unique reason code is 388 registered for each reason. 390 2) A complete description of the conditions under which the reason is 391 used shall be included in a publicly available document. The 392 description shall be sufficiently clear to differentiate the reason 393 from all other existing reasons. 395 3) The document should be available on a public web server and should 396 have a stable URL. 398 Once the IESG Appointed Expert has determined that the registration 399 is appropriate they will advise IANA to register the Package. 401 5.5. Profile Name Registration Procedure 403 Profile Name requesters shall send a request to the IANA to register 404 the Profile Name. Documentation addressing the considerations below 405 shall be provided. The IANA shall then forward the request to the 406 IESG appointed Expert for review. 408 The following considerations shall be met to register a profile with 409 IANA: 411 1) A unique string name and version number (version may be omitted 412 when the profile name contains a wildcard) is registered for each 413 profile. 415 2) A contact name, email and postal addresses for that contact shall 416 be specified. The contact information shall be updated by the 417 defining organization as necessary. 419 3) Profiles registered by other than recognized standards bodies 420 shall have a minimum profile name length of 6 characters. 422 4) Profile names containing a wildcard "*" on the end of their names 423 shall be accepted if the first 6 characters are fully specified. It 424 is assumed that the organization that was issued with the profile 425 name will manage the namespace associated with the wildcard. IANA 426 shall not issue other profiles names within "name*" range. 428 All other profile names are first come-first served if all other 429 conditions are met. 431 Once the IESG Appointed Expert has determined that the registration 432 is appropriate they will advise IANA to register the Package. 434 6. IANA Considerations 436 This document describes an updated package registration procedure. 437 [RFC5226] has been considered in making the updates. This document 438 does not alter the tabular package, error code and service change 439 reason information in the Megaco/H.248 Packages registry. 441 The "Error Code", "ServiceChange Reason" and "Profile Name" IANA 442 considerations have been included for completeness. These 443 considerations align with the considerations documented in H.248.1 444 [H248amm1] and with [RFC3525] (with the exception of Profile Names 445 which did not appear in this version). 447 6.1. New IANA Package Registration 449 On the request for an initial or final Package registration the IANA 450 shall forward the received information (i.e. the Package Text 451 (Specification required as per [RFC5226]) to the IESG appointed 452 expert for review (See section 4.2). 454 After the review when instructed by the IESG appointed Expert the 455 IANA shall register the following information in the "Megaco/H.248 456 Packages" registry as described below: 458 1. Serial Number (Identity used for Binary Encoding, also known as 459 Binary ID) 461 2. Text Name (Identity used for Text Encoding, see section 3 for the 462 syntax) 464 3. Package version 466 4. Extension information - Binary ID and package version 468 5. Status* - IP ("In Progress") or Final 470 6. Package name, Reference and Contact information 472 IANA will maintain the currency and public availability of the 473 tabulation of public and private packages. Packages will be listed 474 in increasing order of serial number. The latest Package version is 475 entered, replacing the previous version in the registry. 477 6.2. IANA Error Code Registration 479 On the request for an Error Code registration, the IANA shall forward 480 the received information (i.e. the Error Code text (Specification 481 required) to the IESG appointed expert for review (See section 4.3). 483 When instructed by the IESG appointed Expert the IANA shall register 484 the following information in the "Megaco/H.248 Packages" registry as 485 described below: 487 1. Error Code Number 489 2. Error Code Text String 491 3. Reference 493 6.3. IANA ServiceChange Reason Registration 495 On the request for an Error Code registration, the IANA shall forward 496 the received information (i.e. the Service Change Reason text and 497 required specification) to the IESG appointed expert for review (See 498 section 4.4). 500 When instructed by the IESG appointed Expert the IANA shall register 501 the following information in the "Megaco/H.248 Packages" registry as 502 described below: 504 1. ServiceChange Reason Number 505 2. ServiceChange Reason Text String 507 3. Reference 509 6.4. IANA Profile Name Registration 511 On the request for a Profile Name registration, the IANA shall 512 forward to received request to the IESG appointed expert for review 513 (See section 4.5). 515 When instructed by the IESG appointed Expert the IANA shall register 516 the following information in the "Megaco/H.248 Packages" registry as 517 described below: 519 1. Profile Name 521 2. Version 523 3. Reference/Contact 525 7. References 527 7.1. Normative References 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, March 1997. 532 [RFC5234] Crocker, D. and Overell, P., "Augmented BNF for Syntax 533 Specifications: ABNF", RFC 5234, January 2008. 535 [H248amm1] International Telecommunication Union, "Gateway control 536 protocol: Version 3", Amendment 1 to ITU-T Recommendation 537 H.248.1, April 2008. 539 7.2. Informative References 541 [RFC3525] Groves C., Pantaleo M., Anderson T. and Taylor T., "Gateway 542 Control Protocol Version 1", RFC 3525, June 2003. 544 [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC 545 5125, February 2008. 547 [RFC5226] Narten, T. and Alvestrand, H., "Guidelines for Writing an 548 IANA Considerations Section in RFCs", BCP26, RFC 5226, May 549 2008. 551 8. Acknowledgments 553 This document was prepared using 2-Word-v2.0.template.dot. 555 Authors' Addresses 557 Christian Groves 558 NTEC Australia 559 Newport, Victoria 560 Australia 562 Email: Christian.Groves@nteczone.com 563 Yangbo Lin 564 Huawei Technologies Co., Ltd. 565 Shenzhen, Guangdong 566 P. R. China 568 Email: linyangbo@huawei.com