IETF conflict review for draft-irtf-nwcrg-network-coding-satellites
conflict-review-irtf-nwcrg-network-coding-satellites-01
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Martin Duke Yes
(Magnus Westerlund) Yes
(Deborah Brungard) No Objection
(Alissa Cooper) No Objection
Roman Danyliw No Objection
Benjamin Kaduk No Objection
Comment (2020-10-21 for -00)
To the IESG: We do have some documents from rtcweb/payload/etc. that implement linear FEC schemes of various sorts; should they be listed as related work as well? To the authors: The document seems to only mention end-to-end encryption once, in the context of such applications based on UDP (ยง3.4), but end-to-end encryption is also prevalent for TCP flows. It might be interesting to have some general discussion of when FEC schemes can/cannot be applied to flows that are encrypted end-to-end. I guess it probably goes without saying that any communications going over a satellite link must be presumed easy to eavesdrop on, and thus that the application using such a link has an onus to apply any cryptographic protection deemed necessary for such situations.
Erik Kline No Objection
Murray Kucherawy No Objection
(Barry Leiba) No Objection
Alvaro Retana No Objection
Comment (2020-10-21 for -00)
I am ok with the assessment, but I would be more comfortable with the standard response: The IESG has concluded that this work is related to IETF work done in the rmt, tsvwg, quic, and dtn WGs, but this relationship does not prevent publishing. The current wording seems to imply a closer relationship. [Maybe it's time for the IESG to talk about deviations from rfc5742 again.]