Language Clarification in “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”
This policy proposal has been accepted
The new RIPE Document is: ripe-634
- State:
- Accepted
- Publication date
- Affects
- Draft document
- Draft
- Author
- Proposal Version
- 1.0 - 20 Oct 2014
- All Versions
-
- Accepted
- 11 Mar 2015
- Working Group
- Address Policy Working Group
- Proposal type
-
- Modify
- Policy term
- Indefinite
- New RIPE Document
Summary of Proposal
The RIPE NCC service region relies on clear and consistent policies. During RIPE 67, Jan Žorž raised the issue that the use of the word “should” could create unwanted ambiguity in policy documents.
According to RFC 2119, the term “should” means that there may exist valid reasons to ignore a particular item. Correspondingly, the term “must” means that the definition is an absolute requirement of the specification.
The RIPE NCC has reviewed “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” and found several occasions where “should” was used while the content and context indicate that “must” would be the appropriate term.
These findings were presented during RIPE 68 and it was agreed that the policy text should be clarified.
This proposal aims to clarify the language in the RIPE Document “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”.
Policy Text
[The following text will update sections 3.1, 5.4 and 7.0 in the RIPE Document “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”, if the proposal reaches consensus.]
a. Current policy text
“3.1 Confidentiality
Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and should not be distributed wider than necessary within the IR. […]”
b. New policy text
“3.1 Confidentiality
Internet Registries (IRs) have a duty of confidentiality to their registrants. Information passed to an IR must be securely stored and must not be distributed wider than necessary within the IR. […]”
c. Current policy text
“5.4 Sub-allocations
[...] LIRs wishing to convert their allocations to PA status should contact the RIPE NCC by email at [email protected]. [...]
d. New policy text
“5.4 Sub-allocations
[...] LIRs wishing to convert their allocations to PA status must contact the RIPE NCC by email at [email protected]. [...]
e. Current policy text
“7.0 Types of Address Space
[...] Clear contractual arrangements are mandatory for PA space. End Users requesting PA space should be given this or a similar warning:
Assignment of this IP space is valid as long as the criteria for the original assignment are met
[...]
LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR- PARTITIONED is not considered used. When the addresses are used, a more specific inetnum should be registered.
LIR-PARTITIONED PI: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum should be registered. […]”
f. New policy text
“7.0 Types of Address Space
[...] Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning:
Assignment of this IP space is valid as long as the criteria for the original assignment are met
[...]
LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR- PARTITIONED is not considered used. When the addresses are used, a more specific inetnum must be registered.
LIR-PARTITIONED PI: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum must be registered. […]”
Rationale
a. Arguments supporting the proposal
- Unambiguous understanding of the policy text
- The policy text allows distributing confidential information if necessary. There are no other valid reasons
- Only the RIPE NCC can convert the status of allocations. Using the word “must” avoids possible confusion that there might be alternative ways to convert the status
- As clear contractual arrangements are mandatory for PA space, also the warning for End Users must be mandatory
- The use of address space must be registered in the RIPE Database, this is one of the goals of the Internet Registry System
b. Arguments opposing the proposal
- These changes will reduce the level of flexibility when interpreting the policy text
Impact Analysis
Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented.
A. RIPE NCC's Understanding of the Proposed Policy
It is the RIPE NCC's understanding that this proposal clarifies the language in RIPE Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" by removing unwanted ambiguity created by the term "should". The replacement with the term "must" confirms the policy's intention of mandatory requirements: Internet Registries can not distribute information wider than necessary, LIRs must contact the RIPE NCC to convert their allocations to PA status, End Users requesting PA space must get a warning regarding the requirements and assignments, and it is mandatory to create assignments for address space in use within LIR-PARTITIONED PA and LIR-PARTITIONED PI.
This is in line with current RIPE NCC procedures.
B. Impact of Policy on Registry and Addressing System
Address/Internet Number Resource Consumption:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
Fragmentation/Aggregation:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
C. Impact of Policy on RIPE NCC Operations/Services
Registration Services:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
Billing/Finance Department:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
RIPE Database:
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
D. Legal Impact of Policy
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented.
E. Implementation
If this proposal is accepted it will be able to be implemented immediately, as existing procedures, tools and documentation are in line with this policy understanding.