[db-wg] NWI-5 changes deployed to RC (Release Candidate) environment

Dear Nathalie, and colleagues,

some observations/questions/comments on the database 1.92[.x?]
preparation/testing and planned deployment.
Please watch out for the "PLEASE" marker for action items.

  > Dear Colleagues,
  > 
  > Following the implementation plan for NWI-5 (Out-of-region ROUTE(6) 
  > objects and removal of ASN authorisation for ROUTE(6) object creation) 
  > we have now deployed the NWI-5 changes to the RC (Release Candidate)
  > environment.
  > The RC environment allows you to test the impact of the changes before
  > we will go to production on 4 September 2018.

  > We encourage you to test the impact of the NWI-5 changes on your scripts
  > and tools and report any issues you may find to ripe-dbm at ripe.net
  > <mailto:ripe-dbm at ripe.net>
our ops team reported that during their first test runs they saw 1.92.2
in the RC environment, and later queries were answered by 1.92.3 -
without any explanation available it looked like they had to redo the testing.
While no unexpected behaviour was identified so far the value of testing
is somewhat questionable if the "system under test" is being changed
in unknown ways without notification or explanation - specifically 
with the open question whether/when/what further changes may occur
before moving to production.
The web pages for the Release Candidate environment and the Release Notes
only talk about 1.92 and do NOT claim to have been updated after 2018-08-03.
I only see two update messages on the wg mailing list (both 2018-08-14)
which are NOT reporting different versions of the RC environment.

PLEASE PROVIDE information on what/why happened, and what to expect.

PLEASE PUBLISH now the time window during which the production system
will be converted.  Production users ought to be able to schedule
important runs to avoid that conversion window, and decide what
better is run before, and potentially final tests on the production
system before continuing routine production - currently available
information means during the whole Sep. 4th (and potentially late Sep. 3rd)
the status of the database is unknown.

I understand that the split of sources RIPE ./. RIPE-NONAUTH will be
handled so that queries using the "default source selection"
(i.e. traditional whois queries WITHOUT -s parameter) will 
return the same results before and after the conversion -
aside of changes due to users changing their data in the database.
(PLEASE confirm - I did not find this explicitly stated in a prominent place,
and only figured out this detail from the impact analysis.)
Inconsistencies during the conversion window would seem
somewhat acceptable - the STRONG requirement for the conversion window
is to KNOW (in advance!) WHEN the system is in a less trustworthy
transitional state.

Operators usually prefer to transition using the "make before break" paradigm.
I note that the production system currently returns an error condition
when queried with explicitly specified sources including the new
RIPE-NONAUTH;  this means explicit query for the new default
("-s RIPE,RIPE-NONAUTH") fails.
Those who have queries that currently specify e.g. -s RIPE,APNIC-GRS
cannot upgrade their tools to the equivalent future form
-s RIPE,RIPE-NONAUTH,APNIC-GRS so far without "breaking".
To support "make before break" and allow users to prepare for
smooth transition the production database actually SHOULD already accept
queries for the new source without returning "unknown source" failure.
For MY environment this is NOT critical.
PLEASE consider quickly improving support for this and report to users.

Regards,
  Ruediger


Ruediger Volk

Deutsche Telekom AG -- Internet Backbone Engineering

E-Mail:  rv at NIC.DTAG.DE