[manet] Re: Mahesh Jethanandani's Discuss on draft-ietf-ma net-dlep-traffic-classification-13: (with DISCUSS and COMMENT )
Don Fedyk <[email protected]>
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <PH7PR14MB5368C9D331143B7DF70577DABBA12@PH7PR14MB5368.namprd14.prod.outlook.com> |
Hi Mahesh We have addressed the Nits but I will give a bit of background on your other DISCUSS comment -The comment is not actually on the traffic classification document but the mostly the Flow control document. I believe the issues were addressed, but agree the email chain does not have closure. See [Don] below, but I have also copied David just in case. Thanks ________________________________ From: Mahesh Jethanandani via Datatracker Sent: Thursday, February 6, 2025 4:32 PM To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Mahesh Jethanandani's Discuss on draft-ietf-manet-dlep-traffic-classification-13: (with DISCUSS and COMMENT) Mahesh Jethanandani has entered the following ballot position for draft-ietf-manet-dlep-traffic-classification-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-traffic-classification/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- "Abstract", paragraph 0 > This document defines a new Data Item for the Dynamic Link Exchange > Protocol (DLEP) to support traffic classification. Traffic > classification information identifies traffic flows based on frame/ > packet content such as destination address. The Data Item is defined > in an extensible and reusable fashion. Its use will be mandated in > other documents defining specific DLEP extensions. This document > also introduces DLEP Sub-Data Items, and Sub-Data Items are defined > to support DiffServ and Ethernet traffic classification. I would note that both RTGDIR and TSVART's early review of the document had issues with the document. However, I did not see a Last Call or Telechat review of the same. But this could easily have been missed because there are four documents, and some of these issues could have been debated as part of the other documents. Even otherwise, there is no e-mail thread that I could find that discusses how the issues were resolved. In either case, it would be nice to know from the Shepherd that the issues raised by David Black were addressed, and more specifically how they were addressed. [Don] There was a period of several meetings where David had expressed some concerns and Lou (and other authors) had discussed them. It was my recollection at the time that David Black Was satisfied before we moved on. But I cannot find a final email - it may have been verbal. Last message I see is March 12th 2024 from David Black Lou, I think we're close to done. There are a few more things that need attention: i) The security considerations text was only updated in the flow-control draft. The other 3 drafts need corresponding security considerations text updates. [Don] This section has been updated several times now. ii) A diff of da-credit-extension-15 against -12 reveals a couple of updates at the end of section 3 (Management Considerations) that need to be applied to ether-credit-extension-03 . [Don] This checks out as being done. iii) New text in section 2.3.2 of the flow control draft: "TIDs in different Credit windows must not overlap." That text solves the problem that it was intended to address, but raises a couple of secondary concerns: - Which entity checks for overlaps? I think it’s the modem. - What happens if overlaps are found? I think it a suitable "you got it wrong" DLEP error goes back to the router and either the overlapping TIDs or all TIDs in the message (which one?) are not used. A sentence or two should be added to explain. [Don] The modification in the draft after this comment draft-ietf-manet-dlep-credit-flow-control-14 has: If a router determines that a newly received Data Item results in credit windows with overlapping TIDs, the Data Item MUST be treated as an error as described above. Which addresses the comment. Finally, in looking back on all the emails, I want to record here that item [H] on amount of imprecision (e.g., what does "significantly different" mean?) was not pursued in revising the drafts as your email characterized that as implementation dependent. That seems ok to me, as this is a modem implementation decision on how aggressive the modem chooses to be in protecting its resources. Thanks, --David ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2, paragraph 2 > fic Classification Data Item This sections defines the Traffic Classification > ^^^^^^^^ Consider using the singular form after the singular determiner "This". Section 6.2, paragraph 1 > ritical to the acceptance of DLEP. We morn his passing on November 23, 2023. > ^^^^^^^ s/morn/mourn/ _______________________________________________ manet mailing list -- [email protected] To unsubscribe send an email to [email protected]