Re: [nwcrg] 2nd RG Last Call for draft "Network coding and satellites"

https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

some comments, since I haven't seen much traffic on this:

Shouldn'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?

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.

Discussion of BBFRAME without discussing the FECFRAME (BBFRAME
with coding) appears to be an omission. Is this imagining a world
where FECFRAME, and its convolutional layers of coding are considered
completely unnecessary due to path coding within the BBFRAME?
If so (and it won't gain much traction) this would need to be stated.
I don't think claiming that FECFRAME is link/channel and out of
scope really flies; BBFRAME is a link construct too.

Fig 2: PEP is primarily a transport-level function; firewalls are
primarily network and transport. Having one outdour unit (dish at gateway?)
when the other end (user terminal) has both an indoor and outdoor
unit (IDU and ODU) seems a simplification. No idea what the stepped
end user boxes mean; if four end users, four boxes the same size
might convey that better, with numbers on them. 1, 2, 3, 4 ... n

minor nits:

section 4.1 - PEP is Enhancing, not Enhancement. PEP_s_ 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 isn't an academic paper with a page limit. Do provide
document object idenitifiers (DOIs) of papers where they exist.

This document has a difficult task (trying to build something
from nothing) but at least it's readable enough to debate.

best

Lloyd Wood lloyd.wood@yahoo.co.uk http://about.me/lloydwood

On Wednesday, 16 October 2019, 01:37:00 GMT+11, Vincent Roca <vincent.roca@inria.fr> wrote: 

Hello everybody,

A first RG Last Call for the « Network coding and satellites » / draft-irtf-nwcrg-network-coding-satellites-04 draft
in April this year enabled to collect many highly valuable feedbacks. They have been taken into consideration 
according to the authors who produced an update.

It’s now time to start a second RG LC for version -06:
https://datatracker.ietf.org/doc/draft-irtf-nwcrg-network-coding-satellites/

We would like to collect your comments by Wednesday 6th, November (3 weeks).

Thanks in advance.

   Marie-Jose and Vincent
_______________________________________________
nwcrg mailing list
nwcrg@irtf.org
https://www.irtf.org/mailman/listinfo/nwcrg