Dear all,
There may be some improvement opportunity for NRTMv3.
The problem with the RIPE NRTMv2/NRTMv3 format is that it has no
'end-of-stream' indicator, thus making the only way to know that the
output has ended (vs. hung/stalled/server dead) is either by observing a
time-out & reconnect & compare last serial, or by using single-command
connections to the NRTM server - which means even worse performance.
When connecting to the RIPE NRTM service and issuing a command like:
"-g RIPE:3:11012700-LAST -k"
It would be good that when the RIPE NRTM server is done sending its
inital blurp of backlogged data, the end of that phase of the stream of
objects is marked by the server sending something like:
"%CURRENT $TS You are now up to date" ($TS can be a unix timestamp)
after this server message the client knows that it can stay connected
and that it has received all information so far.
I would also welcome an investigation into alternative approaches, (some
not-via-WHOIS replication mechanisms), perhaps something over HTTPS can
be done? Either way, something more robust would be useful.
Kind regards,
Job
ps. An analogy can be made between BGP route refresh as described in RFC
2918 and Enhanced Route Refresh as described in RFC 7313. One first one
didn't have an "End of blurp" marker which negatively impacted its
usefulness, the later RFCintroduced the End-of-RIB marker which is
very useful.