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]/
[members-discuss] [ncc-services-wg] Update of RIPE NCC Procedural Document
- Previous message (by thread): [members-discuss] [ncc-services-wg] Update of RIPE NCC Procedural Document
- Next message (by thread): [members-discuss] [FORTIMAIL: prawdopodobny spam] Re: [ncc-services-wg] Update of RIPE NCC Procedural Document
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nikolay Gorstkin
nikolay.gorstkin at gmail.com
Thu Apr 4 09:40:01 CEST 2019
Hi All, > 3 апр. 2019 г., в 18:55, Sascha Luck [ml] <ripe-md at c4inet.net> написал(а): > > On Wed, Apr 03, 2019 at 06:32:06PM +0300, Andrejs Guba wrote: >> I think that mistakes and typos should be somehow distinguished from cases >> where falsified documents and data is used. >> Let’s say after serious mistake RIPE NCC should WARN LIR. Three serious >> mistakes = closure. >> Falsified documents = closure. Yes, definitely! There must be compelling reasons for closing a membership. And this decision must be preceded by a specific warning (penalty). In addition, cases of forgery (photoshop, fabricated registration documents, etc. ..) and unintentional errors should be treated differently. That is - incorrect data is not equal to falsification! For example, when the end-user sends a scan PI-agreement signed by the person that is not in the founding documents (head of department)? Will this be considered a violation? Or in the agreement clearly shows that the signature is a facsimile and not a real handwritten signature? It is indicated that the agreement is valid in electronic form. Is this a violation? In general, we need a simple and transparent rules describing the purpose of penalties. Perhaps it will be good practice to make public information about the penalty on ripe.net web-site and/or create a certain grade scale for each LIR. And of course, such steps must be slow, gradual and accurate. No hurry! > I've yet to hear of a case where the NCC deregistered/closed a > LIR without giving it ample oportunity to correct any incorrect > data. This does not mean it *couldn't* though, the contract language > provides for it :)) That is exactly what happened to us ... We would like to be able to explain without referring to the procedure of Arbitration, but unfortunately we were not given such an opportunity. > another interesting insertion into ripe-716: > > "In the event a Dutch authority orders the RIPE NCC to deregister > specific Internet number resources, the RIPE NCC may comply > without following the process or the timeframes described above." > > Note that this does not mention any court orders. One wonders who > the "Dutch authorities" are that can order the NCC to dereg > resources... Police? Amsterdam Dog Warden? BREIN? It could be funny if it were not so sad, right now we are seeing the RIPE NCC becoming the REGULATOR instead of the COORDINATOR. Considering the latest offers from the RIPE NCC about BGP hijacks, this is similar to how government structures (RKN) operate in Russia. P.S. sorry for my clumsy english ... — regards, Nikolay Gorstkin > > rgds, > SL >> >> Kind regards, >> >> Andrejs Guba >> >> >> >>> Dear Maria, >>> >>> Thank you for the announcement. >>> >>> I'm moving the discussion to members-discuss. >>> >>>> Other amendments were carried out to align the wording of specific >>>> sections with the wording used in the rest of the document, the RIPE NCC >>>> Standard Service Agreement (Sections A.1.2.2.g and B.1.d), and other >>>> RIPE NCC procedural documents (Section A.1.1). Similarly, changes were >>>> made to reflect changes in the RIPE Database (both operational and >>>> structural) and in RIPE Policy requirements (Sections A.1.2.1.1.c and >>>> B.1.c). >>> >>> I would not call this 'wording changes': >>> >>> $ diff ripe697 ripe716 >>> 7c7 >>> < The Member repeatedly provides falsified data or information, or >>> purposefully and/or repeatedly provides incorrect data or information (for >>> example, falsified registration documents or IDs, incorrect/inaccurate >>> contact details, etc.). >>> --- >>>> The Member provides falsified or misleading data or information (for >>>> example, falsified registration documents or IDs), or repeatedly >>>> provides incorrect data or information (for example, >>>> incorrect/inaccurate contact details). >>> 11c11 >>> < The Member submits repeatedly fraudulent requests for Internet number >>> resources (for example, providing incorrect purpose/need or falsified >>> information about the network, etc.). >>> --- >>>> The Member submits fraudulent requests for Internet number resources >>>> (for example, providing incorrect purpose/need or falsified information >>>> about the network, etc.). >>> >>> So the word 'repeatedly' disappear and in case of _any_ only document >>> mistake, deliberately or not made by the member, the RIPE NCC can call >>> this 'misleading data' or 'fraudulent request' and terminate the >>> membership? >>> >>> Thank you. >>> >>> >>> -- >>> Kind regards, >>> Sergey Myasoedov >>> >>> >>>> On 1 Apr 2019, at 10:56, Maria Stafyla <mstafyla at ripe.net> wrote: >>>> >>>> Dear Colleagues, >>>> >>>> The RIPE NCC Procedural document 'Closure of Members, Deregistration of >>>> Internet Resources and Legacy Resources' has recently been reviewed and >>>> updated. The following is an overview of the amendments made. >>>> >>>> Section A.1.1 was amended to include situations where both the Member >>>> and the RIPE NCC agree to terminate the SSA before the usual three month >>>> period has passed. Other changes were made to avoid duplication of >>>> information. >>>> >>>> Section B.2 was updated to specify certain conditions under which a >>>> three month timeframe for deregistration of either Member or End User >>>> resources would be unreasonable. >>>> >>>> The wording in Section B.2.1 was amended to clarify that during the >>>> deregistration process the Member is not allowed to make new >>>> announcements using the resources to be deregistered, and that the RIPE >>>> NCC will update the maintainer on all the Member's resource objects - >>>> not just on the inetnum object. >>>> >>>> Section B.2.2 was amended to bring about alignment of the procedures for >>>> the deregistration of End User and Member resources and to clarify that >>>> if an End User does not have a sponsoring LIR when the deregistration >>>> procedure is initiated, they must first establish a contractual >>>> relationship with one before they can object to that procedure. >>>> >>>> Other amendments were carried out to align the wording of specific >>>> sections with the wording used in the rest of the document, the RIPE NCC >>>> Standard Service Agreement (Sections A.1.2.2.g and B.1.d), and other >>>> RIPE NCC procedural documents (Section A.1.1). Similarly, changes were >>>> made to reflect changes in the RIPE Database (both operational and >>>> structural) and in RIPE Policy requirements (Sections A.1.2.1.1.c and >>>> B.1.c). >>>> >>>> Please see here the relevant link: >>>> https://www.ripe.net/publications/docs/ripe-716/ >>>> >>>> Kind regards, >>>> >>>> Maria Stafyla >>>> Legal Counsel >>>> RIPE NCC >>> >>> >>> _______________________________________________ >>> members-discuss mailing list >>> members-discuss at ripe.net >>> https://mailman.ripe.net/ >>> Unsubscribe: >>> https://lists.ripe.net/mailman/options/members-discuss/lir%40private.lv >>> >> >> >> >> _______________________________________________ >> members-discuss mailing list >> members-discuss at ripe.net >> https://mailman.ripe.net/ >> Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/ripe-md%40c4inet.net > > _______________________________________________ > members-discuss mailing list > members-discuss at ripe.net > https://mailman.ripe.net/ > Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/nikolay.gorstkin%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20190404/5a13d8f3/attachment.html>
- Previous message (by thread): [members-discuss] [ncc-services-wg] Update of RIPE NCC Procedural Document
- Next message (by thread): [members-discuss] [FORTIMAIL: prawdopodobny spam] Re: [ncc-services-wg] Update of RIPE NCC Procedural Document
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]