- db-wg - mailman.ripe.net

Re: [db-wg] Interest to continue NWI-9
by Job Snijders 29 Oct '20

29 Oct '20

Dear group, I think NWI-9 needs to be reworded, it in part has been over taken by current events. Rereading https://www.ripe.net/ripe/mail/archives/db-wg/2019-April/006236.html what is described there actually already has completed. RIPE NCC's NRTM servers are open to the public (this was not the case in april 2019 yet). The NRTM servers can be used to *subscribe* to changes in the RIPE database. When the NRTM client remains connected, it will receive NRTM updates as they come in. THIS IS IN-BAND, AND FAST. The rate of object change is very low compared to most information systems. Looking at https://ripe79.ripe.net/presentations/118-NWI-9_S.Konstantaras_DB-WG.pdf it is not clear to me what the problem definition is and how it relates to the wording of NWI-9. The proposed optimisations are either not in the RIPE IRR -> Cache layer (as NRTM is really near-real-time when implemented correctly) but elsewhere in the end-to-end route server functionality. From this perspective NWI-9 has already been completed! Now, there is plenty to be left desired about NRTM v3. Even though it is both a push and pull protocol and very fast (the push can measured in single digit seconds), NRTM v3 clearly is an ancient protocol and the operational community would benefit from a re-design of NRTM. WORK IS UNDER WAY: LACNIC has committed funding for IRRd's NRTM v4 implementation. RIPE NCC's 'good for the Internet' community fund has also been requested. That decision is still pending with the committee operating that fund. So what we have so far: - A collective desire to replace NRTM v3 with something else - The *only* two IRR server code bases of this industry have (partial) funding to make changes possible: IRRd and RIPE WHOIS server - A standardisation forum to publish the new spec: IETF - Multiple forums for input: RIPE DB-WG, IETF, *NOG, IRC, etc If NWI-9 is kept open I would request it is reworded to the extend that this working group requests RIPE NCC to commit to help design, implement, test & adhere to what will become "NRTM v4". I read Stavros' presentation where the above plan is listed as 'Langzaam' :-) but the characterization may be a little bit off: there is no Legal aspect to deal with: RIPE NCC made NRTM freely, contract-less, publicly and in real-time available already. Also keep in mind that any new protocol will indeed need to be tested (even if general purpose components such as JSON, HTTPS and WebSockets are used!). NRTM v4's design will have nothing to do with how NRTM v3 looks and feels. NRTM v4 will be HTTPS based, I guarantee it! This project has 'NRTM v4' as name to make it clear to the IRR operational community where in the internet-stack this protocol belongs, but that it is an improvement over version 3. NRTM v4 can easily be something that is finished and deployed in 2021. What needs to be done is fairly straight-forward, and lots of existing tools can be used to make the job easier (like HTTPS and JSON). Kind regards, Job On Thu, Oct 29, 2020 at 05:22:10PM +0100, denis walker via db-wg wrote: > Hi Stavros > > Thanks for the comment. I have let Ed know about your interest. > > cheers > denis > co-chair DB-WG > > On Thu, 29 Oct 2020 at 17:11, Stavros Konstantaras via db-wg > <db-wg(a)ripe.net> wrote: > > > > Hi WG chairs, > > > > > > I would like to declare that from our side we are still interested to team up with Ed and RIPE NCC colleagues to continue the work on NWI-9 item > > in order to modernise the NRTM service with something better and more suitable for our current needs. > > > > As far as I can recall, Ed and his team have several ideas to proceed forward with this subject, so I believe that we would be able to draw a clear development plan. > > And as a kind reminder, not only us (AMS-IX) but the European IXP community has expressed interest on proceeding with that subject. > > > > > > Thank you and we are looking forward to discuss further steps on the subject. > > > > > > > > Best regards, > > > > Stavros Konstantaras | Sr. Network Engineer | AMS-IX > > M +31 (0) 620 89 51 04 | T +31 20 305 8999 > > ams-ix.net > > >

1 0

Interest to continue NWI-9
by Stavros Konstantaras 29 Oct '20

29 Oct '20

Hi WG chairs, I would like to declare that from our side we are still interested to team up with Ed and RIPE NCC colleagues to continue the work on NWI-9 item in order to modernise the NRTM service with something better and more suitable for our current needs. As far as I can recall, Ed and his team have several ideas to proceed forward with this subject, so I believe that we would be able to draw a clear development plan. And as a kind reminder, not only us (AMS-IX) but the European IXP community has expressed interest on proceeding with that subject. Thank you and we are looking forward to discuss further steps on the subject. Best regards, Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net

2 1

Agenda RIPE81 - Database Working Group
by William Sylvester 25 Oct '20

25 Oct '20

Db-wg members, Here’s the database working group agenda for our meeting this week. Best regards, DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 15 mins Edward Shryane, RIPE NCC C. NWI - Open Proposals – 10 mins Denis Walker, DB-WG Co-Chair D. Cloud Migration – 20 mins Sander Buskens, RIPE NCC Z. AOB (open discussion)

1 0

in-addr.arpa glue?
by Randy Bush 23 Oct '20

23 Oct '20

domain: 0.28.147.in-addr.arpa descr: RG79-147-28-0 admin-c: RB45695-RIPE tech-c: RB45695-RIPE zone-c: RB45695-RIPE nserver: rip.psg.com nserver: nlns.globnix.net mnt-by: MAINT-RGNET source: RIPE ***Error: No response from nameserver for zone 28.147.in-addr.arpa when trying to fetch glue. ***Error: Not enough data about 0.28.147.in-addr.arpa was found to be able to run tests. not aware of glue in in-addr.arpa zones does it want me to delete the 28.147.in-addr.arpa parent zone first? that seems scary. randy

3 3

New on RIPE Labs: Our Plan to Fix Country Codes - NWI-10
by Stefania Fokaeos 23 Oct '20

23 Oct '20

Dear colleagues, As part of our preparation for the implementation of NWI-10, we've written an article on RIPE Labs in which we look at our plans for fixing country codes in the RIPE Database. https://labs.ripe.net/Members/stefania_fokaeos/our-plan-to-fix-country-codes <https://labs.ripe.net/Members/stefania_fokaeos/our-plan-to-fix-country-codes> During the RIPE Database WG session next Thursday at RIPE 81 all NWIs will be discussed and if needed my colleague Ed Shryane can provide more details. Kind regards, Stefania Fokaeos RIPE NCC

1 0

MNTNER Naming : Consensus
by William Sylvester 19 Oct '20

19 Oct '20

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

4 5

NWI reviews: NWI-3, NWI-6 consensus
by denis walker 15 Oct '20

15 Oct '20

Colleagues The author of 'NWI-6 Applicable data model not clear from contextless objects' has agreed that it can be cancelled. No one disagreed with that so the chairs agree to cancel NWI-6. It was suggested that 'NWI-3 Afrinic IRR Homing' was partly superseded by 'NWI-5 Out of region ROUTE(6) / AUT-NUM objects'. As NWI-5 is finished then NWI-3 should also be marked as finished. No one disagreed with this so the chairs agree that NWI-3 is finished. Ed, please mark NWI-3 as 'Finished' and NWI-6 as 'Cancelled'. cheers denis co-chair DB-WG

2 1

Re: [db-wg] proposal: new attribute 'geofeed:'
by Q 07 Oct '20

07 Oct '20

Hi Elad, > Not everyone will add the "geofeed" value and the geolocations in the csv will not validated by a 3rd party and may also be not up to date. It is a fair point that not everyone will use this, but I think a significant enough number will to warrant addition. On the point of validation it would be perhaps advisable for the RIPE DB to verify the reachability of the file (as with rDNS setup), but I don't think further validation is within scope. > I suggest to make the csv creation (of each INETNUM object) automatic and hosted by RIPE NCC Ggood suggestion, not everyone will want to use their own webserver for this, and a simple service provided by RIPE would help improve adoption, however I'm not sure that people who can't host a CSV file should really be dealing in this anyway. > RIPE NCC can use all the current ATLAS Probes in order to check the physical location of each ip This feels like a guess at best, and providing guesswork as authoritative information is hardly a sensible idea. Overall this proposal gets a +1 from me, and due to this purposefully light nature of the geofeed standard itself I don't think RIPE NCC should add too much to it. Thanks, Q Director [image: https://as207960.net] <https://as207960.net> <https://www.youracclaim.com/badges/4570b2d1-947f-426a-832d-d0e4bf445267/pub…> https://as207960.net AS207960 Cyfyngedig Phone: +44 29 2010 2455 (ext 601) Fax: +44 29 2010 2455 Address: 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU

1 0

NWI reviews: NWI-6 Applicable data model not clear from contextless objects
by ripedenis＠yahoo.co.uk 07 Oct '20

07 Oct '20

Colleagues This is the last of the NWIs from 4 years agohttps://www.ripe.net/ripe/mail/archives/db-wg/2016-June/005272.html For this one I am not even sure what is being asked for and I don't agree with some of the points in the problem statement. Maybe Job can expand on it. Any comments appreciated... cheersdenis co-chair DB-WG

2 1

RIPE Database Requirements Task Force BoF, 26 October 2020
by Bijal Sanghani 07 Oct '20

07 Oct '20

Dear colleagues, The RIPE Database Requirements Task Force (DBTF) will organise its second BoF on Monday, 26 October 2020 from 16:00-17:00 (UTC+1) via Meetecho. During this BoF, the DBTF will present its latest draft and invite participants to provide feedback on the document. The Meetecho link to join the BoF will be shared one week before the event at: https://ripe81.ripe.net/programme/meeting-plan/bof/ <https://ripe81.ripe.net/programme/meeting-plan/bof/> We look forward to discussing the future of the RIPE Database with you! Kind regards, Bijal Sanghani on behalf of the DBTF

1 0

Whois Release 1.98
by Edward Shryane 01 Oct '20

01 Oct '20

Dear Working Group, RIPE Database release 1.98 has been deployed to the Release Candidate environment. We plan to deploy to production on Thursday 1st October. This release includes the following main changes: * NWI-11 Punycode Internationalized Domain Names in email addresses. * Return remark in RDAP response when abuse-mailbox validation has failed. * RDAP CORS changes * RDAP invalid syntax exception * A deleted object may be matched in the fulltextsearch index (fixed) In addition to other small improvements and bug fixes. The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

NWI reviews: NWI-3 - Afrinic IRR Homing
by ripedenis＠yahoo.co.uk 01 Oct '20

01 Oct '20

Dear Colleagues This is another 4 year old task about 'encouraging' the transfer of ROUTE(6) objects for Afrinic resources from the RIPE Database to the Afrinic Database.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005241.html Is this still an ongoing task? Is there anything more that needs to be done from the RIPE region to complete this Task? Or can we consider this task as completed now? My feeling is that it was superceeded by 'NWI-5 Out of region ROUTE(6) / AUT-NUM objects', which is marked as 'Finished'https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html As always, your comments are appreciated... cheersdenis co-chair DB-WG

5 7

WHOIS Referrals for transferred number resources
by Ronald F. Guilmette 30 Sep '20

30 Sep '20

I have been writing a modest little software tool recently that seeks to ferret out the identity of the "top level" registrant organization for any given assigned IPv4 address. In this context by "top level" I mean the entity that obtained the relevant IP address assignment directly, either from one of the five regional Internet registries or else from some subserviant national Internet registry. This softare tool always starts by querying whois.iana.org in order to obtain a first-order referral to one of the WHOIS servers belonging to of the five regional Internet registries... usually and often the correct one that actually holds the desired information. Due to various inter-region transfers that have taken place over time however, the first-order referral given by whois.iana.org is often simply wrong, and it is really some other WHOIS server of some other one of the five regional Internet registries that actually contains the information sought. Conveniently, in the case of the ARIN WHOIS server and the APNIC WHOIS server, even in those cases where these respective WHOIS servers do not contain the data sought, e.g. due to some inter-region transfer, these WHOIS servers are at least helpful enough to provide in their responses explict referrals to the proper regional Internet registry WHOIS server where the desired data can in fact be obtained. I would like to request that NCC staff administering the RIPE WHOIS data base likewise incoroprate some such helpful explicit referral text into the WHOIS responses for all number resources where whois.iana.org believes that the resources are under the administration of RIPE, but where in fact the number resources in question have been transferred to some different region. During the early testing of my small software tool I have already encountered a number of such cases. In each of these cases I had to sort out the problem by hand -- I had to ferret out the correct RIR WHOIS server by other means, the responses from whois.ripe.net being of no help whatsoever in this regard, and I then had to program in some "manual overide" work-arounds in my code in order to deal with these cases: 51.79.0.0/16 51.81.0.0/16 51.161.0.0/16 51.162.0.0/17 51.222.0.0/16 151.101.0.0/16 151.139.0.0/16 151.164.0.0/16 151.190.0.0/16 185.105.7.0/24 185.150.189.0/24 185.150.190.0/23 185.171.208.0/22 194.204.192.0/18 I have some faith and hope that the community, the members, and the staff of the RIPE region will wish to be at least as helpful with repect to this WHOIS referral issue as their North American and Asia/Pacific counterparts. Given the expected increases in inter-regional transfers it seems that the time is... well... ripe, to address this small but consequential issue within the data base. Regards, rfg

2 3

Fw: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Hi Lutz Good try but this script does not do it. Firstly, if you start with the allocation object it needs to be -rM in the first query. Then you are only looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:" attribute in the object. It may have both in which case the local attribute overrides the "abuse-c:" in the referenced ORGANISATION object. Also to manage this feature it is not just about producing a list of abuse email addresses. It is knowing where these are referenced within a hierarchy and knowing which parts of the hierarchy are covered by which addresses. I agree that most resources will only have a single abuse contact referenced from their single ORGANISATION object. However, we were pushed hard by the community to allow "abuse-c:" to be added to the INET(6)NUM objects. I assume therefore that this feature has been used. So we already have a mix of abuse contacts referenced from both ORGANISATION and resource objects. When this was asked for the emphasis was on 'ease of use' to add these contacts. Probably no one gave much thought to how these contacts will be cleaned up when no longer relevant. It's most likely that someone will ask someone to remove it. Knowing human nature it is more likely some will just be forgotten about. If the contact is still there it is still active, but maybe no one is reading that email address any longer. I am not an operator so I don't know how many end user customers in large networks handle their own abuse reports. Or how many sub allocations handle abuse with their own customers handling abuse. So I don't know how complex this will get and maybe all operators already have good procedures in place to manage all this. That is why I am asking the question...is such a visualisation tool needed, useful or a waste of time? As an analyst, I can only see how complex this 'could' become over time. Unless we go back to the drawing board and redesign the abuse contact system (again) this is not going to be simplified any time soon. cheersdenis co-chair DB-WG On Thursday, 24 September 2020, 15:32:09 CEST, Lutz Donnerhacke via db-wg <db-wg(a)ripe.net> wrote: > > 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

2 1

Fw: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Colleagues 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. cheersdenis co-chair DB-WG ----- Forwarded message ----- From: ripedenis--- via anti-abuse-wg <anti-abuse-wg(a)ripe.net>To: anti-abuse-wg(a)ripe.net <anti-abuse-wg(a)ripe.net>Sent: Tuesday, 22 September 2020, 22:50:52 CESTSubject: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes Colleagues This is now a very old NWI that never got out of the starting blocks. I am posting this to the AA-WG as I think the discussion is more relevant to this community given the impact of not properly managing this data. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html Since I raised this point the world has moved on and the situation is now even more complex. The "abuse-c:" attribute can be added to:-the resource holders primary ORGANISATION object-any secondary ORGANISATION object referenced from any point in the address hierarchy-any resource object at any point in the address hierarchy-all, or any combination, of the above These (multiple) "abuse-c:" attributes can reference the same or multiple ROLE objects. These (multiple) ROLE objects can include "abuse-mailbox:" attributes referencing the same or multiple email addresses. Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss.... cheersdenis co-chair DB-WG

3 2

Re: [db-wg] 57.224.0.0/11
by Lutz Donnerhacke 23 Sep '20

23 Sep '20

> In message <20200923071702.GA5107(a)hydra.ck.polsl.pl>, > Piotr Strzyzewski <Piotr.Strzyzewski(a)polsl.pl> 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.

1 0

57.224.0.0/11
by Ronald F. Guilmette 23 Sep '20

23 Sep '20

I admit to being a bit naive and uneducated, so perhaps someone here will take pity on me and explain this to me. I was under the impression that the world was running out of IPv4 addresses. But regardless of that, it seems that a old line French company that has been in business since 1949 was awarded an entire /11 block by RIPE NCC as recently as February of this year. I confess that this leaves me a bit perplexed. If someone will explain, I'll appreciate it. And, oh, by the way, yes, I do see the word "LEGACY" there. But I also see two different created: lines and their associated field values, both of which appear to tell a rather different story. inetnum: 57.224.0.0 - 57.255.255.255 netname: SITA-NET country: BE org: ORG-SIDT4-RIPE admin-c: SITA tech-c: SITA status: LEGACY mnt-by: SITA-MNT mnt-by: RIPE-NCC-LEGACY-MNT created: 2020-02-04T16:41:22Z last-modified: 2020-02-04T16:41:22Z source: RIPE organisation: ORG-SIDT4-RIPE org-name: Societe Internationale de Telecommunications Aeronautiques org-type: LIR address: Chemin de Joinville 26 address: 1216 address: Geneva address: SWITZERLAND phone: +41227476000 e-mail: info(a)sita.aero abuse-c: SITA mnt-ref: RIPE-NCC-HM-MNT mnt-ref: SITA-MNT mnt-by: RIPE-NCC-HM-MNT mnt-by: SITA-MNT created: 2015-06-10T15:19:37Z last-modified: 2016-08-24T10:21:24Z source: RIPE

5 12

Call for Presentations / DRAFT Agenda RIPE81 - Database Working Group
by William Sylvester 14 Sep '20

14 Sep '20

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE81. If you would like to present please submit your content as soon as possible to the chairs. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – XX mins Edward Shryane, RIPE NCC C. Proposed Presentations HERE – YY mins D. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

mntner with misleading primary key
by Tom Hill 08 Sep '20

08 Sep '20

Hello db-wg, A simple query to the RIPEDB ('whois -h whois.ripe.net -r AS2856') returns the aut-num AS2856 that you would expect, but it also returns a mntner with the same primary key: % Information related to 'as2856' mntner: as2856 admin-c: JA6431-RIPE auth: SSO # Filtered mnt-by: as2856 created: 2018-08-23T15:46:37Z last-modified: 2018-08-23T15:46:37Z source: RIPE # Filtered This has caused some concern, and while we (2856) have already determined how that mnter came to be in the database - and that there isn't any immediate risk - it isn't in any way affiliated with the AS2856 network, or any part of the parent company. One can imagine that given the quality of NOCs & their understanding of database objects the world over, that one of them might be convinced that the person associated with this mntner was indeed associated with the network AS2856, and they might also be convinced to announce prefixes that they otherwise should not. It is obvious that speaking to the owner of the mntner and politely asking them to switch to a new mntner would be pertinent, but as far as I'm aware they're under no obligation to do so. Yet, it feels that AS2856 (or any network in the RIPE region) remains potentially at some risk should a bad actor combine such a mntner, with some questionable verification of their credentials, and socially engineer their way toward a route hijack. Should it be possible to create mntners (or other objects) that infer a relationship and/or authority to a given aut-num (or organisation?) Might there be negative side-effects in restricting the primary key of mntners from impersonating other objects? I'm unable to construct a query to the RIPEDB that looks for mntner objects beginning with 'as', in order to gauge how common this is. I suspect that's because the phrase is too short, but if it is possible please do enlighten me! :) Regards, -- Tom

12 22

Re: [db-wg] RPSL requirements in aut-num objects
by Lutz Donnerhacke 28 Aug '20

28 Aug '20

> 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.

1 0

RPSL parser nits
by Lutz Donnerhacke 18 Aug '20

18 Aug '20

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

6 10

NWI-11 Internationalised Domain Names
by ripedenis＠yahoo.co.uk 06 Aug '20

06 Aug '20

Hi Ed The chairs see there is a consensus to move forward with implementing Punycode. Can you present an impact analysis explaining what changes you propose, what effect those changes will have on updates and queries (by all the different methods), if anyone needs to modify their software interacting with the database. cheersdenis co-chair DB-WG

4 9

NWI-11 Internationalised Domain Names
by ripedenis＠yahoo.co.uk 13 Jul '20

13 Jul '20

Colleagues There has been some discussion recently and many times over the years about addressing this issue. The chairs believe there has been enough support shown to move forward with this. We would therefore like to present this as 'NWI-11 Internationalised Domain Names'. We propose a problem statement based on the text provided recently by Leo Vegoda, as shown below. The RIPE NCC has a proposal for a solution to this problem using punycode. We would like to ask the RIPE NCC to present this proposal to the working group. If anyone has any other proposals for a solution, we welcome a discussion on this matter. cheersdenis co-chair DB-WG Problem Statement The RIPE NCC service region includes countries whose language is not written using Latin script. Many of the languages used in the RIPE NCC service region are written in Latin script but use diacritical marks that fall outside the US-ASCII character set. Internationalized Domain Names (IDNs) support the use of these scripts in DNS. ICANN began delegating IDN Top-Level Domains as part of a test program in 2007 and the IETF updated the IDNA protocol in 2008 and as of mid 2020, there were over 160 IDN TLDs in the root zone. The IETF published eight standards track RFCs on using IDNs in e-mail in 2012 and 2013. It is reasonable that organizations communicating with people whose preferred script is not Latin-based would want to use an IDN domain for e-mail as well as a web presence. It is also likely that the registry for an IDN TLD would want to use that TLD for its e-mail addresses. RFC 3912 explicitly notes that the WHOIS protocol has not been internationalized while recognizing that some servers attempt to do so. RDAP has been deployed by the RIPE NCC and explicitly supports internationalization by UTF-8 encoding all queries and responses. The RIPE community could decide to ignore EAI by trying to require organizations to deploy a secondary e-mail address for use in the RIPE Database. This would reduce the effectiveness of the RIPE Database as the secondary address is less likely to be monitored and used, and so be ineffective.

7 19

Puny code or UTF-8 (or both)?
by ripedenis＠yahoo.co.uk 13 Jul '20

13 Jul '20

Colleagues After the recent discussion it seems their is support for the idea of UTF-8, whilst there is also support for Puny code as an interim step. To implement UTF-8 in the RIPE Database requires much more detailed discussions, including non technical aspects of the change. This is not likely to happen quickly. There has been support shown to introduce Puny code as a first step towards internationalisation of the data, which can be done quickly by the RIPE NCC. Do we therefore have support to introduce Puny code now and then consider how to move forward with UTF-8? cheersdenis co-chair DB-WG

8 7

Re: [db-wg] NWI-11 Internationalised Domain Names
by Elad Cohen 07 Jul '20

07 Jul '20

Hello, I would like to suggest an improvement: In the whois database backend, each textual attribute (last name, etc) can have an additional column and in that column the punycode-representation of the attribute value can be written. The punycode-representation can be added in the related column only if there was at least a single non-ascii character in the textual value that was inputted by the user, otherwise it will be empty. The punycode-representation can be in the format of [FIELD-NAME]--[punycode-ascii-characters] instead of xn--[punycode-ascii-characters], in order to avoid duplication with textual strings that starts with "xn--". There shouldn't be "punycode representation" columns in the database for email-related fields, nor for object-reference fields. Using the above, old protocols will still be able to interact with the database as they are now, no ground up development of the whole backend will be needed to support internationalization, the new "punycode-representation" columns encoding is similar to the encoding of the current columns, end-users will be able to use their internationalized names and other internationalized textual strings, RIPE NCC will be able to display internationalized strings online and through supported-services. Regards, Elad ________________________________ From: db-wg on behalf of Edward Shryane via db-wg Sent: Friday, June 26, 2020 5:55 PM To: db-wg Cc: ripedenis(a)yahoo.co.uk Subject: Re: [db-wg] NWI-11 Internationalised Domain Names Dear Working Group, I'd like to propose the following Solution Definition for NWI-11. Introduction Currently, the RIPE database supports email addresses encoded in the Latin-1 character set. However an email address can have an Internationalised Domain Name (IDN), with characters outside Latin-1 (i.e. Unicode). This causes interoperability problems as non-ASCII characters in an email address may not be accepted by a mail server, and only a small subset of Unicode characters can be encoded as Latin-1. Solution Definition In order to support Internationalised Domain Names (IDN) in an email address in the RIPE database, I propose to automatically encode email addresses in the Punycode format. Punycode (as defined in RFC 3492) is a way to encode strings containing Unicode characters, such as internationalised domain name (IDN) domains, into ASCII. When updating the RIPE database, it is already possible to submit a Punycode encoded value (i.e. with ASCII encoding) for an email address value, but this change automates the conversion of any non-ASCII encoded email address to Punycode. This change will only affect attributes with an email address syntax (i.e. abuse-mailbox, e-mail, irt-nfy, mnt-nfy, notify, ref-nfy, upd-to). Automatic Punycode encoding will only be applied to the domain part of the email address. The local part of the address must only contain ASCII characters. If non-ASCII characters are found in the local part, the address is rejected as invalid. When querying the RIPE database, any Punycode encoded email address is returned in Punycode (i.e it is not decoded). I welcome feedback from the community on this proposal. Regards Ed Shryane RIPE NCC On 22 Jun 2020, at 22:49, ripedenis--- via db-wg <db-wg(a)ripe.net<mailto:db-wg@ripe.net>> wrote: Colleagues There has been some discussion recently and many times over the years about addressing this issue. The chairs believe there has been enough support shown to move forward with this. We would therefore like to present this as 'NWI-11 Internationalised Domain Names'. We propose a problem statement based on the text provided recently by Leo Vegoda, as shown below. The RIPE NCC has a proposal for a solution to this problem using punycode. We would like to ask the RIPE NCC to present this proposal to the working group. If anyone has any other proposals for a solution, we welcome a discussion on this matter. cheers denis co-chair DB-WG Problem Statement The RIPE NCC service region includes countries whose language is not written using Latin script. Many of the languages used in the RIPE NCC service region are written in Latin script but use diacritical marks that fall outside the US-ASCII character set. Internationalized Domain Names (IDNs) support the use of these scripts in DNS. ICANN began delegating IDN Top-Level Domains as part of a test program in 2007 and the IETF updated the IDNA protocol in 2008 and as of mid 2020, there were over 160 IDN TLDs in the root zone. The IETF published eight standards track RFCs on using IDNs in e-mail in 2012 and 2013. It is reasonable that organizations communicating with people whose preferred script is not Latin-based would want to use an IDN domain for e-mail as well as a web presence. It is also likely that the registry for an IDN TLD would want to use that TLD for its e-mail addresses. RFC 3912 explicitly notes that the WHOIS protocol has not been internationalized while recognizing that some servers attempt to do so. RDAP has been deployed by the RIPE NCC and explicitly supports internationalization by UTF-8 encoding all queries and responses. The RIPE community could decide to ignore EAI by trying to require organizations to deploy a secondary e-mail address for use in the RIPE Database. This would reduce the effectiveness of the RIPE Database as the secondary address is less likely to be monitored and used, and so be ineffective.

1 0