- db-wg - mailman.ripe.net

Chair Selection Process Revision Proposal
by William Sylvester 29 Jan '18

29 Jan '18

WG Members, At the RIPE75 in Dubai, the working group chairs committed to presenting a proposal for revising the chair selection process and general housekeeping of the Database working group. This was motivated from some of the challenges we experienced as a working group over the past year. After taking a review of the other RIPE community working groups, the proposal below represents what we feel Is a fair approach to revise our current processes. This also includes clarification on matters where previously our processes were unclear. This also includes comments and feedback from members of the working group. Please express your support or otherwise for these changes, the intent is to use this process for future chair selection including the pending selection process due. Kind regards, William & Denis DB-WG Co-Chairs Proposed revision to the Database Working Group chair selection process; 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.

4 4

Last Call - creation of new out of region ROUTE(6) objects
by denis walker 11 Jan '18

11 Jan '18

Colleagues Plans to implement the solution for NWI-5 by dropping the auth requirement from ASNs in ROUTE(6) object creation and marking existing out of region ROUTE(6) objects in the database with a different source tag are progressing. In December I asked if we should continue to allow the creation of new ROUTE(6) objects in the RIPE Database (with the new source tag) for non RIPE address space. There were a few comments supporting the view NOT to allow any new object creations. There were no comments supporting the continued creation of any new objects. During the earlier, lengthy discussion on NWI-5 quite a few people supported the use of the RIPE Database for ROUTE(6) objects for non RIPE address space. With the plan to drop the ASN auth requirement are those people satisfied that we no longer need to create these ROUTE(6) objects in the RIPE Database? So basically I am making a last call to see if anyone still feels there is any need to allow creation of any new ROUTE(6) objects in the RIPE Database for non RIPE address space? cheersdenisco-chair DB WG

5 6

Creation of out of region ROUTE(6) objects
by denis walker 14 Dec '17

14 Dec '17

Colleagues We are now approaching the implementation stage for managing the existing out of region ROUTE(6) objects in the RIPE Database (NWI-5). A question has been asked about the creation of new ROUTE(6) objects in the RIPE Database relating to non RIPE address space. This will still be technically possible after implementation of the solution for NWI-5. The question we now need to answer is...Do we want to allow the creation of new ROUTE(6) objects in the RIPE Database for non RIPE address space? Over the years this issue has been debated within this community there have been arguments made for and against this situation. The case against doing this is well known now. If anyone believes there is still a case for allowing these object creations (either for any address space or for some section of the global address space) then can you please make your case now. We would like to wrap up this whole issue with a clear consensus from the community. cheersdenisco-chair DB WG

4 3

Validation on "org-name:" syntax (double spaces and newlines)
by Alexander Stranzky 01 Dec '17

01 Dec '17

Am 12.11.17 um 12:00 schrieb db-wg-request(a)ripe.net: > Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the ?org-name:? attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the ?org-name:? matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. While currently not an issue, you should include other non-spaces whitespace (i.e. Tabs & NULL-Bytes) in your blacklist. Regards, Alex -- velia.net Internetdienste GmbH * Hessen-Homburg-Platz 1 * D-63452 Hanau Geschäftsführer: Franz G. Köhler, Arek Akilli * AG Hanau * HRB 7588 Tel: +49 6181 1898119 * http://www.velia.net Follow us on twitter: https://twitter.com/velia_net

4 3

Validation on "org-name:" syntax (double spaces and newlines)
by Tim Bruijnzeels 23 Nov '17

23 Nov '17

Dear Working Group, Out of 114181 ORGANISATION objects, 112 objects use multiple consecutive whitespace in the “org-name:” attribute and only 1 uses a multi-line value. While this is a tiny fraction these objects are a bit problematic to us when we verify that the “org-name:” matches the name of the organisation that we allocated or assigned resources to in our records. We also believe that this is highly confusing to users and tools parsing these objects. Therefore we like to clean these objects up and remove any multi-whitespace or multi-line occurrences. We can of course follow up with these organisation individually, but the reason that I bring it up here is that we also want to have stricter syntax rules in place to prevent this from happening again. We can do either of the following: 1) replace multi-whitespace or multi-line occurrences on input (warn, but just strip the additional space) 2) reject multi-whitespace or multi-line occurrences on input I am leaning towards option 2, but I would value your input. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

6 6

Proxy proposal large communities
by Tim Bruijnzeels 14 Nov '17

14 Nov '17

Dear Working Group, As discussed at RIPE 75 I want to forward a request by Job Snijders on GitHub: https://github.com/RIPE-NCC/whois/issues/410 Job is asking to add a “large_community" keyword to RPSL dictionary where applicable. And provides the following example: Suggestion: name the keyword large_community mp-export: afi ipv6.unicast to AS13105 announce AS-RCNET-V6 AND NOT large_community.contains(21414:0:570) export: to AS6777 action large_community .= { 6777:0:6777 }; announce AS-FORTHNET mp-import: afi ipv6.unicast from AS8631 msk-rs2.ripn.net action large_community={31376:0:2}; pref=100; accept AS-MSKROUTESERVER import: from AS35082 95.128.51.234 at 95.128.51.233 action pref=500; large_community.append(29527:0:35082,29527:0:60000,29527:0:61200,29527:0:61210); accept AS-VIBUS-LONDON filter-set: fltr-as21229-export descr: Filter for AS21229 exported prefixes filter: AS-TVNETWORK AND large_community(21229:0:1) From our end I do not see any issues implementing this on the server side, but I can’t speak to how this will be treated by scripts that may parse RPSL today. Please discuss. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC

5 24

new NWI? - was: mntner object updates by mail
by Piotr Strzyzewski 27 Oct '17

27 Oct '17

Dear WG Members After a nice chat just a seconds after DB-WG session has ended it was brought to the attention of few of us that there was an email sent last December by Ulf Kieber (with some responses) about mntner object updates by mail. Dear Chairs, can we proceed with that and make it next NWI? Piotr -- Piotr Strzyżewski Silesian University of Technology, Computer Centre Gliwice, Poland

5 5

Co-Chair Resignation
by William Sylvester 20 Oct '17

20 Oct '17

All, Denis and I were notified this morning by David that he is resigning as a co-chair for the database working group. He also indicated that he had resigned from Larus and was no longer employed there. He had intended to notify the working group sooner; his delays were the result of his relocation from Hong Kong back to Europe. He will not be attending the RIPE meeting next week in Dubai. David is very apologetic for what has transpired and that it has taken focus from the working groups primary tasks. I know this has been a very charged situation for the working group, and I appreciate everyone maintaining the professionalism I greatly respect within our community. We wish David the best in his future endeavors and thank him for his contributions. As a working group, we consider this issue closed. If you have any questions or concerns please notify the chairs. As we are nearing the end of the year, Denis and I have agreed to kick off the chair selection process earlier this year. We will be sending details out on the chair selection process soon. Best regards, William & Denis, co-chairs

2 1

NWI-2 Displaying history for database objects where available
by den is 20 Oct '17

20 Oct '17

Colleagues The DB WG co-chairs would now like to address this issue. There was some discussion on the mailing list in May to July of 2016. In brief the issue is that the current history mechanism has an arbitrary design constraint that only the history of currently existing objects can be seen. This may also not be complete if the object has been deleted and re-created. The problem definition has not yet been finalised. Also there was some discussion about the reasons for wanting more historical information being made available for resource objects (and possibly some other object types). We would therefore like to ask anyone with concerns about historical data to please review what was said last year and express support or otherwise and perhaps add some reasoning as to why more data is needed. cheers denis co-chair DB WG

4 4

DMARC Settings Change on RIPE Database Working Group Mailing List
by Adam Castle 19 Oct '17

19 Oct '17

Hi RIPE Database Working Group, In March 2017, the RIPE NCC implemented a requested DMARC change to this list < https://www.ripe.net/ripe/mail/archives/db-wg/2017-March/005514.html > The change was to enable the DMARC 'Wrap Message' setting in Mailman so that DMARC-enabled users could receive emails from the list sent via other DMARC-enabled users. Unfortunately, this caused some users to see emails come through as attachments, as well as various other compatibility issues with some mail clients. After consultation with the RIPE Database Working Group Co-Chairs, we have changed the Mailman setting to 'Munge the From address'. If you experience any emails from this mailing list as attachments from this point onwards, then please let me know. Many thanks, Adam Castle Web Services Manager RIPE NCC

2 1