[sig-policy] prop-037: Deprecation of email updates for APNIC Registry a

  • To: sig-policy at apnic dot net
  • Subject: [sig-policy] prop-037: Deprecation of email updates for APNIC Registry and whois data
  • From: Toshiyuki Hosaka <hosaka at nic dot ad dot jp>
  • Date: Tue, 06 Feb 2007 14:12:52 +0900
  • Cc:
  • List-archive: <http://www.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • Organization: Japan Network Information Center (JPNIC)
  • User-agent: Thunderbird (Windows/20061207)
      An updated version of the proposal "Deprecation of email updates for
      APNIC Registry and whois data" has been sent to the Policy SIG for
      review. The updated proposal contains a revised timeframe as
      recommended by the APNIC resource management systems Working Group.
      The policy proposal will be presented at the Policy SIG at APNIC 23 in
      Bali, Indonesia, 26 February - 2 March 2007. You are invited to review
      and comment on the proposal on the mailing list before the meeting.
      The proposal's history can be found at:
      Toshiyuki Hosaka
      on behalf of Policy SIG chairs
      hosaka at nic dot ad dot jp
      prop-037-v002: Deprecation of email updates for APNIC Registry and whois
      Author:    APNIC Secretariat
                 <secretariat at apnic dot net>
      Version:   2
      Date:      6 February 2007
      There are two ways to update data in the APNIC registry (which includes
      whois data). The first is to use interfaces on the certificate-secured
      MyAPNIC web site. The second is to send plain text updates by email to
      <autodbm at apnic dot net> (for whois objects only).
      This is a proposal to progressively phase out email updates.
      Problem summary
          The mechanisms for securing the contents of an email and validating
          the identity of the author of the update are weak by modern
          standards. Although there are ways of improving the use of email for
          secure transactions, these are not considered sufficiently
          scaleable and a burden on member resources.
      Unsolicited mails (spam):
          The destination for email updates, <autodbm at apnic dot net>, suffers from
          the same set of problems as any other email address on the Internet.
          Despite the APNIC Secretariat's best efforts to reduce the impact of
          spam and email-borne viruses, the <autodbm at apnic dot net> system
          constantly receives irrelevant emails, which can affect the system's
          ability to efficiently process legitimate updates.
          It has also been observed that members' mail servers often reject
          automated replies from <autodbm at apnic dot net> as spam. This frequently
          interferes with the update process, causing confusion for users and
          avoidable work for the APNIC Helpdesk.
      Service development:
          APNIC registry services are becoming more complex and their
          requirements are growing beyond the capabilities of the email update
          For instance, the provisions for protecting the privacy of customer
          data (Policy prop-007-v001) require an interactive feedback cycle
          that would be difficult and complex in an automated email
          transaction. At present these privacy provisions are supported only
          in MyAPNIC.
          It is also doubtful that an email-based process will be able to
          support the likely future implementation of routing security using
          RFC3779 and related mechanisms.
      Proposal summary
      The APNIC Secretariat will complete the phase out of email-based
      updates to registry data 18 months after adoption of the policy.
      Implementation stages:
          To ensure that enough time is given to APNIC members to familiarise
          themselves with alternative ways of updating registry records, we
          propose the following schedule after adoption:
          - 6 months: Prototype available that accepts all objects
          - 10 months: Current system will stop accepting domain objects
          via email and start accepting domain objects via XML/REST
          - 14 months: Current system stop accepting inetnum, inet6num,
          autnum objects and start accepting inetnum, inet6num,
          autnum objects via XML/REST
          - 18 months: production system stop accepting remaining rpsl
          objects and start accepting remaining rpsl object via xml
          At every stage, the Secretariat will actively inform those who are
          still using email updates to change to the new method.
      Situation in other RIRs
      LACNIC currently does not accept any updates to registry via email. All
      updates are via a web-based interface.
      ARIN only accepts modifications to registry data via email.
      RIPE NCC primarily accepts modifications to registry data via email;
      however, a web portal 'LIR Portal' has been developed to augment the
      management of registry data.
      AfriNIC currently accepts modifications to registry data via email. A
      web based 'MyAfriNIC' portal is being developed.
      Details of this proposal
      Before deprecating email updates, the APNIC Secretariat will provide an
      alternative mechanism that is suitable for automated and secured
      registry transactions. It is expected that this mechanism will be based
      on web services (XML/REST), delivering atomic transactions via a
      certificate-secured HTTPS layer, as presented in the APNIC 21 DNS
      operations SIG.
      During the process of email update deprecation, MyAPNIC functionality
      will remain unaffected.
      The following steps are proposed to ensure a smooth migration for
      members using email updates.
      - Deploy evaluation web services technology to allow registry record
        update using automated tools
        - Target: 6 months after adoption
        - Provide a test system with its own URL for users to safely test
          their scripts
        - Provide example command line Unix tools to aid in members'
          automation efforts
      - Deprecate domain object email updates
        - Target: 10 months after adoption
        - Public and members announcement 1 month prior to cut-off date
        - Monitor and actively inform users who are still sending updates
          via email
      - Deprecate inetnum, inet6num, aut-num objects email updates
        - Target: 14 months after adoption
        - Public and members announcement 1 month prior to cut-off date
        - Monitor and actively inform users who are still sending updates
          via e-mail
      - Deprecate all remaining objects email updates
        - Target: 18 months after adoption
        - Public and members announcement 1 month prior to cut-off date
        - Monitor and actively inform users who are still sending updates
          via email
      - The APNIC Secretariat will present progress reports at APNIC 25 and
        APNIC 26.
      Advantages and disadvantages of adopting the proposed policy
      The web services system will provide immediate feedback on the success
      or failure of an update to registry data (within the TCP session).
      All updates to APNIC registry will be encrypted in transit, and the
      identity of the author verified and authorised by APNIC certificates.
      All future data submitted to the APNIC Secretariat will be in an XML
      structured syntax. The XML schema will be publicly available for
      members' own development use.
      The APNIC Secretariat will only support strong encryption and
      authentication mechanisms for managing registry data.
      Effect on APNIC members
      - Members currently using automated email procedures for managing APNIC
        data should prepare in advance for the deprecation.
      - Members using simple email methods for managing their registry data
        should evaluate their process and be prepared to implement new
      Effect on NIRs
      NIRs should consider their data management procedures with APNIC and
      modify their manual and automated systems as appropriate.
      RFC3779: X.509 Extensions for IP Addresses and AS Identifiers
      DRAFT: A Profile for X.509 PKIX Resource Certificates
      DRAFT: Profile for Resource Certificate Repository Structure
      APNIC Policy: Privacy of customer assignment records
      APNIC Presentation: APNIC reverse DNS management roadmap