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

[rpd] New proposal - "Mandatory requirements for registering assignments and sub-allocations" (AFPUB-2014-GEN-003-DRAFT-01)

Jean Robert Hountomey jrhountomey at gmail.com
Sat Sep 27 00:03:36 UTC 2014


Thank you Dr Paulos, I will submit the new version.

Best Regards.

Jean Robert.


On 9/26/14, 11:14 AM, Dr Paulos Nyirenda wrote:
>
> Seun,
>
> While I am still considering the proposal, I would like to comment on 
> the process for this policy proposal.
>
> Normally, a proposal that ammends a policy like this has produced a 
> full version of the ammended policy and not just a list of the 
> ammendments as has been done here. The full version of the policy then 
> replaces the previous version or as the saying goes "obsoletes" the 
> previous version in a tracked histrory. This allows the ammendments to 
> be considered in the context of the whole policy and not just bits of 
> it like this.
>
> So, in this case I think the way forward would be to ask the author to 
> insert the ammendments and to produce the full ammended version of 
> AFPUB-2005-v4-001 which is what should be presented to RPD for discussion.
>
> The list of ammendments can be put in the problem section of the new 
> proposal or however the author wants it done with the guidance of the 
> co-chairs BUT it is the full policy that should be discussed on RPD 
> and not just the ammendments like this.
>
> I am open to correction on the process but at least that is the way I 
> recall its use.
>
> Regards,
>
> Paulos
> ======================
> Dr Paulos B Nyirenda
> NIC.MW & .mw ccTLD
> http://www.registrar.mw
>
>
> On 26 Sep 2014 at 15:43, Seun Ojedeji <seun.ojedeji at gmail.com> wrote:
>
> >
> > Dear members,
> >
> > We have received a new policy Proposal - "Mandatory requirements for
> > registering assignments and sub-allocations"
> > (AFPUB-2014-GEN-003-DRAFT-01)
> >
> > Draft Policy name: Mandatory requirements for registering assignments
> > and sub-allocations Unique identifier: AFPUB-2014-GEN-003-DRAFT-01
> > Status: New Submission Date: September 22, 2014 Author: Jean Robert
> > Hountomey URL:
> > http://www.afrinic.net/en/community/policy-development/policy-proposal
> > s/1215-mandatory-require
> > ments-for-registering-assignments-and-sub-allocations Short url:
> > http://goo.gl/vOJIrN
> >
> > Text Below:
> >
> > 1.Summary of the Problem Being Addressed by this Policy Proposal
> >
> > The AFRINIC IPv4 Allocation policy - AFPUB-2005-v4-001 (1) guides the
> > responsible management of unique IPv4 address space in the AFRINIC
> > region. The document was implemented in May 17, 2006.
> >
> > In a document called "Creating Customer Assignments" (2) last Updated
> > on Monday, 02 September 2013, AFRINIC has detailed the process of
> > registering LIR network infrastructure and customer IP address
> > assignments in the AFRINIC whois database. While the two documents are
> > still applicable, the AFRINIC community has questioned at several
> > occasions AFRINIC's allocations. In addition few, AFRINIC Resource
> > Members (3) have not registered their assignments in the AFRINIC
> > database.
> >
> > 2.Summary of How this Proposal Addresses the Problem
> >
> > This document merges the AFRINIC IPv4 Allocation policy and Creating
> > Customer Assignments by introducing a section (section 9.7) into
> > AFRINIC IPV4 Allocation Policy. In addition, the document makes
> > mandatory the registration of all allocations and assignments in the
> > AFRINIC database. Furthermore, the document gives the authority to
> > AFRINIC staff to conduct any process after approbation by the
> > community to reclaim resources from unregistered assignments /
> > allocations / sub-allocation since they are considered invalid. 3.
> > Proposal
> >
> > 3.1. Modification of section (8b) of the AFRINIC IPV4 Allocation
> > policy by replacing "will be" by "must be".
> >
> > a. All communication with AFRINIC must be in English.
> > b. All allocations and assignments must be registered in an AFRINIC
> > database. Any unregistered assignments / allocations / sub-allocation
> > will be considered invalid.
> >
> > The registration data (name, IP block/range, contacts, status, etc..)
> > must be correct at all times. This is necessary to support network
> > operations.
> >
> > 3.2 The proposal adds section (9.7) - "Mandatory Requirement for
> > registering assignments" to AFRINIC IPV4 Allocation Policy.
> >
> > Assignment registration is important for several reasons:
> >
> > -To inform the Internet community which organization is using the IPv4
> > address space, including the point of contact in case of operation
> > problems, security
> >
> > -To ensure that the Resource Member has completed or is close to
> > completing address space allocation such that the allocation of
> > additional space is justified
> >
> > -Assignment Registration also helps AFRINIC in analyzing additional
> > IPV4 block request made by a Resource Member in an open transparent
> > process
> >
> > -Assignments must include the following mandatory attributes regarding
> > the assignee: inetnum, net name, descr, country, admin-c, tech-c, org
> >
> > and any other mandatory information required as defined by an AFRINIC
> > policy.
> >
> > 3.2.1 Size of block and timeframe
> >
> > All IP block assignments equal or larger than a /29 made by an AFRINIC
> > Resource Member for its own network or customer must be registered and
> > documented in AFRINIC Whois database no later than seven (7) business
> > days after the assignment.
> >
> > 3.2.2 Residential Customers
> >
> > When the assignment is for residential customers, the address blocks
> > that are being used by equipment or customer service areas, by service
> > must be registered (dialup access server, DSLAM/DSL access Server,
> > WIFI Access Point, WIMAX Cell, Cloud infrastructure etc..) The
> > Resource Member must specify in the AFRINIC whois database that the
> > block is used for Residential Customers (netname, desc)
> >
> > 3.3.3 Confidentiality.
> >
> > It is understandable that for business requirement and customer
> > information protection the Resource Member might be reluctant to
> > provide these information in the public database. The information must
> > be provided to AFRINIC for audit purpose under confidential agreement.
> >
> > The Resources assigned must still be registered in AFRINIC Whois
> > database with the following exception:
> >
> > -netname and descr must describe the usage of the block
> > -all other information can be the same as the Ressource Member's
> > information with the understanding that he is liable for any issue
> > related to the IP Block.
> >
> > 4.References:
> >
> > (1) IPv4 Allocation Policy (Assignment Policies and Guidelines)
> > http://AFRINIC.net/en/library/policies/126-policy-ipv4-address-allocat
> > ion-policies
> >
> > (2) Creating Customer Assignments
> > http://www.AFRINIC.net/en/library/membership-documents/214-creating-cu
> > stomer-assignments
> >
> > (3) Definition of AFRINIC Resource Member
> > http://www.AFRINIC.net/en/services/rs
> >
> > Useful urls:
> > Policy under discussion:
> > http://www.afrinic.net/en/community/policy-development/policy-proposal
> > s Policy proposals:
> > http://www.afrinic.net/en/community/policy-development/policy-proposal
> > s About the policy development process:
> > http://www.afrinic.net/en/community/policy-development/pdwg
> >
> > Regards
> > ---
> > Seun Ojedeji & Adam Nelson
> > PDWG Co-Chairs
>
>
>
> _______________________________________________
> 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/20140926/06b598ab/attachment.html>


More information about the RPD mailing list