|
1.
|
Clear description of the referenced document:
|
|
|
|
|
2.
|
Status of approval:
|
|
|
Approved
|
|
3.
|
Justification for the specific reference:
|
|
|
H.235 Annex G references RFC 3830 as the (MIKEY) key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, the MIKEY key management protocol and its variants to support the Secure Real-time Transport Protocol.
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3830
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
RFC 3830 has been in existence since 2004. This text is a Proposed Standard. These documents have been reviewed extensively in IETF.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
RFC is a standards-track document and is currently in the "Proposed Standard" state. Current standards status of this document can be found at ftp://ftp.isi.edu/in-notes/std/std1.txt
Updated by: RFC 4738, 6309
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
RFC 3830 defines the MIKEY key management protocol and is expected to be widely used.
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997./
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999./
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998./
[PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories, June 14, 2002, www.rsalabs.com/
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997./
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998./
[SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995./
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March 2004./
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998./
[X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002./
[AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
|
|
9.
|
Qualification of
ISOC/IETF:
|
|
|
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).
9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.
9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
|
|
10.
|
Other (for any supplementary information):
|
|
|
References should always be made to RFC numbers (and not by other designations such as STD, BCP, etc.). References not to be made to documents referred to as "Internet Drafts" or RFCs categorized as "Historic". Normative references should not be made to RFCs that are not standards, for example, "Informational" and "Experimental" RFCs.
|
|
