Agenda: on datatracker
Meeting material: on datatracker
Meeting link: Webex Link
Live Minutes: CODIMD Link
Alexander does the usual agenda bashing.
Pascal reviews conclusions from last meeting. (slide 8) JCZ: was not able to attend last meeting, got debrief from Sergio. Discussed between the authors. Pascal: the objective of the OLD/NEW is to have a formal explanation of what you want to achieve. It leaves some questions how to implement the changes. JCZ: there is already the normative language, but didn't want to repeat text. Dominique: The juxtaposition of this text and RFC 8724 can be ambiguous; I agree that 3.2.1 and 3.2.2 become informational (no uppercase) and to have a 3.2.3 which unambiguously describes what 8724+compound_ack looks like. Think of a patch file that rewrites RFC8724's text. JCZ: useful feedback. We will do the changes Pascal: Did not find a shepherd. Polled the int directorate, but no answer. Éric: polling the call to find a candidate; no answer :-( Alexander: to do poll the mailing list JCZ: we will nee to update the data model Laurent: I made the change, I need to send to you.
Laurent: pushed new stuff on the github; unstable so not pushed to datatracker.
Edgar does not use compression in his doc, better make it a feature, like fragmentation already was. Alexander: see it as: in a switch, IP may be a feature so it's not there if the switch is pure layer 2.
default of 1 is suggested e.g., if we do slow start must be less than 2^dtag_size, but not sure how to express that in YANG Dominique: max-window-size is called window size in the RFC. Laurent: OK Pascal: the comment could be more informative, indicating that it is the maximum numbre of tiles
Laurent : changed to indicate that the L2 decides when to send acks
Laurent: packaged parameters to form the frame together, then the fragmentation
Laurent: I do not understand the penultimate tile comment
Dominique: to do: find the slides expliciting the issue and discuss next time
Dominique: hard to use the inactivity timer since the sender and receiver do not have the same lifetime since packets may be lost
Pascal: yes but the sender times out after the receiver so the sender is safe to reuse the dtag when it times out
Dominique: not efficient since lifetime can be long.
Dominique: to do: try to find again what the issue was with the DTag lifetime at the receiver, if there really was any issue at all.
Laurent: todo : if there are compression rules (compression "feature"), then there must be a no-compression rule.