Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] New proposal - "AfriNIC Whois Database Update Process" (AFPUB-2014-GEN-001-DRAFT-01)

Jean Robert Hountomey jrhountomey at gmail.com
Mon May 19 04:24:54 UTC 2014


Kofi and Al,

Thank you for taking your time and adding your comments on this policy.


 > 1. What are some of the specific challenges facing AfriNIC that this 
policy seeks to address other than
 > the general problem of outdated POC NOT responding to correspondences?
 > Is it challenges to communication of annual membership fees renewal 
invoices?

RH. I am not aware of any issue related to communication of annual 
membership fees renewal invoices. I leave this to AfriNIC's operations.
Everyone who has tried to contact a resource owner in the AfriNIC 
Service Region for different reason will tell you how difficult it is.  
As far as I am concerned, less than 1/4 is successful. We ended up using 
"best effort" talking to friends and trusted contacts to have access to 
the right person.
FYI this issue has been reported since May 2007 at the AfriNIC-6 meeting 
in Abuja, mentioned in June 2008 by the Afrispam Working group and 
reported at different meetings. We would like to give AfriNIC the 
mandate to act on this issue and to hold someone accountable.

 > 2. I will like to see "may" in all the clauses changed to "shall" or 
"will" to leave no room for ambiguity or misinterpretation.
 > In other words to be explicit as to action to be taken.

RH. May, Shall, Will  is indeed a challenge. Understood. Pending more 
comment from the community in order to update.
Note: Andrew has also made a point for .2.4 from "may publish" to "will 
publish"

 >3. I believe policies when ratified are guidelines we all agree to. 
Let us not leave anything to AfriNIC or staff of AfriNIC be it "at their
 > discretion" or "internal process" where these may become subjective 
to flaws and personal interpretation or double standards.
 > What are the current methods of communication used to reach members? 
E-mail? Phone call? SMS? Snail mail? Perhaps a policy in this > 
direction to be referenced by all other communication processes.

RH. Thank you for this good point. There a few reasons for opening the 
room to AfriNIC Staff to use any methods of communication:

a. With the portal myAfriNIC we guess (but I am not AfriNIC Staff) that 
it will be easier to write a script that reminds users at login the need 
to update their information.
Questions raised:
***  are all the members using effectively myAfriNIC ?
*** how often a member connect to myAfriNIC in a year time frame ?
*** are the current contacts in myAfriNIC accurate ? (How many are 
accurate ?).

b. if we ask AfriNIC to use email knowing there are inaccurate 
information. What are the chances to reach people ?

c. if we ask AfriNIC to use phone calls, for trying unsuccessfully to 
call few people to remove issues in their network, I am not sure if this 
will work better and also it involves costs.

d. Which methods of communication should we choose as efficient ?

e. If we make it inflexible, could AfriNIC use a combination of methods 
and/or other methods like 1:1 interaction with members present at 
different meetings as an example ?

We understand that a policy like this one, impacts business operations 
and requires resources alignment.  We  don't have the numbers to make 
mandatory any suggestions about the communication methods. Also we 
believe that  AfriNIC's staff know their business and we ask them to 
find innovative ways to engage members.

In addition we may not want while trying to be too perfect to open the 
door for further justification that the policy was not applicable 
because the communication methods were not efficient.  I trust AfriNIC's 
staff, BOD and Elders (the Group of 6)  for choosing the best 
communication methods and actions if this policy is accepted.  AfriNIC 
holds two meetings a year (May/June and Last week of October), it is our 
understanding that the community will be updated at least twice a year 
on this matter.

 > Let's endeavour to make standard Policies (thorough) that will leave 
little decisions disguised as "AfriNIC staff discretion" or "internal
 > process" that can make interpretation of the policies biased.

RH. Agreed. Let's not be too rigid when it comes to business operations. 
Let's also be flexible and leave the room opened to trust and innovation 
and avoid going back to the starting box because we would have been too 
restrictive. AfriNIC is a young ORG learning from its mistakes.

Best Regards.

Jean Robert.

On 5/18/14, 9:29 AM, Kofi ansa akufo wrote:
>
> Hello Seun and All
>
> 1. What are some of the specific challenges facing AfriNIC that this 
> policy seeks to address other than the general problem of outdated POC 
> NOT responding to correspondences?
>
> Is it challenges to communication of annual membership fees renewal 
> invoices?
>
> Is it challenges of no response to ABUSE request information?
>
> I believe the current specifics should be stated to see how best the 
> policy can be discussed / debated to tackle the issues.
>
> 2. I will like to see "may" in all the clauses changed to "shall" or 
> "will" to leave no room for ambiguity or misinterpretation. In other 
> words to be explicit as to action to be taken.
>
> 3. I believe policies when ratified are guidelines we all agree to. 
> Let us not leave anything to AfriNIC or staff of AfriNIC be it "at 
> their discretion" or "internal process" where these may become 
> subjective to flaws and personal interpretation or double standards. 
> What are the current methods of communication used to reach members? 
> E-mail? Phone call? SMS? Snail mail? Perhaps a policy in this 
> direction to be referenced by all other communication processes.
>
> Again I site an example of a "90 day application expiry" as a so 
> called "internal process" which is contrary to what is defined in RSA 
> and staff of AfriNIC fail to communicate to applicant. This the 
> applicant had to threaten with legal address before changes to 
> decision was made recently.
>
> Let's endeavour to make standard Policies (thorough) that will leave 
> little decisions disguised as "AfriNIC staff discretion" or "internal 
> process" that can make interpretation of the policies biased.
>
> Cheers
>
> Kofi
>
> On May 18, 2014 3:57 PM, "Seun Ojedeji" <seun.ojedeji at gmail.com 
> <mailto:seun.ojedeji at gmail.com>> wrote:
>
>     Dear members,
>
>     We have received a new policy - "AfriNIC Whois Database Update
>     Process" (AFPUB-2014-GEN-001-DRAFT-01)
>
>     While this may not be on the agenda of the next public policy
>     meeting, we encourage the community to discuss this on the list
>     and at the upcoming face to face meeting. Public url to the
>     "draft" policy will soon be made available. However the content is
>     pasted below for comments and discussion from the PDWG/community.
>
>     ____________________________________________________________________________________________________________________
>
>     Draft Policy name: AfriNIC Whois Database Update Process
>     Unique identifier: AFPUB-2014-GEN-001-DRAFT-01
>     Status: New
>     Submission Date 15 MAY 2014
>     Author:Jean Robert Hountomey
>
>
>     1.Summary of the Problem Being Addressed by this Policy Proposal
>
>     The African network infrastructure is growing with changes and
>     extensions. This growth has brought changes in telecommunication
>     and Internet infrastructure. With the emergence of new operators,
>     mergers and acquisitions, the dynamism brought by the penetration
>     of Internet technology has required organizational changes with
>     job rotation. The need for accurate whois data has been in the
>     news for years all over the world.
>
>     Inaccurate data is still present in the AfriNIC whois database
>     because changes have occurred in organizations (point of contact,
>     contact information etc.) and object owners have not updated their
>     records. The result is a "No response" from "whois" contacts
>     listed in the AfriNIC Database.
>
>     The goal of the proposal is setting a process towards ensuring
>     that AfriNIC whois database is updated. A previous policy
>     (AFPUB-2012-GEN-001-DRAFT-02 : AfriNIC Whois Database Clean-up )
>     was withdrawn by the Author after AfriNIC advised that there was
>     already an internal process to handle the cleanup of whois data
>     and do general contact update. However it has been noticed that
>     objects in AfriNIC database are not accurate.
>
>     2. Summary of How this Proposal Addresses the Problem
>
>     This proposal asks AfriNIC to maintain accuracy through a
>     periodical database clean up. Furthermore, at least
>     once a year or at the renewal of resources, AFRINIC staff should
>     conduct a whois database information validation.
>
>     3. The Proposal
>
>     AfriNIC members are committed through the RSA to maintain their
>     data and keep it accurate.  AfriNIC will then
>     maintain accuracy of whois information through periodical database
>     clean up or update. AfriNIC will periodically ask object
>     owners in the Whois Database to actively check and update the
>     accuracy of data in AfriNIC whois database.
>
>     3.1 Cleanup
>
>     3.1.1 - General Database Cleanup: At the ratification of this
>     policy, AfriNIC staff will conduct a first cleanup by asking all
>     POC present except those who received their objects in less than a
>     year to confirm their POC information. We leave to AfriNIC staff
>     the discretion to use any communication tool they find useful for
>     this action.
>
>     3.1.2 - Annual Clean up: After the first cleanup, AfriNIC will
>     conduct a cleanup once a year. We leave to AfriNIC's staff to
>     define the period.
>
>     3.1.3 - At the request of additional resources or services,
>     AfriNIC staff will ask the organization to update its records.
>
>     3.2. If a change is requested by another policy.
>
>     In case another AfriNIC policy made mandatory a change or
>     introduce another object, the object owner is required to make
>     this update.
>
>     3.2 Steps
>
>     3.2.1 - AfriNIC staff will ask members to confirm accuracy of
>     their records in the Whois database in a month's
>     timeframe when contacted by email.
>
>      3.2.2 - After one month, AfriNIC Staff will use any communication
>     tools at their discretion to contact
>     those who have not answered or those whose email has bounced back.
>
>      3.2.3 - After another month of unresponsive response, the record
>     will be marked invalid.
>
>      3.2.4 - AfriNIC may publish publicly a report about number
>     resources with invalid POC.
>
>      3.2.5 - One year after the first contact initiation, if the data
>     is still not accurate and the organization has failed to respond
>     to the call to resolve the data inconsistency, AfriNIC may
>     claim the number resources back.
>
>     4. Situation within other RIRs
>
>     - ARIN conducts an annual POC (point of contact) validation process:
>     https://www.arin.net/resources/services/poc_validation.html
>     - At APNIC, there was a similar policy proposed that did not reach
>     consensus and was withdrawn by the author.
>     http://www.apnic.net/__data/assets/file/0006/22857/prop-084-v002.txt
>     - RIPE NCC
>     http://www.ripe.net/data-tools/support/clean-up-of-unreferenced-data
>     - LACNIC obligates the resources holders contractually throught
>     their RSA and reviews whois data when resources are requested and
>     updates accordingly
>
>     *History*
>
>       * 02 Oct. 2012 - AFPUB-2012-GEN-001-DRAFT-02 was withdrawn by
>         the Author.
>
>     *Previous Versions *
>
>     None
>
>     Kind Regards,
>
>     Seun Ojedeji, Emile Milandou
>     PDWG Co-Chairs
>
>     _______________________________________________
>     rpd mailing list
>     rpd at afrinic.net <mailto:rpd at afrinic.net>
>     https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>
>
>
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20140518/d2f70faa/attachment.html>


More information about the RPD mailing list