One document matched: draft-groves-megaco-pkgereg-01.txt
Differences from draft-groves-megaco-pkgereg-00.txt
Network Working Group C. Groves
Internet Draft NTEC Australia
Intended status: BCP Y. Lin
Expires: September 2008 Huawei
March 12, 2008
H.248/MEGACO Package Registration Procedures
draft-groves-megaco-pkgereg-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 12, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document updates the H.248/MEGACO IANA Package Registration
procedures in order to better describe the Package registration
process and to provide a more formal review and feedback process.
Groves Expires September 12, 2008 [Page 1]
Internet-Draft Package Registration Procedures March 2008
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents
1. Introduction ....................................... 2
2. Updated Package Registration Procedures .................. 4
3. Formal Syntax ....................................... 6
4. Security Considerations ............................... 6
5. IANA Considerations .................................. 6
5.1. New IANA Package Registration Text .................. 7
6. Acknowledgments ..................................... 9
7. References ........................................ 10
7.1. Normative References ............................ 10
7.2. Informative References........................... 10
Author's Addresses .................................... 10
Intellectual Property Statement .......................... 10
Disclaimer of Validity ................................. 11
1. Introduction
Since the initial development of H.248/MEGACO a number of
organizations have made use of the H.248/MEGACO protocol Package
mechanism in order to allow a certain function to be controlled by
H.248/MEGACO. The H.248/MEGACO package mechanism was in part
introduced to allow organizations who had an in depth knowledge in a
particular functional area to independently produce a package on this
functionality. This acknowledged the fact that neither the IETF
MEGACO Working Group nor the ITU-T Study Group 16 possessed in depth
knowledge in all areas. Whilst this approach has been successful in
the number and range of packages produced, in some cases these
Packages were/are not fully aligned with H.248/MEGACO principles.
Once a Package has been published and registered it is problematic to
rectify any issues.
The introduction of problems/inconsistencies was in part caused by
the fact that the Packages were not fully reviewed by H.248/MEGACO
experts. In fact the IANA H.248/MEGACO registration process did not
actually specify that an in depth review should take place.
The current H.248/MEGACO Package registration process was defined
when ITU-T Study Group 16 and the IETF Megaco Working Groups were
both active in Megaco/H.248 standardization and produced nearly all
Groves Expires September 12, 2008 [Page 2]
Internet-Draft Package Registration Procedures March 2008
the registered Packages. Packages were reviewed in the IETF MEGACO
Working Group and the Working Group chair was the IESG appointed
expert in charge of the review of the requests for H.248 Package
registration. This meant that H.248 Packages under went an informal
review before being registered. However this has changed.
The current situation is that now the IETF Megaco working group is
disbanded and new H.248/MEGACO development occurs through Question 3
of ITU-T Study Group 16 only (not withstanding email discussion on
the IETF MEGACO mailing list). This move to ITU-T defined
Recommendations is discussed in [RFC5125].
Given this situation, it is appropriate that the H.248/Package
Package definition and IANA registration rules are updated to
introduce a formal review step before the Package registration
process is completed and ideally before the Package is published.
This process would only be applicable to public Packages.
As part of the Package development process Package developers are
encouraged to send their Package for review to the ITU-T Study Group
Question Rapporteur responsible for the H.248 sub-series (Question 3
of Study Group 16 at the time of writing). When registering the
Package with IANA, package developers are required to send a copy of
the package for review by the IESG appointed expert. It is
recommended to register the Package before final approval by the
group in question in order to solicit feedback on the quality of
their Package. Where ever possible this review will be done in
conjunction with other H.248/MEGACO experts (e.g. in Q.3/16 and/or
the MEGACO mailing list).
The existing IANA Package registration process is a two step process.
When Packages are first registered they receive the status of "In
Progress (IP)". This allows Package developers to request a PackageID
before the document is fully approved. When the document is approved
then a change of status to "Final", may be requested. The new
procedure introduces the step that the IESG appointed expert is
consulted before a change of status is made. If the Package has been
reviewed and is acceptable then the status may be changed to "Final".
However if the package has not been provided for review or it has
outstanding comments then the status shall remain at "IP".
The goal of the updated text is to define a process that provides a
timely technical review of packages to ensure that H.248/MEGACO
packages are of good quality and minimize duplication.
Groves Expires September 12, 2008 [Page 3]
Internet-Draft Package Registration Procedures March 2008
2. Updated Package Registration Procedures
Amendment 1 to ITU-T Recommendation H.248.1v3 introduces the new
H.248 Package registration procedures in clause 14. These new
procedures are detailed below:
14 IANA considerations
14.1 Packages
The following considerations shall be met to register a package with
IANA:
1) A unique string name, unique serial number and version number is
registered for each package. The string name is used as the PackageID
for text encoding. The serial number is used as the PackageID for
with binary encoding. Serial Numbers 0x8000 to 0xFFFF are reserved
for private use. Serial number 0 is reserved. The unique string name
and unique serial number may be requested by the package requestor or
assigned by IANA.
2) The package requestor shall provide a contact name, email and
postal addresses for that contact shall be specified. The contact
information shall be updated by the defining organization as
necessary.
3) The package requestor shall provide a reference to a document that
describes the package, which should be public:
The document shall specify the version of the package that it
describes.
If the document is public, it should be located on a public web
server and should have a stable URL. The site should provide a
mechanism to provide comments and appropriate responses should be
returned.
If the document is not public, it must be made available for IESG
appointed Expert review at the time of the application.
4) IANA shall ensure that packages registered by other than
recognized standards bodies shall have a minimum package name length
of 8 characters.
5) IANA shall ensure that package names are allocated on a first
come-first served if all other conditions are met.
Groves Expires September 12, 2008 [Page 4]
Internet-Draft Package Registration Procedures March 2008
If the above five criteria are met then IANA shall register the
following information in the registry as described below:
1. Binary ID (or serial number)
2. Text ID
3. Package version
4. Extension information - Binary ID and package version
5. Status - IP ("In Progress") or Final. "In Progress" indicates that
the package has not been fully reviewed and approved therefore may
contain errors or may not be consistent with H.248 principles.
"Final" indicates that the Package has been reviewed and approved and
is stable.
6. Package name, Reference and Contact information
The documenting text does not have to be publicly available at the
time of the registration request, however the text shall be provided
to the IESG appointed expert for review at the time of application.
IANA shall register new packages with a status of "IP". Package
requestors are encouraged to request registration as early as
practicable in the design process, to reserve a binary ID. Binary
IDs shall be published in the document defining the package.
Package requestors for non-private packages under development shall
send the package text to IANA. They are also encouraged to send the
package to the ITU-T Study Group/Question responsible for the H.248
sub-series of Recommendations (Q.3/16 at the time of writing) for
review. These should occur as soon as practicable after the rough
draft of the definition is completed and at least before the package
is approved in order to ensure the package is consistent with H.248
methodologies and package design principles. The IANA shall forward
the Package to the IESG appointed Expert for review. During the
review the input package will be compared to the Package template for
completeness, as well as being compared against protocol syntax and
procedures. It will be compared against existing work to see that it
doesn't duplicate existing functionality. The Expert reviewer will
then work towards a resolution of any issues with the Package
requestor. The IESG appointed Expert may complete the review in
consultation with other H.248 experts (i.e. Question 3 of ITU-T Study
Group 16). If the package is deemed suitable, the IESG appointed
Expert shall issue a statement indicating approval, copied to IANA.
Groves Expires September 12, 2008 [Page 5]
Internet-Draft Package Registration Procedures March 2008
Once the package is complete, IANA shall be notified of the
completion of the package by the group developing the package. Upon
receipt of this notification, IANA shall notify the IESG appointed
Expert, and if the Package has been reviewed and the comments
addressed the package is deemed to be approved.
If the IESG appointed Expert responds to IANA's update notification
with an approval indication, IANA shall update the status to "Final".
If the IESG appointed Expert responds that the package has not been
reviewed, or was deemed unsuitable, IANA shall alter the status back
to "IP". In either case, IANA shall notify the developing group of
the outcome of the status update.
A package shall not be set to status "Final" without the express
approval of the IESG appointed Expert.
3. Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-5234 [RFC5234].
Text encoded PackageIDs shall conform to the "PackageName" encoding
in H.248.1 [H248Amm1] Annex B. Repeated below for convienience:
PackageName = NAME
NAME = ALPHA *63(ALPHA / DIGIT / "_")
Note: A digit is not allowed as the first character of a package
name.
4. Security Considerations
Updating the IANA H.248/MEGACO package registration procedures has no
additional security implications. Security for the H.248/MEGACO
protocol is discussed in H.248.1 section 10. Requestors for public
packages for a particular standards development organization must be
authorized by that organization to request a Package registration.
5. IANA Considerations
This document describes an updated package registration procedure.
RFC-2434 [RFC2434] has been considered in making the updates. This
document does not alter the tabular package, error code and service
change reason information at: http://www.iana.org/assignments/megaco-
h248 . As such only a change to the header information on packages is
required.
Groves Expires September 12, 2008 [Page 6]
Internet-Draft Package Registration Procedures March 2008
5.1. Appointment of the IESG H.248/MEGACO Expert
The IESG shall remain responsible for allocating the H.248/MEGACO
expert. It is recommended that this person be involved in ongoing
H.248/MEGACO development. As such it is recommended that
identification of the IESG expert be done in consultation with the
ITU-T Study Group/Question responsible for the H.248 sub-series of
Recommendations. Q.3/16 at the time of writing.
5.2. New IANA Package Registration Text
The IANA will assign a serial number to each package meeting the
conditions of registration (except for an update of an existing
package, which retains the serial number of the package it is
updating), in consecutive order of registration.
The following considerations shall be met to register a package with
the IANA:
1) A unique string name, unique serial number and version number is
registered for each package. The string name is used as the PackageID
for text encoding. The serial number is used as the PackageID for
binary encoding. Public packages MUST be given serial numbers in the
range 0x0001 to 0x7fff. Private packages MUST be given serial
numbers in the range 0x8000 to 0xffff. Serial number 0 is reserved.
The unique string name and unique serial number may be requested by
the package requestor or assigned by the IANA.
2) The package requestor shall provide a contact name, email and
postal addresses for that contact shall be specified. The contact
information shall be updated by the defining organization as
necessary.
3) The package requestor shall provide a reference to a document that
describes the package, which should be public:
a) The document shall specify the version of the package that it
describes.
b) If the document is public, it should be located on a public web
server and should have a stable URL. The site should provide a
mechanism to provide comments and appropriate responses should be
returned.
c) If the document is not public, it must be made available for
review by the IESG appointed Expert at the time of the application.
Groves Expires September 12, 2008 [Page 7]
Internet-Draft Package Registration Procedures March 2008
4) The IANA shall ensure that packages registered by other than
recognized standards bodies shall have a minimum package name length
of 8 characters.
5) The IANA shall ensure that package names are allocated on a first
come-first served if all other conditions are met.
If the above five criteria are met then the IANA shall register the
following information in the registry as described below:
1. Binary ID (or serial number)
2. Text ID - See RFCXXXX (Editor's note please insert the ID of this
document) section 3 for the syntax.
3. Package version
4. Extension information - Binary ID and package version
5. Status* - IP ("In Progress") or Final.
6. Package name, Reference and Contact information
Status - "In Progress" indicates that the package has not been fully
reviewed and approved therefore may contain errors or may not be
consistent with H.248 principles. "Final" indicates that the Package
has been reviewed and approved and is stable.
The documenting text does not have to be publicly available at the
time of the registration request, however the text shall be provided
available for review by the IESG appointed Expert at the time of
application. IANA shall register new packages with a status of "IP".
Package requestors are encouraged to request registration as early as
practicable in the design process, to reserve a binary ID. Binary
IDs shall be published in the document defining the package.
Package requestors for non-private packages under development shall
send the package text to IANA. They are also encouraged to send the
package to the ITU-T Study Group/Question responsible for the H.248
sub-series of Recommendations (Q.3/16 at the time of writing) for
review. This should occur as soon as practicable after the rough
draft of the definition is completed and at least before the package
is approved in order to ensure the package is consistent with H.248
methodologies and package design principles. The IANA shall forward
the Package to the IESG appointed Expert for review. During the
review the input package will be compared to the Package template for
completeness, as well as being compared against protocol syntax and
Groves Expires September 12, 2008 [Page 8]
Internet-Draft Package Registration Procedures March 2008
procedures. It will be compared against existing work to see that it
doesn't duplicate existing functionality. The Expert reviewer will
then work towards a resolution of any issues with the Package
requestor. The IESG appointed Expert may complete the review in
consultation with other H.248 experts (i.e. Question 3 of ITU-T Study
Group 16). If the package is deemed suitable, the IESG appointed
Expert shall issue a statement indicating approval, copied to IANA.
H.248.1 Amendment 1 [H248Amm1] section 14 and RFCxxxx (Editor's
note:a reference to this document) section 2.contain details of this
review procedure
IANA will maintain the currency and public availability of the
tabulation of public and private packages. Packages will be listed
in increasing order of serial number. Updates to packages will be
listed in increasing order of version number.
6. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Groves Expires September 12, 2008 [Page 9]
Internet-Draft Package Registration Procedures March 2008
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D. and Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[H248Amm1] International Telecommunication Union, "Gateway control
protocol: Version 3", Amendment 1 to ITU-T Recommendation
H.248.1, July 2007.
7.2. Informative References
[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", RFC
5125, February 2008.
[RFC2434] Narten, T. and Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP26, RFC 2434,
October 1998.
Authors' Addresses
Christian Groves
NTEC Australia
Newport, Victoria
Australia
Email: Christian.Groves@nteczone.com
Yangbo Lin
Huawei Technologies Co., Ltd.
Shenzhen, Guangdong
P. R. China
Email: linyangbo@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
Groves Expires September 12, 2008 [Page 10]
Internet-Draft Package Registration Procedures March 2008
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 procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general 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
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Groves Expires September 12, 2008 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 05:53:32 |