Re: [address-policy-wg] 2014-08 New Policy Proposal (Language Clarification in âContractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Regionâ)
On Thu, Oct 23, 2014 at 03:15:24PM +0200, Marco Schmidt wrote:
A proposed change to RIPE Document "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" is now available for discussion.
# Any resources allocated/assigned to the RIPE NCC will be registered in the # RIPE Database. All policies set for allocating or assigning resources to # LIRs apply equally to the RIPE NCC. The RIPE NCC as a resource holder should # fulfil the same basic requirements also expected of normal LIRs, such as returning # unused resources. As an exception from normal LIRs, RIPE NCC as a resource holder # is exempted from signing any of the normal contracts required for number resource allocation/assignment. RFC 2119, as mentioned in the introduction, is not relevant to this document (see earlier mail). In this case, the change appears straightforward even if should vs must was interpreted in a natural language context. On second thought, it remains undefined what the "basic requirements" are (leaving another ambiguity) and it isn't clear whether the list of exemptions is exhaustive. As an example: is the NCC undergoing a regular or case by case audit and who is supposed to execute that? Arbiters are supposed to evaluate requests, but how would the NCC's adherence to the "basic requirements, [...] such as returning unused resources" be supervised? There's no vox populi appeal to the arbiters. But wait, we have a general community involvement in the NCC's operation and my perception was it was considered functioning. So, I'm not really convinced that an s/should/must/ would prevent the NCC from running wild if it wanted to. On the other hand, I might be looking forward to future policy proposals and further should vs must (or similar) discussions except that the PDP rarely provides the right slot for this level of detail. In other words: what's being tried to fixed here is likely to happen again. Back to 2014-08: it's either unnecessary or incomplete. -Peter PS: Obviously in this case it is prudent for the NCC as the submitter to err on the side of caution
On 23/10/2014 21:50, Peter Koch wrote:
In this case, the change appears straightforward even if should vs must was interpreted in a natural language context. On second thought, it remains undefined what the "basic requirements" are (leaving another ambiguity) and it isn't clear whether the list of exemptions is exhaustive. As an example: is the NCC undergoing a regular or case by case audit and who is supposed to execute that? Arbiters are supposed to evaluate requests, but how would the NCC's adherence to the "basic requirements, [...] such as returning unused resources" be supervised? There's no vox populi appeal to the arbiters. But wait, we have a general community involvement in the NCC's operation and my perception was it was considered functioning. So, I'm not really convinced that an s/should/must/ would prevent the NCC from running wild if it wanted to. On the other hand, I might be looking forward to future policy proposals and further should vs must (or similar) discussions except that the PDP rarely provides the right slot for this level of detail. In other words: what's being tried to fixed here is likely to happen again.
Peter, You may have misunderstood this one. The change from "should" to "must" refers explicitly to the 6 points which need to be included in all end-user contracts, namely:
- Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date - Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database - Notice that none of the provider independent resources may be sub-assigned to a third party - Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources - A clear statement that the resources will return by default to the RIPE NCC if The resource holder cannot be contacted The annual fee to the LIR is not paid - A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time
re:
Back to 2014-08: it's either unnecessary or incomplete.
It looks like an eminently reasonable proposal to me. It was never intended that these six points be optional. Nick
On Thu, Oct 23, 2014 at 10:30:27PM +0100, Nick Hilliard wrote:
You may have misunderstood this one. The change from "should" to "must" refers explicitly to the 6 points which need to be included in all end-user contracts, namely:
thanks, Nick, my mistake, indeed. 2014-08 seemed OK (except for the misapplication of RFC 2119). The comments were in response to 2014-07, "Language Clarification in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" -Peter
On 24/10/2014 07:16, Peter Koch wrote:
thanks, Nick, my mistake, indeed. 2014-08 seemed OK (except for the misapplication of RFC 2119). The comments were in response to 2014-07, "Language Clarification in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
Uh, are you sure the comments weren't intended for 2014-11? At least one of us is thoroughly confused here, possibly both. Nick
On Fri, Oct 24, 2014 at 03:20:52PM +0100, Nick Hilliard wrote:
On 24/10/2014 07:16, Peter Koch wrote:
thanks, Nick, my mistake, indeed. 2014-08 seemed OK (except for the misapplication of RFC 2119). The comments were in response to 2014-07, "Language Clarification in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
Uh, are you sure the comments weren't intended for 2014-11? At least one of us is thoroughly confused here, possibly both.
you aren't, I was and that twice, which is why I decided, after noting it, to move slowly, stick to handrails all day and probably throttle postings a bit. Still I think I said what I meant and still mean w.r.t. policies affecting the NCC. Have a nice weekend, Peter
Hi, On Fri, Oct 24, 2014 at 04:31:37PM +0200, Peter Koch wrote:
Uh, are you sure the comments weren't intended for 2014-11? At least one of us is thoroughly confused here, possibly both.
you aren't, I was and that twice, which is why I decided, after noting it, to move slowly, stick to handrails all day and probably throttle postings a bit. Still I think I said what I meant and still mean w.r.t. policies affecting the NCC.
After you deconfuse yourself, please send the comments in the thread relating to that proposal, with the subject identifying the particular proposal they apply to. Otherwise it will be absolutely impossible for Sander and me later on to sort out which comment was sent to proposal X but really applies to Y or Z (and FTR, I'll formally ignore this particular subthread, since it was officially not intended for 2014-07 or 2014-08). thanks, Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (3)
-
Gert Doering -
Nick Hilliard -
Peter Koch