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.]

Martin Vigoureux No Objection

Robert Wilton No Objection