Re: [address-policy-wg] 2014-10 New Policy Proposal (Language Clarification in âIPv6 Addresses for Internet Root Servers In The RIPE Regionâ)
On Thu, Oct 23, 2014 at 03:37:23PM +0200, Marco Schmidt wrote:
A proposed change to RIPE Document "IPv6 Addresses for Internet Root Servers In The RIPE Region" is now available for discussion.
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. 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. 3) The status of ripe-233, especially in the light of the omnibus document ripe-623 is probably a bit vague. 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). 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). Resolved, no support -Peter
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
participants (2)
-
Nick Hilliard -
Peter Koch