idnits 2.17.1 draft-eastlake-iana-cfm-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (May 22, 2014) is 3626 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Donald Eastlake 3rd 2 Internet-Draft Huawei 3 Intended Status: Best Current Practice 4 Expires: November 21, 2014 May 22, 2014 6 IANA Considerations for CFM (Connectivity Fault Management) Code Points 7 9 Status of This Document 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 This document is intended to become a Best Current Practice. 15 Distribution of this document is unlimited. Comments should be sent 16 to the author. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 30 Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 IEEE 802.1 has specified Connectivity Fault Management (CFM) OAM 36 facilities. CFM messages are structured with an OpCode field and have 37 provision for the inclusion of TLV (type, length, value) structured 38 information. IEEE 802.1 has allocated blocks of CFM OpCodes and TLV 39 Types to the IETF. This document specifies the IANA Considerations 40 for the assignment of values from these blocks. 42 Table of Contents 44 1. Introduction............................................3 45 1.1 Terminology............................................3 47 2. IANA Considerations.....................................4 48 3. Security Considerations.................................4 50 Normative References.......................................5 51 Informative References.....................................5 52 Author's Address...........................................5 54 Appendix A: IEEE 802.1 WG Liaison..........................6 56 1. Introduction 58 The IEEE 802.1 Working Group has specified Connectivity Fault 59 Management (CFM) [802.1Q] OAM [RFC6291] facilities. CFM messages are 60 structured with an OpCode field and have provision for the inclusion 61 of TLV (type, length, value) structured information. 63 IEEE 802.1 has allocated the block of 32 CFM OpCodes from 64 through 64 95 and the block of 32 CFM TLV Types from 64 through 95 to the IETF 65 (see Appendix A). This document specifies the IANA Considerations for 66 the assignment of values from these two blocks. 68 IEEE 802.1 previously allocated similar blocks of the values from 32 69 through 63 to ITU-T [Y.1731]. 71 1.1 Terminology 73 Capitalized IANA Considerations terms such as "Standards Action" are 74 to be interpreted as described in [RFC5226]. 76 2. IANA Considerations 78 IANA is requested to create a "CFM OAM IETF Parameters" Registry with 79 two registries as follows: 81 Registry Name: CFM OAM IETF OpCodes 83 Registration Procedures: Standards Action 85 Reference: [802.1Q] [this document] 87 Note: This parameter originates with the IEEE 802.1 Working 88 Group that has allocated the block of values from 64 to 95 to 89 the IETF. 91 Value Assignment Reference 92 ===== ========== ========= 93 64-95 Unassigned [this document] 95 Registry Name: CFM OAM IETF TLV Types 97 Registration Procedures: Standards Action 99 Reference: [802.1Q] [this document] 101 Note: This parameter originates with the IEEE 802.1 Working 102 Group that has allocated the block of values from 64 to 95 to 103 the IETF. 105 Value Assignment Reference 106 ===== ========== ========= 107 64-95 Unassigned [this document] 109 3. Security Considerations 111 This document is concerned with assignment of values from the blocks 112 of IEEE 802.1 CFM OpCodes and TLV Types that the IEEE 802.1 Working 113 Group has allocated to the IETF. It is not directly concerned with 114 security. 116 Normative References 118 [802.1Q] - "IEEE Standard for Local and metropolitan area networks / 119 Media Access Control (MAC) Bridges and Virtual Bridge Local 120 Area Networks", IEEE Std 802.1Q-2011, 31 August 2011. 122 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 123 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 124 2008. 126 Informative References 128 [RFC6291] - Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 129 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 130 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 132 [Y.1731] - ITU-T Recommendation G.8013/Y.1731, "OAM Functions and 133 Mechanisms for Ethernet-based Networks", July 2011. 135 Author's Address 137 Donald Eastlake 3rd 138 Huawei 139 155 Beaver Street 140 Milford, MA 01757 USA 142 tel: +1-508-333-2270 143 email: d3e3e3@gmail.com 145 Appendix A: IEEE 802.1 WG Liaison 147 To: Jari Arkko, IETF chair 148 cc: Stephen J. Trowbridge, ITU-T SG15 chair, 149 Donald Eastlake, Erik Nordmark, IETF TRILL WG, 150 Eric Gray, IETF/IEEE liaison 152 From: Tony Jeffree, IEEE 802.1 WG Chair 154 Date: Thursday, 06 March 2014 156 Reference: 24 September 2013 Liaison from TRILL WG 158 After considering the referenced liaison from the TRILL WG, 159 IEEE 802.1 has voted to approve the allocation of code points 160 from the Connectivity Fault Management protocol of IEEE Std 161 802.1Q(TM)-2011 for use by IETF. The expectation of IEEE 162 802.1 is that these code points will be allocated through 163 IANA only on the basis of IETF standards actions. 164 Specifically, the allocation includes: 166 + 32 CFM OpCode Field values. Reference IEEE Std 802.1Q-2011 168 Clause 21.4.3, Table 21-4. The OpCode Field values 64-95 169 10 170 are allocated to the IETF. 172 + 32 TLV Type Field values. Reference IEEE Std 802.1Q-2011 174 Clause 21.5.1.1, Table 21-6. The Type Field values 64-95 175 10 176 are allocated to the IETF. 178 IEEE Std 802.1Q will be revised at some future date to document this 179 allocation. In the meantime, the allocation will be recorded through 180 the IEEE 802.1 maintenance process. 182 Regards, 184 Tony Jeffree 185 IEEE 802.1 Working Group Chair 187 Copyright and IPR Provisions 189 Copyright (c) 2014 IETF Trust and the persons identified as the 190 document authors. All rights reserved. 192 This document is subject to BCP 78 and the IETF Trust's Legal 193 Provisions Relating to IETF Documents 194 (http://trustee.ietf.org/license-info) in effect on the date of 195 publication of this document. Please review these documents 196 carefully, as they describe your rights and restrictions with respect 197 to this document. Code Components extracted from this document must 198 include Simplified BSD License text as described in Section 4.e of 199 the Trust Legal Provisions and are provided without warranty as 200 described in the Simplified BSD License.