Hi Sue,
Thanks for the review. Sorry for the tardy reply.
On Mon, Aug 12, 2024 at 2:24 PM Susan Hares via Datatracker <noreply@xxxxxxxx> wrote:
> Reviewer: Susan Hares
> Review result: Has Issues
>
> ...
>
> Document: draft-ietf-manet-dlep-ether-credit-extension-06
> Reviewer: Susan Hares
> Result: Ready with issues
> Review Date: 2024-08-12
>
> Summary: This document refers to draft-ietf-manet-dlep-credit-flow-15.txt
> and RFC8175. My technical issue with this specification is
> draft-ietf-manet-dlep-credit-flow-15, and the lack of comments on
> wildcards in the security section. This document also has editorial nits.
>
> Benefit of this draft: Credit window schemes can enable effective data flow
> processing for 802.1Q.
>
> Issue 1: Issue with draft-ietf-manet-dlep-credit-flow-15:
> draft-ietf-manet-credit-window as a specification of the credit-window scenario.
> draft-ietf-manet-credit-window is a document declared "DEAD" by the IESG
> with flaws noted in the TSV-ART and OPS-DIR review.
>
> In my gen-art review for draft-ietf-manet-dlep-credit-flow-15, I've noted issues in that document.
> https://datatracker.ietf.org/doc/review-ietf-manet-dlep-credit-flow-control-15-genart-lc-hares-2024-08-12/
>
> Since that document is a key reference in this document, those issues impact this document.
We are working on resolving comments, updating, and getting these four drafts through:
> Issue 2: "wildcard" matching of any PCP or VID needs security/manageability comment
>
> Wildcards ease the manageability of matching PCP or VID fields. However, the
> security section should make some comment about the risks of wildcard matching for these fields.
> Comments on Editorial NITs:
> 1. Unclear use of ".e.g.," format in 3 places
>
> Place 1: Section 4, paragraph 7.
>
> Old text:/
> Routers may have limits on the number of queues that they can support
> and, perhaps, even limits in supported credit window combinations,
> e.g., if per destination queues can even be supported at all. /
>
> Translating the "e.g.," to "For example, if per destination queues can even be supported at all"
> gives an unclear sentence. Best to rewrite this sentence.
How about
Routers may have limits on the number of queues that they can support
and limits on supported credit window combinations. Per destination
queues might not be supported at all.
> Place 2: Section 4, paragraph 7, last sentence
>
> Old text:/
> In either case, the mismatch of
> capabilities SHOULD be reported to the user via normal network
> management mechanisms, e.g., user interface or error logging./
>
> The "e.g.," format is used correctly in the singular form ("a--" or "b--").
> However, the "e.g.," format does not create a clear sentence.
>
> Two alternative:
>
> New text-1:/
> In either case, the mismatch of
> capabilities SHOULD be reported to the user via normal network
> management mechanisms (e.g. user interface or error logging)./
>
> New text-2:/
> In either case, the mismatch of
> capabilities SHOULD be reported to the user via normal network
> management mechanisms suchg as user interface or error logging./
How about a tweak on text 2:
In either case, the mismatch of
capabilities SHOULD be reported to the user via normal network
management mechanisms such as user interface messages or error logging.
> Place 3: Section 4: Security considerations, paragraph 1, sentence 2
>
> Old text:/The defined extension
> exposes vulnerabilities similar to existing DLEP messages, e.g., an
> injected message resizes a credit window to a value that results in a
> denial of service./
>
> The "e.g.," format does not provide a clear indication that this vulnerability is one
> of several potential vulnerabilities.
How about
The defined extension is exposed to vulnerabilities similar to existing
DLEP messages and discussed in the Security Considerations section
Thanks for the review. Sorry for the tardy reply.
On Mon, Aug 12, 2024 at 2:24 PM Susan Hares via Datatracker <noreply@xxxxxxxx> wrote:
> Reviewer: Susan Hares
> Review result: Has Issues
>
> ...
>
> Document: draft-ietf-manet-dlep-ether-credit-extension-06
> Reviewer: Susan Hares
> Result: Ready with issues
> Review Date: 2024-08-12
>
> Summary: This document refers to draft-ietf-manet-dlep-credit-flow-15.txt
> and RFC8175. My technical issue with this specification is
> draft-ietf-manet-dlep-credit-flow-15, and the lack of comments on
> wildcards in the security section. This document also has editorial nits.
>
> Benefit of this draft: Credit window schemes can enable effective data flow
> processing for 802.1Q.
>
> Issue 1: Issue with draft-ietf-manet-dlep-credit-flow-15:
> draft-ietf-manet-credit-window as a specification of the credit-window scenario.
> draft-ietf-manet-credit-window is a document declared "DEAD" by the IESG
> with flaws noted in the TSV-ART and OPS-DIR review.
>
> In my gen-art review for draft-ietf-manet-dlep-credit-flow-15, I've noted issues in that document.
> https://datatracker.ietf.org/doc/review-ietf-manet-dlep-credit-flow-control-15-genart-lc-hares-2024-08-12/
>
> Since that document is a key reference in this document, those issues impact this document.
We are working on resolving comments, updating, and getting these four drafts through:
- draft-ietf-manet-dlep-credit-flow-control-15
- draft-ietf-manet-dlep-da-credit-extension-18
- draft-ietf-manet-dlep-ether-credit-extension-06
- draft-ietf-manet-dlep-traffic-classification-12
> Issue 2: "wildcard" matching of any PCP or VID needs security/manageability comment
>
> Wildcards ease the manageability of matching PCP or VID fields. However, the
> security section should make some comment about the risks of wildcard matching for these fields.
Something like:
Care must be exercised in the use of wildcards for matching PCP and VID fields. Wildcards may be convenient to match a number of packet flows but could inadvertently match new flows that appear after the wildcard matching has been set up or more flows than intended.
> Comments on Editorial NITs:
> 1. Unclear use of ".e.g.," format in 3 places
>
> Place 1: Section 4, paragraph 7.
>
> Old text:/
> Routers may have limits on the number of queues that they can support
> and, perhaps, even limits in supported credit window combinations,
> e.g., if per destination queues can even be supported at all. /
>
> Translating the "e.g.," to "For example, if per destination queues can even be supported at all"
> gives an unclear sentence. Best to rewrite this sentence.
How about
Routers may have limits on the number of queues that they can support
and limits on supported credit window combinations. Per destination
queues might not be supported at all.
> Place 2: Section 4, paragraph 7, last sentence
>
> Old text:/
> In either case, the mismatch of
> capabilities SHOULD be reported to the user via normal network
> management mechanisms, e.g., user interface or error logging./
>
> The "e.g.," format is used correctly in the singular form ("a--" or "b--").
> However, the "e.g.," format does not create a clear sentence.
>
> Two alternative:
>
> New text-1:/
> In either case, the mismatch of
> capabilities SHOULD be reported to the user via normal network
> management mechanisms (e.g. user interface or error logging)./
>
> New text-2:/
> In either case, the mismatch of
> capabilities SHOULD be reported to the user via normal network
> management mechanisms suchg as user interface or error logging./
How about a tweak on text 2:
In either case, the mismatch of
capabilities SHOULD be reported to the user via normal network
management mechanisms such as user interface messages or error logging.
> Place 3: Section 4: Security considerations, paragraph 1, sentence 2
>
> Old text:/The defined extension
> exposes vulnerabilities similar to existing DLEP messages, e.g., an
> injected message resizes a credit window to a value that results in a
> denial of service./
>
> The "e.g.," format does not provide a clear indication that this vulnerability is one
> of several potential vulnerabilities.
How about
The defined extension is exposed to vulnerabilities similar to existing
DLEP messages and discussed in the Security Considerations section
of [RFC8175] such as an injected message resizing a credit window
to a value that results in a denial of service.
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
to a value that results in a denial of service.
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
