[nwcrg] IRSG review of draft-irtf-nwcrg-bats-03

["David R. Oran" <[e-mail]>]

I reviewed draft-irtf-nwcrg-bats-03 as designated reviewer for the IRSG. 
The document is in very good shape and the technical content sound. I 
have just a few minor comments and some grammar/typographic nits for the 
authors to consider prior to publication.

## Minor Comments
- In the introduction (paragraph 2), you should mention more than just 
interference as something that makes a wireless channel unreliable. 
There’s also fading, multipath, etc.

- Discussion of multipath doesn’t show up until quite far along in the 
document, and in a few places the wording seems to restrict operation to 
a single receiver. There is in fact good discussion of multicast in the 
research questions section, so I suggest just a brief mention in the 
introduction that BATs is intended to work well in both unicast and 
multicast environments, possibly with a forward reference to the later 
discussion.

- On p7, the way the requirements on coded packets are laid out is bit 
difficult to follow. I suggest  starting each set with something like a 
description list, with who the requirement applies to as the lead-in, 
for example:

	**Encoder** - the encoder DDP must deliver each coded packet with for 
following:
	-	BID: batch ID
	**Recoder** - The DDP MUST deliver the following information to each 
recorder:
	- M: batch size
	- q: recoding field size
	**Decoder** - The DDP MUST deliver the following information to each 
decoder:
	- M: batch size
	- q: recoding field size
	- K: the number of source packets
	- T: the number of Octets in a source packet
	- DD: the degree of distribution	

- p9, beginning of section 2.2.4 says “A destination node needs the 
data transmitted by the source node”. Well, sure, but are you trying 
to say something beyond the obvious here? If so, it isn’t coming 
through.

- In the various field descriptions and the equations, you use the 
letter “O” for “octets”. This slowed me down a bit as I had to 
think each time that you didn’t mean zero (“0”), despite the fact 
that the glyphs are in fact distinguishable in all three target 
renderings. It might be a pain to fix all of these, but I do think a 
better choice would either be “T” (which you use in the example 
above as a parameter for the decoder), or a two-letter variable name 
like “OC”.

- On p12 you say “A common primitive polynomial should be specified 
for all the finite field multiplications over GF(256). Is this actually 
a MUST for the operation of the code?

- In the discussion of routing issues, on p18, you talk about the 
possibility of different batches being sent on different paths to 
achieve multipath gain. Is there a reason why batches can’t be 
similarly split and sent over different paths? If not, why not?

- Section 4.3 is titled “Application-related issues”, however most 
(perhaps all?) of the discussion isn’t actually about applications but 
about usage and deployment scenarios over different kinds of network 
technologies and topologies. Suggest renaming this “Usage Scenario 
Considerations” or something similar and if there are in fact 
application issues (e.g. multimedia, IoT, etc.) split those out in a 
separate section.

- In section 6 on security considerations you address eavesdropping 
well, but don’t talk at all about traffic analysis. Are there 
interesting factors in BATs affecting the ability of traffic analysis to 
figure out what is happening with the application data flows, e.g. does 
BATs produce detectable timing or padding behavior that can be leveraged 
better than non-coded data, or perhaps conversely make things harder for 
an adversary?

- The discussion of attestation in section 6.2 left me feeling a bit 
un-satisfied, given that the protocol doesn’t actually provide 
provenance (i.e. the attestation of the chain of coders/recoders does 
not seem explicitly bound into the data streams). Simple origin 
authentication (e.g. using signatures) doesn’t seem to be adequate. Am 
I missing something here?

## Nits
- p7, s/DD[i] is the possibility/DD[i] is the probability/

- p12, s/addition is an logical XOR/addition is a logical XOR/

- p17, s/increasing too much end-to-end latency/increasing end-to-end 
latency too much/
- p17, s/achieves the mulicast/achieves the multicast/

[End of review]