Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item
draft-ietf-manet-dlep-traffic-classification-16
Discuss
Yes
Jim Guichard
No Objection
Erik Kline
Orie Steele
(John Scudder)
No Record
Ketan Talaulikar
Mike Bishop
Mohamed Boucadair
Éric Vyncke
Summary: Has a DISCUSS. Needs one more YES or NO OBJECTION position to pass.
Mahesh Jethanandani
Discuss
Discuss
(2025-02-03 for -13)
Sent
"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.
Comment
(2025-02-03 for -13)
Sent
------------------------------------------------------------------------------- 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/
Jim Guichard
Yes
Andy Newton
(was Discuss)
No Objection
Comment
(2025-03-24 for -15)
Sent
Thanks for addressing my concerns, and thanks for this document and the work you all have done.
Deb Cooley
(was Discuss)
No Objection
Comment
(2025-03-22 for -14)
Sent
Thank you for addressing my comments and the discuss.
Erik Kline
No Objection
Gorry Fairhurst
No Objection
Comment
(2025-03-24 for -15)
Sent
1. In the PDF render, the figure for Ethernet Traffic Classification Sub-Data Item, appears to be missing some spaces for alignment of the FID row. 2. In section 2.3.1, the following text appears to have an extraneous “the”; “prior to the using the carried information,” 3. “Implementations following the "networked deployment" model described in the "Implementation Scenarios" of [RFC8175] SHOULD refer to [BCP195] for additional details.” - This appears to be an inappropriate use of an RFC2119 keyword, since it does not define an implementation requirement. Please consider a lower-case “should” for this sentence. 4. The references to section 2.1.1 are a little odd, in that 2.1.1 appears to only contain one line about error processing that does itself refer to processing the same as any other Data Item parsing error encountered in DLEP, see [RFC8175]. Was this intentional? Could the text instead refer to the relevant section of RC 8175? 5. I don’t think the security mechanisms are sufficiently defined. Please can you explain what threats these updates are expected to counter. This currently leads to two very ineffective security considerations for transport layer security mechanisms and Layer 2 security mechanisms.
Gunter Van de Velde
No Objection
Comment
(2025-02-04 for -13)
Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-manet-dlep-traffic-classification-13 # 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-traffic-classification-13.txt # Many thanks to Darren Dukes for the RTGDIR review follow up. # Detailed Review # =============== 315 0 1 2 3 4 5 6 7 316 +---+---+---+---+---+---+---+---+ 317 | DSCP | MBZ | 318 +---+---+---+---+---+---+---+---+ 319 320 DSCP: Differentiated Services Codepoint 321 MBZ: MUST be zero GV> This reads odd. Why the uppercase "MUST" and then all lower case "be zero" instead of "Be Zero". What most the device do when MBZ happens to be not zero? Same MBZ observation applies to line402 of the document. What about the following: " DSCP: Differentiated Services Codepoint (RFC 2474). MBZ: Must Be Zero MUST be set to zero when transmitted. Receivers MUST ignore this field upon reception. "
Orie Steele
No Objection
Paul Wouters
(was Discuss)
No Objection
Comment
(2025-03-26)
Sent
Thanks for fixing the two length figure issues.
I have updated my ballot to No Objection, but note that one bug is still
not fixed. I believe this:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Classification Sub-Data Item 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Classification Sub-Data Item n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Traffic Classification Sub-Data Item 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Traffic Classification Sub-Data Item n ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
otherwise "Traffic Classification Sub-Data Item n" would appear to only be
of length 32 bits
Roman Danyliw
(was Discuss)
No Objection
Comment
(2025-03-24 for -15)
Sent
Thank you for addressing my COMMENT and DISCUSS feedback.
Ketan Talaulikar
No Record
Mike Bishop
No Record
Mohamed Boucadair
No Record
Éric Vyncke
No Record
Murray Kucherawy Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2025-02-05 for -13)
Sent for earlier
Section 5.2 declares a new registry, a range of which is controlled by "Specification Required" rules. RFC 8126, Section 4.6, says: As with Expert Review (Section 4.5), clear guidance to the designated expert should be provided when defining the registry, and thorough understanding of Section 5 is important. Is no such advice in order here? Also, as Roman observed: Should there be a "Reference" column added to this registry?
John Scudder Former IESG member
No Objection
No Objection
(for -13)
Not sent
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection
(2025-02-05 for -13)
Not sent
Thanks to David Black for really good review of the document that has lead to more clarity on the classification. I am supporting Romans's discuss. This specification refers to RFC8126 but does not follows it.