IANA considerations in RFC 2538bis

[Simon Josefsson <[e-mail]>]

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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>