I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-grow-nrtm-v4-08
Title: Quality of Outcome (QoO)
Reviewer: Paul Kyzivat
Review Date: 2026-02-25
IETF LC End Date: 2026-03-04
IESG Telechat date: ?
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
Issues: None
Nits: 5
1) NIT: Undefined term:
Section 1 (Introduction) uses the term "RIR". This appears nowhere else
in the document. Please provide a definition/expansion for this term.
2) NIT: Unspecified rationale for specific time intervals:
There are frequency rules tied to one minute, one hour, and 24 hour
intervals. I gather the intent is to balance the need for timely data
against the load on clients and servers to keep the data up-to-date. It
seems to me that the load generated by these will vary based on number
of clients. And the appropriateness of these may vary depending on the
type of data. It would be helpful to have some explanation for why these
specific values have been chosen.
3) NIT: Under-specified error handling:
There are many places that identify error conditions and state that when
these occur the file MUST be rejected. But I find no explanation of what
is to be done when a file is rejected in this way. I presume there must
be some recovery action.
4) NIT:
In the example payload of an Update Notification File in section 6.3,
the snapshot is version 3. and there are deltas with versions 2,3, and
4. Why are there are deltas with versions 2 & 3? Isn't version 4 the
first delta version applicable to this snapshot?
I presume there is a reason. It would be helpful if this was explained.
5) NIT: The future evolution of this protocol:
The IANA Considerations section makes a provocative statement:
"NRTMv4 is expected to be the final revision of the protocol family used
for IRR database replication. Solution requirements that arise in the
future are likely best solved using either RPKI [RFC6480] or RDAP
[RFC9082]. From that perspective, the document does not define any IANA
registry for protocol maintenance."
I don't understand the relationships of these protocols, but in general
such assertions often turn out to be false. Rather than burying this in
the IANA considerations section, I suggest you add another section where
you explain further the envisioned future of Internet routing data
synchronization, and how this document fits within it.
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
