Hi Nick,
the issue that concerns me is that creating a requirement for a contract means that there is a requirement for legal people to be involved in the transfer process. Whatever about legal wording in civil law countries (NL, most of europe), common law countries (ie/uk/us, etc) generally tend to benefit from more specific wording. If there is any hint of ambiguity, it creates the possibility of argument and that is painful when it happens.
There are always agreements/contracts in place, also with the current transfer processes. In this particular case you will have to think about an End-User Agreement (for PI IPv6) to be in place with an Sponsoring LIR. Also each transfer needs to be accomplished with a so called Transfer Agreement (template from RIPE).
The term "minimum assignment size" is used sloppily all over the place in the ripe policy document store to mean different things in different places. In this case, the wording isn't particularly ambiguous to you or me, but it would not necessarily be clear at first sight to the man on the Clapham omnibus. If five uncontentious words were added, this would make its interpretation completely clear.
And with that man on the Clapham omnibus you refer to a hypothetical reasonable person ... ( I had to look it up ... ) The irony ..
Weighing things up, common sense suggests that it would be more sensible to clarify than not.
Previous policy proposals have had clarification text added between phases, so it's possible that adding the text wouldn't necessarily delay the proposal - obviously this is a decision for the ap-wg chairs.
As we are going into a full re-styling of the Transfer Policies into a single document, we will have to see if it is going to be required to do that in this particular version or in the next re-style. There is little value imho to add clarification text here as we are going to cut the text in a couple weeks into a new document. If that new version needs a beter explanation it would make more sense in doing it there.
As a more general observation, it might be useful for a future unified policy to differentiate between depleted resources (e.g. ipv4 / asn16) and non depleted resources (e.g. ipv6 /asn32) and make it clear that the cooling off period is intended depleted resources.
I like the suggestion to look into the structure and difference between depleted and non depleted resources. I'll take that in mind for the Transfer doc. Thanks Nick, Regards, Erik