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

[Colin Perkins <[e-mail]>]

Thanks, Vincent. I’ll start the IRSG final poll.
Colin



On 6 Dec 2022, at 21:30, Vincent Roca wrote:

> Dear Authors, Colin,
>
> Yes, I’m happy with this new version.
> Thank you for this quick update.
>
> Regards,   Vincent
>
>
>> Le 6 déc. 2022 à 19:32, Colin Perkins <[e-mail]> a écrit 
>> :
>>
>> Dear Shenghao,
>>
>> Thank you - once Vincent confirms this addresses his comment, I’ll 
>> move this forward.
>>
>> Colin
>>
>>
>>
>> On 6 Dec 2022, at 16:24, Shenghao Yang wrote:
>>
>> Dear Colin, David and Vincent,
>>
>> Thank you for your quick comments. An update is submitted. 
>> https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/06/ 
>> <https://datatracker.ietf.org/doc/draft-irtf-nwcrg-bats/06/>
>>
>> We are happy to cite RFC 9265, which is very relevant.
>>
>> 2^(d-M)T>=2^T is changed to 2^(-(d-M)T)<=2^(-T)
>>
>>
>> Shenghao
>>
>>
>> On Tue, Dec 6, 2022 at 4:01 AM Colin Perkins <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>> 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] 
>>> <mailto:[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] <mailto:[e-mail]>
>>> https://www.irtf.org/mailman/listinfo/nwcrg 
>>> <https://www.irtf.org/mailman/listinfo/nwcrg>
>>
>> _______________________________________________
>> nwcrg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.irtf.org/mailman/listinfo/nwcrg 
>> <https://www.irtf.org/mailman/listinfo/nwcrg>
>> DaveO
>>
>> _______________________________________________
>> nwcrg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.irtf.org/mailman/listinfo/nwcrg 
>> <https://www.irtf.org/mailman/listinfo/nwcrg>