diff --git a/ripe-738.txt b/ripe-738.txt
index 98986c3..18589f6 100644
--- a/ripe-738.txt
+++ b/ripe-738.txt
@@ -112,9 +112,14 @@ To “allocate” means to distribute address space to IRs for the purpose of su
 
 2.6. Assign
 
-To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organisations and are not to be sub-assigned to other parties.
+To “assign” means to delegate address space to an ISP or End User for specific use within the Internet infrastructure that ISP or End User operates. Assignments must only be made for specific purposes documented by specific organisations, and an assignment holder is not allowed to create further sub-assignments to another entity from address space partially or fully covering an assignment.
 
-Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder's network, connecting a server or appliance to an assignment holder's network and setting up point-to-point links with 3rd parties.
+Providing another entity inside the assignment holder's network and located at the same geographical end-site with prefix sizes of /56 or longer, e.g., for letting visitors connect to the assignment holder's network, providing static addresses when connecting a server or appliance to an assignment holder's network, or providing a single service with multiple addresses is not considered a sub-assignment.
+
+Similarly, using a /64 or longer when setting up point-to-point links with other ISPs for the purpose of exchanging traffic and Internet routing information does not constitute a sub-assignment.
+Any other use of a prefix from an assignment up to prefixes of /128 bit, i.e., up to single addresses, to connect an end-site of another entity to the Internet, always constitutes a prohibited sub-assignment.
+
+Finally, using more specific prefixes from a less-specific assignment for different parts of the same infrastructure within one organziation does not constitute a sub-assignment, if the purpose of the assignment is the operation of that infrastructure.
 
 2.7. Utilisation
 
@@ -133,12 +138,18 @@ where (in the case of this document) the objects are IPv6 site addresses assigne
 
 2.9. End Site
 
-An End Site is defined as the location of an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves:
+An End Site for assignments from a provider's allocation is defined as the topological location of an End User (subscriber) in the RIPE NCC Service Region who has a business or legal relationship (same or associated entities) with a service provider that involves:
  *that service provider assigning address space to the End User location
  *that service provider providing transit service for the End User location to other sites
  *that service provider carrying the End User's location traffic
  *that service provider advertising an aggregate prefix route that contains the End User's location assignment
 
+An End Site for provider independent assignments (PI) directly to an End User from the RIPE NCC via a sponsoring LIR or directly to an LIR is defined as any topological location in the RIPE NCC Service Region where the End User deploys Internet connected devices, which has a different routing policy than other End Sites of that End User.
+Furthermore, the following considerations hold:
+ *different routing policies can be realized, for example, by ensuring that traffic towards this End Site does not travers other End Sites of the assignment holder, unless, e.g., a loss of outbound connectivity occurs at the End Site where a prefix is used
+ *a Layer 2 connection between two End Sites does not make them one End Site as long as both End Sites have different routing policies
+ *placing a single device at a location for the main purpose of providing Internet access to a single End User / Customer present at that location does not make that location an End Site of an assignment holder
+
 3. Goals of IPv6 address space management
 
 3.1. Goals
@@ -251,7 +262,7 @@ If an LIR needs more address space, it must provide documentation justifying its
 
 There is no specific policy for an LIR to allocate address space to subordinate ISPs. Each LIR organisation may develop its own policy for subordinate ISPs to encourage optimum utilisation of the total address block allocated to the LIR. However, all /48 assignments to End Sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary.
 
-5.4. Assignment
+5.4. Assignments by LIRs from their allocation
 
 LIRs must make IPv6 assignments in accordance with the following provisions.
 
@@ -259,9 +270,9 @@ LIRs must make IPv6 assignments in accordance with the following provisions.
 
 End Users are assigned an End Site assignment from their LIR or ISP. The size of the assignment is a local decision for the LIR or ISP to make, using a value of "n" x /64. Section 4.2 of ripe-690 provides guidelines about this.
 
-5.4.2. Assignments shorter than a /48 to a single End Site
+5.4.2. Assignments from PA shorter than a /48
 
-Assignments larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage or because different routing requirements exist for additional assignments.
+Assignments made by an LIR from their allocation to an End User larger than a /48 (shorter prefix) or additional assignments exceeding a total of a /48 must be based on address usage, or because routing requirements necessitate a larger assignment.
 
 In case of an audit or when making a request for a subsequent allocation, the LIR must be able to present documentation justifying the need for assignments shorter than a /48 to a single End-Site.
 
@@ -303,9 +314,39 @@ The PI assignment cannot be further sub-assigned to other organisations.
 
 7.1. IPv6 Provider Independent (PI) Assignment Size
 
-The minimum size of the assignment is a /48.
+PI assignments are made to End Users for uses within their infrastructure that do not require sub-assignments according to "2.6. Assign".
+PI assignments have a prefix length of /48 or shorter, i.e., cannot be of prefix length /49-/128.
+
+To avoid fragmentation, shorter assignments are possible based on addressing need analogous to Section 5.4.2. and for End Users with multiple End Sites according to "2.9 End Site", e.g., when with different routing requirements exist for these End Sites.
+When requesting an assignment of a prefix shorter than a /48, or when making a request for a larger or additional assignments, the End User must be able to present documentation justifying the need for assignments shorter than a /48, for example, by providing information on the current and/or planned routing policies in place for each End Site, or by providing documentation on the number of devices to be connected at that End Site.
+
+7.1.1. PI Assignment at the Nibble Boundary
+
+To aid aggregation as per "3.4. Aggregation" / "3.8. Conflict of Goals" and reduce the need for renumbering in case of futher growth as per "3.7. Minimised Overhead", justified assignments are to be made in nibble boundary steps, i.e., starting with /48, followed by /44, /40 etc. in steps of 4 bit, instead of assigning multiple shorter prefixes.
+This means that an End User demonstrating the need for at least two /48s, e.g., due to two End Sites should receive a /44, and an End User demonstrating the need for at least seventeen /48s, e.g., due to seventeen different End Sites should receive a /40 etc.
+It is recommended that address space up to the next nibble boundary is reserved if an End User qualifies for a PI assignment of a specific size.
+
+Registrations for PI assignmets made under this policy are atomic and cannot be split up into smaller prefixes, e.g., a /44 of assigned PI cannot be broken into two or more independent assignments held by the same or different entities.
+This does not relate to routing, i.e., one or multiple more specific prefixes from an assignment may be individually routed, as long as no sub-assignment takes place.
+
+7.1.2. Requesting a Larger Assignment
+
+If an End User or LIR already holding a PI assignment made under this policy needs a larger Assignment, the End User or LIR must submit a request for a larger assignment and not for one or multiple additional assignments.
+This request can be granted, if the criteria for a larger assignment are met as per "7.1. IPv6 Provider Independent (PI) Assignment Size".
+When granted, and a reservation for the assignment holder or sufficient unallocated space around the current assignment exists, the assignment must be extended to the next nibble boundary.
+If the requested extension to the next nibble boundary cannot be satisfied from an existing reservation or adjacent unallocated space, the End User or LIR receives a new Assignment as per "7.1.1. PI Assignment at the Nibble Boundary" and must return the previous assignment after a six month renumbering period.
+
+7.1.3. Existing PI Assignments
+
+If an End User or LIR, holding one or multiple existing PI assignments, requests an aditional assignment or enlargement of one or multiple of their existing assignment, the request is handled as per "7.1.2. Requesting a Larger Assignment", even if those assignments were made under previous versions of this policy.
+This means that their addressing need will be assessed according to "7.1.2. Requesting a Larger Assignment" and they will receive a single assignment corresponding to the result of that evaluation.
+If the new assignment can be satisfied by the available reservation or adjacent unallocated space of an existing PI assignment to the assignment holder, this option should be used.
+If multiple existing assignments satisfy this requirement, the End User's preference for which assignment to expand should be considered.
 
-The considerations of "5.4.2. Assignments shorter than a /48 to a single End-Site" must be followed if needed.
+Apart from the newly received or extended PI assignment, all other PI assignments must be returned to the NCC after a period for renumbering as soon as the new PI assignment has been created or an existing one was extended.
+The renumbering period for PI assignments previously made under the current version of this policy is six months.
+For PI assignments whose requests were evaluated based on a previous version of this policy, the initial renumbering period is twelve months, which can be extended by twelve months every twelve months, if the End User provides the NCC with documentation demonstrating that a renumbering is currently not feasible, e.g., due to high costs or operational complexity.
+Even though, technically, the renumbering period can thereby extended indefinately, return of these PI assignments remains mandated.
 
 7.2. IPv6 Provider Independent (PI) Assignments for LIRs
 
