- db-wg - mailman.ripe.net

Whois Release Process
by Cynthia Revström 24 Jun '19

24 Jun '19

Hello DB-WG, Ed proposed a change to the WHOIS release process at the DB-WG session @ RIPE78. This change would be to immediately deploy bug fixes without a release candidate. I would just like to voice my opinion on it, so my thought is that maybe give the db-wg 24h to voice opinions or something like that. Just a thought but anyways. - Cynthia

4 5

RIPE Database Questionnaire
by Sandra Bras 05 Jun '19

05 Jun '19

Hello everyone, As a follow-up to my short presentation in the RIPE Database Working Group session during RIPE 78, I would like to share the link to our questionnaire. We’re currently developing the RIPE Database exam for the RIPE NCC Certified Professionals programme. It is crucial that we align not only our learning content, but also the exam questions, with the tasks you regularly carry out in the RIPE Database. It is important for us that, as an experienced user of the RIPE Database, you help us ensure that our testing is robust and relevant, by completing this short questionnaire (only four questions): https://www.ripe.net/support/certified-professionals/ripe-database-question… <https://www.ripe.net/support/certified-professionals/ripe-database-question…> Read more about the RIPE NCC Certified Professionals programme in this RIPE Labs article: https://labs.ripe.net/Members/sandra_bras/ripe-ncc-certified-professionals-… <https://labs.ripe.net/Members/sandra_bras/ripe-ncc-certified-professionals-…> And sign up to take part in the pilot RIPE Database exam and become one of our first RIPE NCC Certified Professionals: https://www.ripe.net/support/certified-professionals <https://www.ripe.net/support/certified-professionals> Please do contact me if you would like any further information. Warm regards, Sandra Brás E-Learning Programme Manager RIPE NCC

2 1

Authenticating References to Objects
by Edward Shryane 04 Jun '19

04 Jun '19

Dear Working Group, as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects. Currently, only references to organisation objects can be protected with the mnt-ref attribute. However, we could extend this protection to other types of objects: - Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s) This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email). Please let me know your feedback on this proposal. Regards Ed Shryane RIPE NCC

8 10

NWI-9 In-band notification mechanism - proposed Solution Definition
by Edward Shryane 28 May '19

28 May '19

Dear Working Group, given the Problem Definition for NWI-9: "There is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status." As presented at last week's DB-WG meeting, I'd like to propose a Solution Definition: (1) The current NRTM service is not suitable. The current NRTM is a member-only service, with a separate agreement: https://www.ripe.net/manage-ips-and-asns/db/nrtm-mirroring The work needed to change this (including technical changes to open the service) is greater than providing a re-implementation. The existing service will remain available on the same terms. (2) Implement a replacement NRTM interface The current NRTM is a custom protocol, which is complicated to use, and not easy to extend without breaking existing clients. Instead implement a replacement NRTM interface, based on modern standards. - The interface is generally available without needing to be a member, or to sign an agreement. - The protocol uses HTTPS and WebSockets, with object data in JSON format. - A client can request the current available range of updates, and also request a closed or open range of updates. - A separator comment is inserted between updates, with an 'end of stream' comment after each group of updates. - All object updates are returned, except for person and role objects. - Personal data is filtered from all object updates, consistent with the other query interfaces. - A client can optionally request filtering updates by object type. - A client can optionally identify themselves by providing credentials. - The interface can be extended later by adding more request parameters. Please let me know what you think. Regards Ed Shryane RIPE NCC

3 2

Suggestion further validity-checking
by Jens Ott - Opteamax GmbH 28 May '19

28 May '19

Dear DB-WG, I am newly subscribed to this mailing-list although I am already active in RIPE-community for quite some time. Some of you might know me in person. To be honest, I am not sure if this is the right place to send my mail to and if it's not I'd be happy to be told who to address better. For debugging our prefix-list-generator I increased verbosity of the tool a little. As side-effekt I was also pointed to a route-object in the ripe-database which contains a "hole"-definition where the netmask doesn't match (X.Y.226.0/21) and actually is the same size as the entire route-object. I already contacted the maintainer of that object but think it might be a good idea to add a validity-check on adding new objects to prevent this kind of faulty objects in the DB. Best regards -- Jens Ott Geschäftsführer Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo(a)opteamax.de HRB: 23144, Amtsgericht Montabaur Geschäftsführer: Jens Ott Umsatzsteuer-ID.: DE264133989

6 10

NWI-8: LIR's SSO Authentication Groups - Implementation Plan
by Edward Shryane 27 May '19

27 May '19

Dear working group, here is the RIPE NCC's proposed implementation plan for NWI-8: LIR's SSO Authentication Groups. Scope - To simplify the implementation, synchronisation will be done using the existing SSO authentication method. - Authentication groups (and any new authentication method) will be deferred until later. Introduction - The synchronisation of non-billing users with the RIPE database will be done with a default maintainer. - Setting a default maintainer for the organisation is a pre-requisite for synchronisation. - A default maintainer is already able to maintain the organisation object and top-level resources. - Extending this existing mechanism simplifies the synchronisation of users. Implementation - A new checkbox will be added to the Account Details page in the LIR Portal, in the Maintainer section. - "Synchronise non-billing users with the default maintainer". - If no default maintainer is set, the checkbox is disabled. - The synchronise checkbox is not checked by default (the user must confirm this action first). - When the user enables the synchronise checkbox, they must first authenticate with the default maintainer. - The user must prove they control the maintainer before user accounts are added to it. - If the user's account is already present on the maintainer, this authentication is automatic. - Otherwise if the maintainer contains any password credentials, the user will be asked for a password. - Otherwise the user is asked to first add their credentials to the maintainer separately. - Once the checkbox is enabled, synchronisation is performed. - Any existing user accounts are removed from the maintainer. - Any non-billing user accounts are added to the maintainer. - Any other credentials (passwords or PGP keys) are not affected. - After synchronisation is enabled - Whenever a non-billing user is added or removed from the organisation, the default maintainer is updated accordingly. - A default maintainer can only be synchronised with a single organisation. - If a user is removed from one organisation, but remains in a different organisation, this would create a conflict when synchronising. - If synchronisation is disabled - Users are no longer synchronised with the default maintainer, but existing user accounts are not removed. - Notifications - To receive email notifications when the default maintainer is updated, use the notify: and/or mnt-nfy: attribute(s) on the maintainer itself. Regards Ed Shryane RIPE NCC

3 3

Agenda RIPE78 - Database Working Group
by William Sylvester 16 May '19

16 May '19

Database WG Members, Please find the attached agenda for the RIPE Database Working group meeting in Iceland. Regards, William & Denis A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 20 mins Edward Shryane, RIPE NCC C. Personal Data in the RIPE Database – 15 mins Denis Walker D. Cleaning Up Locked Persons – 10 mins Edward Shryane, RIPE NCC E. Country Codes Proposal – 10 mins Nikolas Pediaditis, RIPE NCC F. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Whois Release 1.94
by Edward Shryane 08 May '19

08 May '19

Dear Working Group, RIPE Database release 1.94 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Wednesday, 8th May. Release 1.94 includes the following changes: * Notify the user in the abuse-c comment if address validation has not been completed. * Improved email address validation. * Perform daily limit accounting for personal data in the Full Text Search interface. * Do not remove an abuse-mailbox attribute from a role object, if that role is referenced in a resources' abuse-c attribute. The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt The release notes have been published: https://www.ripe.net/manage-ips-and-asns/db/release-notes 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-9 In-band notification mechanism? ???
by ripedenis＠yahoo.co.uk 15 Apr '19

15 Apr '19

Colleagues Problem Definition There is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status. Last week Aris was the only person to confirm that he wants this feature. If we are to move forward with this feature can a few more people wave their hands in the air, or send a +1 email. cheersdenis co-chair DB-WG

6 5

NWI-8 LIR´s SSO Authentication Groups
by ripedenis＠yahoo.co.uk 15 Apr '19

15 Apr '19

Colleagues I think we have now agreed on these problem and solution definitions: Problem Definition LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account will be contained in a default authentication group -Non billing users added or removed through the portal UI will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service Stage 2 -Non billing Users listed in an LIR´s portal account can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method The chairs will now ask the RIPE NCC to work from these definitions in preparing their implementation plan. cheersdenis co-chair DB-WG

2 1

NWIs update
by ripedenis＠yahoo.co.uk 10 Apr '19

10 Apr '19

Colleagues We would like some feedback on the following NWIs and their current status. I would also like to remind colleagues that we have posted a couple of questions on the Address Policy WG mailing list about policy requirements for contact details. We would appreciate some feedback on those questions on that mailing list. cheersdenisco-chair DB-WG NWI-7 abuse-c implementation If the RIPE NCC can confirm that the cleanup of PERSON, ORGANISATION, MNTNER and IRT objects has been done to remove any "abuse-mailbox:" attributes and the 'person' keyword has been updated to take account of the "abuse-c:", we would like to mark NWI-7 as 'Finished'. NWI-8 LIR´s SSO Authentication Groups We agreed on this problem definition: Problem DefinitionLIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Do we agree on this (staged) solution definition?(Draft) Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, will be contained in a default authentication group -Non billing users added or removed through the portal UI, who have an SSO authentication account, will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service -(Non billing users who did not have an SSO authentication account who then create one, will be automatically adjusted in this group - NCC, is this feasable?) -(Non billing users who are listed in the LIR's authentication group who then delete their SSO authentication account, will be automatically adjusted in this group - NCC, is this feasable?) Stage 2 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method NWI-9 In-band notification mechanism? ???Is there a wish to create this issue as an NWI with the following problem definition? Problem DefinitionThere is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status.

9 25

Call for Presentations / Draft Agenda RIPE78 - Database Working Group
by William Sylvester 08 Apr '19

08 Apr '19

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE78. 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 – 50 mins Edward Shryane, RIPE NCC C. Proposed Presentation HERE – 10 mins D. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

NRTM Open access
by Cynthia Revström 03 Apr '19

03 Apr '19

Hello db-wg, This is sort of a follow up on a previous discussion. I would just like to say that in a project I am working on as a volunteer I would like to have NRTM, but really we can't mess around with the agreements and such for how NRTM currently is at RIPE. So I would really like the NRTM access to be open. Because if you look at it like this, you can very easily download the entire database that is updated every 24h, but not get NRTM access which is the same but realtime. How does this make sense? - Cynthia

1 0

personal data...next step?
by ripedenis＠yahoo.co.uk 25 Mar '19

25 Mar '19

Colleagues I made a presentation at RIPE 77 last year about personal data in the RIPE Database. Whilst I have been thinking a lot about this since then, and some other comments have been made on different mailing lists recently, no action has yet been considered. This is not a trivial issue to fix and there are a number of points to consider. It will most likely require some semantic changes to the RIPE Database, and possibly the internal Registry Database and member portal may need some changes, as well as some work to be done by resource holders. It may also be an appropriate moment to review the requirements for contacts and contact data in both databases. The optimal solution is to manage the changes necessary to be compliant with privacy laws and practices with the least technical changes and work required by resource holders within a reasonable time frame. I see two approaches to doing this, a lightweight and a heavyweight option. The lightweight option is for myself, working with a couple of members who are interested in finding solutions for this issue, to look at all the concerns, raise points with the community for clarification and work towards a policy proposal on personal data in the RIPE Database. The heavyweight option is to set up a task force to look at the whole issue surrounding contacts and personal data, consider possible solutions and report back to the community at a future RIPE Meeting. My personal preference is for the lightweight option. Whilst it is an issue suitable for a Task Force to consider, history shows that Task Forces often take years to reach conclusions and workable solutions. The previous Data Protection Task Force met for 3 years and the recent Accountability Task Force has been meeting for over 2 years, whilst BCOP has been in operation for more than 5 years. I feel this issue needs a solution implementing this year. I would like to hear opinions from the community on which way to go.... cheersdenisco-chair DB-WG

4 4

In-band notification mechanism?
by Aris Lambrianidis 24 Mar '19

24 Mar '19

Dear all, Back in the day, RFC1996 introduced the NOTIFY mechanism in DNS, which significantly helped with information propagation delay, as it facilitated the transition from a pull (poll) to a push (interrupt) model. The problem we, as AMS-IX, are facing is quite similar when it comes to polling the RIPE database for changes. This seems inefficient. Although the analogy breaks down quickly, as there are no RIPE database "clients" similar to DNS slave servers parsing NOTIFY messages, we would love to see any RIPE API created or extended, or any other mechanism implemented by which a client "registers interest" for any objects it wants to be notified of changes. As a simple example, if we were to "register interest" (e.g. via a REST POST or PUT method) for the AS-AMS-IX-SET as-set object, we would be programmatically notified whenever the "last-modified" field of the as-set was changed. Based on the above, I have 3 questions: 1. Does something like what is described above already exist? 2. If it doesn't exist, would others be interested on such functionality? 3. If it doesn't exist, while knowing that this is only a high level overview of the concept and many details are missing, is this generally feasible? Kind regards, Aris Lambrianidis AMS-IX

7 20

Database website supporting the template and verbose flags on the query page again
by Ivana Svonja 15 Mar '19

15 Mar '19

Dear Working Group, we have now restored support for the template (-t) and verbose (-v) flags to the query page on the Database website: https://apps.db.ripe.net/db-web-ui/#/query <https://apps.db.ripe.net/db-web-ui/#/query> Regards Ivana Svonja RIPE NCC

1 0

Personal Data in the RIPE Database - next step
by ripedenis＠yahoo.co.uk 11 Mar '19

11 Mar '19

Colleagues All the responses made indicated a preference for the lightweight option to move forward. Elvis Velea and James Kennedy indicated that they are interested in working with myself on a policy proposal. We will make a start on this and bring some issues to the community as we go along that need a wider viewpoint. cheersdenisco-chair DB-WG

1 0

as-set object(s) to declare AS value frameworks
by Niels ten Oever 08 Mar '19

08 Mar '19

Dear Database WG, Recent public debates on the ethics and social implications of digital technology, as well as the feedback I received on my presentation at RIPE77 [0], have stimulated me to think more about how value frameworks can inform routing decisions. Based on the analysis of several discussions in the IETF community [1], the ICANN community [2], and the recent book by David Clarke [3], I thought a voluntary declaration of values might be relevant for discussion in the RIPE community. A way of doing this could be the discussion of the introduction of two AS-SET objects in the routing database. This could enable Autonomous Systems to declare the values frameworks they adhere to. An example of possible objects would be: [object0] as-set: AS-GDPR remarks: members of this set declare to be compliant with the General Data Protection Regulation of the European Union mbrs-by-ref: ANY [/object0] [object1] as-set: AS-UNGP remarks: members of this set declare to have adopted and implemented the United Nations Guiding Principles on Business and Human Rights mbrs-by-ref: ANY [/object1] Members of these sets would declare to live up to these values. Based on these sets, other AS-es could, for example, choose to preferentially route via AS-es that are member of (one of) these sets. These value frameworks (the GDPR and UNGPs) were chosen because these are widely known and adopted standards in our community [4], so the understanding of these values should not be subject to a lot of interpretation and discussion. Do you think this would be a reasonable approach, and if so, would you consider becoming a member of (one of) these sets? Or do you think there are better ways to achieve this? Looking forward to hear what you think. Best, Niels PS I posted a similar e-mail to the routing WG to discuss the routing implications of this proposal. Please accept my apologies if this is considered as cross-posting, but I thought both aspects of this proposal might be interesting to discuss. [0] https://ripe77.ripe.net/archives/video/2113/ [1] For instance in the discussions on RFC1958, RFC3935, RFC6873, RFC7258, and RFC8280 [2] Most notably resulting in the addition of a commitment to human rights during the IANA transition, but of course as well during the extensive WHOIS discussions [3] https://mitpress.mit.edu/books/designing-internet [4] For instance SIDN has engaged in a Human Rights Impact Assessment https://www.sidn.nl/a/over-sidn/mensenrechten-daar-voldoen-we-toch-aan , and Cisco, Ericsson, Google, NTT, Orange, AT&T, IBM and many others have adopted the UNGPs - Cisco https://www.business-humanrights.org/en/cisco-systems-0?keywords=cisco - Ericsson https://www.business-humanrights.org/en/ericsson-0?keywords=ericsson#a117755 - Google https://www.business-humanrights.org/en/google-0?keywords=google - NTT https://www.business-humanrights.org/en/nippon-telegraph-and-telephone-ntt-… http://www.ntt.co.jp/csr_e/report.html - Orange https://www.business-humanrights.org/en/orange-0 - AT&T https://www.business-humanrights.org/en/att-0?keywords=AT&T - IBM https://www.business-humanrights.org/en/ibm-0?keywords=IBM -- Niels ten Oever Researcher and PhD Candidate Datactive Research Group University of Amsterdam PGP fingerprint 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

2 1

personal data...next step?
by Jetten Raymond 04 Mar '19

04 Mar '19

Hi, I would prefer the lightweight option as well. Rgds, Ray

2 1

Whois Release 1.93
by Edward Shryane 04 Mar '19

04 Mar '19

Dear Working Group, RIPE Database release 1.93 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Monday, 25th February. Release 1.93 includes the following main changes: * Improved email address validation. * Do not allow expired public keys to authenticate updates, and expire signed messages after 1 hour. * Validate bogon space in route(6) creation. * Warn the user if the resource abuse-c is identical to the organisation's abuse-c. * Allow use of elliptic curve algorithm in key-cert objects (updated cryptography library). * Fixed NRTM client parsing end of stream comment in keepalive mode. * Filter out comment in autocomplete API (used by the DB web application) * Only validate reserved words in primary key on create, so existing objects can be updated. * Database schema changes for 2017-02 Abuse-c Validation implementation. The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt The release notes will also be published shortly: https://www.ripe.net/manage-ips-and-asns/db/release-notes 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 2

Whois Release 1.92.6.2
by Edward Shryane 01 Mar '19

01 Mar '19

Dear Working Group, RIPE Database release 1.92.6.2 was deployed to production yesterday evening, with a single change from the previous 1.92.6 release. Following the Database downtime on 22 February, this change restores the Full Text Search functionality. More information on the downtime can be found on our website: https://www.ripe.net/support/service-announcements/ripe-database-full-text-… We apologise for any inconvenience caused by this incident. Regards Ed Shryane RIPE NCC

1 0

No more personal objects in the RIPE Database?
by Hans Petter Holen 23 Feb '19

23 Feb '19

Following Denis’s presentation at the last database working group meeting and Elvis’s messages to the RIPE NCC members list I think it is time to have a new discussion on the need for personal objects in the RIPE Database. https://ripe77.ripe.net/presentations/63-PERSONobjects.pdf https://ripe77.ripe.net/archives/video/2298/ https://www.ripe.net/ripe/mail/archives/members-discuss/2019-February/00329… This is not questioning previous legal assessments of GDPR compliance, but taking a step back and looking at how would we do this if we were to design the RIPE Database with today's privacy requirements in mind. The ccTLD for .NO, Norid made an update to their service last year to completely remove person objects from their database. https://www.norid.no/uploads/2017/12/Datamodell-revidert-en-v2.pdf In terms of the RIPE Database, that would mean that resources would refer to organisational objects and roles, not to personal objects. Perhaps Denis and/or Elvis would propose a policy change in this respect? Hans Petter

3 3

Re: [db-wg] Idea: magic mntner for all LIR contacts
by Tore Anderson 19 Feb '19

19 Feb '19

* Aleksi Suhonen > On 03/12/2018 10:35, Tore Anderson via db-wg wrote: >> So I was thinking: is this mandatory and error-prone duplication of work >> really necessary? Wouldn't it be possible to instead have some kind of >> magic mntner object that is is kept automatically up to date with «auth: >> SSO»-attributes for all the LIR user accounts? > > I second this idea. Perhaps this should be a different object type tho, to make it clear that editing the magic maintainer by hand will have undesired results. It should be interchangeable with normal maintainers of course, a bit like person objects and role objects are. Or maybe just expand the existing SSO attribute to accept a RegID. For example: mntner: FOOBAR-MNT auth: SSO no.foobar Which would allow maintenance by all registered user accounts in LIR no.foobar (except for accounts with the «billing» privilege level). > Do you want someone to co-author a PDP on this? I was hoping that a PDP wouldn't be necessary, to be honest. That is, if the NCC thought it was a good idea they could just go ahead and implement it. (If I recall correctly, the «auth: SSO» functionality was added without there being a community policy demanding it.) That said, if you want to write a proposal to this effect I'd be happy to put my name on it. Tore

9 44

Proposal for restricting authentication concerning use of revoked and expired GPG ID's in key-cert objects
by Christoffer Hansen (Lists) 11 Feb '19

11 Feb '19

Dear DB WG, It came to my attention the RIPE NCC Database does not do validation of signed updates. (Other than checking the key is allowed to sign updates for object(s) in question) I got the understanding from writing to DB-WG-Chairs this was a decision made years back. I think is less than optimal from a security perspective an signed update (with GPG and/or X509 certs) is not validated against (1) when the update was signed (E.g. signing was done 10 minutes ago) and (2) that the expiration date for the keys are not validated. Usually I will expect if I revoke a GPG-key|X509-cert. It cannot be used any more. But the RIPE NCC Database does still allow this currently. This is relevant in the case I ever lose a private GPG-key|X509-cert to less than friendly 3rd-parties. And the lost private GPG-key|X509-cert is the one used for signing updates to the database. What I have in mind. Is the RIPE NCC Database begins verifying validity (not revoked and/or expired) of GPG-key|X509-cert used to sign updates with. Christoffer

7 10

Certain sponsored? ASNs without sponsoring-org
by Cynthia Revström 08 Jan '19

08 Jan '19

So I have now run across several ASNs in which the org is of type "OTHER" yet there is no sponsoring-org, could this please be clarified? Example ASNs: AS200358, AS204842 If it is like I think it is, it must be that they have lost their sponsors but if that is the case, I would like to see a remark that is an "RIPE NCC managed value" saying something like "This ASN does not have any sponsor since YYYY-MM-DD". I am not entirely sure on this but something to clarify what is going on. Kind regards, Cynthia Revström

5 9