IETF conflict review for draft-irtf-nwcrg-network-coding-satellites
conflict-review-irtf-nwcrg-network-coding-satellites-01

The following approval message was sent
From: The IESG
To: nwcrg-chairs@ietf.org,
    Vincent Roca ,
    Internet Research Steering Group ,
    Colin Perkins ,
    draft-irtf-nwcrg-network-coding-satellites@ietf.org,
    irtf-chair@irtf.org
Cc: iana@iana.org,
    IETF-Announce ,
    The IESG
Subject: Results of IETF-conflict review for draft-irtf-nwcrg-network-coding-satellites-14

The IESG has completed a review of
draft-irtf-nwcrg-network-coding-satellites-14 consistent with RFC5742.

The IESG has no problem with the publication of 'Network coding for satellite
systems'  as an
Informational RFC.

The IESG has concluded that this work is related to IETF work done  in the
rmt, tsvwg, and quic WGs, but this relationship does not prevent publishing.

The IESG would also like the IRTF to review the comments in the datatracker
related to this document and determine whether or not they merit
incorporation into the document. Comments may exist in both the ballot and
the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-irtf-nwcrg-network-coding-satellites/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

The process for such documents is described in RFC 5743

Thank you,

The IESG Secretary

[Ballot comment]
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.

[Ballot comment]
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.]