2023-03 status problem

Hello working group, As the authors were in a bit of a difficult position. The chairs won't move this policy proposal forward as there was no feedback during the discussion phase. We were under the impression that the chairs had extended the deadline of the phase as we did talk about that, but it didn’t actually happen. When I sent my reminder the discussion phase was therefore already over, so all the support and feedback we got then Doesn’t Count™. They have indicated that they will only reopen the discussion phase if they know that there actually will be engagement for this to be meaningful. So, can the people who are interested in this proposal please pinky swear that they will contribute if it does get another discussion phase? ;) You may have to repeat your feedback in the proper phase of the PDP to be counted. This approach is less pragmatic than I would have chose when I was a chair, but this is not my working group :) And the chairs are right that the reason for this being a policy proposal is that the NCC (legal) team wants formal community support, so I can see why they are following the process to the letter. So let’s do this formally right. PS: Denis, thank you for your contribution! We’re going to ask the RIPE NCC to comment on the interaction between the policies, and whether a separate policy like this one (with maybe a cleanup of the text in Address Policy) is preferred to integrating this in the transfer policy or not. Considering that the RIPE NCC gave us a hard deadline to get this policy in place, I’m hesitant to restart the whole process this late. Cheers! Sander --- for every complex problem, there’s a solution that is simple, neat, and wrong

Hi, On Mon, May 15, 2023 at 12:10:22PM +0200, Sander Steffann wrote:
As the authors were in a bit of a difficult position. The chairs won't move this policy proposal forward as there was no feedback during the discussion phase.
I would argue that it's *their* job to solicit feedback in time for the deadline, not yours, and also it's *their* job to ask their WG what it wants. I think this is a spectacular failure and should have never entered the PDP, but if at all, it should have been APWG as Denis pointed out. Besides, I've stated often enough that I support the idea, so, no, I will not satisfy bureaucratics here by repeating it once more. Let the proposal fail if the lawyers want it that way. Gert Doering -- policy wonk -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

<tangent>
Let the proposal fail if the lawyers want it that way.
there is an underlying problem on this vector. the lawyers work for the ncc and, correctly, protect the ncc, not the community. randy

On 2023 May 15 (Mon) at 12:10:22 +0200 (+0200), Sander Steffann wrote: :Hello working group, : :As the authors were in a bit of a difficult position. The chairs won't move this policy proposal forward as there was no feedback during the discussion phase. : :We were under the impression that the chairs had extended the deadline of the phase as we did talk about that, but it didn’t actually happen. When I sent my reminder the discussion phase was therefore already over, so all the support and feedback we got then Doesn’t Count™. They have indicated that they will only reopen the discussion phase if they know that there actually will be engagement for this to be meaningful. : :So, can the people who are interested in this proposal please pinky swear that they will contribute if it does get another discussion phase? ;) You may have to repeat your feedback in the proper phase of the PDP to be counted. This approach is less pragmatic than I would have chose when I was a chair, but this is not my working group :) And the chairs are right that the reason for this being a policy proposal is that the NCC (legal) team wants formal community support, so I can see why they are following the process to the letter. So let’s do this formally right. : :PS: Denis, thank you for your contribution! We’re going to ask the RIPE NCC to comment on the interaction between the policies, and whether a separate policy like this one (with maybe a cleanup of the text in Address Policy) is preferred to integrating this in the transfer policy or not. Considering that the RIPE NCC gave us a hard deadline to get this policy in place, I’m hesitant to restart the whole process this late. : :Cheers! :Sander What a waste of time. The charis need to sort this out and stop fucking up a clearly desired and clearly necessary thing. If they can't, or aren't willing to, then they should step down. -- Fuch's Warning: If you actually look like your passport photo, you aren't well enough to travel.

Hi Sander, I will repeat myself on what I've stated earlier on this .. This shouldn't be a PDP / policy topic, but an operation implementation on the portal. Which doesn't require a policy change as far as I'm aware of. The requested change to the LIR portal, is similar ( imho ) to adding 2FA .. it is the decision of the NCC to offer the option, it is the decision of the LIR to actually use it or not .. With the risk of being locked out of the LIR portal, if they don't manage their 2FA properly .. This shouldn't be a policy and yes I've heard what Athena said .. I disagree with her on this topic .. This should be decided by the EB and implemented by the NCC. If the WG didn't receive any feedback during the discussion phase, this means that policy making is still decided by around 20 ish people in the community of 22.000 ... And nobody was interested enough to be bothered .. and the intended targets of the portal change are probably hiding in shelters or walking through the fields ... If this was decided that it is a PDP topic, the chance is that the opposition of the conflict, could also provide opposition on the PDP / proposal here.. And that is why in this particular situation, PDP isn't the solution here. I'm not against the proposal, I don't think this should be put through PDP for said reasons. Regards Erik Bais On 15/05/2023, 12:10, "ncc-services-wg on behalf of Sander Steffann" <ncc-services-wg-bounces@ripe.net <mailto:ncc-services-wg-bounces@ripe.net> on behalf of sander@steffann.nl <mailto:sander@steffann.nl>> wrote: Hello working group, As the authors were in a bit of a difficult position. The chairs won't move this policy proposal forward as there was no feedback during the discussion phase. We were under the impression that the chairs had extended the deadline of the phase as we did talk about that, but it didn’t actually happen. When I sent my reminder the discussion phase was therefore already over, so all the support and feedback we got then Doesn’t Count™. They have indicated that they will only reopen the discussion phase if they know that there actually will be engagement for this to be meaningful. So, can the people who are interested in this proposal please pinky swear that they will contribute if it does get another discussion phase? ;) You may have to repeat your feedback in the proper phase of the PDP to be counted. This approach is less pragmatic than I would have chose when I was a chair, but this is not my working group :) And the chairs are right that the reason for this being a policy proposal is that the NCC (legal) team wants formal community support, so I can see why they are following the process to the letter. So let’s do this formally right. PS: Denis, thank you for your contribution! We’re going to ask the RIPE NCC to comment on the interaction between the policies, and whether a separate policy like this one (with maybe a cleanup of the text in Address Policy) is preferred to integrating this in the transfer policy or not. Considering that the RIPE NCC gave us a hard deadline to get this policy in place, I’m hesitant to restart the whole process this late. Cheers! Sander --- for every complex problem, there’s a solution that is simple, neat, and wrong -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ncc-services-wg <https://lists.ripe.net/mailman/listinfo/ncc-services-wg>

Hi Erik I would disagree with you here as a matter of principle. On Mon, 15 May 2023 at 14:47, Erik Bais <erik@bais.name> wrote:
Hi Sander,
I will repeat myself on what I've stated earlier on this ..
This shouldn't be a PDP / policy topic, but an operation implementation on the portal. Which doesn't require a policy change as far as I'm aware of. The requested change to the LIR portal, is similar ( imho ) to adding 2FA .. it is the decision of the NCC to offer the option, it is the decision of the LIR to actually use it or not
I understand that you are focussed on the current issue. But this has wider implications. What you are suggesting here is that the RIPE NCC can offer a service so that individual LIRs can choose to ignore RIPE policy. That is a very dangerous precedent. It completely undermines the whole community based PDP. It allows an LIR to decide to use a service the NCC has decided to offer that prevents a resource from being transferred. The Transfer policy says that resource CAN be transferred. So the combined decisions of the NCC and the LIR violates the Transfer policy. I also don't think the EB has the right to allow the NCC to offer such a service in the long term. As a short term, emergency arrangement, that is fine. But the EB should not have the right to override RIPE policy. The only way to do this is to put an opt out clause in the Transfer policy. Then invoking the opt out, and effectively locking the transfer of a specific resource, complies with the policy and doesn't violate it. As for people involved in any conflict opposing the policy change, keep in mind that consensus is not a vote. Numbers don't count. To oppose the change people must present sound objections. "I want to force someone to transfer resources to me against their free will" is not an acceptable objection and can be discounted by the WG chairs when determining consensus. cheers denis
With the risk of being locked out of the LIR portal, if they don't manage their 2FA properly ..
This shouldn't be a policy and yes I've heard what Athena said .. I disagree with her on this topic ..
This should be decided by the EB and implemented by the NCC.
If the WG didn't receive any feedback during the discussion phase, this means that policy making is still decided by around 20 ish people in the community of 22.000 ... And nobody was interested enough to be bothered .. and the intended targets of the portal change are probably hiding in shelters or walking through the fields ...
If this was decided that it is a PDP topic, the chance is that the opposition of the conflict, could also provide opposition on the PDP / proposal here.. And that is why in this particular situation, PDP isn't the solution here.
I'm not against the proposal, I don't think this should be put through PDP for said reasons.
Regards Erik Bais
On 15/05/2023, 12:10, "ncc-services-wg on behalf of Sander Steffann" <ncc-services-wg-bounces@ripe.net <mailto:ncc-services-wg-bounces@ripe.net> on behalf of sander@steffann.nl <mailto:sander@steffann.nl>> wrote:
Hello working group,
As the authors were in a bit of a difficult position. The chairs won't move this policy proposal forward as there was no feedback during the discussion phase.
We were under the impression that the chairs had extended the deadline of the phase as we did talk about that, but it didn’t actually happen. When I sent my reminder the discussion phase was therefore already over, so all the support and feedback we got then Doesn’t Count™. They have indicated that they will only reopen the discussion phase if they know that there actually will be engagement for this to be meaningful.
So, can the people who are interested in this proposal please pinky swear that they will contribute if it does get another discussion phase? ;) You may have to repeat your feedback in the proper phase of the PDP to be counted. This approach is less pragmatic than I would have chose when I was a chair, but this is not my working group :) And the chairs are right that the reason for this being a policy proposal is that the NCC (legal) team wants formal community support, so I can see why they are following the process to the letter. So let’s do this formally right.
PS: Denis, thank you for your contribution! We’re going to ask the RIPE NCC to comment on the interaction between the policies, and whether a separate policy like this one (with maybe a cleanup of the text in Address Policy) is preferred to integrating this in the transfer policy or not. Considering that the RIPE NCC gave us a hard deadline to get this policy in place, I’m hesitant to restart the whole process this late.
Cheers! Sander
--- for every complex problem, there’s a solution that is simple, neat, and wrong
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ncc-services-wg <https://lists.ripe.net/mailman/listinfo/ncc-services-wg>
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ncc-services-wg

Hi, On Mon, May 15, 2023 at 03:53:56PM +0200, denis walker wrote:
The Transfer policy says that resource CAN be transferred.
This implies the will of the outgoing and incoming resource holders. There is nothing in the policy that says "a resource can be transferred *against the will* of the current resource holder". So, the proposed lockdown is an explicit statement of the resource holder "it is not my wish to transfer any of my resources in the next 6 months". I do not see why this would be violating policy if the outgoing resource holder states "I do not want to transfer anything", in a format that is appropriate for the circumstances - notably, "whatever happens to me in the next months, do not believe anything else I might be forced to say". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Hi, On Mon, May 15, 2023 at 4:11 PM Gert Doering <gert@space.net> wrote:
Hi,
On Mon, May 15, 2023 at 03:53:56PM +0200, denis walker wrote:
The Transfer policy says that resource CAN be transferred.
This implies the will of the outgoing and incoming resource holders.
There is nothing in the policy that says "a resource can be transferred *against the will* of the current resource holder".
So, the proposed lockdown is an explicit statement of the resource holder "it is not my wish to transfer any of my resources in the next 6 months".
I do not see why this would be violating policy if the outgoing resource holder states "I do not want to transfer anything", in a format that is appropriate for the circumstances - notably, "whatever happens to me in the next months, do not believe anything else I might be forced to say".
What should the RIPE NCC do if that member later submits a policy-compliant transfer request, during their previously requested "transfer lockdown" period? Does the "transfer lock" mechanism override the Transfer Policy? Seems needlessly messy to me and far too open to interpretation. I support the idea of clearly documenting a Transfer Lockdown mechanism in the Transfer Policy. "Any legitimate resource holder is allowed to transfer complete or partial blocks of address space or number resources (IPv4, IPv6 and AS Numbers) that were previously allocated or assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry (RIR) system." https://www.ripe.net/publications/docs/ripe-682#2-0-transfers-within-the-rip... Regards, James

Hi, On Mon, May 15, 2023 at 04:23:53PM +0200, James Kennedy wrote:
I do not see why this would be violating policy if the outgoing resource holder states "I do not want to transfer anything", in a format that is appropriate for the circumstances - notably, "whatever happens to me in the next months, do not believe anything else I might be forced to say".
What should the RIPE NCC do if that member later submits a policy-compliant transfer request, during their previously requested "transfer lockdown" period? Does the "transfer lock" mechanism override the Transfer Policy?
What is unclear about a clear statement of will that says "ignore everything I am going to say about this for the next 6 months"? There is no leeway for interpretation or doubt here.
Seems needlessly messy to me and far too open to interpretation. I support the idea of clearly documenting a Transfer Lockdown mechanism in the Transfer Policy.
"Any legitimate resource holder is allowed to transfer complete or partial blocks of address space or number resources (IPv4, IPv6 and AS Numbers) that were previously allocated or assigned to them by the RIPE NCC or otherwise through the Regional Internet Registry (RIR) system." https://www.ripe.net/publications/docs/ripe-682#2-0-transfers-within-the-rip...
Yes, *allowed*, so the NCC can not deny a resource holder the right *if he wants so*. But if he clearly states "I do not want to excercise this right for the next 6 months" this is a matter of consenting adults, and contractual matters. Amend the SSAC if needed to cover this case (this I'd actually find somewhat logical). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

What should the RIPE NCC do if that member later submits a policy-compliant transfer request, during their previously requested "transfer lockdown" period? Does the "transfer lock" mechanism override the Transfer Policy?
What is unclear about a clear statement of will that says "ignore everything I am going to say about this for the next 6 months"?
There is no leeway for interpretation or doubt here.
I think the only one who’s really qualified to have an opinion on that is Athina. Perhaps the NCC can comment about what they would need in the form of policy to implement this with minimum drama. Then we can write that and be done with it. Alex

Hi Denis, It is up to the resource holder to decide if they want transfer resources ... It should also be up to themselves, if they want to opt-out for a set period of time and register that choice with the NCC if they don't want to consume a certain provided service. This is similar as with the RPKI ROA creation .. It is possible to create a ROA that will cause your prefixes to be not accepted by networks that drop invalid ROA's ... Again, it is your choice to do that ... it was never part of the RPKI policy (* I authored that policy btw.. ) that all ROA's should match the actual announcements in BGP. The RPKI policy for members never achieved consensus .. and was decided upon by a GM vote .. the additional resources ( PI / Legal ) for non-members, was done here : https://www.ripe.net/participate/policies/proposals/2013-04 Erik On 15/05/2023, 15:54, "denis walker" <ripedenis@gmail.com <mailto:ripedenis@gmail.com>> wrote: Hi Erik I would disagree with you here as a matter of principle. On Mon, 15 May 2023 at 14:47, Erik Bais <erik@bais.name <mailto:erik@bais.name>> wrote:
Hi Sander,
I will repeat myself on what I've stated earlier on this ..
This shouldn't be a PDP / policy topic, but an operation implementation on the portal. Which doesn't require a policy change as far as I'm aware of. The requested change to the LIR portal, is similar ( imho ) to adding 2FA .. it is the decision of the NCC to offer the option, it is the decision of the LIR to actually use it or not
I understand that you are focussed on the current issue. But this has wider implications. What you are suggesting here is that the RIPE NCC can offer a service so that individual LIRs can choose to ignore RIPE policy. That is a very dangerous precedent. It completely undermines the whole community based PDP. It allows an LIR to decide to use a service the NCC has decided to offer that prevents a resource from being transferred. The Transfer policy says that resource CAN be transferred. So the combined decisions of the NCC and the LIR violates the Transfer policy. I also don't think the EB has the right to allow the NCC to offer such a service in the long term. As a short term, emergency arrangement, that is fine. But the EB should not have the right to override RIPE policy. The only way to do this is to put an opt out clause in the Transfer policy. Then invoking the opt out, and effectively locking the transfer of a specific resource, complies with the policy and doesn't violate it. As for people involved in any conflict opposing the policy change, keep in mind that consensus is not a vote. Numbers don't count. To oppose the change people must present sound objections. "I want to force someone to transfer resources to me against their free will" is not an acceptable objection and can be discounted by the WG chairs when determining consensus. cheers denis
With the risk of being locked out of the LIR portal, if they don't manage their 2FA properly ..
This shouldn't be a policy and yes I've heard what Athena said .. I disagree with her on this topic ..
This should be decided by the EB and implemented by the NCC.
If the WG didn't receive any feedback during the discussion phase, this means that policy making is still decided by around 20 ish people in the community of 22.000 ... And nobody was interested enough to be bothered .. and the intended targets of the portal change are probably hiding in shelters or walking through the fields ...
If this was decided that it is a PDP topic, the chance is that the opposition of the conflict, could also provide opposition on the PDP / proposal here.. And that is why in this particular situation, PDP isn't the solution here.
I'm not against the proposal, I don't think this should be put through PDP for said reasons.
Regards Erik Bais
On 15/05/2023, 12:10, "ncc-services-wg on behalf of Sander Steffann" <ncc-services-wg-bounces@ripe.net <mailto:ncc-services-wg-bounces@ripe.net> <mailto:ncc-services-wg-bounces@ripe.net <mailto:ncc-services-wg-bounces@ripe.net>> on behalf of sander@steffann.nl <mailto:sander@steffann.nl> <mailto:sander@steffann.nl <mailto:sander@steffann.nl>>> wrote:
Hello working group,
As the authors were in a bit of a difficult position. The chairs won't move this policy proposal forward as there was no feedback during the discussion phase.
We were under the impression that the chairs had extended the deadline of the phase as we did talk about that, but it didn’t actually happen. When I sent my reminder the discussion phase was therefore already over, so all the support and feedback we got then Doesn’t Count™. They have indicated that they will only reopen the discussion phase if they know that there actually will be engagement for this to be meaningful.
So, can the people who are interested in this proposal please pinky swear that they will contribute if it does get another discussion phase? ;) You may have to repeat your feedback in the proper phase of the PDP to be counted. This approach is less pragmatic than I would have chose when I was a chair, but this is not my working group :) And the chairs are right that the reason for this being a policy proposal is that the NCC (legal) team wants formal community support, so I can see why they are following the process to the letter. So let’s do this formally right.
PS: Denis, thank you for your contribution! We’re going to ask the RIPE NCC to comment on the interaction between the policies, and whether a separate policy like this one (with maybe a cleanup of the text in Address Policy) is preferred to integrating this in the transfer policy or not. Considering that the RIPE NCC gave us a hard deadline to get this policy in place, I’m hesitant to restart the whole process this late.
Cheers! Sander
--- for every complex problem, there’s a solution that is simple, neat, and wrong
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ncc-services-wg <https://lists.ripe.net/mailman/listinfo/ncc-services-wg> <https://lists.ripe.net/mailman/listinfo/ncc-services-wg> <https://lists.ripe.net/mailman/listinfo/ncc-services-wg>>
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ncc-services-wg <https://lists.ripe.net/mailman/listinfo/ncc-services-wg>
participants (8)
-
Alex Le Heux
-
denis walker
-
Erik Bais
-
Gert Doering
-
James Kennedy
-
Peter Hessler
-
Randy Bush
-
Sander Steffann