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

[rpd] Proposal: Clarification on temporary resource usage

Sylvain BAYA abscoco at gmail.com
Thu Apr 18 10:18:42 UTC 2019 

{/...much arguments => long mail :-//}

Hi all,
Hoping that this mail finds y'all in good health, please see my comments
inline...

Le ven. 21 déc. 2018 8:20 AM, Ernest Byaruhanga <ernest at afrinic.net
<mailto:ernest at afrinic.net>> a écrit :


    A new policy proposal has been received:

    Title: Clarification on temporary resource usage
    ID:AFPUB-2018-GEN-004-DRAFT01
    Author: Manga Willy Ted
    URL: https://afrinic.net/policy/2018-gen-004-d1#proposal

    The proposal introduces modifications to CPM 9.0 which deals with
    issuance of number resources for temporary use (such as for
    conferences and experiments).

    The proposal has been published at :
    https://afrinic.net/policy/2018-gen-004-d1#proposal
    (Text in orange color depicts changes to current policy text)


    Plain text version:

    ————————————
    Clarification on temporary resource usage
    ————————————

    1.0 Summary of the problem being addressed by this proposal

    With IPv4 exhaustion coming, IPv4 resource assignments need better
    management because of scarcity. For instance, what happens if some
    entities request a /20 worth of IPv4 for temporary usage during soft
    landing phase 2? 


...it seems as the softlanding policy [1]  is already covering this
situation...or not ? :-/

    With current IPv6 evolution, we think entities requesting temporary
    resources should deploy more IPv6 prefixes than IPv4 prefixes.


...i may be wrong, but i don't really understand why RPD activities (or
an IP policy) could|should deal with (or focus on) IPv6 operational
deployment :-/

...because that is what it seems to me.

IMHO the problem statement must be in line with RPD possibilities|missions. 
So i recommend to rephrase it ; in order to first remove *operational*
considerations here... 

    2.0 Summary of how this proposal addresses the problem

    This proposal aims to restrict the size of IPv4 resource requests
    for temporary use such as conferences and meetings and in addition, 


I tend to aggree, but there is a remaining question : Is the proposed
restriction, of IPv4 prefix, really needed ? as we already have a
softlanding policy [1] as mentionned by the actual text of CPM (v1.3)
[2] section 9.0...

...convince me please :-)

    encourages IPv6 usage for those purposes. We believe that IPv6 is
    now mature enough to be deployed for this kind of usage.


Ok ! now, the challenge, here, should be first to stay on the scope [3]
of RPD's good practices for policy writing...

    Any IPv4 space requested for temporary usage should not be more than
    /22 - especially for meetings and events.


...the actual section 9.0 of the CPM (v1.3) clearly states that there
are other types of usages (/experiments/) for temporary resources. You
can think of a R&D project, or a serie of tests for network application,
to figure which kind of experiments such organization can wish to realize...

...then try to answer this question : 
Why must we especially restrict the prefix of temporary ressource usages
? in other words

Why are we really needing to restrict the IPv4 prefix that could be
assigned for temporary usage ? or

Is it really necessary to restrict the IPv4 prefix an entity can request
for temporary usage ?

Even if yes : how could we better achieve that when considering other
usages like experiments from researches entities including temporary
Internet measurements activities (for example) ?

    The requesting entity should use IPv6-only on their networks and
    deploy IPv4 at the edge of the network using an IPv6 transition
    mechanism.


...i see this as an interference with BCOPs style recommandations then
out of the RPD scope [3] IMHO :-/

    Lastly, we believe the title of this section of the CPM should
    reflect exactly the fact that we are dealing with assignments only
    and not allocations too.


Thanks for this useful clarification.

    3.0 Proposal

    CPM 9.0 to be modified as follows:

    9.0 Temporary Resource Assignments

    9.1 Documenting the temporary activity

    The activity requiring temporary IP resources should be publicly
    documented and available on a website reachable at least during the
    entire period of the event. Entities requiring such IP resources are
    expected to demonstrate an understanding that when the activity or
    experiment for which they require the IP resources ends, the IP
    resources will be returned to AFRINIC. A "publicly accessible
    document" is a document that is publicly and openly available free
    of charge and free of any constraints of disclosure. AFRINIC will
    not recognize any activity under this policy if such an activity
    cannot be publicly disclosed.

    9.2 Assignments of IP resources
    Resources are assigned on a lease basis for a period of one month.
    The assignment can be renewed on application to AFRINIC providing
    the necessary information. The size of the assigned IP resource will
    be determined from the plan submitted by the requesting entity. In
    the particular case of IPv4, the size cannot exceed a /22.

    9.2.1 Required Documentation:
    The requesting organisation should contact AFRINIC with the
    following information:
    a.  Details of Organisation: Legal Organisation name, Country Where
    Registered, Postal Address, Physical Address, Telephone and Fax
    Numbers, website (this is a must).
    b.  Details of activity requiring the temporary assignment: Website
    detailing the activity or Website with a link to similar previous
    activities, Links from other (relevant) sites about this activity,
    and the date when the above activity ends.
    c.   The planned use of these IP resources: List subnet size
    required, and for what it will be used plus any AS numbers and
    reverse delegation, if required.
    d.  The intended date of return of the IP resources above.

    9.3 Technical recommendations


...since i'm not for adding these kind of operational recommendations in
IP policies, i propose a different approach.

Concretely, i suggest to remove all lines below and replace it by this
*drafting text* or something more *neutral* in the sens of operationality :

[/After that the AFRINIC Staff has taken the decision to temporary
allocate some ressources to an entity, the AFRINIC Staff *must* also
provide that entity with appropriate technicals recommendations in line
with related existing BCOPs and RFCs Standards ; for conformance./]

    a.  The requesting entity is encouraged to deploy IPv6-only networks
    and push IPv4 at the edge according to an IPv6 transition mechanism
    (such as NAT64+DNS64 or 464XLAT)


Question : /is it applicable for all types of usages ? /

Again, can we really|logically recommend it to a given entity which
needs some temporary resources to realize a *particular* experiment ?

    b.  The requesting entity could base its architecture from some RFCs
    such as:
    c.  [rfc3750] (INFORMATIONAL) Unmanaged Networks for IPv6 Transition
    Scenarios
    d.  [rfc4213] (Standards Track) Basic Transition Mechanisms for IPv6
    Hosts and Routers
    e.  [rfc6180] (INFORMATIONAL) Guidelines for Using IPv6 Transition
    Mechanisms during IPv6 Deployment


My personal thought and huge will is that the AFRINIC Community has its
BCOPs repository where a BCOP for “Operational|Practical Uses of
Temporary Resources Assigned” might contain some of the above
recommendations. 

...so, to achieve the goal of more IPv6[-only] deployment in AFRINIC
region, we should not bring operational, even legitimate, orientations
on IP Policies, but let's try to do other things including to produce
more Best Current Operational Practice (BCOPs) with our NOG communities... 

    [...]


I think that this policy draft should use the approach of the section
6.6 [4] of the CPM (v1.3) for more coherence. It is about assignments
for internet experiments only when it belong to IPv6. Then the duration
of the lease is twelve months. If you want a technical event organiser
to use more IPv6 during theirs meetings, you can precise that the
minimum of the temporary term is different for IPv4 and for IPv6
resources. So they will be able to organize more than one event before
coming back to AFRINIC for a new lease.

Even the sectioon 6.6 [4] of the CPM (v1.3) needs some improvements, but
we should begin by correcting what we can here and trying to prevent any
overlap with the said sectioon 6.6 [4] ;-)

...three things to considere :
 * Limitation of the number of times an entity can request for extension
of the same lease ?
 * Differenciation on the conditions of the lease for IPv4 and IPv6 ?
 * Differenciation on the type of resources to temporary assign ?
__
[1]: https://www.afrinic.net/library/policies/697-ipv4-soft-landing-policy
[2]: https://afrinic.net/policy/manual
[3]: https://afrinic.net/policy/manual#Scope-PDP
[4]: https://afrinic.net/policy/manual#Assignments-Internet-Experiments

Regards,
--sb.

-- 

Regards,
Sylvain B.
<http://www.chretiennement.org> 
__
Website : <https://www.cmnog.cm>
Wiki : <https://www.cmnog.cm/dokuwiki>
Surveys : <https://survey.cmnog.cm>
Subscribe to Mailing List : <https://lists.cmnog.cm/mailman/listinfo/cmnog/>
Mailing List's Archives : <https://lists.cmnog.cm/pipermail/cmnog/>
Last Event's Feed : <https://twitter.com/hashtag/cmNOGlab3>
<https://twitter.com/cmN0G>
<https://facebook.com/cmNOG>
<https://twitter.com/hashtag/REBOOTcmNOG>
<https://twitter.com/hashtag/cmNOG>
<https://cmnog.wordpress.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190418/652a2ba8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x0387408365AC8594.asc
Type: application/pgp-keys
Size: 4826 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190418/652a2ba8/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20190418/652a2ba8/attachment-0001.sig>

More information about the RPD mailing list