[sig-db]Database SIG Proposal

  • To: <sig-db-chair at apnic dot net>, <sig-db at apnic dot net>
  • Subject: [sig-db]Database SIG Proposal
  • From: "save" <save at apnic dot net>
  • Date: Tue, 22 Jul 2003 12:56:47 +1000
  • Cc: <sig at apnic dot net>
  • Importance: Normal
  • List-archive: <http://www.apnic.net/mailing-lists/sig-db/>
  • List-help: <mailto:sig-db-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on whois database issues <sig-db.lists.apnic.net>
  • List-post: <mailto:sig-db@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-db>,<mailto:sig-db-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-db>,<mailto:sig-db-request@lists.apnic.net?subject=unsubscribe>
  • Sender: sig-db-admin@lists.apnic.net
    • 
      A proposal(P) is submitted below for the forthcoming Database SIG in
      Seoul, Korea on August 21st. 
      
      Your comments and feedback are appreciated and most welcome.
      
      Regards,
      
      Save Vocea
      APNIC Secretariat
      ----------------------------------------------------------------------
      See you at APNIC 16
      Seoul, Korea, 19-22 August 2003          http://www.apnic.net/meetings
      ----------------------------------------------------------------------
      
      Privacy of Customer Assignment Records
      
      Proposed by: Paul Wilson, APNIC Secretariat
      Version: 1.0
      Date: 18 July 2003
      
      1	Summary
      
      In this document it is proposed that customer assignment records of
      APNIC Member ISPs need no longer be publicly accessible in the APNIC
      database.  These registrations are essential to the verification of
      resource utilisation during the address request process, however for a
      number of reasons it is no longer desirable that they must necessarily
      be publicly available. ISPs wishing to register and maintain customer
      assignments publicly should be able to do so; however a new database
      attribute will allow the records to be hidden from public view if
      desired.
      
      
      2	Background and Rationale 
      
      2.1	Privacy Concerns
      
      In recent years, increasing concern about protection of private
      information on the Internet has been expressed by many parts of the
      community, and through conventions and legislation, in most parts of the
      world.  Within the APNIC member community, concern has been expressed
      specifically about the requirement to publicly register customer
      assignments, which are often regarded by ISPs and customers as private
      information.
      
      Furthermore, in certain jurisdictions an organisation which publishes
      data on behalf of other parties may be held to be jointly responsible
      for the accuracy of this information.  This may place APNIC itself at
      risk, in case of damages caused by inaccurate customer assignment
      information.
      
      2.2	Registration Goal
      
      Accurate resource registration is a fundamental goal of Internet
      resource management, however it is important to recognise which types of
      registration are essential to this goal, and which registration records
      can be feasibly maintained and controlled under APNIC policies. 
      
      APNIC members are obliged under current policies to maintain accurate
      customer assignment records in the database.  Realistically, this is an
      onerous and expensive task which can often not be performed in a
      complete or timely manner, and as a consequence many assignment records
      are inaccurate. Because the APNIC Secretariat can have no direct control
      over these registrations, it is inevitable that incorrect records will
      continue to exist, compromising the overall registration goal.
      
      On the other hand, records pertaining to allocations and assignments
      which are made by the APNIC registry to its members and customers are
      essential to the resource registration goal.  In case of technical
      problems related to the address space concerned, these records identify
      the party which is responsible for the resources concerned.  These
      records are far fewer in number and can be maintained in an accurate
      state.  
      
      
      3	Proposal
      
      It is proposed that customer assignments (and sub-allocation records)
      need no longer be publicly accessible in the APNIC database via normal
      "whois" queries. 
      
      Customer registration records must still be registered within the APNIC
      database, in order to document address utilisation, however a new
      "hidden:" database attribute will be provided to allow the records to be
      excluded from public whois query results. 
      
      ISPs may wish to register and maintain public registrations, in order
      that customer contact information be available publicly, however should
      be their choice. By doing so, ISPs must also commit to maintenance of
      accurate records, and APNIC should explicitly disclaim responsibility
      for accuracy of these records.
      
      A management interface for customer assignments will be provided within
      the "MyAPNIC" service, in order that address space utilisation may be
      tracked.
      
      
      4	Implementation
      
      The following steps are involved in implementation of this proposal:
      
      a.	Provision of a "hidden:" attribute within the APNIC database,
      for use with "inetnum", "inet6num" and "autnum" objects (if this
      attribute is included with value "yes", the record will not be visible
      in public whois queries, and it will not be exported to any database
      mirrors);
      
      b.	modification of the "MyAPNIC" service to allow maintenance of
      "hidden" records;
      
      c.	modification of APNIC policy documentation to reflect the above
      changes.
      
      
      If is proposed to implement this policy within six months of approval by
      the APNIC community.