|The Policy Development Process||Public Policy Meetings||View Current Policies
||Policy Manual||View recent discussions
|The Policy Development Working Group (PDWG)||Meeting Minutes||View Policy Proposals
AFRINIC-17 PPM Minutes
28 Nov 2012 (14:45 – 16:00)
1) Welcome and Introduction to the PDP
2) Summary of Proposals Under Discussion in other regions
3) Proposal: AFPUB-2012-v4-002-draft-01: Redefine Core DNS Service Provider
4) Proposal: AFPUB-2012-v4-001-draft-01: Anycast Assignments in the AFRINIC service region
28 Nov 2012 (09:00 – 13:00)
5) Proposal: AFPUB-2012-DNS-001-draft-01: No Reverse Unless Assigned
6) Proposal: AFPUB-2012-GEN-001-draft-01: Whois Database Clean up
7) Proposal: AFPUB-2012-GEN-002-draft-02: Regional Internet Registry Privacy
8) Policy Development Open Microphone
1. Welcome and Introduction to the PDP
Alan Barrett, the PDWG Co-Chair welcomed participants to the AFRINIC17 public policy meeting and introduced the AFRINIC region PDP. He also went through the detailed agenda of the upcoming 2-day policy discussions.
He mentioned that anyone can submit a proposal, post it on the RPD list for discussions not lasting less than 4 weeks before it is presented at a face-to-face meeting where if there is consensus, the PDWG co-chairs forward the proposal to a 2-week last call. If the no consensus, the proposal goes back to the mailing list where the author(s) can perhaps give revised versions of the proposals based on feedback received. The proposal, after a successful last call period, is sent to the board for ratification and to AFRINIC for implementation.
Some questions were raised from the floor, the first one being about the process of involving everyone's participation as well as equity of participation from the entire continent where there was concern that only a few people are involved. The co-chair stated that the process is open, and transparent, and that AFRINIC does a great job in its outreach activities to spread the message about the PDP such that everyone can take part.
Douglas Onyango inquired about the Emergency Process in the by-laws that would give the board power to introduce or fast track a policy, and asked if it can be incorporated in the PDP. Adiel (CEO, AFRINIC) mentioned that the provisions in the by-laws could be incorporated within the PDP.
2. Summary of Proposals Under Discussion in other regions
Ernest Byaruhanga presented the policy proposals still under discussion in other regions to the meeting.
3. Proposal AFPUB-2012-v4-002-draft-01: Redefine Core DNS Service Provider
Frank Habicht remotely presented this proposal as the author.
4. Proposal: AFPUB-2012-v4-001-draft-01: Anycast Assignments in the AFRINIC service region
Mark Elkins presented the proposal on behalf of the authors (himself being a co-author).
The chair opened discussions about the proposals AFPUB-2012-v4-001-draft-01 and AFPUB-2012-v4-002-draft-01
Douglas Onyango suggested that combining the proposals AFPUB-2012-v4-002-draft-01 and AFPUB-2012-DNS-001-draft-01 as they both deal with DNS. He would also like to see IPv6 included in both of the policies.
Alain Aina raised a point of order about the fact that discussions on the mailing lists about this proposal were not presented. The co-chair stated that although the PDP does not have this requirement, he already presented a summary of the discussions on the proposal.
Mark Tinka indicated that there could be room for abuse as it's hard to police what happens to the assignment when the DNS operators stop using the space for the purpose it was requested. He also stated his belief that any core DNS operator already probably has address block that could be used for anycast, and hence does not support both proposals. He went on to suggest that any operator get space for both purposes from their existing allocations, also insisting that the current policies can be modified to include clauses that can cater for these requirements, rather than doing new policy documents.
Alan Barrett indicated that its possible that some operators can assign a smaller prefix from a larger block, but the authors of the proposals might want to consider that some DNS operators do not have big blocks where to deaggregate and obtain smaller blocks for such purposes.
Paulos Nyirenda asked if an assessment for the implementation of these proposals has been conducted by AFRINIC. The Chair stated that he has requested the assessment, which will be provided by AFRINIC in 2 weeks
Alain suggested an update to the existing PI policy such that if a company applies for anycast space but already has an allocation, the space can be denied, and only issued to those companies without their own space.
After all the discussion and show of hands, the Chair declared that there was no consensus on both AFPUB-2012-v4-002-draft-01 and AFPUB-2012-v4-001-draft-01 and deferred them back to the mailing list for more discussion from the PDWG.
5. Proposal: AFPUB-2012-DNS-001-draft-01: No Reverse Unless Assigned
Tim McGinnis (the author) presented the proposal remotely to the meeting participants.
6. Proposal: AFPUB-2012-GEN-001-draft-01: Whois Database Clean up
Jean-Robert Hountomey (the author) presented the proposal remotely to the meeting participants.
The chair opened the floor for discussions on proposals AFPUB-2012-DNS-001-draft-01 and AFPUB-2012-GEN-001-draft-01
There was another question regarding the rDNS issue, if it was actually technically possible to have rDNS services when you have no IP addresses in the whois database. Ernest Byaruhanga clarified that indeed one cannot have reverse DNS unless they have an AFRINIC allocation or assignment, but the policy proposal under discussion specifically refers to customers networks, where the LIR is required to register or record any IP addresses assigned to a customer or end-site into the whois database, else, AFRINIC should deny rDNS services to the LIR.
Leo Vegoda wondered if there could be an incentive to create bogus assignments so reverse DNS can be provided. Ernest Byaruhanga commented that at the time the LIR requests a subsequent allocation, AFRINIC audits the registered assignments and where there are irregularities discovered, the LIR will be requested to correct them else the additional allocation will not be approved and other services could be withdrawn in compliance with policy and the signed Registration Services Agreement.
Another participant wondered about how many assignments must be registered for the reverse DNS services to be provided, and asked if in case the LIR records just one assignment, it would make it OK for AFRINIC to offer reverse DNS.
The author (McTim) indicated this is something he is open to, and is willing to edit the proposal to have these thresholds. Alan Barett also supported the idea of indicating what percentages of the allocation should be registered as assigned before rDNS services can be provided.
Douglas Onyango asked why the rDNS proposal has the exclusion of resources that have been assigned already; indicating he also needs this included, but indicated he supports the proposal in principle. On the database clean-up proposal, also stated that the clean up should be applied to all registrations without applying time limits. Douglas also commented the requirement to make it mandatory for AFRINIC to publish a report with invalid POCs, and wanted the text to read "must" not "may", also stating that this should not be just twice a year; this report should be readily available at any point in time.
Mark Elkins suggested a "shame list" which should be public, stating which companies have invalid contacts, as this can motivate companies to not get on the list. He however indicated his support for the two proposals.
Haitham El Nakhal suggested combining the proposals AFPUB-2012-GEN-001-draft-01 and AFPUB-2012-DNS-001-draft-01 as they both deal with cleaning up the whois database.
Adiel mentioned that there is already an activity on-going for whois data integrity, for the authors to consider. Douglas mentioned that if AFRINIC has some work going on internally already, perhaps it's wise to work on improving such an activity towards the requirements in this proposal and may be the authors can withdraw the policy once AFRINIC has flagged that work as complete. There were some concerns that an internal AFRINIC activity and a policy do not mean the same thing, as a policy explicitly makes AFRINIC accountable towards delivering the requirements. Alain said this seems to be a problem that does not necessarily require a policy to solve and that after each meeting, the CEO can record the community's recommendations towards what their expectations of AFRINIC are and what activities AFRINIC can focus on, instead of drafting a policy proposal for each problem.
After discussions and show of hands, the Chair declared that there was no consensus on both AFPUB-2012-DNS-001-draft-01 and AFPUB-2012-GEN-001-draft-01. They were both deferred to the mailing list for further discussions from the PDWG.
7. Proposal: AFPUB-2012-GEN-002-draft-02: Regional Internet Registry Privacy
Subramanian Moonesamy (a.k.a SM), the author of proposal AFPUB-2012-GEN-002-draft-02 remotely presented it to the community.
The chair opened the floor for discussions on proposal AFPUB-2012-GEN-002-draft-02
Yaovi Atohoun stated that from the presentation, it is not clear to see the exact context and problem that the proposal is trying to address. He also stated that there is a format on the AFRINIC website which all policy proposals should follow, as this allows the community to easily read through the proposal and understand perhaps what problems the proposal is trying to address, as the template has been designed with this in mind.
Douglas stated that the problem statement is not very clear, stating that usually, data protection and privacy is governed by the law in the country where a company is incorporated, and that AFRINIC is therefore bound by Mauritius law. Hence, a policy cannot and does not have the legal authority to address such an issue. He said that the policy could create complications to AFRINIC as Adiel pointed out. Douglas therefore said he does not support it.
The Chair declared that there was no consensus on AFPUB-2012-GEN-002-draft-02 and deferred the proposal back to the mailing list for more discussion.
8. Policy Development Open Microphone
The chair introduced the Open Microphone session and requested anyone with an idea that needs to be addressed by policy, or an issue with current policy that needs to be revised, to come to the microphone and state out their ideas or suggestions or contributions.
Nacer Adamou asked if the African community is thinking about how they will manage IPv4 requests from other regions since those regions are mostly exhausted. He also asked if there is any discussion about how Africa will manage this critical period in terms of management of the last IPv4 address space block?
Some members indicated that there is no transfer policy and that on the management of the last /8, there is already a policy that has been implemented for that purpose.
Douglas indicated he is thinking of a policy around on lame reverse DNS delegations. He indicated if this is something AFRINIC can implement if done. Alain indicated he likes this idea although not through a policy. It can be an internal activity or project at AFRINIC, as they have already started some on going activities about data integrity. Alex Le Heux stated that RIPE NCC tracks lame delegations but does not act on them.
Mark Elkins also wondered if there is a way to entice legacy resource holders to formalize their membership with AFRINIC, and perhaps this is something either the community or the board can consider.
Alain asked if the co-chairs could integrate or include remote participants and online participation towards determining consensus. The Chair said this is something that needs to be looked at for future meetings.
The Chair adjourned the meeting
Discussions are taking place on the policy working group mailing list if you want to subscribe to the mailing send your subscription request to rpd-request [at] afrinic.net with 'Subscribe' as subject line
Mailing list archives can be found at https://lists.afrinic.net/pipermail/rpd