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

I looked over -04 and my comments have been addressed. Thank you! While 
I didn’t do a detailed re-read (looking mostly at the sections I had 
commented on) I did notice a few typos that should be fixed:

in 4.2, s/packets of a batche on the same path/packets of a batch on the 
same path/
in 6.2, s/reduancy/redundant/

Also, I saw the good comments in an email from Vincent, which should get 
covered in a revision.

I’m happy for this to advance past IRSG review as soon as you can 
issue a further update.

Many Thanks,
DaveO.

On 3 Dec 2022, at 12:29, Shenghao Yang wrote:

> Dear David,
>
> We just submitted a revised version based on comments.
> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/04/ 
> <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/04/>
>
> See the point-to-point response below. The security related issues 
> took us some time to revise.
>
>
> Best,
>
> Shenghao
>
>> On Jun 22, 2022, at 21:43, David R. Oran <daveoran@orandom.net> 
>> wrote:
>>
>> 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.
>>
>>
> We mentioned fading and multiparty in the revision.
>>
>> 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.
>>
>>
> Multicast is mentioned in the introduction with referring to Sec 4.
>> 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
> The presentation style of this part is revised.
>> 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.
>>
> This paragraph is rewritten.
>> 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”.
>>
>>
> O is changed to CO (the first two letters of coefficient).
>>
>> 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?
>>
> “Should” is changed to “MUST"
>> 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?
>>
> We add the discussion about whether to transmit the packets of a batch 
> on the same path or different paths for unicast and multicast.
>> 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.
>>
> The section title is changed to “Usage Scenario Considerations”.
>> 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?
>>
> A new subsection is added to discuss traffic analysis. See 6.2.
>> 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?
>>
> The pollution attack part is rewritten. See 6.3.
>> 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]
>>
>> _______________________________________________
>> nwcrg mailing list
>> nwcrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/nwcrg

> _______________________________________________
> nwcrg mailing list
> nwcrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nwcrg
DaveO