Network Coding for Satellite Systems
draft-irtf-nwcrg-network-coding-satellites-15

I'm always a bit surprised when people are still paying lip service to
the OSI model (and then call it ISO model); in the I*TF context by now
I'm expecting references to the Internet layer model (RFC 1122).

Other nits have been sent to the authors.

Thank you for compiling this information!

I reviewed it and think it is ready to go. 
The use cases are clearly described and helpful to understand the application of network coding in Satellite systems.
One minor thing in its reference part somehow comes to my attention : )  It looks strange to quote a draft written in 2017 with "work in progress".  Should these (as below) be changed to "expired" to keep consistent with their status in the datatracker?
[I-D.chin-nfvrg-cloud-5g-core-structure-yang]
              Chen, C. and Z. Pan, "Yang Data Model for Cloud Native 5G
              Core structure", draft-chin-nfvrg-cloud-5g-core-structure-
              yang-00 (work in progress), December 2017.
[I-D.vazquez-nfvrg-netcod-function-virtualization]
              Vazquez-Castro, M., Do-Duy, T., Romano, S., and A. Tulino,
              "Network Coding Function Virtualization", draft-vazquez-
              nfvrg-netcod-function-virtualization-02 (work in
              progress), November 2017.

This is not my area of expertise but I thought it was clear and easily understandable and that it did not contain any obviously problematic material.  One minor typo in the last sentence of section 3.4:

"In this use-case, adding network coding  techniques will prevent the end-to-end retransmission from occurring since the packet losses would probably recovered."

I don't know if that should be "recover" or "be recovered" (or something else entirely).

I'm also curious how various network coding mechanisms would or would not work for encrypted traffic (for example, mixing), but I am comfortable with that being out-of-scope for this document.

Comments were already sent by mail; repeating here for the record:

I reviewed this document and think it is ready to go.
 
A few small editorial points: Based on the RFC style guide you cannot have references in the abstract (meaning just remove the actual reference and only write RFC8406). Also I think the abstract could be a bit short and more crisp. And while there is an nice and quiet extensive glossary at the end, there are a couple of mostly well-know acronyms which might still be worth spelling out on first occurrence, given the desired audience: mainly FEC, CPE, RTT, and DTN. And finally the security considerations section is quite short, which is fine as. I don’t think there is much to discuss, but maybe there is a good reference to give to another NC document that has more discussion about security implication…?

My ballot was previously sent to the IRSG via e-mail, but I'm recording it here, since the datatracker now allows at-large IRSG members to enter their own ballots.

A nit - "A glossary is proposed in Section 6 to clarify the terminology use throughout the document." should probably be something like "A glossary is included in Section 6 to clarify the terminology use throughout the document."

I'm not sure I can parse

   While there is an active research Community working on network coding
   techniques above the network layer in general and in SATCOM in
   particular, not much of this work made it to commercial systems in
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the satellite industry.  
   
Is "made it to commercial systems" something like "has been deployed in commercial systems"?

Now that you are requesting publication, you can probably change

   In this context, this document aims at
                                  ^^^^^^
   identifying opportunities for further usage of network coding in
   ^^^^^^^^^^^
   commercial SATCOM networks.
   
to

  In this context, this document
   identifies opportunities for further usage of network coding in
   ^^^^^^^^^
   commercial SATCOM networks.
   
I know it's hard to say clearly, but

   o  Forward Erasure Correction (FEC) (also called Application-Level
      FEC) operates in and above the network layer and targets packet
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      loss recovery.
 
"in and above the network layer" is ambiguous. I think it means "in, above, or both", but it's hard to read. Perhaps

   o  Forward Erasure Correction (FEC) (also called Application-Level
      FEC) operates above the PHYsical (PHY) layer and targets packet
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      loss recovery.
 
(since you used that term in the previous bullet), or "above the link payer" if that term is more accurate. Using ISO terms to describe an Internet protocol stack is hard ("subnetwork layer" is another choice) :-)

In

   There are multiple SATCOM systems, for example broadcast TV, point to
   point communication or IoT and monitoring
                          ^^^^^^^^^^^^^^^^^^
   
Is "IoT and monitoring" one term or two? If "two", "monitoring" is vague (would this include medical monitoring?) If you can qualify "monitoring" in any way, that would be clearer to me.

In
   This could also be achieved by using other multicast or broadcast
   systems, such as NACK-Oriented Reliable Multicast (NORM) [RFC5740] or
   File Delivery over Unidirectional Transport (FLUTE) [RFC6726].  Both
   NORM and FLUTE are limited to block coding, none of them supporting
                                             ^^^^^^^^^^^^^^
   more flexible sliding window encoding schemes that allow decoding
   before receiving the whole block an added delay benefit
   [RFC8406][RFC8681].

should probably be "; neither of them"  with a semicolon. 

This text

   Depending
   on the use-case (e.g., very high frequency bands, mobile users) or
          ^^^^^^^^
   depending on the deployment use-cases (e.g., performance of the
                               ^^^^^^^^^
   network between each individual data block), the relevance of adding
   network coding is different.
   
uses the same term in two very different contexts, and only one is qualified. Is there a qualifier you can attach to the first use? Or could these examples be merged into one list of use case examples?

In this text,

   Many SATCOM systems typically use Performance Enhancing Proxy (PEP)
   RFC 3135 [RFC3135].  PEPs usually split end-to-end connections and
   forward transport or application layer packets to the satellite
   baseband gateway that deals with layer-2 and layer-1 encapsulation.
                                    ^^^^^^^^^^^^^^^^^^^
   PEPs contribute to mitigate congestion in a SATCOM systems by
   limiting the impact of long delays on Internet protocols.  A PEP
   mechanism could also include network coding operation and thus
   support the use-cases that have been discussed in the Section 3 of
   this document.
   
Are these PHY (used previously) and Link Layers? Or something else? If this is a new term for the same thing, it would be great to pick one term and use it consistently.

I think this

   Communications among deep-space platforms and terrestrial gateways
   can be a challenge.  Reliable end-to-end (E2E) communications over
   such paths must cope with very long delays and frequent link
   disruptions; indeed, E2E connectivity may be available only
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   intermittently.  Delay/Disruption Tolerant Networking (DTN) [RFC4838]
   ^^^^^^^^^^^^^^
   is a solution to enable reliable internetworking space communications
   where both standard ad-hoc routing and E2E Internet protocols cannot
   be used.  Moreover, DTN can also be seen as an alternative solution
   to transfer data between a central PEP and a remote PEP.
   
is more correctly "E2E connectivity may only be available intermittently, if at all" - there may not be a continuous end-to-end path at all in DTN, or do I misunderstand?

In this text,

   o  PEP: Performance Enhancing Proxy [RFC3135] - a typical PEP for
      satellite communications include compression, caching and TCP
                                                                ^^^
      acceleration;
      ^^^^^^^^^^^^
 
I know "TCP acceleration" is the correct marketing term (I worked at a company that sold them, in my darkest past), but would it be correct to say something like "TCP ACK spoofing", or "TCP connection splicing", which is I think the 3GPP term?