Ballot for draft-ietf-manet-dlep-traffic-classification
Discuss
Yes
No Objection
No Record
Summary: Has 5 DISCUSSes. Needs 4 more YES or NO OBJECTION positions to pass.
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.1: Data item type field is 16 bits? Please clarify. Section 2.1: Is there an upper limit to the length of the length field (in Section 2.1.1 the length field for the sub data item is a 16 bit unsigned integer)? If not, why not? Section 2.1: Reserved field, why doesn't the router have to validate this (it allows a covert channel if not validated)? Section 2.2: NumDSCPs: How does it work to have a wildcard in this field? Does the entity creating the item not know how many DSCPs there are? Seems odd. Also seems like a way for a third party to add/remove DSCPs. Section 2.3: Length: Same comment as Section 2.1. Is there a total bit length for the field? If not, why not? Section 2.3: NumPCPs: Same comment as Section 2.2 (NumDSCPs). Section 2.3: Pad: Same comment as Section 2.1 (reserved field). Section 3: What is the expected behaviour when either the router or modem don't understand the extensions? Is it treated like a failure? Or are they ignored? Is there a transition strategy where some parts of the system have been updated but others have not?
"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.
------------------------------------------------------------------------------- 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/
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?
Section 5 says: This document requests the assignment of several values by IANA. All assignments are to registries defined by [RFC8175]. But it only creates one registration to an extant registry, right? I would just delete this text. Also about Section 5.2: The presentation here is a little confusing. One of these rows defines a range available for reservation and the rules for such registrations, while all other rows are actual registrations. It might be helpful to take the "Specification Required" row out and turn it into prose. A nit about Section 4: * "... introduces finer grain flow ..." -- s/grain/grained/ ...and one in Appendix A: * "... We morn his passing ..." -- s/morn/mourn/
I support Deb's DISCUSS Section 2.3.1 It states "After successful validation, the receiver MUST ...", but it does not state what the receiver should do when it fails validation. As the protocol seems to have a window size of 1, my guess is that it MUST sent an error message of some kind so that the other peer can send another/new/different DLEP messages again?
The figure in Section 2.1 makes it appear that a Traffic Classification Sub-Data Item is 32 bits in size, but Section 2.1.1 shows it is variable length of at least 64 bits (again using to to me unknown convention of ":" instead of "~" A field name of "Must be two" is confusing. Normally we write the real name with the value,eg foo (2)
** Section 5.2 defines a registry which includes code points with an allocation policy of Specification Required. Implicit in policy is the review of a designated expert (DE). However, this document does not provide guidance to the DE on what to approve. See Sections 4.5 and 4.6 of RFC8126.
** Section 2. Editorial. The Traffic Classification Data Item represents a list of flows that may be used at the same time for traffic sent from a router to a modem. "Used at the same time" to do what? ** Section 2.1 When an extension requires use of this Data Item the Traffic Classification Data Item SHOULD be included by a modem in any Session Initialization Response Message -- Are “Data Item” and “Traffic Classification Data Item” the same data item? -- What is the alternative to using his Data Item in a Session Initialization Response Message? ** Section 5.2. Should the new registry defined in this section have an additional column which is a reference to a document which provides further details?
# 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. "
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.