- db-wg - mailman.ripe.net

WG Co-Chairs Tasks (was: Where are we with NWIs?)
by Sylvain Baya 21 Jul '23

21 Jul '23

{change the topic. focus: basic tasks} Dear RIPE DB-WG, Hope this email finds you in good health. Please see my comments below inline... Thanks. Le mercredi 19 juillet 2023, denis walker via db-wg <db-wg(a)ripe.net> a écrit : > Colleagues > > One or two vocal members of this community frequently express their > opinion that all WG chairs should sit silently in the background, post an > occasional review and wait to declare consensus or not. > Hi Denis, Thanks for your email, brother. ...you seem to disagree with the WG consensus :-) or it's just with those few "vocal" WG participants? Do seek, first, if there is any rough consensus, or not, please. Is there actually any consensus on the matter? > > I am always willing to try out ideas from the community. > That's not part of the tasks of Co-Chairs, imho :-/ ...i may be wrong, though. Again! you *must* ask to the WG participants if they are ok with that idea, first...prior to engage on disruptive behavior. > So for the last couple of months, since RIPE 86, I have stayed silent on > DB matters. > > Please, it's not about you, brother. If you push back to the WG, you would be less concerned about your WG participant's opinions. In what, as a Co-chair, shall you be concerned about your WG's participant opinions? Please think of it twice, brother...if you care much; then how could you act fairly? or in other words: Do you expect your WG participants to hope to get a fair process, at end? > How has the conversation been on NWIs? > > Which one? Is it into the Co-chair's tasks list to follow-up on the active NWIs progress? > > Oh there hasn't been any. > > This WG have three Co-chairs, may i suggest to our Co-chairs to: 1] organise their team; 2] identify their *willing* regular tasks list; 3] discuss it with the DB-WG; 4] distribute the resulting regular tasks list amongst them (Co-chairs) 5] bind on that. > > How have they progressed beyond some steps already in progress? > Oh there hasn't been any. > Are we any closer to completing action on most NWIs? > Er no we aren't. > > Please, do not justify a disruptive behavior by stats poured like that. It *should* not work that way, brother: 1| remove your hat first 2| voice your personal opinion 3| wait the other Co-chairs to seek any consensus 4| put back your Co-chair's hat 5| and go ahead. That's, imho, what Randy is trying to recommend, if i got it well. > > So I think it is fair to say this is not an appropriate way of working > with some WGs these days. > The DB-WG may be an exception, but how to deal with that difference? Revisit the Co-chair's tasks list? What else? > > I will now go back to my previous way of working where, as a co-chair, I > do have an agenda - to get things done, > Please read my previous comments :-) Yes to "Get Things Done"! No to handle "Things" without rough consensus! Yes to do any-"Thing " with "no hat"! > > for the good of the internet. > We have already experienced that before and we know that the "good of the Internet" is a matter of collaborative engagement of any stakeholders available. ...but! don't get me wrong, please: i have no doubt on your sincerity or capacity to act as fairly as it would be possible. Note that those who would come after you would also benefit to whatever disruption we would have agreed on now. Imagine, then, some really bad actor with own hidden *agenda* taking the position after you...what would be the safeguards? ...i stop here, while thinking to have said enough on this topic. By the way! i personally appreciate the fondamental values and expertise of Denis and i hope we would be able to get more benefit on his presence on this WG. Shalom, --sb. > Whether you consider that a 'personal' or 'professional' or 'DB' agenda is > up to you. Just to be clear, this is not the same as for the good of > 'operators'. There are many stakeholder groups in this community now. We > are no longer just > 'the operator community' or even 'the technical community'. > > So I will continue to engage with the community, push out ideas (even > crazy ideas sometimes), start and drive conversations until we get > resolutions. Incidentally, this quiet period since RIPE 86 does remind > us how busy you all are and how difficult it is for you to find the > time to get so involved with the fine detail of small technical and > operational changes to the RIPE Database. Which does fit with the > presentation I did at RIPE 86 on how to manage the RIPE Database. I > will come back to that shortly. > > cheers > denis > co-chair DB-WG > > -- > [...] -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

2 2

Progress on NWI-4
by Wessel Sandkuijl 20 Jul '23

20 Jul '23

Hi, I've reviewed Ed's impact analysis for NWI-4 and his proposal to add a new status value "ALLOCATED-ASSIGNED PA". This will not cover all use cases and it's use will most likely be limited as most people are used to the "ALLOCATED PA" versus "ASSIGNED PA" status values. I would highly prefer the earlier alternative proposal to use a tuple (using both prefix and status) so no new status value is introduced to the RIPE database. Can this be moved forward? Regards, Wessel Sandkuijl

4 4

Route(6) objects
by Kaupo Ehtnurm 12 Jul '23

12 Jul '23

Hello For example I have 2001:1234::/32 ipv6 network. And I want to start using DDoS protection service that one of my ip transit provider offers. But my edge routers are multihomed and enabling ddos protection on one transit provider lets half of the attack still come in from our other ip transit providers in case of DDoS attack. But if our ip transit provider that provides also a ddos protection would hijack the routes from us with more specific routes, then instead of traffic flowing from my other ip transit providers to my AS it flows to my DDOS protection providers AS. Route hijacking solves the problem where half of the attack still comes in to my AS from other transit providers. For in order for the DDoS protection service provider to be able to hijack the routes correctly from us we need to have more specific ROA and route(6) objects done. With ROA it is easy, I just create the following ROA: " 2001:1234::/32 max length 48 ASN AS1234" But with route(6) objects this isn't so easy, because these objects don't have max length or any other operators that it accepts. And because of that I need to hope the entire internet to accept all the /48s that fit into 2001:1234::/32 prefix if I have following route6 object: " 2001:1234::/32 AS1234". But to be correct with my db records I would need to make all the /48 route6 objects that fit into that /32 and instead of 1 object I need to create 65536 objects. First of all I would hit the object creation limit per day in ripe DB. With this limit enabled, I would create the records over 2 months. And the manageability of those records would be a nightmare. If ROAs and route(6) objects go hand-in-hand anyway for the most of the time, then why can't route objects have "max length" or somekind of operator like ROAs have? Lugupidamisega / Best regards, Kaupo Ehtnurm Network & System administrator WaveCom AS ISO 9001 & 27001 Certified DC and verified VMware Cloud kaupo(a)wavecom.ee | +372 5685 0002 Endla 16, Tallinn 10142 Estonia | [ http://www.wavecom.ee/ | www.wavecom.ee ]

9 22

Co-chairs Personal Goals versus only DB Working Group Goals
by Sylvain Baya 08 Jul '23

08 Jul '23

{thread changed to add a maybe late comment} Dear RIPE DB-WG, Hope this email finds you in good health! Please see my comments below, inline... Thanks. Le vendredi 9 juin 2023, denis walker via db-wg <db-wg(a)ripe.net> a écrit : > Hi Randy > > That would be fine if we had a very active and engaging community. Like we > had 20 years ago. > > Hi Denis, Thanks for your email, brother! No excuse! to try to bypass the reminded principle. ...imho! > But the vast vast vast majority of this community is silent on almost all > database matters. The vocal people are a handful of well known members of > the community, > > ...i suspect that it's not only an era problem; my guess is simply that it might be more a matter of natural growth of the population/community. If you check old and current stats of participation ratio, i submit that it would be *almost* influenced only by the population/community growth, with relatively nearly the same numbers of real active participants... That argument of delegitimating those who are voluntarily participating, is not convincing me... How come that those who.are participating are *blamed*? Where are, actually, the others? What's the $threshold of non-representativity? ...i would agree with a *WG's goal* tasking the DB-WG Co-chairs to find a way to have more participation than that $threshold. > whose views on many matters are also quite well known. > > Are we really able to handle more various opinions? ...i mean, you know, suppose half of the accounts subscribed show up here with theirs contributions. ...i agree that it might not be what you asked for; then maybe you should work (or ask RIPE NCC) on finding a way to address the $threshold issue, when identified. > > Sometimes someone raises a point and it gets little or no response. Like > assigning an allocation. Often the chairs know from face to face > discussions, people want this option. But there is no discussion. In > situations like this I've found that a chair needs to drive the discussion. > > Maybe you could (non exclusively): option#1: start with regular reports or blog articles to inform the whole community of those issues raised privately option#2: advise those, who choose to discuss public matters privately, to post it on list; in order to expect the support of part of the WG. option#3: collect allowed private comments to the Staff; for inclusion consideration into their next PIER [*]. > > Even if that means making an outrageous suggestion that no one will agree > to, but it generates a reaction. From the following discussion we can move > forward. > > Also sometimes a chair needs to throw ideas out into the community to move > the service forwards. The chairs talk with the NCC engineers. We often > discuss ideas that no one in the community is thinking about. If the chairs > don't then raise it with the community the idea can never be considered. > > Not sure! imho! the Staff should have a way [1] to share their experience and recommendations regarding their implementation of the Policy Manual. They should share these information on that channel...and if it no longer exists; please ask for a reboot. > So either the chairs or the NCC engineers need to be able to put ideas > into the public domain, and sometimes drive the discussion to get it > started, or technically and socially the database as a product and service > just stagnates. > > __ [*]: PIER (Policy Implementation Experience Report) *Purpose of Policy Experience Report* < https://www.arin.net/participate/meetings/reports/ARIN_34/PDF/thursday/nobi… > <quote_page2> *Purpose of Policy Experience Report* *• Review existing policies – Ambiguous text/Inconsistencies/Gaps/Effectiveness • Identify areas where new or modified policy may be needed – Operational experience – Customer feedback • Provide feedback to community and make recommendations when appropriate * </quote_page2> > I often take on this role, as well as the devil's advocate to question > what others say. I don't see it as pushing a personal agenda. I have no > personal agenda. It doesn't matter to me personally if the database evolves > or dies. It does matter to the industry and society. I have no employer or > financial interest in how the database evolves. I can look at each issue > and consider how it fits in with that old saying...for the good of the > Internet. > > This is one of the reasons why I've put myself forward again as a chair > for another couple of years. > > Thanks for your much appreciated engagement, imho! and congrates for your selection as Co-chair. > I hope in that time David can spearhead a new generation of WG chairs. > > Congratulations and welcome, Co-chair David! Maybe, raising awareness of the need to participate within your generation-peers, should be considered too...dear David :-) > > Then dinosaurs like myself (and others) can ascend into advisory positions > instead of decision making roles. > > Thanks for continuing to support the community and the DB-WG, in particular. Shalom, --sb. > > Cheers > Denis > > > > On Fri, 9 Jun 2023, 15:37 Randy Bush via db-wg, <db-wg(a)ripe.net> wrote: > >> > Some of my goals as a co-chair would be >> > - To support the moderation of the mailing list and facilitate working >> > group tasks >> > - Promote active discussion, sending summary emails to make the >> > content easier to follow >> > - Perform community outreach to raise awareness of this working group >> > and the policy process >> >> /me likes. simple, but what a chair should be doing. leave personal >> agendas at the door. >> >> randy >> >> [...] > > -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

1 0

Database Working Group Chair Selection
by William Sylvester 07 Jul '23

07 Jul '23

Fellow working group members, We currently have two slots open, the first is Denis’s term has come to an end. In keeping with our continuity plan to have chairs on a three year rotation offset yearly. The other open slot has two years remaining as a term. We have two candidates currently for these open slots with preferences as indicated; Denis Walker, two year term David Tatlisu, three year term I encourage each candidate to post any statements they wish to make directly to the working group. This notice serves as the candidate announcement and call for discussion. Thanks, William DB-WG Co-Chair Our current chair process is as revised in 2017, as follows; 1) Number of chairs is a minimum of 2 with a maximum of 3. 2) Chair can be removed at any time by consensus. 3) Chair terms are staggered yearly. 4) One chair per year is replaced. 5) Working group selects chair by consensus. 6) The consensus judgement will be made by the serving WG co-chair(s) and will exclude the co-chair(s) who is the subject of that consensus judgement. 7) Selection process is as follow; 7.1) Interested parties have two weeks to make their interest known via the mailing list, or directly to the Chair/s. 7.2) After two weeks, the Chair/s ensure that all candidates are announced on the mailing list and issue a call for discussion. 7.3) WG members express their approval or otherwise of the presented candidates. 7.4) Two weeks after the call for discussion, the Chair/s declare a decision, based on mailing list discussion, as they would do for a policy proposal. 8) Any appeal over a consensus decision will be heard by the RIPE Chair (or their deputy) whose decision shall be final. 9) In the case more than one chair is up for selection at the same time, the chair with the greatest support will take a multi-year term, the chair with the least support will take the second longest term. Terms will be determined by the number of chairs (3 chairs = 3 year term, 2 chairs = 2 year teams). The intent is to maintain continuity of the working group chairs. So the working group is never left without a chair.

6 8

Inter-RIR ASN Transfer Resulting whois
by Lee Hetherington 07 Jul '23

07 Jul '23

Hi DB-WG, Apologies if this has been discussed before; I recently transferred my personal ASN from RIPE to ARIN. One of the side effects of this, is that the IANA whois, has a referral to RIPE for the entire block of ASNs that my ASN was part of, but of course, the RIPE whois now returns a message stating that the ASN is no longer in the RIPE region, and lists out the other RIRs - but no hints into which one is now responsible (Certainly not so a machine can follow along) - below is the output; refer: whois.ripe.net as-block: 34816-35839 organisation: Assigned by RIPE NCC whois: whois.ripe.net descr: Assigned by RIPE NCC changed: 2005-02 source: IANA # whois.ripe.net as-block: AS35008 - AS35008 descr: ASN block not managed by the RIPE NCC remarks: ------------------------------------------------------ remarks: remarks: aut-num objects within this block represent routing remarks: policy published in the RIPE Database remarks: remarks: For registration information, remarks: you can find the whois server to query, or the remarks: IANA registry to query on this web page: remarks: http://www.iana.org/assignments/ipv4-address-space remarks: remarks: You can access databases of other RIR's at: remarks: remarks: AFRINIC (Africa) remarks: http://www.afrinic.net/ whois.afrinic.net remarks: remarks: APNIC (Asia Pacific) remarks: http://www.apnic.net/ whois.apnic.net remarks: remarks: ARIN (Northern America) remarks: http://www.arin.net/ whois.arin.net remarks: remarks: LACNIC (Latin America and the Carribean) remarks: http://www.lacnic.net/ whois.lacnic.net remarks: remarks: ------------------------------------------------------ mnt-by: RIPE-DBM-MNT created: 2023-06-30T06:35:17Z last-modified: 2023-06-30T06:35:17Z source: RIPE Would it make sense, for the RIPE whois to also include a refer entry, much like that of the IANA whois? In my case, this could be a refer: whois.arin.net entry, in the hope that the whois client follows along and gets the correct record. Of course, the ultimate solution here would be IANA putting a record for the absolute ASN into their data, and sending the whois client along to the now correct whois server. Cheers, --Lee

1 0

Updated Full Text Search API
by Edward Shryane 23 Jun '23

23 Jun '23

Dear Colleagues, In the Whois 1.107 release, we have made some improvements to the Full Text Search API and also to the backend Elasticsearch implementation. We have also improved the API documentation: https://apps.db.ripe.net/docs/11.How-to-Query-the-RIPE-Database/02-Web-Quer… If you prefer using the web interface to Full Text Search, it is still available: https://apps.db.ripe.net/db-web-ui/fulltextsearch If you have any suggestions for improvements or find any issues, please let me know. Regards Ed Shryane RIPE NCC

1 0

RIPE Database Quarterly Planning Q3 2023
by Edward Shryane 23 Jun '23

23 Jun '23

Dear colleagues, We have published our next quarterly plans for the RIPE Database on our website: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning In this quarter, we will continue to work on publishing the source code to our web application and move the RIPE Database documentation to a new interface. By sharing these plans with you, we want to inform you of the ongoing developments on the RIPE Database and get your feedback on other work items you would like us to focus on. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact the DB team directly at ripe-dbm(a)ripe.net . Regards Ed Shryane RIPE NCC

1 0

About rpki
by Cunchang Huang 22 Jun '23

22 Jun '23

I now need to get the expiration time of the rpki we set, how can I get it Cunchang Huang

1 0

NWI-14 Authenticating References to Objects
by denis walker 19 Jun '23

19 Jun '23

Colleagues The chairs propose creating NWI-14 for expanding the optional use of the "mnt-ref:" attribute to protect objects from accidental or intentional mis-representation of responsibility. See slide 14 of this presentation for the problem definition: https://ripe78.ripe.net/presentations/129-RIPE78-Operational-Update.pdf We ask the RIPE NCC to add NWI-14 to the list. cheers denis co-chair DB-WG

3 4

Whois Release 1.107
by Edward Shryane 19 Jun '23

19 Jun '23

Dear colleagues, RIPE Database release 1.107 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 19th June. This release includes the following main changes: * NWI-14: added mnt-ref: attribute to person, role, mntner, irt object types * Sign NRTMv4 notifications * Full text search fixes * Limit resource lookups in RDAP organisation entity requests * Allow any characters in local part of SSO auth: email addresses * Fixed country: attribute validation * Include country: attribute in organisation split file The release notes are on the website: https://apps.db.ripe.net/docs/21.Release-Notes.html#ripe-database-release-1… 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

Sponsored ASNs AccountOwner's in extended delegate file don't move with sponsor
by Ben Cartwright-Cox 15 Jun '23

15 Jun '23

I'm not 100% sure if this is the correct place to report/discuss this quirk I've come across, but db-wg is the closest I have, so here it goes. In (what I call) the RIPE delegate file https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest Sponsored ASNs have slightly funny behaviour. For ASNs that are sponsored, the account owner UUID is always the ASN that sponsored the ASN first. If sponsorship is moved, the account owner UUID does not change. However given (as far as I understand) sponsored ASNs are PI resources, surely they should get the same treatment as the IPv4 and IPv6 entries (in that the PI holder has their own accountowner uuid) What do we think? Is this behaviour of being sticky to the original sponsor account UUID a bug? Should sponsored ASNs have their own account UUID? Have I completely misunderstood what any of this file means? I ask most of this because my own system bgp.tools allows you to quickly lookup resources by account, and for my own production ASN: $ curl -s https://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest | grep 206924 ripencc|GB|asn|206924|1|20170411|allocated|b786bde2-1363-44c5-aec3-5ac65ee325e6 It shows all of the remaining ASNs that were originally registered by the now defunct LIR: https://bgp.tools/rir-owner/b786bde2-1363-44c5-aec3-5ac65ee325e6 Cheers Ben Cartwright-Cox

2 3

NWI update
by denis walker 24 May '23

24 May '23

Colleagues In the past we have done an NWI update as a presentation during the RIPE Meeting. However, as there is usually very little movement on most NWIs, the presentations are not very informative. This time we will present the update as an email and ask for any questions in the AOB at the end of the WG session on Thursday afternoon. NWI-2 Historical queries No comments since RIPE 85 NWI-4 Assigning a full allocation One comment today expressing a preference for the combined primary key (prefix/status) rather than simply changing the status. This allows separate objects for the allocation and the assignment with their own information and references. NWI-12 NRTMv4 In progress, for more details see: https://github.com/mxsasha/nrtmv4/ NWI-13 Geofeed Legal review posted to list last week. The RIPE NCC will discuss internally how to tighten up the wording of the proposed purpose text. The RIPE NCC Executive Board will need to approve the change to the Terms & Conditions to accept the new purpose. Then geofeed should be usable without the previous legal restrictions. NWI-14 Extending use of mnt-ref Implementation in progress by RIPE NCC NWI-16 Using RIPE Database as an IPAM solution No comments since RIPE 85 NWI-15,17,18 Task Force recommendations No comments cheers denis co-chair DB-WG

1 0

Re: [db-wg] Agenda RIPE86 - Database Working Group - REVISED
by William Sylvester 16 May '23

16 May '23

Here is the revised agenda for the Database Working Group for RIPE86. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 10 min * Welcome * Scribe * Jabber * Chairs & Succession Planning * Agenda B. Operational Update– 20 mins Edward Shryane, RIPE NCC C. Managing the RIPE DB – 20 mins Denis Walker, Co-Chair DB-WG D. Use Cases of the RIPE Database – 15 mins Maria Stafyla, Co-Chair DB-WG Z. AOB (open discussion)

1 0

Agenda RIPE86 - Database Working Group
by William Sylvester 15 May '23

15 May '23

Below is the agenda for the Database Working Group for RIPE86. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 10 min * Welcome * Scribe * Jabber * Chairs & Succession Planning * Agenda B. NWI Update – 20 mins Denis Walker, Co-Chair DB-WG C. Operational Update– 20 mins Edward Shryane, RIPE NCC D. Geofeed Discussion – 15 mins Maria Stafyla, Co-Chair DB-WG Z. AOB (open discussion)

2 1

Proposed Service Criticality Form
by Edward Shryane 12 May '23

12 May '23

Dear Colleagues, During RIPE 84 in May, we discussed the Service Criticality Framework. We mentioned that we would like the Database Working Group's input on the criticality rating for the RIPE Database. Thank you to the Co-chairs for asking the working group for input in July with the original form: https://www.ripe.net/ripe/mail/archives/db-wg/2022-July/007527.html Since we have yet to receive any feedback so far, we plan to share our proposed completed form with the working group on Monday, 12 December. We hope that this will invite more input. Regards Ed Shryane RIPE NCC

3 4

chair selection
by denis walker 20 Apr '23

20 Apr '23

Colleagues The process for selecting chairs and terms of office is documented here https://www.ripe.net/participate/ripe/wg/active-wg/db/database-wg-chair-sel… Accordingly, Denis's term of office expires at RIPE 86. If anyone is interested in joining the team please contact db-wg-chairs(a)ripe.net over the next two weeks. cheers William and denis co-chairs DB-WG

1 1

Whois Release 1.106.1
by Edward Shryane 19 Apr '23

19 Apr '23

Dear Colleagues, RIPE Database release 1.106.1 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 19th April. This release includes the following main changes: * NWI-12 NRTMv4 improvements (snapshot, deltas, notification files) * Updated Zonemaster client to match API Changes (used for domain object validation) * Redirect RDAP reverse domain queries to the authoritative source * Fix hightlight issue with dot in Elasticsearch (used by Full Text Search API) 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

-T
by Randy Bush 12 Apr '23

12 Apr '23

i just want to fetch the domain object [ actually, what i would love is to fetch all domain objects with mnt-by: MAINT-RGNET but one step at a time ] ryuu.rg.net:/Users/randy> telnet -4 whois.ripe.net 43 Trying 193.0.6.135... Connected to whois.ripe.net. Escape character is '^]'. % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf -T domain 150.180.198.in-addr.arpa % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '150.180.198.in-addr.arpa' domain: 150.180.198.in-addr.arpa descr: RG79-198-180-151 admin-c: RB45695-RIPE tech-c: RB45695-RIPE zone-c: RB45695-RIPE nserver: rip.psg.com nserver: nlns.globnix.net ds-rdata: 54446 8 2 3b1fdae94f0e47d280e23ad1b62fb1451d98f29f66863420d6a3d0f5fa2f1037 mnt-by: MAINT-RGNET created: 2016-03-16T18:42:51Z last-modified: 2023-04-07T16:00:58Z source: RIPE person: Randy Bush address: RGnet OÜ address: Sakala tn 7-2 address: Tallinn address: EE-10141 address: Estonia phone: +33 7 67 97 33 30 nic-hdl: RB45695-RIPE mnt-by: MAINT-RGNET created: 2019-05-20T12:22:32Z last-modified: 2019-12-12T06:06:38Z source: RIPE % This query was served by the RIPE Database Query Service version 1.106 (BUSA) Connection closed by foreign host. so maybe it wants the option at the end? ryuu.rg.net:/Users/randy> telnet -4 whois.ripe.net 43 Trying 193.0.6.135... Connected to whois.ripe.net. Escape character is '^]'. % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf 230.83.192.in-addr.arpa -T domain % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '230.83.192.in-addr.arpa' domain: 230.83.192.in-addr.arpa descr: RG79-192-83-230 admin-c: RB366-ARIN tech-c: RB366-ARIN zone-c: RB366-ARIN nserver: rip.psg.com nserver: nlns.globnix.net ds-rdata: 142 8 2 1e1f841e69f79afa0c6775647e90597c88dbe7121867473700b7a51c358d9045 mnt-by: MAINT-RGNET created: 2016-03-16T18:42:51Z last-modified: 2016-03-16T18:42:51Z source: RIPE person: Randy Bush address: RGnet, LLC address: 5147 Crystal Springs address: Bainbridge Island, WA 98110 address: United States phone: +1 206 356 8341 fax-no: +1 206 973 2762 nic-hdl: RB366-ARIN mnt-by: MAINT-RGNET created: 1970-01-01T00:00:00Z last-modified: 2019-12-12T06:03:49Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.106 (SHETLAND) Connection closed by foreign host. clue bat appreciated randy

3 3

More specific INET6NUM for IPv6 PI
by Tobias Fiebig 04 Apr '23

04 Apr '23

Heho, for some unrelated reasons I have been thinking about more specific INET6NUM objects for IPv6 PI assignments that still list the same organization but detail a specific purpose of the more specific to aid, e.g., debugging and information sharing. As this is a relatively quick thought that crept up to my brain (I don't want to request or suggest anything; More interested in understanding the current situation), i'd really appreciate some input, mainly to understand where i might have missed some context. With best regards, Tobias # Description The following might, for example, be the use of a /48 PI assignment: 2001:db8:1234::/48 2001:db8:1234::/52 - Public Internet Infrastructure 2001:db8:1234::/56 - Network; Loopbacks, transfer etc. 2001:db8:1234:100::/56 - Infrastructure PoP1 (mail, web, DNS) 2001:db8:1234:200::/56 - Infrastructure PoP2 (backup, DNS) 2001:db8:1234:f000::/52 - Office France 2001:db8:1234:f000::/56 - Office (infra) France 2001:db8:1234:f100::/56 - Office (wired) France 2001:db8:1234:f200::/56 - Office (wifi) France 2001:db8:1234:f300::/56 - Office (guest wifi) France 2001:db8:1234:d000::/52 - Office Germany 2001:db8:1234:d000::/56 - Office (infra) Germany 2001:db8:1234:d100::/56 - Office (wired) Germany 2001:db8:1234:d200::/56 - Office (wifi) Germany 2001:db8:1234:d300::/56 - Office (guest wifi) Germany Dedicated INET6NUM objects could be useful for: - The per-office-country /52 to properly attribute geoloc and direct to the right (local) role contacts (noc.fr(a)example.com vs. noc.de@) - Indicate that the internal office wifis have a /64 on each client - Indicating the status of the guest wifis and a different abuse department, as they--containing externals--might have to be handled differently, and there is no prefix delegation (PI requirements) - Creating objects for pop1/pop2 infra networks (noc.infra@, detailing use for public-facing/DMZish systems) - Creating objects providing additional information on more specifics that may show up in traceroutes - ... In all cases, the ORG of the objects would remain the same as that of the assigned /48. This is currently not possible in the DB as: - There is no fitting status:, and ASSIGNED PI can not use by LIR/end- user MNTs - The creation of more specific INET6NUM objects is not allowed in general Arguments against allowing more specifics below PI are: # The org should just request one PI per pop/use (infra/de/fr) Here, I would argue, that this does not necessarily conform to address space conversation; Technically, the /48 is enough for this specific org. Also, while RIPE 738 2.6 notes that assignments should only be made for _specific_ purposes, it explicitly lists some of the use-cases and splits described above. Furthermore, when requesting PI, the ability to use more specifics from a /48 is a common argument why only a /48 can be provided to one end-user with multiple pops. Similarly, requesting multiple /48s increases the numbering overhead for the end-user, and even if one larger-than /48 assignment was made (which is a discussion out-of-scope and for another wg here), the issue of creating more specifics for the /48s would remain the same. # Policy forbids it I am actually not sure whether ripe-738 actually forbids this. Reading Sec. 2.6, I only see a restriction to specific purposes (see above) and a restriction of more specifics being 'sub-assigned to other parties', which is reiterated in the preamble of Sec. 7. In my reading, though, that does not mean that an assignee could not create more specific INET6NUM to more accurately document the extend of the specific use of the assignment, as long as the ORG remains the same. -- Tobias Fiebig M tobias(a)fiebig.nl

4 3

ORGANISATION country code
by denis walker 23 Mar '23

23 Mar '23

Colleagues We have a number of outstanding issues from RIPE 85 so let's start with NWI-10. Ed said in his update, "Country code is now editable in organisations without co-maintained resources" I think this is a really bad idea. The country codes entered into ORGANISATION objects by the RIPE NCC are well defined, verified and maintained by the RIPE NCC. If we allow users to edit this field in other ORGANISATION objects, the values they enter will be undefined, unverified and meaningless. Just like the country code in resource objects. I don't think we should allow more meaningless data to be added to the RIPE Database. Even worse, we are mixing well defined data with meaningless data in the same attribute in the same object. This will end up with some people trusting all of this data and some people not trusting any of it...confusion. I suggest we don't allow users to enter any data into this attribute and remove any data that may have already been entered. If there is a need for resource holders to enter a country code in ORGANISATION objects set up for end users, then let's define a specific attribute for that with a well defined meaning. Your thoughts are welcome... cheers denis co-chair DB-WG

11 36

RIPE Database Quarterly Planning Q2 2023
by Edward Shryane 21 Mar '23

21 Mar '23

Dear colleagues, We have published our quarterly plans for Q2 2023 for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning In this quarter, we will work on the NWI-12 NRTMv4 implementation, publishing the source code to our web application and opening the Full Text Search API to end users among other items. We hope that by providing these plans, we can better inform the community of the ongoing developments on the RIPE Database and get feedback on our work. The goal of our quarterly planning is to communicate the work we’re doing for the coming months, get your input and start a discussion on other developments we should work on. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact the DB team directly at ripe-dbm(a)ripe.net . Regards Ed Shryane RIPE NCC

1 0

Discussion and Decision making in the DB-WG
by denis walker 08 Mar '23

08 Mar '23

Colleagues I would like to clarify a couple of points here in case anyone has doubts. I often get heavily involved in some discussions on the mailing list. I sometimes have strong views and probably come across as quite pushy. But I always present arguments to support my viewpoint. I am not one of those who make a bold headline and then disappear behind a rock, expecting you to just accept my comment. Of course I am not always right. I am happy to hear from anyone who (partially) disagrees with me or others as long as you offer some arguments to support your viewpoint. I also like to hear from people who (partially) agree with me or others. We don't get a lot of people joining discussions on this mailing list. That's one of the reasons I reply to many comments to try to keep the discussion alive. Sometimes someone makes a comment, no one responds and the conversation dies. But on the other hand, by replying to many of the comments, some people may see me as talking over you. It is a fine line to get it right. The bottom line is, if more people were involved in discussions, expressing a range of supported views, I could say less or even shut up. To make decisions it is always better to have multiple views. When it comes to decisions, if I have been heavily involved in a discussion I always step back from the final decision. In those cases William will make the decision. So just because I am a co-chair and push a particular view does not mean it is a done deal. It really would help if more people expressed opinions on these issues we try to develop... cheers denis co-chair DB-WG

1 0

Set default maintainer on locked inetnum resources
by Edward Shryane 06 Mar '23

06 Mar '23

Dear colleagues, From time to time, the RIPE NCC gets requests from LIRs to unlock their PA assignments that have RIPE-NCC-LOCKED-MNT as mnt-by. These inetnums are locked due to the deprecation of the NONE authentication scheme in 2004: https://www.ripe.net/publications/news/announcements/deprecation-of-the-non… A total of 438 ASSIGNED PA AND 13 LEGACY inetnums have both this maintainer, and a responsible LIR organisation referenced in a less-specific inetnum. The DB team wishes to update these inetnums with the responsible LIR's default maintainer, so they can be maintained by the LIR without needing to contact the RIPE NCC. We will inform the affected maintainers. Please let me know your comments. If there are no objections, I'd like to implement this in the coming weeks. Regards Ed Shryane RIPE NCC

3 6

recording ROV enforcement
by Tomas Hlavacek 03 Mar '23

03 Mar '23

Dear colleagues, In the last few years we saw numerous experiments that strove to identify networks that enforce ROV. These works came not only from the scientific community but also from the industry, which indicates that many different parties are interested in this question and are willing to work to get the answer. This brings me to the question whether there is any structured and machine-readable way that the networks and IXPs can use to publish the fact that they enforce ROV? It seems that the logical place for this would be IRR and therefore I am off-topic here, but since I am not aware of any previous efforts to extend the RPSL for this particular purpose and I can imagine reasons against it, I was wondering if there is something else, possibly in the non-IRR part of the RIPE DB or somewhere else? Best regards, Tomas

3 3