A.    Submission Date:

  6/11/08
   update by expert 2008-12-24

   B.   Submission Type:
        [x] New RRTYPE
        [ ] Modification to existing RRTYPE

   C.   Contact Information for submitter:
               Name: Jim Reid
               Email Address: jim at telnic.org
               International telephone number: +44 20 7467 6474
               Other contact handles: none
        (Note: This information will be publicly posted)


   D.   Motivation for the new RRTYPE application?

     There is a need to provide a mechanism in the DNS to publish
     descriptive information about the status of the zone,
     particularly for zones holding real-time contact data. At
     present a variety of ad-hoc schemes and conventions are
     used. These approaches are confusing and impractical since an
     arbitrary DNS client needs a priori knowledge of which of
     these schemes, if any, has been used by a zone administrator.

     Assigning a new RRtype for a resource record to hold this
     information will provide a simple, standardised way of
     publishing and retrieving zone status information.


   E.   Description of the proposed RR type.

     The proposed RRtype is essentially identical to a TXT record:
     the zone status information contained as free text in the
     RDATA. Further details about the record format and its
     potential applications is given in draft-reid-dnsext-zs-01.txt.
    [Note from experts: draft was last description as of 
      RRTYPE approval.]

   F.   What existing RRTYPE or RRTYPEs come closest to filling that
        need and why are they unsatisfactory?

  The TXT record is the closest RRtype to the one proposed
  here. However TXT records are already used in many zones for
  a variety of purposes. This makes it awkward and impractical
  to differentiate a TXT record containing zone status
  information from other TXT records that may exist for a
  domain name. Allocating a new, dedicated RRtype for zone
  status is the cleanest way to deal with this issue. It would
  also prevent further mission creep by overloading the already
  overloaded TXT RRtype.


   G.   What mnemonic is requested for the new RRTYPE (optional)?
        Note: this can be left blank and the mnemonic decided after the
        template is accepted.

  NINFO  
      [Note from experts: originally requested as ZS, but NINFO
       approved.]

   H.   Does the requested RRTYPE make use of any existing IANA
        Registry or require the creation of a new IANA Sub-registry and
        in DNS Parameters?

  No.

   I.   Does the proposal require/expect any changes in DNS
        servers/resolvers that prevent the new type from being
        processed as an unknown RRTYPE (see [RFC3597])?

  No.

   J.   Comments:

     None.