[address-policy-wg] 2014-10 New Policy Proposal (Language Clarification in "IPv6 Addresses for Internet Root Servers In The RIPE Region")

On 23/10/2014 21:03, Peter Koch wrote:
> 1) the motivating pointer to RFC 2119 is misguided. RIPE documents do not
>    make a reference to RFC 2119 in general and even less so in this particular
>    case. There's already enough confusion in the IETF with "must"
>    vs "MUST", i.e., when keywords do and don't bear their special meaning.

The proposal does not draw a distinction between "must" and "MUST".  RIPE
documents can start referencing 2119 today, if they want.

> 2) the change is unnecessary and does not provide clarification.
>    The text is already clearly stating that assigned address space stays
>    with the service and will (have to) be returned to the RIPE NCC if
>    the service is terminated.  A "should" is sufficient.

"should" means: "really ought to, but if not then whatevs", which is not
the intention of the policy.  Probably the RIPE NCC would implement this
"must" if there were a new request, so clarification of intent is not a bad
idea.

> 3) The status of ripe-233, especially in the light of the omnibus document
>    ripe-623 is probably a bit vague.  

ripe-233 applies solely to ipv6 space; ripe-623 applies to ipv4 space.
It's not clear why this is relevant either.

> ripe-233 exists for historic reference,
>    therefore any change applied by this proposal would retroactively try
>    to change the rule for past assignments with no new assignments to be
>    expected (for lack of policy).

ripe-233 / successor exist not just for historic reference, but may apply
to future assignments if there are reassignments of root servers in the
future.  The future is a long time.

Re: retroactive changes, are there any ipv6 assignments made to root
servers which use the ipv6 addresses for other purposes?  I.e. is the RIPE
community asking that actual behaviour be changed?

> 4) Issuing a new document with a new timestamp is likely to cause more
>    confusion than it strives to solve (lacking sth equivalent to a
>    "Historic" document status and/or explanatory introductory text
>    in the updated document).

This seems to be an argument that policy updates shouldn't happen because
they might confuse people.

Nick