IANA considerations in RFC 2538bis
Simon Josefsson <jas@extundo.com> Thu, 12 January 2006 17:02 UTC
From: Simon Josefsson <jas@extundo.com>
Subject: IANA considerations in RFC 2538bis
Date: Thu, 12 Jan 2006 18:02:13 +0100
Lines: 132
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-From: owner-namedroppers@ops.ietf.org Thu Jan 12 18:13:38 2006
Return-path: <owner-namedroppers@ops.ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.0
To: namedroppers@ops.ietf.org
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:21:060112:namedroppers@ops.ietf.org::4M6dhRsZUsDVRYXs:08Wr
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)
X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com
X-Virus-Status: Clean
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072125.2560.58840.ARCHIVE@ietfa.amsl.com>
Dear WG: The IANA found problems in RFC 2538bis. Below is some discussion about this, and my proposal to fix things. If there are no objections to my proposal I will send my proposal to the IANA on January 20 00:00:00 CET and make sure the document is updated correspondingly during AUTH48. I've co-ordinated the size of this time window with the WG chairs. The IANA considerations in 2538bis reads: Decimal Type Meaning Reference ------- ---- ------- --------- 0 Reserved RFC xxxx 1 PKIX X.509 as per PKIX RFC xxxx 2 SPKI SPKI certificate RFC xxxx 3 PGP OpenPGP packet RFC xxxx 4 IPKIX The URL of an X.509 data object RFC xxxx 5 ISPKI The URL of an SPKI certificate RFC xxxx 6 IPGP The URL of an OpenPGP packet RFC xxxx 7 ACPKIX Attribute Certificate RFC xxxx 8 IACPKIX The URL of an Attribute Certificate RFC xxxx 9-252 Available for IANA assignment by IETF Standards action 253 URI URI private RFC xxxx 254 OID OID private RFC xxxx 255-65023 Available for IANA assignment by IETF Consensus 65024-65534 Experimental RFC xxxx 65535 Reserved RFC xxxx Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can only be assigned by an IETF standards action [7]. This document assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] based on RFC documentation of the certificate type. The availability of private types under 0x00FD and 0x00FE ought to satisfy most requirements for proprietary or private types. The IANA considerations in RFC 2538 reads: Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can only be assigned by an IETF standards action [RFC 2434] (and this document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE). Certificate types 0x0100 through 0xFEFF are assigned through IETF Consensus [RFC 2434] based on RFC documentation of the certificate type. The availability of private types under 0x00FD and 0x00FE should satisfy most requirements for proprietary or private types. As you should have noticed, the text in 2538bis doesn't match the table in 2538bis. Specifically, the table makes 255-65023 available for IANA assignment, but the text says the range is 256-65279. The table is inherited from section 2 of RFC 2538, and was not duplicated in the RFC 2538 IANA Considerations. I believe we should preserve the ranges documented in the IANA Considerations of RFC 2538 as much as possible. Let's ignore the table in section 2 of RFC 2538. That table is the origin of 255 as the start of the range. I believe the table above is incorrect that it permit 255 for IANA registration. We should reserve the lowest 8 bits for IETF Standards actions. Thus, I propose to reserve 255 in the table. (Reserving it is the same as making it available for IANA assignment through IETF Standards action, because the approved IETF standards could simply update RFC 2538bis if so required.) I believe the experimental range should be (as in RFC 2538) FF00-FFFF (65280-65535). The table inside the document in RFC 2538 says that 65535 is reserved, and I propose we keep this. The "meaning" field has little mandatory significance. Here is my proposed new IANA section: Decimal Type Meaning Reference ------- ---- ------- --------- 0 Reserved RFC xxxx 1 PKIX X.509 as per PKIX RFC xxxx 2 SPKI SPKI certificate RFC xxxx 3 PGP OpenPGP packet RFC xxxx 4 IPKIX The URL of an X.509 data object RFC xxxx 5 ISPKI The URL of an SPKI certificate RFC xxxx 6 IPGP The URL of an OpenPGP packet RFC xxxx 7 ACPKIX Attribute Certificate RFC xxxx 8 IACPKIX The URL of an Attribute Certificate RFC xxxx 9-252 Available for IANA assignment by IETF Standards action 253 URI URI private RFC xxxx 254 OID OID private RFC xxxx 255 Reserved RFC xxxx 256-65279 Available for IANA assignment by IETF Consensus 65280-65534 Experimental RFC xxxx 65535 Reserved RFC xxxx Certificate types 0x0000 through 0x00FF (255) and 0xFF00 (65028) through 0xFFFF (65535) can only be assigned by an IETF standards action [7]. This document assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate types 0x0100 (256) through 0xFEFF (65279) are assigned through IETF Consensus [7] based on RFC documentation of the certificate type. The availability of private types under 0x00FD (253) and 0x00FE (254) ought to satisfy most requirements for proprietary or private types. You can inspect this modification with the new and old text side by side at: http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis-from--09.diff.html Thanks to Michelle Cotton of the IANA who let us know about this problem. When I have the opportunity, I'd also like to invite review for other problems that may be fixed during AUTH48. The unpublished -10, which include the proposal above, is available from: http://josefsson.org/rfc2538bis/draft-ietf-dnsext-rfc2538bis.txt That document is what I'll use to compare with what the RFC editor sends me during AUTH48. That link will be updated whenever I receive any suggested minor changes. Any significant changes will naturally be brought up on this list first. Thanks, Simon -- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/namedroppers/>
- IANA considerations in RFC 2538bis Simon Josefsson
- Re: IANA considerations in RFC 2538bis Edward Lewis
- Re: IANA considerations in RFC 2538bis Simon Josefsson