diff --git a/doc/draft/draft-ietf-ipseckey-rr-00.txt b/doc/draft/draft-ietf-ipseckey-rr-00.txt
new file mode 100644
index 0000000000..49df4b0ae1
--- /dev/null
+++ b/doc/draft/draft-ietf-ipseckey-rr-00.txt
@@ -0,0 +1,728 @@
+
+
+IPSECKEY WG                                                M. Richardson
+Internet-Draft                                                       SSW
+Expires: September 28, 2003                               March 30, 2003
+
+
+           A method for storing IPsec keying material in DNS.
+                    draft-ietf-ipseckey-rr-00.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at http://
+   www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on September 28, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes a new resource record for DNS.  This record
+   may be used to store public keys for use in IPsec systems.
+
+   This record replaces the functionality of the sub-type #1 of the KEY
+   Resource Record, which has been proposed to be obsoleted by RFC3445
+   [9].
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003               [Page 1]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Storage formats  . . . . . . . . . . . . . . . . . . . . . . .  4
+   2.1 IPSECKEY RDATA format  . . . . . . . . . . . . . . . . . . . .  4
+   2.2 RDATA format - precedence  . . . . . . . . . . . . . . . . . .  4
+   2.3 RDATA format - algorithm type  . . . . . . . . . . . . . . . .  4
+   2.4 RDATA format - gateway . . . . . . . . . . . . . . . . . . . .  4
+   2.5 RDATA format - RSA public key  . . . . . . . . . . . . . . . .  5
+   2.6 RDATA format - DSA public key  . . . . . . . . . . . . . . . .  5
+   3.  Presentation formats . . . . . . . . . . . . . . . . . . . . .  6
+   3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . .  6
+   3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
+       Normative references . . . . . . . . . . . . . . . . . . . . . 11
+       Non-normative references . . . . . . . . . . . . . . . . . . . 12
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003               [Page 2]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+1. Introduction
+
+1.1 Overview
+
+   The IPSECKEY resource record (RR) is used to publish a public key
+   that is to be associated with a Domain Name System (DNS) name.  This
+   can be the public key of a host, network, or application (in the case
+   of per-port keying).
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC2119 [5].
+
+   An IPSECKEY resource record SHOULD be authenticated DNSSEC resource
+   record.
+
+   It is expected that there will often be multiple IPSECKEY resource
+   records at the same terminal node.  This will be due to the presence
+   of multiple gateways and the need to rollover keys.
+
+   This resource record is class independent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003               [Page 3]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+2. Storage formats
+
+   The type number for the IPSECKEY RR is TBD.
+
+2.1 IPSECKEY RDATA format
+
+   The RDATA for an IPSECKEY RR consists of a precedence value, a public
+   key (and algorithm type), and an optional gateway address.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  precedence   |  algorithm    |         gateway               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
+      ~                            gateway                            ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               /
+      /                          public key                           /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+
+2.2 RDATA format - precedence
+
+   This is an 8-bit precedence for this record.  This is interpreted in
+   the same way as the PREFERENCE field described in section 3.3.9 of
+   RFC1035 [2].
+
+2.3 RDATA format - algorithm type
+
+   aThe algorithm type field indicates the type of key that is present
+   in the public key field.  A positive number, larger than 0 identifies
+   an algorithm type.  The following values, which have been previously
+   defined by IANA are useful (see RFC2535 [6]).
+
+   A value of 0 indicates that no key is present.
+
+   The following values defined by IANA are useful:
+
+   3  A DSA key is present, in the format defined in RFC2536 [7]
+
+   5  A RSA key is present, in the format defined in RFC3110 [8]
+
+
+2.4 RDATA format - gateway
+
+   The gateway field indicates a gateway to which an IPsec tunnel may be
+   created in order to reach the entity holding this resource record.
+
+
+
+Richardson             Expires September 28, 2003               [Page 4]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+   The gateway field is a normal wire-encoded domain name (section 3.3
+   of RFC1035 [2]).
+
+   If no gateway is to be represented, then a null domain name MUST be
+   present.
+
+   It is a simple fully qualified domain name (FQDN).  IP version 4 and
+   IP version 6 addresses may be represented using the reverse name
+   format, from in-addr.arpa.  and ip6.arpa.
+
+   For instance, the IP version 4 address 192.0.1.2 is represented as
+   the domain name 2.1.0.192.in-addr.arpa.
+
+2.5 RDATA format - RSA public key
+
+   If the algorithm type has the value 5 then public key portion
+   contains an RSA public key, encoded as described in secion 2 of
+   RFC3110 [8].
+
+   RFC2065 limited the exponent and modulus to 2552 bits in length, and
+   RFC3110 to 4096 bits.  No such limit is specified here for the
+   purposes of encoding and decoding.
+
+   The length in octets of the public exponent length is represented as
+   one octet if it is in the range of 1 to 255 and by a zero octet
+   followed by a two octet unsigned length if it is longer than 255
+   bytes.  The public key modulus field is a multiprecision unsigned
+   integer.  The length of the modulus can be determined from the
+   RDLENGTH and the preceding RDATA fields including the exponent.
+
+   Leading zero bytes are prohibited in the exponent and modulus.
+
+2.6 RDATA format - DSA public key
+
+   If the algorithm type has the value 3, then public key portion
+   contains an DSA public key, encoded as described in RFC2536 [7].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003               [Page 5]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+3. Presentation formats
+
+3.1 Representation of IPSECKEY RRs
+
+   IPSECKEY RRs may appear as lines in a zone data master file.  The
+   precedence, algorithm and gateway fields are REQUIRED.  There base64
+   encoded public key block is OPTIONAL.
+
+   If no gateway is to be indicated, then the root (".") SHOULD be used.
+
+3.2 Examples
+
+   An example of a node 192.2.0.38 that will accept IPsec tunnels on its
+   own behalf.
+
+   38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5
+                    38.0.2.192.in-addr.arpa.
+                    AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+                    Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
+                    9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
+                    49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
+                    MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
+                    cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
+                    fejrfi1H )
+
+   An example of a node, 192.2.0.38 that has published its key only.
+
+   38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5
+                    .
+                    AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+                    Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
+                    9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
+                    49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
+                    MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
+                    cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
+                    fejrfi1H )
+
+   An example of a node, 192.2.0.38 that has delegated authority to the
+   node 192.2.3.5.
+
+   38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5
+                    5.3.2.192.in-addr.arpa.
+                    AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+                    Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
+                    9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
+                    49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
+                    MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
+                    cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
+
+
+
+Richardson             Expires September 28, 2003               [Page 6]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+                    fejrfi1H )
+
+   An example of a node, 192.1.0.38 that has delegated authority to the
+   node with the identity "mygateway.example.com".
+
+   38.0.2.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 5
+                    mygateway.example.com.
+                    AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+                    Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
+                    9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
+                    49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
+                    MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
+                    cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
+                    fejrfi1H )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003               [Page 7]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+4. Security Considerations
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003               [Page 8]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+5. IANA Considerations
+
+   IANA is asked to assign a resource record type number from the normal
+   resource record number space.
+
+   The algorithm field does not require any IANA action, as it is
+   inherited from DNS KEY algorithm values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003               [Page 9]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+6. Acknowledgments
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003              [Page 10]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+Normative references
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [4]  Eastlake, D. and C. Kaufman, "Domain Name System Security
+        Extensions", RFC 2065, January 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003              [Page 11]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+Non-normative references
+
+   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [7]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+        (DNS)", RFC 2536, March 1999.
+
+   [8]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+        System (DNS)", RFC 3110, May 2001.
+
+   [9]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
+        Record (RR)", RFC 3445, December 2002.
+
+
+Author's Address
+
+   Michael C. Richardson
+   Sandelman Software Works
+   470 Dawson Avenue
+   Ottawa, ON  K1Z 5V7
+   CA
+
+   EMail: mcr@sandelman.ottawa.on.ca
+   URI:   http://www.sandelman.ottawa.on.ca/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003              [Page 12]
+
+Internet-Draft                   ipsecrr                      March 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson             Expires September 28, 2003              [Page 13]
+