[manet] Gorry Fairhurst's No Objection on draft-ietf-manet-d lep-traffic-classification-15: (with COMMENT)
Gorry Fairhurst via Datatracker <[email protected]>
| Newsgroups | gmane.ietf.manet |
|---|---|
| Message-ID | <174284519256.1606337.17801096131549009250@dt-datatracker-5b9b68c5b6-zxk6z> |
Gorry Fairhurst has entered the following ballot position for draft-ietf-manet-dlep-traffic-classification-15: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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. _______________________________________________ manet mailing list -- [email protected] To unsubscribe send an email to [email protected]