|
1.
|
Clear description of the referenced document:
|
|
|
|
|
2.
|
Status of approval:
|
|
|
The referred RFC was approved 2014-06 by IESG (Internet Engineering Steering Group)
|
|
3.
|
Justification for the specific reference:
|
|
|
G.8112 refers to the terminology defined in RFC 7213
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
IETF IPR archives at http://www.ietf.org/ipr.html
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
The status of the referred RFC is "Proposed Standard".
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
The status of the referred RFC is "Proposed Standard". No errata exist.
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
References within the referenced RFC are listed under item (8).
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
[EUI-64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", March 1997,http://standards.ieee.org/regauth/oui/tutorials/EUI64.html./
[LLDP] IEEE, "Station and Media Access Control Connectivity Discovery", IEEE 802.1AB, September 2009./
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997./
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001./
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008./
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009./
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS TransportProfile Data Plane Architecture", RFC 5960, August 2010./
[RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS GenericAssociated Channel (G-ACh) Advertisement Protocol", RFC7212, June 2014./
|
|
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):
|
|
|
Reference should always be made by RFC number (and not by other designations such as STD, BCP, etc.). References should not be made to documents referred to as "Internet Drafts" or to IETF RFCs categorized as Historic or Experimental. Normative references must only be made to IETF RFCs that are Standards Track or to Informational RFCs that have IETF consensus.
|
|
