- db-wg - mailman.ripe.net

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