Hi, > My reading of PDP 2.4 is [..]
Please stop being a lawyer. I have told you how we do things in this working group. Please listen to what the chairs are telling you. > My reason to re-raise those now, is because they become evident when you > compare the proposed 2.6 change with the policy proposal arguments AND > specially the impact analysis, contradictions which for some reason, I didn’t > discover before (so disagree with you, those points aren’t the same I raised > before, may be similar, but the reason now is the contradictory text), and > this seems to be in the scope of PDP 2.4. I think you are mis-interpreting the policy proposal. I see no such contradiction. > The author of the proposal and the NCC could confirm their intent: > 1) Is the proposal looking for disallowing a /64 ? If so, then the impact > analysis is broken and NCC is looking to implement something different than > what the proposal is asking for. The policy is explicitly not mentioning prefix lengths but clarifying intentions. Delegating a prefix is still not allowed. The NCC explains in the impact analysis that having only a single device/user/etc on a subnet (i.e. RFC8273) is treated the same as having multiple users on a subnet: both are not considered assignments and are therefore permitted. > 2) The proposal clearly is NOT intended for “permanent” broadband services, > but his is NOT stated in the proposed text change. I doubt that the NCC can > enforce a policy that don’t have that stated in the policy text. Can the NCC > confirm that? The proposal adds a one-paragraph extension to the existing policy to allow connecting devices to a network: "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. [...and some examples...]". There are more use-cases than you and I can think of, and trying to enumerate which ones are allowed and which ones aren't is bad overengineering. This has been discussed before. And these days it's not viable to provision broadband customers without delegating (DHCPv6-PD) address space to them anyway. > 3) I also believe that the policy isn’t pretending to be used in data > centers. Can this be clarified? Where did you get that idea? "connecting a server or appliance to an assignment holder's network" is one of the explicit examples of what is allowed. > Regarding a possible appeal. The procedure talks about “unless there are > exceptional extenuating circumstances”. > > I think it is the case for an impact analysis contradicting the proposal. I think you are reading more into this proposal that what is actually there, and based on that have misinterpreted it. > Is up the chairs to decide that, of course and I understand that you may need > to wait until the end of the last call to decide on that (this is the reason > why I understand that the appeal doesn’t make sense now, unless you have > already taken a decision). You're misunderstanding what we are suggesting you appeal to. We're suggesting you appeal the decision that there was consensus at the end of the review phase and that the proposal was ready to go to last-call. If you don't agree with that decision then you can appeal it. At the end of last-call there will be another decision about whether we have consensus or not, based on the feedback received during last-call. That decision has (of course) not been made yet, but as I said in my previous email I so far haven't seen any reasons that block that consensus *yet*. We'll have to wait for the end of last-call to make a final judgement :) > If you believe is not the case, then, please let me know how to send the > appeal to the “Working Group Chairs Collective (WGCC)”, I guess there is a > mailing list for that? Sure: RIPE WG Chairs <[email protected]> Cheers, Sander
