idnits 2.17.1 draft-arkko-pana-iana-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5191, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5191, updated by this document, for RFC5378 checks: 2003-04-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2010) is 5177 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Updates: 5191 (if approved) A. Yegin 5 Intended status: Standards Track Samsung 6 Expires: August 20, 2010 February 16, 2010 8 IANA Rules for PANA (Protocol for Carrying Authentication for Network 9 Access) 10 draft-arkko-pana-iana-02 12 Abstract 14 This document relaxes the IANA rules for the Protocol for Carrying 15 Authentication for Network Access (PANA). 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 20, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 1. Introduction 57 This document relaxes the IANA rules for the Protocol for Carrying 58 Authentication for Network Access (PANA) [RFC5191]. Rules for the 59 following protocol fields, all defined in [RFC5191], are affected: 61 o Message Type 63 o Message Flags 65 o Attribute-Value Pair (AVP) Flags 67 o Result-Code AVP Value 69 o Termination-Cause AVP Value 71 The rationale for this update is that there can be situations where 72 it makes sense to grant an allocation under special circumstances. 73 At the time of writing this, one such allocation is currently in the 74 approval process at the IETF. By changing the current IANA rules to 75 allow also for IESG Approval [RFC5226], it becomes possible for the 76 Internet Engineering Steering Group (IESG) to consider an allocation 77 request, even if it does not fulfill the default rule. For instance, 78 an experimental protocol extension could perhaps deserve an 79 allocation from a field of reserved bits, as long as a sufficient 80 number of bits still remains for other purposes, and the PANA 81 community is happy with such an allocation. 83 2. IANA Considerations 85 IANA is requested to updated the registries related to PANA Message 86 Types, Message Flags, AVP Flags, Result-Code AVP Values, and 87 Termination-Cause AVP Values as specified below. All other PANA IANA 88 registries are to remain unchanged. 90 2.1. Message Type 92 The Message Type namespace is used to identify PANA messages. 93 Message Type 0 is not used and is not assigned by IANA. The range of 94 values 1 - 65,519 are for permanent, standard message types, 95 allocated by IETF Review or IESG approval [RFC5226]. Previously, the 96 rule for this range was allocation by IETF Review only. [RFC5191] 97 defined the range of values 1 - 4. The same Message Type is used for 98 both the request and the answer messages, except for type 1. The 99 Request bit distinguishes requests from answers. 101 The range of values 65,520 - 65,535 (hexadecimal values 0xfff0 - 102 0xffff) are reserved for experimental messages. As these codes are 103 only for experimental and testing purposes, no guarantee is made for 104 interoperability between the communicating PANA Client (PaC) and PANA 105 Authentication Agent (PAA) using experimental commands, as outlined 106 in [RFC3692]. 108 2.2. Message Flags 110 There are 16 bits in the Flags field of the PANA message header. 111 Section 6.2 of [RFC5191] assigned bit 0 ('R'), 1 ('S'), 2 ('C'), 3 112 ('A'), 4 ('P'), and 5 ('I'). Allocations from the remaining free 113 bits in the PANA header Flag field are done via Standards Action or 114 IESG Approval [RFC5226]. Previously, the rule for these bits was 115 allocation by Standards Action only. 117 2.3. AVP Flags 119 There are 16 bits in the AVP Flags field of the AVP header, defined 120 in Section 6.3 of [RFC5191]. That RFC also assigned bit 0 ('V'). 121 The remaining bits are assigned via a Standards Action or IESG 122 Approval [RFC5226]. Previously, the rule for these bits was 123 allocation by Standards Action only. 125 2.4. Result-Code AVP Values 127 As defined in Section 8.7 of [RFC5191], the Result-Code AVP (AVP Code 128 7) defines the values 0-2. 130 All remaining values are available for assignment via IETF Review or 131 IESG Approval [RFC5226]. Previously, the rule for these bits was 132 allocation by IETF Review only. 134 2.5. Termination-Cause AVP Values 136 As defined in Section 8.9 of [RFC5191], the Termination-Cause AVP 137 (AVP Code 9) defines the values 1, 4, and 8. 139 All remaining values are available for assignment via IETF Review or 140 IESG Approval [RFC5226]. Previously, the rule for these bits was 141 allocation by IETF Review only. 143 3. Security Considerations 145 This specification does not change the security properties of PANA. 147 However, a few words are necessary about the use of the experimental 148 code points defined in Section 2.1. Potentially harmful side-effects 149 from the use of the experimental values needs to be carefully 150 evaluated before deploying any experiment across networks that the 151 owner of the experiment does not entirely control. Guidance given in 152 [RFC3692] about the use of experimental values needs to be followed. 154 4. References 156 4.1. Normative References 158 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 159 Yegin, "Protocol for Carrying Authentication for Network 160 Access (PANA)", RFC 5191, May 2008. 162 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 163 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 164 May 2008. 166 4.2. Informative References 168 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 169 Considered Useful", BCP 82, RFC 3692, January 2004. 171 Appendix A. Changes from RFC 5191 173 This document changes the IANA rules for the Message Type, Message 174 Flags, AVP Flags, Result-Code AVP Value, and Termination-Cause AVP 175 Value. 177 Appendix B. Acknowledgments 179 The authors would like to thank Yoshihiro Ohba, Ralph Droms, Magnus 180 Westerlund, and Alfred Hoenes for reviews and comments on this topic. 182 Authors' Addresses 184 Jari Arkko 185 Ericsson 186 Jorvas 02420 187 Finland 189 Email: jari.arkko@piuha.net 191 Alper Yegin 192 Samsung 193 Istanbul 194 Turkey 196 Email: alper.yegin@yegin.org