idnits 2.17.1 draft-lha-krb-wg-some-numbers-to-iana-00.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 RFC4120, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4121, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1964, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3961, 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 RFC1964, updated by this document, for RFC5378 checks: 1996-06-01) -- 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 (March 23, 2010) is 5148 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Hornquist Astrand 3 Internet-Draft Apple, Inc 4 Updates: 1964, 3961, 4120, 4121 March 23, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: September 24, 2010 9 Kerberos number registry to IANA 10 draft-lha-krb-wg-some-numbers-to-iana-00 12 Abstract 14 Kerberos have many registers where only some have been registered, 15 this document tries to cover the rest of them. There is a private 16 space but that can not be used for implementation in released 17 software. Also private is not avaible for all types. This document 18 moves control over the numbers to an IANA number registerty. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 24, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Registration procedures . . . . . . . . . . . . . . . . . . . 5 63 4. Authorization Data Types . . . . . . . . . . . . . . . . . . . 6 64 5. Key Usage Numbers . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Address types . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Transited Encoding Types . . . . . . . . . . . . . . . . . . . 9 67 8. Name Types . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 12. Normative References . . . . . . . . . . . . . . . . . . . . . 14 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Requirements Notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Background 82 [RFC4120] and other draft, RFC and private documents currently 83 defines uses of Kerberos protocol numbers, after serveral confusions 84 and collisions in shipped code its time to move them to an IANA 85 registerty. 87 3. Registration procedures 89 A Kerberos number registration have the same "Registration 90 procedures" for number based registration. 92 Exceptions are: Error codes and Key Usage Numbers. 94 o 0-65536: Specification Required, expert review (krb-wg mailing- 95 list) that the specification is implementable in an interopable 96 manner 98 o 65536 and higher: first come, first serve 100 4. Authorization Data Types 102 Tom, please contribute the your list here. 104 5. Key Usage Numbers 106 Special considerations for key usage numbers in addition to what 107 rules in specified in "Registration procedures". 109 Odd numbers SHOULD be allocated to checksums operations Even numbers 110 SHOULD be allocated to encryption operations 112 Tom, please contribute the your list here. 114 6. Address types 116 Tom, please contribute the your list here. 118 7. Transited Encoding Types 120 Tom, please contribute the your list here. 122 8. Name Types 124 Tom, please contribute the your list here. 126 9. Error codes 128 Error codes may only be registered with Standards action. 130 Tom, please contribute the your list here. 132 10. Security Considerations 134 There is no security consideration, this documents move control over 135 the registry to IANA. 137 11. IANA Considerations 139 This create a number of registries. 141 12. Normative References 143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 144 Requirement Levels", BCP 14, RFC 2119, March 1997. 146 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 147 Kerberos Network Authentication Service (V5)", RFC 4120, 148 July 2005. 150 Author's Address 152 Love Hornquist Astrand 153 Apple, Inc 154 Cupertino 155 USA 157 Email: lha@apple.com