You are here: Home > Participate > Policy Development > Policy Proposals > 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

Language Clarification in “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”

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 lir-help _at_ ripe _dot_ net. [...]

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 lir-help _at_ ripe _dot_ net. [...]

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.

Get Involved

The Address Policy Working Group develops policies relating to the allocation and registration of Internet number resources (IPv4 and IPv6 addresses and ASNs) by the RIPE NCC and its members. Anyone with an interest in Internet numbering issues is welcome to observe, participate and contribute to the WG. To post a message to the list, send an email to address-policy-wg@ripe.net. Please note that only subscribers can post messages.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum

Please contact if you need more information.

Stay up to date!

Follow @PDO_RIPE_NCC on Twitter.