jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-irtf-nwcrg-network-coding-satellites-07

Commentary: section 4.1 - PEP is Enhancing , not Enhancement . PEPs usually split ... section 4.2 - quickly varying channel conditions - if on the satellite link ( where discussing channel conditions is out of scope ? ) that 's what ACM , which is defined in the glossary , does -- and where network coding does not do as well . ASMS - spell out the conference name . No need to abbreviate journal names - this is n't an academic paper with a page limit . Do provide document object idenitifiers ( DOIs ) of papers where they exist 
 Thanks for the nits on the PEP . For the comment on ACM , we have updated the text ( PR ) : " This problem has been tackled in the past for physical - layer code , but there remains questions on how to adapt the overhead for , e.g. , the quickly varying channel conditions use - case where ACM may not be reacting quickly enough . " We have updated the conference in PR and PR
SATCOM systems typically feature Performance Enhancement Proxy (PEP)
RFC3135.  PEP usually split TCP end-to-end connections and forward
TCP packets to the satellite baseband gateway that deals with layer-2
and layer-1 encapsulations.  PEP contributes to mitigate congestion
in a SATCOM systems.  PEP could host coding mechanisms and thus
support use-cases that have been discussed in this document.
SATCOM systems typically feature Performance Enhancing Proxy (PEP)
RFC3135.  PEPs usually split TCP end-to-end connections and forward
TCP packets to the satellite baseband gateway that deals with layer-2
and layer-1 encapsulations.  PEP contributes to mitigate congestion
in a SATCOM systems.  PEP could host coding mechanisms and thus
support use-cases that have been discussed in this document.
This problem has been tackled in the past for physical-layer code,
but there remains questions on how to adapt the overhead for, e.g.,
the quickly varying channel conditions use-case.
This problem has been tackled in the past for physical-layer code,
but there remains questions on how to adapt the overhead for, e.g.,
the quickly varying channel conditions use-case where ACM may not be
reacting quickly enough.
Draft: draft-irtf-nwcrg-network-coding-satellites-07

Commentary: I 'm puzzled as to how this document claims that channel and link codings are out of scope - and then talks about channel mode , dealing with varying channel conditions ( yet without using channel codings ) , etc . They 're stated as out of scope ... 
 If the intent is treating the overall end - to - end path as some sort of virtual ' channel ' that coding packets are applied to , this needs to be said explicitly upfront . If ' channel ' means more than one concatenated physical path here , this needs to be said . Unless your audience is only network coding people ... the title should likely be ' network coding applicability to satellite - based scenarios ' or similar , too . Needs to be really specific for clarity . 
 In PR , we have changed : " Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document . " by " Channel and link codings are gathered in the PHY layer coding and are out of the scope of this document . It focuses on situations where coding is not widely deployed in current SATCOM systems . " For the comment on the end - to - end path , the notion of virtual ' channel ' depends on the use - case and coding is not applied at the same level . For the title , we have moved from " Network coding and satellites " to " Coding techniques for satellite systems " from version 04 and 05 of the document to be more generic . I guess we should not go back to the " network coding"-like title .
Channel and link codings are gathered in the PHY layer coding and
are out of the scope of this document.
Channel and link codings are gathered in the PHY layer coding and
are out of the scope of this document.  It focuses on situations
where coding is not widely deployed in current SATCOM systems.
Draft: draft-irtf-nwcrg-network-coding-satellites-07

Commentary: Should n't the ' This document is a product of ' para be far earlier in the document ? Should mention be made of a glossary at end , rather than putting the glossary at the front ? 
 In PR : we have moved the glossary to the bottom of the document and moved the " This document is a product of " at the beginning of the introduction .
This document is the product of and represents the collaborative work
and consensus of the Coding for Efficient Network Communications
Research Group (NWCRG); it is not an IETF product and is not a
standard.  A glossary is proposed in sec:glossary.
This document is the product of and represents the collaborative work
and consensus of the Coding for Efficient Network Communications
Research Group (NWCRG); it is not an IETF product and is not a
standard.
Draft: draft-irtf-nwcrg-network-coding-satellites-06

Commentary: Q (   ): in or above network layer ( above means no re - encoding in the router ) ? A : both - and the document is clear about it - no layer 2 coding . Q (   ): what are the " C " is the architecture picture ? A : this is where we could put the coding . 
 Done with PR and
FEC (also called Application-Level FEC) operate above the network
layer.
FEC (also called Application-Level FEC) operate in and above the
network layer.
Draft: draft-irtf-nwcrg-network-coding-satellites-05

Commentary: this is cherrypicking , not discussing link / channel FEC ( Error ) or ACK . the heading should really be ' of network coding schemes ' . " to cover cases where where " ? At the physical layer , FEC mechanisms can be exploited.-- Erasure or Error ? " Based on public information , coding does not seem to be widely used at higher layers . " it is n't , and that section can be reduced to just that sentence . 
 Vincent in item X1 , 1st sentence , it suggests QUIC is a video streaming application . Change it .  . 2 raises a general question : it refers to upper applications that are by nature on the end - hosts . Everything is imaginable here and this is not specific to a SATCOM system . Why do n't you limit yourself to the communication layers + middleware ? I 'm a bit confused . When you say : " Based on public information , coding does not seem to be widely used at higher layers . " I guess you limit yourself to the " packetization UDP / IP + middleware " but do not consider upper applications . It 's also confusing . 
 We think that these comments have been assessed with PR
X1 embodies the source coding techniques that could be used at
application level for instance within QUIC or other video
streaming applications.  This is not specific to SATCOM systems
since such deployment can be relevant for broadband Internet
access discussions.
X1 embodies the source coding techniques that could be used at
application level for instance within QUIC.  This is not specific
to SATCOM systems since such deployment can be relevant for
broadband Internet access discussions.
Draft: draft-irtf-nwcrg-network-coding-satellites-05

Commentary: Introduction physical - layer reliability mechanisms -- hyphenate adjectival terms style : e.g. should be in a clause separated by commas , not brackets . 500 ms one - way delivery delay ( or path -- i.e. not propagation ) 
 Intro must do the same , clarifying also it 's not a standard , and give an estimation of the support it collected during discussion within the group . For instance ( taken from rfc 8406 ): This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group ( NWCRG ) ; it is not an IETF product and is not a standard . < A SMALL HISTORY HERE OF THE DOC AND SUPPORT IT GATHERED . 
 I think PR solves the issue .
This document is the product of and represents the collaborative work
and consensus of the Coding for Efficient Network Communications
Research Group (NWCRG); it is not an IETF product and is not a
standard.
This section details use-cases where coding techniques could improve
the overall performance of a SATCOM system (e.g. considering a more
efficient usage of the satellite resource, delivery delay, delivery
ratio).
This section details use-cases where coding techniques could improve
the overall performance of a SATCOM system (e.g., considering a more
efficient usage of the satellite resource, delivery delay, delivery
ratio).
This use-case is mostly relevant for when mobile users are considered
or when the chosen band induce a required physical-layer coding that
may change over time (Q/V bands, Ka band, etc.).  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 block), the relevance of adding coding techniques is
different.
This use-case is mostly relevant for when mobile users are considered
or when the chosen band induce a required physical-layer coding that
may change over time (Q/V bands, Ka band, etc.).  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 block), the relevance of adding coding techniques is
different.
Draft: draft-irtf-nwcrg-network-coding-satellites-05

Commentary: abstract This memo details a multi - gateway satellite system to identify multiple opportunities on how network coding techniques could be deployed at a wider scale . this is talking about network coding , and this draft needs to be perfectly clear throughout that it is doing so , otherwise people who know and use other coding and have had little use for network coding previously will simply stop reading . Blurring the coding case is not helping your cause . I called this out previously . This is important . 
 Vincent : Abstract : The current abstract is not sufficiently detailed : which type of coding ? Do you refer to FEC or NC ( say so ) since it may also be used for other types of coding . The notion of " wider scale " also suggests it is already deployed ( is it the case ? ) , or that it may be used outside of the multi - gateway satellite system itself . On the whole , this abstract is pretty ambiguous . 
 abstract must mention the origin . This document is the product of the Coding for Efficient Network Communications Research Group ( NWCRG ) . 
 We have rephrased the whole abstract and we think PR cover this issue .
This memo details a multi-gateway satellite system to identify
multiple opportunities on how coding techniques could be deployed at
a wider scale.
This document is the product of the Coding for Efficient Network
Communications Research Group (NWCRG).  This document follows the
taxonomy document RFC8406 and considers coding as a linear
combination of packets that operate above the network layer.  In this
context, this memo details a multi-gateway satellite system to
identify use-cases where coding is relevant.  As example, coding
operating above the network layer can be exploited to cope from
residual losses or provide reliable multicast services.  The
objective is to contribute to a larger deployment of such techniques
in SATCOM systems.  This memo also identifies open research issues
related to the deployment of coding in SATCOM systems, such as the
interaction between congestion controls and coding techniques.
Draft: draft-irtf-nwcrg-network-coding-satellites-05

Commentary: First sentence , the use of " these techniques " is ambiguous . Which techniques ? 
 Thanks . Updated in PR
This document discuses some opportunities to introduce these
techniques at a wider scale in satellite telecommunications systems.
This document discuses some opportunities to introduce coding
techniques at a wider scale in satellite telecommunications systems.
Draft: draft-irtf-nwcrg-network-coding-satellites-05

Commentary: This section deserves a small introduction where you explain that you discuss a few topics , without trying to be exhaustive . Section 5.1 Are PEP part of " Network Functions " ? What 's their position in the architecture of  . 1?I do n't understand why the question on code rate to use is in a challenge called " increased deployability " . I 'd rather put it in a challenge on dynamic adaptation ( which is not identified ) . 
 Corrected and answered in PR
SATCOM systems typically feature Performance Enhancement Proxy (PEP)
RFC3135.  PEP usually split TCP end-to-end connections and forward
TCP packets to the satellite baseband gateway that deals with layer-2
and layer-1 encapsulations.  PEP could host coding techniques and
thus support the use-cases that have been discussed in this document.
Deploying coding schemes at the TCP level in these equipment could be
relevant and independent from the specific characteristics of a
SATCOM link.  However, there is a research issue in the recurrent
trade-off in SATCOM systems: how much overhead from redundant
reliability packets can be introduced to guarantee a better end-user
QoE while optimizing capacity usage ?
SATCOM systems typically feature Performance Enhancement Proxy (PEP)
RFC3135.  PEP usually split TCP end-to-end connections and forward
TCP packets to the satellite baseband gateway that deals with layer-2
and layer-1 encapsulations.  PEP contributes to mitigate congestion
in a SATCOM systems.  PEP could host coding mechanisms and thus
support use-cases that have been discussed in this document.
Deploying coding schemes at the TCP level in these equipment could be
relevant and independent from the specific characteristics of a
SATCOM link.  This leads to research question on the interaction
between coding schemes and TCP congestion controls.
The recurrent trade-off in SATCOM systems remains: how much overhead
from redundant reliability packets can be introduced to guarantee a
better end-user QoE while optimizing capacity usage ?
Draft: draft-irtf-nwcrg-network-coding-satellites-06

Commentary: Answer to issue 
   : Section 4.2 , 2nd Paragraph " Unidirectional " implies ( to me ) no ACKs . Without ACKs , FLUTE must do repair in such a way as to not need to know exactly what was lost . This seems different enough to me to be explained separate from NORM . 
 Our objective is not to discuss about NORM and FLUTE , which is out of scope of the document . We cite these protocols as possible usage example . Also note that although FLUTE is unidirectional , the RFC keeps a door open proposing bidirectional communications for security purpose and to enable full reliability transfer . As a result , we move this sentence at the end of this section as a complementary material and completed the FLUTE description .
A multicast flow (M) is forwarded to both satellite terminals A and
B.  However packet Ni (resp.  Nj) get lost at terminal A (resp.  B),
A multicast flow (M) is forwarded to both satellite terminals A and
B.  However packet Ni (resp.  Nj) gets lost at terminal A (resp.  B),
encoding schemes RFC8406.
encoding schemes RFC8406.  Note that although FLUTE is defined as an
unidirectional protocol, the RFC proposes a bidirectional
communication method to enable full reliability transfer and for
security purpose.
Draft: draft-irtf-nwcrg-network-coding-satellites-06

Commentary: I have no idea what this section means . Virtualised antennas ? virtualised reflectors ? Good luck with that .      - core - structure - yang referring to an expired -00 internet - draft does not add credibility . 
 MJM : But on the virtualization comment : we had presentations in the group on NFV ( network virtualization ) with NC for satellites . I am sure that the authors of this work could add to Lloyd ’s comments on that section . 
 We have a research challenge and changed the title of section in PR . The section aims at identifying research challenge related to the interaction between NC and virtualization ( function chaining , buffer management , etc ) .
A research challenge would be the optimization of the NFV service
function chaining, considering a virtualized infrastructure and other
SATCOM specific functions, to guarantee an efficient radio usage and
easy-to-deploy SATCOM services.
A research challenge would be the optimization of the NFV service
function chaining, considering a virtualized infrastructure and other
SATCOM specific functions, to guarantee an efficient radio usage and
easy-to-deploy SATCOM services.  Moreover, another challenge related
to a virtualized SATCOM terminals is the management of limited
buffered equipments.
Draft: draft-irtf-nwcrg-network-coding-satellites-06

Commentary:   : Forward Error Correction ( FEC ) coding below the network layer takes us a long way . At the same time , I think network coding has a lot to offer re reducing retransmission delay when the FEC coding is not enough . I do see that the referenced taxonomy document includes Forward Erasure Correction . This “ FEC ” is described as an application layer technique . The overlapping use of “ FEC ” is unfortunate for those of who work down at the lower layers . In any case , it is not always clear which “ FEC ” the document is referring to . 
 I understand that there is some confusion on the usage of the accronym . We have clarified in the document that " Following the taxonomy document [ RFC8406 ] , channel and link codings are gathered in the PHY layer coding and are out of the scope of this document . " We have in PR that this document considers FEC above the network layer .
This document considers FEC as coding mechanisms above the network
layer only.
X2 embodies the physical-layer, applied to the PLFRAME, to
optimize the satellite capacity usage.  At the physical layer, FEC
mechanisms can be exploited.
X2 embodies the physical-layer, applied to the PLFRAME, to
optimize the satellite capacity usage.  At the physical layer,
other coding mechanisms can be exploited.
Draft: draft-irtf-nwcrg-network-coding-satellites-06

Commentary: " We have noticed an active research activity on coding and SATCOM in the past . " -- if it 's active , it 's not in the past . if it 's in the past , it 's not active . Do you mean ' in the past we have noticed ' ? that 's redundant . 
 You are right . This leads to some confusion . We propose to change as in PR
We have noticed an active research activity on coding and SATCOM in
the past.  That being said, not much has actually made it to
industrial developments.  In this context, this document aims at
identifying opportunities for further usage of coding in these
systems.
We notice an active research activity on coding and SATCOM.  That
being said, not much has actually made it to industrial developments.
In this context, this document aims at identifying opportunities for
further usage of coding in these systems.
Draft: draft-irtf-nwcrg-network-coding-satellites-06

Commentary: Just corrected legitimize . 
 legitimate -legitimize . This entire section is unnecessary . With this draft on a multi - gateway satellite system and DVB , you 're talking about geostationary satellites which are always visible . Little disruption . 600ms or so delay is coped with by Internet protocols ( RFC829 SATNET work etc . ) So , not a significant delay issue either . It 's out of scope for the abstract . And geostationary satellites generally do n't use CCSDS for broadband ; TDRSS is so much a special case . Since we 're not standards track , References are n't split informative / normative -- but given the DVB starting point , I 'd expect to see more DVB - S references . EN 302 307 , which details extensions of the original satellite transmission standard DVB - S ( EN 300 421 ) , etc . 
 We need to discuss this point . Just corrected legitimize in
Coding enables E2E reliable communication over DTN with adaptive re-
encoding, as proposed in THAI15.  In this case, the use-cases
proposed in subsec:varying would legitimate the usage of coding
within the DTN stack to improve the channel utilization and the E2E
transmission delay.  In this context, the use of erasure coding
inside a Consultative Committee for Space Data Systems (CCSDS)
architecture has been specified in CCSDS-131.5-O-1.  A research
challenge would be on how such coding can be integrated in the IETF
DTN stack.
Coding enables E2E reliable communication over DTN with adaptive re-
encoding, as proposed in THAI15.  In this case, the use-cases
proposed in subsec:varying would legitimize the usage of coding
within the DTN stack to improve the channel utilization and the E2E
transmission delay.  In this context, the use of erasure coding
inside a Consultative Committee for Space Data Systems (CCSDS)
architecture has been specified in CCSDS-131.5-O-1.  A research
challenge would be on how such coding can be integrated in the IETF
DTN stack.