ShuaiZhao
commented
2 years ago From Eric
Kyle,
First, thank you for your technical review on this document. The more eyes on a document, the better the result.
Allow me to reply, as the responsible AD for DRIP, about your last point: whether this work should happen at the IETF.
As an IESG member, my view is that the IETF should welcome new pieces of work related to IP technologies. After two BoF, and a community consensus, the DRIP WG was officially formed (i.e., with the IETF community support). While the DRIP meetings do not attract hundreds of people, there are enough IETF engineers to make progress. So, in my opinion, this work can be done at the IETF (albeit other fora could have hosted it as the work is at the border of other fora -- like ICAO). The charter is also explicitly requesting the re-use of existing protocols as much as possible.
More specifically on this document (and I will let the WG chairs, the doc shepherd, the authors, and the WG to add more), it is an informational document (so no protocol action included) about architecture. So, it is expected (and even required) that such an architecture I-D does not specify anything.
Finally, other DRIP I-D, notably the RID one, will specify format and processing, i.e., real standards.
Thank you anyway for your review and your concern on getting the IETF efficient and lean,
Regards
-éric
Reviewer: Kyle Rose Review result: Ready
This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.
When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.
Status: Ready (with TSVART-nonspecific LC comments)
I don't see any novel transport issues in this document: there is precedent for everything being proposed, with explicit references to existing RFCs.
Putting my individual reviewer hat on, however:
"Frequently changing" is not the right standard for preventing replay attacks: "novel" is. The idea is that the sender needs to sign data that has never been signed before and moreover that the receiver knows a priori would never have been signed by the key owner before. This is why, for instance, time codes are frequently used in such constructions: because time flows in only one direction, everyone has the ability to agree on what the current time is (even in a scenario in which participants are moving at relativistic speeds, a single reference frame can be chosen arbitrarily as the basis for the shared time scale), and no properly-functioning implementation would sign a future time code.
"Must" should probably be lowercase given that this is an informational document. Moreover, given the document overall takes the approach of making recommendations to others about how they can use IETF protocols in their technology space, and given that the IETF is not the protocol police, such recommendations really should be suggestions ("may be registered using such-and-such a protocol") rather than normative requirements.