Hi all,
Writing this as one of the administrators of NLNOG’s IRRExplorer
(https://irrexplorer.nlnog.net/), which relies heavily on synchronising
IRR data from many sources via NRTM. I see a lot of benefit in this more
formal description of the protocol and a lot of improvements from NRTMv3
in at least efficiency and security. So thanks to the authors for their
effort!
I’m not that well experienced in the process of writing RFCs, so feel
free to ignore my comments if they’re not relevant or how things
should go, but reading the document I have some remarks (mostly on the
way things are written down, not as on the specification):
A first general comment, is that to me it’s a bit weird that this
specification is about v4 of the NRTM protocol, without any reference to
older versions of the protocol other than to point out differences.
I’ve heard that older versions are less well defined (and a quick
search seems to confirm this), but even if there was no formal
specification to refer to, I would expect that to be mentioned in the
document, since ‘v4’ there are older versions of the specification.
3.3: order of description of items
To me, the order of the items in 3.3 (publishing updates) is a bit
strange. This is mostly because it starts with explaining rules for the
deltas claiming they can’t be more than 24 hours old, before
specifying that snapshot files should be generated at least once a day,
which explains why deltas older than 24 hours should be removed.
I’m not sure why this order (delta, snapshots, update notification)
was chosen, to me it would have been more logical to read about
snapshots first, then the delta files and finally the update
notifications.
In 3.3.1 (Publishing updates, delta files):
* If multiple changes have occurred within the time frame that
would
cancel each other out, like an addition and immediate deletion of
the same object, the mirror server MUST still include all these
changes.
Reads as a more detailed explanation of the later mentioned
* The Delta File MUST include all changes that happened during the
time frame, in the order in which they occurred.
I think they could either be combined (‘The Delta File MUST include
all changes that happened during the time frame, in the order in which
they occurred, even if these changes cancel each other out’), or at
least order of these two items should be reversed.
Thanks and best regards,
Teun
On 23 Apr 2025, at 21:23, Paolo Lucente wrote:
This email begins a two-week WGLC on:
Near Real Time Mirroring (NRTM) version 4
https://datatracker.ietf.org/doc/draft-ietf-grow-nrtm-v4/06/
Abstract: This document specifies a one-way synchronization protocol
for
Internet Routing Registry (IRR) records. The protocol allows
instances of IRR database servers to mirror IRR records, specified
in
the Routing Policy Specification Language (RPSL), between each
other.
The implementation report can be reviewed here:
https://wiki.ietf.org/en/group/grow/implementations/draft-ietf-grow-nrtm-v4
Please take time to review this draft and post comments by May 8th
2025.
Questions, suggestions, supportive comments, and objections are
welcomed.
In parallel there will be another email shortly for the IPR poll.
Paolo
GROW co-chair
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
