|
1.
|
Clear description of the referenced document:
|
|
|
|
Name:
|
IETF RFC 3513 (2003)
|
|
Title:
|
Internet Protocol Version 6 (IPv6) Addressing Architecture, IETF RFC, 2003.
|
|
|
2.
|
Status of approval:
|
|
|
The referred RFCs were approved by IESG (Internet Engineering Steering Group).
|
|
3.
|
Justification for the specific reference:
|
|
|
Draft Rec. X.websec-1 can use Internet Protocol Version 6 (IPv6) Addressing Architecture Facilities as discussed in [18] as a means of loose coupling.
|
|
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=3513
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
The status of all the referred RFCs, is "Proposed Standard".
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
The status of all the referred RFCs, is "Proposed Standard".
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
References within the referenced RFCs are listed under item (8).
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative References/
/
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6/
(IPv6) Specification", RFC 2460, December 1998./
/
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision/
3", BCP 9 , RFC 2026, October 1996./
/
Informative References/
/
[ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting/
Service", RFC 1546, November 1993./
/
[AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC/
2402, November 1998./
/
[AGGR] Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable/
Global Unicast Address Format", RFC 2374, July 1998./
/
[CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless/
Inter-Domain Routing (CIDR): An Address Assignment and/
Aggregation Strategy", RFC 1519, September 1993./
/
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet/
Networks", RFC 2464, December 1998./
/
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)/
Registration Authority",/
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,/
March 1997./
/
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI/
Networks", RFC 2467, December 1998./
/
[MASGN] Hinden, R. and S. Deering, "IPv6 Multicast Address/
Assignments", RFC 2375, July 1998./
/
[NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J./
and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996./
/
[PRIV] Narten, T. and R. Draves, "Privacy Extensions for Stateless/
Address Autoconfiguration in IPv6", RFC 3041, January 2001./
/
[TOKEN] Crawford, M., Narten, T. and S. Thomas, "Transmission of/
IPv6 Packets over Token Ring Networks", RFC 2470, December/
1998./
[TRAN] Gilligan, R. and E. Nordmark, "Transition Mechanisms for/
IPv6 Hosts and Routers", RFC 2893, August 2000./
/
|
|
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):
|
|
|
None
|
|
