Re: [db-wg] So what happened last night to the DB?
> I have thought about doing it so, as I was also included as the > maintainers of the object. The real question is: why did blake66 made > such an object ? And how could we prevent something alike to happen > again (not an easy question -- maybe limiting the amount of mnt-by ?) Especially the DB should not process backscatter messages from MAILER-DAEMON. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
* Denis Walker wrote: > [... it's old ...] > > Just a quick list from memory of some problems surrounding the > database. 'Hear from users'...Whenever I bring up any issues like > this, I either hit a total wall of silence or I am hit with familiar > negativity. NO one ever talks about the future of the RIPE Database in > a positive way. Daniel said at the BOFF in Iceland, "It's time to stop > tinkering around the edges of the RIPE Database". I thought that would > be the trigger to start this positive discussion. At the BOFF there > were lots of heads nodding in agreement. Any thought of a positive > discussion was lost as quickly as people left the BOFF heading for the > bar. A Task Force was set up, I thought, to document the business > requirements for the RIPE Database and public registry. All they did > was look backwards and write a document on the history of the > database...many of us already knew that. There are proposals out there, which can model he idea of Whois-DBs better. Simply spoken, the idea of Whois is to publish the responsibility/ownership of limited resources, which are hierarchically maintained. Problems arose, if your data is duplicated into a data store you do not operate yourself: - How to keep it updated? - How to track modifications you did not authorized? - How to unpublish or control access of sensitive data? - How to deal with discrepancies in local law of the data owner and the operator? The most natural approach is to distribute control and storage of the data. An Whois service like whois.iana.org simply respond with the contractual information IANA had for the resource: If queried, show the contractual party and a refer: line. If we adopt this model for RIPE DB, this would have some consequences: - Every LIR is obligated to operate its own Whois service. - RIPE might offer to continue their current DB for those, which are not yet able to run on their own. (Transition period) - RIPE NCC has to include contractual obligations to ensure a stable and useful operations of the LIR Whois service. - RIPE NCC has to actively monitor those services and take action if they are not in a compliant state. (call Atlas for help?) - Every LIR is obligated to handle the subordinate delegations in a similar way. Even for assignments, this might be useful. - On the tooling side, some major changes are necessary: bgpq and irrtoolset can't any longer rely on single source. They have to implement a recursive crawler and deal with a lot of problems like inaccessibility, rate limits, geofencing, ... - The routing community has to think about their best practices: + Drop automatic ACL generation in favour of rPKI? + Drop RPSL procession (already gone?) + Where to obtain the traffic steering communities for peers? PS: I'm personally interested in this model for ICANN in order to overcome the Thick-Whois approach with a large drive-through for LEA and paying mass-access-actors, violating at least the GDPR. -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
* Denis Walker wrote: > But looking through lots of email notifications about changes that you > already know about, because you did them, and maybe in the middle is a > notification of an attempted security breach that failed on > authentication (that you may miss), doesn't that also eat up brain > cycles? Please do not assume that LIR activities are single handed everywhere. Several LIRs do have an automation (i.e. netbox) to update the RIPE DB. Others might have multiple independent people working with RIPE on their own behalf. So notifications, especially the notify: attribute are currently in use. > So how about a compromise. A full audit trail of all details of all > changes to all your data available by default to designated people > through your portal account. Plus a daily email summarising all the > changes also sent to people whose email addresses are set up in the > portal account. So still no notif email addresses needed all across > the database. This could even be done per maintainer. How about using the notify: attribute for notifications? -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
> In this release, we will implement mail bounce detection (i.e. an outgoing > message has permanently failed delivery) and also unsubscription (i.e. one- > click unsubscribe from a mail client). Once an address is undeliverable or > unsubscribed, we will not send further Whois update acknowledgements or > notifications to that address. However we will continue to send targeted > notifications where required by RIPE policy (e.g. abuse-c validation, RIPE- > NONAUTH route object cleanup etc.). Thank you for your ongoing work and please forgive my ignorance on this subject. IIUC, all addresses, which are unavailable for the sending RIPE MTA once, will be blocked until manual interference. The cause of this error might be located in the RIPE MTA, the RIPE uplink, a global network routing issue, a peering issue, our uplink, our local MTA, or even a DNS(sec) issue. In consequence we will not receive any notifications anymore unless we try to update the very object in question and read the warning box the RIPE-DB update web form. Hence we can't rely on the email notifications anymore? -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Re: [db-wg] NWI-13 Geofeed Legal Analysis
So the geofeed attribute will be deleted from the database? Do you have a timeframe for this implementation? Von: db-wg Im Auftrag von Maria Stafyla via db-wg Gesendet: Donnerstag, 28. Juli 2022 13:33 An: db-wg@ripe.net Betreff: [db-wg] NWI-13 Geofeed Legal Analysis Dear colleagues, Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed. Executive Summary: - The RIPE Database is meant to contain specific information for its documented purposes. - Information inserted in the geofeed attribute could in some cases qualify as personal data. - The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’. - This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data. - The restrictions are now implemented based on the status of the registration. - If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary. Legal Analysis: The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions. In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required. Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles. Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community. As mentioned in the Legal Review Impact Analysis, if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered as containing personal data and GDPR will apply. This is why we have proposed to implement restrictions. These restrictions are essential to avoid any processing of personal data that is not required or necessary for the currently defined purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database. Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted. According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3). We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time. The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil. If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions. In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects). On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman
Re: [db-wg] running in whios-circles...?
* Gert Doering wrote: > On Thu, Sep 16, 2021 at 07:00:01AM +0000, Lutz Donnerhacke via db-wg wrote: > > Did you ever tried to correct wrong entries in the IANA whois? > > I did and the entries were fixed (within a period of about a year). > > It's certainly possible to have correct data in the IANA server. > > OTOH if the problem is serious enough, an IANA review can be triggered. > > I'm not sure it's the community's job to review IANA data continuously > and fix their DB every time a network transfer between RIRs is done. > > I'm fairly sure a smart mind can come up with some solution involving > computers here. Despite your appropriate sarcasm, there are options to urge IANA to fix this automatically. The first step would be to recognise the problem at the review level. It would be helpful to start this with an ASO action on ICANN72. (*SOs are allowed to start PDPs, also known as policy changes)
Re: [db-wg] running in whios-circles...?
* Ronald F. Guilmette wrote: > Gert Doering wrote: > >Ideally, IANA should point to the final RIR right away. > > That would certainly be more helpful than the present state of affairs, > within which the IANA WHOIS server is not merely failing to give out > correct referrals, but is actually giving out demonstratably incorrect > referrals. > > Functionally and operationally, the portion of the IANA WHOIS service that > provides referrals for IP addresses is, at present, worse than useless > due to the innumerable incorrect referrals it provides. If IANA does not > wish to correct that, then they should at least configure the thing so that > it will stop providing *any* responses at all when queried about IP > addresses. Did you ever tried to correct wrong entries in the IANA whois? I did and the entries were fixed (within a period of about a year). It's certainly possible to have correct data in the IANA server. OTOH if the problem is serious enough, an IANA review can be triggered.
Re: [db-wg] proposal: new attribute 'geofeed:'
> By enriching the RPSL dictionary and having a “geofeed” RPSL attribute > (which by the way should not be mandatory) will be easier for someone > to extend his parser to use that field without overloading the parser > with many “if” and regex expressions. Plus the upcoming RFC specifies > A that "The format MUST be as in this example,“ so a verification needs to be > applied later on. I second this. > Of course it’s weird to talk about enriching RPSL on 2020 but putting > this apart, I believe it’s more correct to implement it in this way. If nobody ever adapts RPSL to the new requirements, RPSL is dead. So the question is: Should we throw away the RRDB in favour of something else, or do we extend RPSL in the way it was designed?
Re: [db-wg] MNTNER Naming : Consensus
Of course it’s not necessary. I just want to point out, that the source is usually a prefix, while the function is usually an appendix. At least to my understanding. Von: ripede...@yahoo.co.uk Gesendet: Donnerstag, 1. Oktober 2020 13:55 An: 'db-wg@ripe.net' ; Lutz Donnerhacke Betreff: Re: [db-wg] MNTNER Naming : Consensus Hi Lutz There is no requirement for a source on a MNTNER name. So in your example the MNTNER could simply be NCC-MNT. cheers denis co-chair DB-WG On Thursday, 1 October 2020, 08:53:56 CEST, Lutz Donnerhacke via db-wg mailto:db-wg@ripe.net>> wrote: So the general scheme is SOURCE-NAME-FUNCTION, i.e. RIPE-NCC-MNT ? Von: db-wg mailto:db-wg-boun...@ripe.net>> Im Auftrag von William Sylvester via db-wg Gesendet: Mittwoch, 30. September 2020 21:44 An: db-wg@ripe.net<mailto:db-wg@ripe.net> Betreff: [db-wg] MNTNER Naming : Consensus db-wg members, The chairs of the database working group believe there is a consensus to have a standardised name format for creating new MNTNER objects. There was talk of a prefix (MNT-) or a suffix (-MNT). When creating a new standard it doesn't really make sense to introduce a standard with multiple formats. As there are currently 36347 MNTNERs that end with -MNT and 12480 MNTNERs that start with MNT-, we suggest that the standard should be to end with -MNT. We ask the RIPE NCC to take the next steps in moving this request forward, conducting an impact analysis, and proceed with implementation. Best regards. William & denis db-wg chairs
Re: [db-wg] MNTNER Naming : Consensus
So the general scheme is SOURCE-NAME-FUNCTION, i.e. RIPE-NCC-MNT ? Von: db-wg Im Auftrag von William Sylvester via db-wg Gesendet: Mittwoch, 30. September 2020 21:44 An: db-wg@ripe.net Betreff: [db-wg] MNTNER Naming : Consensus db-wg members, The chairs of the database working group believe there is a consensus to have a standardised name format for creating new MNTNER objects. There was talk of a prefix (MNT-) or a suffix (-MNT). When creating a new standard it doesn't really make sense to introduce a standard with multiple formats. As there are currently 36347 MNTNERs that end with -MNT and 12480 MNTNERs that start with MNT-, we suggest that the standard should be to end with -MNT. We ask the RIPE NCC to take the next steps in moving this request forward, conducting an impact analysis, and proceed with implementation. Best regards. William & denis db-wg chairs
Re: [db-wg] Fw: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes
> > We need to take some action on these old NWIs. Either we move forward > with them or we cancel them. It is difficult to draw a consensus on 2 > comments. Can you please give us a couple of minutes of your time and > let us know if this NWI-1 is needed, useful or a waste of time. > > I share the view already expressed. If we need a tool, maybe the problem > is somewhere else. I support any proposal, that comes to the same result as the ripe whois database tool. It's not really hard to do correctly. #! /bin/sh getripe="whois -h whois.ripe.net --" $getripe -rL -T inetnum,inet6num "$1" | egrep '^org:' | while read ot ov; do $getripe -r -T organisation $ov | egrep '^abuse-c:' | while read at av; do $getripe -r $av | fgrep abuse-mailbox done done | tail -1 In order to fix the issue on the database side, it's necessary to prevent any occurrence of "abuse-mailbox" in all objects beside an newly created "abuse-contact" type, which is only allowed to referenced in the "abuse-c". See here for a corner case: https://lutz.donnerhacke.de/eng/Blog/Antispammers-and-Abuse-C
Re: [db-wg] 57.224.0.0/11
> In message <20200923071702.ga5...@hydra.ck.polsl.pl>, > Piotr Strzyzewski wrote: > >Let me add some little humour here: > > > >$ dig txt gb. +short > >"This domain is frozen and will be phased out" > >"For details see the web page on: www.nic.uk" > >"Domain names for United Kingdom go under .uk" > > > >It is "phased out" for many years already. ;-) To make it even more funny: In the ICANN32 meeting in Paris in 2008, the IDN ccTLD fast track session was heavily heating, because only non-latin scripts should qualify for this "fast track" procedure. So the GAC member from UK stand up and insisted, that they need to have geographic region TLDs, too. The response from the plenum was ... "You insisting in obey the rules, word by word?" - "Yes." - "So your ISO 3166 code is GB, but you are using UK, which violates the rules. I'd suggest to clean up you mess first, ..." - the GAC member sat down, redfaced.
Re: [db-wg] RPSL requirements in aut-num objects
> On Thu, Jul 02, 2020 at 05:58:19PM +0000, Lutz Donnerhacke via db-wg > wrote: > > I'd suggest to remove the crippled parser from the records in the > > first step. > > Even if someone tries to use the data-set, it's not even possible to > > bring in correct data. > > How do you expect an adoption under this condition? > > > > So, my primary question: Where is the source code and how to > > contribute? > > Secondary question: Can we first declare the fields as free from text > > fields, before removing them? > > What is the benefit of declaring such fields 'free form'? RFC 2622 requires to accept attributes which are not defined in the dictionary during paring. Of course, then the parser has no ability to validate the arguments or the allowed operators. It should issue a warning or ignore the attribute. Unfortunately the current parser in the RIPE DB has a different understanding of RPSL: it does not even allow attributes defined in the RFC (i.e. next-hop, protocols). So it's not possible to fill the aut-num with valid RPSL, or even adding new attributes. As long as the parser is broken, the field might be not validated (or issue a warning instead of an error). And the parser should be fixed. That's why I'm asking for the location of the source code.
Re: [db-wg] RPSL requirements in aut-num objects
* Nick wrote: > disconnect between two data sets, it's time to question whether it's > worth maintaining the data sets. I'd suggest to remove the crippled parser from the records in the first step. Even if someone tries to use the data-set, it's not even possible to bring in correct data. How do you expect an adoption under this condition? So, my primary question: Where is the source code and how to contribute? Secondary question: Can we first declare the fields as free from text fields, before removing them? Lutz
Re: [db-wg] RPSL parser nits
> You may want to think twice about whether it's worth investing time and > effort in rpsl in 2020. That's true, but I do need some style of machine readable documentation internally as well as an slightly competent looking aut-num object for peering purposes. So the only choices are: a) invent something new for internal usage and update the RADB in addition. b) use the existing ideas and tools. I do not have any problem in patching or rewriting software, if necessary. For solution a) I have to do everything by myself anyway, so where is the difference to b), even if I'm the only user? If the projects are abandoned, who is to contact to shift the responsibility?
[db-wg] RPSL parser nits
Hello, I try to be a bit more expressive in the aut-num of ASN199284, but fail to get accepted at least the valid parts by the RPSL parser. Of course, there are invalid expressions in my terms for the sake of expressiveness, i.e. - next-hop is only valid for static routes - communities must not contain the PeerAS pattern But the other parts should be accepted, i.e. - protocol OSPF - rtr-sets in router expression part It would be a cool idea to keep the formatting, or better have smart pretty printing of the RSPLng structures. Currently only the "syncupdate" Interface is able to keep the line warps, which is pretty annoying. Where can I found the currently running code and do you accept patches in this regard? Many thanks in advance Lutz Donnerhacke
