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

[Colin Perkins <[e-mail]>]

Thank you to Shenghao and the authors for the update, and to Dave and 
Vincent for the speedy response.

It seems the changes address the major review comments, but there are a 
few minor issue remaining. If it’s possible to issue an update to 
address those, we can then move this draft forward.

Regards,
Colin




On 5 Dec 2022, at 16:00, David R. Oran wrote:

> 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 <[e-mail]> 
>>> 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
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/nwcrg
>
>> _______________________________________________
>> nwcrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/nwcrg
> DaveO

> _______________________________________________
> nwcrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nwcrg