This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)
- Previous message (by thread): [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Mon Jan 15 17:59:22 CET 2018
Below, in-line. Saludos, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces at ripe.net> en nombre de Sander Steffann <sander at steffann.nl> Fecha: lunes, 15 de enero de 2018, 17:37 Para: JORDI PALET MARTINEZ <jordi.palet at consulintel.es> CC: <address-policy-wg at ripe.net> Asunto: Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification) 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. [Jordi] I think we are in-sync, but your response clearly demonstrates that there is a need for clarifying the text. -> Policy proposal “Providing another entity with separate addresses (not prefixes)” -> a /64 is a prefix > 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. [Jordi] Again, we are in-sync, but I don’t agree that DHCPv6-PD is the only way, and the actual proposal text doesn’t state it, even if the argument of the proposal explain it. Can the NCC confirm if they apply the policy text or the “arguments” of the policy proposal? I think it is the policy text, so we are missing something. > 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. [Jordi] I fully understand that text, but still think that is not the same if I run a host/server in a hotspot, with many VMs, using RFC8273 or DHCPv6-PD or a manual or proprietary mechanisms, which I fully understand within the intent of the policy (and I agree), vs running a complete data center (which typically is using non-temporary addresses/prefixes). Again, I think it may be clear in the argument of the proposal, but not in the policy text. Which one is used by NCC to evaluate a request? > 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 :) [Jordi] Believe me, I’m not interested in appealing, I’m interested in reaching consensus on a text that is coherent. My reading of the actual situation is that even if it may look that we have consensus, when you re-read everything and put it together towards implementing the policy, it doesn’t work. The text is not concrete enough so to be enforced in the evaluation (again, unless the NCC read the arguments and not the policy text). > 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 <wg-chairs at ripe.net> Cheers, Sander ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
- Previous message (by thread): [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]