<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="FR" link="blue" vlink="purple"> <div class="WordSection1"> Hello Nick,<o:p></o:p> <o:p> </o:p> You say that:<o:p></o:p> " Secondly, there is no RIPE Community policy that I'm aware of which mandates LIR termination for anything, and certainly not for minor issues like this."<o:p></o:p> But the ripe-680 "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" explicitly states in §9 "Closing an LIR by the RIPE NCC" that "The RIPE NCC may close an LIR for any of the following reasons [...] <o:p></o:p> - the LIR cannot be contacted by the RIPE NCC for a significant period of time<o:p></o:p> - the LIR consistently violates the RIPE community's policies...."<o:p></o:p> <a href="https://www.ripe.net/publications/docs/ripe-680#9">https://www.ripe.net/publications/docs/ripe-680#9</a><o:p></o:p> And, furthermore, the syntax is : the LIR “may close”… consequently the proposal wouldn’t introduce any stricter mandate to terminate an LIR.<o:p></o:p> <o:p> </o:p> And Marco Schmidt confirmed yesterday that “The RIPE NCC would not activate the closure procedure simply because a mail server was broken. The closure procedure can be activated if the resource holder refuses to provide correct abuse contact information, which would be considered a consistent policy violation, or if they are unresponsive over a longer period. During this process, the RIPE NCC will have attempted to contact them several times via different channels before considering that a resource holder is unresponsive.” <o:p></o:p> <o:p> </o:p> Regards<o:p></o:p> <o:p> </o:p> Hervé<o:p></o:p> <o:p> </o:p> -----Message d'origine----- De : anti-abuse-wg [mailto:anti-abuse-wg-bounces@ripe.net] De la part de Nick Hilliard Envoyé : mercredi 24 janvier 2018 15:40 À : Brian Nisbet Cc : Gert Doering; anti-abuse-wg@ripe.net Objet : Re: [anti-abuse-wg] [policy-announce] 2017-02 Review Phase (Regular abuse-c Validation) <o:p> </o:p> Brian Nisbet wrote:<o:p></o:p> > No, it isn't. It's a statement that the process has many steps and <o:p></o:p> > that the NCC both say they do and clearly do whatever they can to not <o:p></o:p> > reach the termination point of the process. I'm not saying it could <o:p></o:p> > never happen, I'm saying that it if happens it's may have been started <o:p></o:p> > by<o:p></o:p> > 2017-02 but the deregistration would happen because over ~9 months the <o:p></o:p> > NCC would be unable to in contact with the LIR in any way.<o:p></o:p> <o:p> </o:p> Couple of things here.<o:p></o:p> <o:p> </o:p> Firstly, you're not denying that an extreme policy compliance enforcement mechanism exists.<o:p></o:p> <o:p> </o:p> Having a policy which allows a LIR contract to be terminated is extreme, de-facto. It is extreme because the consequences of address resource withdrawal would be terminal for many address holders.<o:p></o:p> <o:p> </o:p> I don't disagree that there are legitimate situations where LIR contract termination could be justified, but non-compliance with a relatively minor bureaucratic tickbox operation is not one of them.<o:p></o:p> <o:p> </o:p> Presenting an argument about operational procedures and saying that this hasn't been deployed in the past is a different issue.<o:p></o:p> <o:p> </o:p> It's akin to describing the colour of a pair of gloves and showing how soft and how nice and even how comfortable they are, while pretending that just because the gloves are so nice, that there isn't an iron fist underneath.<o:p></o:p> <o:p> </o:p> Make no mistake, there here is an iron fist being inserted into the policy here and the policy proposal document is - unusually for a policy proposal - explicitly stating in the interpretation notes that this can, and will be used if compliance is not achieved.<o:p></o:p> <o:p> </o:p> Again, I have no problem with a policy of LIR termination in situations where that is justified. This is not one of those situations.<o:p></o:p> <o:p> </o:p> Secondly, there is no RIPE Community policy that I'm aware of which mandates LIR termination for anything, and certainly not for minor issues like this.<o:p></o:p> <o:p> </o:p> It needs to be pointed out that the RIPE NCC board has recently, and without notification to either the membership or the RIPE Community, substantially changed the terms of the "RIPE NCC Audit Activity"<o:p></o:p> document which is a RIPE NCC operational policy, not a RIPE Community policy. The old policy stated that the escalation path was "further measures may be necessary", without stating what those further measures were. Notably, termination of the rights of resource holders was not included. The new policy, dating from Jan 10th states that LIR termination is now a formal and documented RIPE NCC policy. This represents a substantial change in itself.<o:p></o:p> <o:p> </o:p> Confusingly, the "RIPE NCC Audit Activity" document is linked from several RIPE Community policies without restriction, which means that we now appear to be in the awkward situation where the RIPE NCC is<o:p></o:p> *arguably* making changes to RIPE Community policy (without reference or even notification to the community) because existing references in RIPE Community policy documents referred to RIPE-423 and previous versions rather than RIPE-694. This is troubling in its own right.<o:p></o:p> <o:p> </o:p> What's inside the scope of AAWG is that apparently RIPE-694 now exists and if a policy is passed which acknowledges this document content change, then that RIPE Community policy - unlike all other previous RIPE Community policies which acknowledged RIPE-423 - will give explicit RIPE community mandate to termination of resource holder rights under the terms of 694.<o:p></o:p> <o:p> </o:p> This marks a dramatic and substantial change in RIPE Community policy because for the first time, the community would be explicitly giving a mandate to the RIPE NCC to use RIPE-694 rather than RIPE-423.<o:p></o:p> <o:p> </o:p> With due respect to your analysis, this is a far larger issue than ought to be dealt with in AAWG. If there is serious intent to continue with any proposal which involves extinguishment of resource holder rights, that discussion needs to be brought up into the context of the larger RIPE Community and the RIPE NCC membership rather than just this working group.<o:p></o:p> <o:p> </o:p> Nick<o:p></o:p> <o:p> </o:p> </div> <PRE>_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. </PRE></body> </html>