Ballot for draft-ietf-manet-dlep-credit-flow-control
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Please note that this discuss applies to the traffic classification draft, and perhaps to the other two DLEP drafts on the telechat. I would be happy to have them all addressed together, at the authors discretion. Section 4: The transport layer security recommendations in RFC8175 are largely outdated (it predates TLS1.3, RFC8446). It references RFC 7525 (which has been obsoleted by RFC 9325) and RFC 5487 which may/may not be relevant today (i.e. it is very old - predating both TLS 1.2, RFC 5746, and TLS1.3). In addition, the link layer security recommendations are similarily outdated. Please address this issue in this draft's Security Considerations. Section 4: I would also like to see documentation of the risk of 'leaking data' into unused (and unvalidated by the receiver) protocol fields.
Section 2, paragraph 6: Wildcards are mentioned here, but no where else in the draft. Specifically, which packet types listed in this draft can have wildcards specified? Sections 2.3.1, 2.3.3, 2.3.4: Reserved field, why doesn't the router/modem have to validate this (it allows a covert channel if not validated)?
I was going to COMMENT the same as Murray about the use of SHOULDs, so please consider his comment.
# Gunter Van de Velde, RTG AD, comments for draft-ietf-manet-dlep-credit-flow-control-17 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-manet-dlep-credit-flow-control-17.txt # Many thanks to Dhruv Dhody for the RTGDIR review, and the follow up. # Detailed Review # =============== 400 Length: 401 16 402 403 Per [RFC8175] Length is the number of octets in the Data Item. It 404 MUST be equal to sixteen (16). GV> This field seems slightly underspecified. Maybe point out that the Length is set in multiples of bytes, not bits. GV> What must happen if the length is not set to value '16'? ignore? send a trap? reset the process? Please advice 496 Length: 497 2 498 499 Per [RFC8175] Length is the number of octets in the Data Item. It 500 MUST be equal to two (2). GV> similar observation as above. Kind Regards, Gunter Van de Velde Routing Area Director
Thanks for carrying this document across the finish line. I have one question: ### Section 2.3.1 "Finally, a queue size (in octets) is provided for informational purposes." Where?
I suggest reviewing several of the SHOULDs in this document. For instance, there's a cluster of them in the last paragraph of Section 2.3.4. Since SHOULD presents a choice to an implementer, I could decide to do none of these and still claim I'm compliant with this specification. Is that the intent? You might instead want to add some guidance about when you imagine an implementer might legitimately not do what you're saying here. Or if you can't come up with such guidance, then consider that this really might be a MUST.
I suspect Deb's DISCUSS. Note the figure in Section 2.3.1 shows 2 32 bit credit fields but the text describes it as one 64 bit credit field. Please fix the figure. Looking again, I see a ":" notation that I've never seen used before. I think the following is far cleaner: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Credit Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is also done in other sections, eg 2.3.3, 2.3.4, etc In 2.3.2 the description of field "Data Item Type" should be "Data Item Type (TBA5)". Flow Identifier (FID): should probably say it is a two octet value ? I would also use the more common ~ instead of : syntax in the diagrams to indicate variable length. Section 4 Since this protocol has a window size of one (only one outstanding msg allowed), couldn't an enduser/malicious code somehow block this traffic flow from happening by sending bogus msgs that fill up the queue of size 1? How can an implementation protect itself against this?
I support Deb Cooley's DISCUSS position. Thank you to Sue Hares for the GENART review. From her review, please consider: ** Section 2.4, Management Considerations, would benefit discuss of the "potential challenges and downsides of the flow control scheme. For instance, if the RF link capacity rapidly changes, what is the benefit of this flow control?" ** Additional operational considerations: "knowledge about credits may get inconsistent. Mismatches may also include situations where packets are lost or dropped (e.g. checksum failures)"
First of all, special thanks to David Black for his (as usual) excellent TSVART review and to the authors for resolving those. Nit: s/"Message Values" /" Message Type Values" in section 5.1. There is no "message values" registry defined by RFC8175