Hi Gorry,
Thanks for the feedback, I really appreciate it. we'll make sure that TSVWG is copied when RTGWG is to LC this draft.
Thanks,
Yingzhen
On Thu, Dec 7, 2023 at 5:03 AM Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
On 06/12/2023 19:05, Colin Perkins via Datatracker wrote:
> Reviewer: Colin Perkins
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@xxxxxxxx if you reply to or forward this review.
>
> I am not an expert on YANG or DiffServ, and I have not followed the development
> and discussion related to this draft. This review is hence necessarily written
> from a generalist transport perspective. Please accept my apologies if I touch
> on topics that have been considered before in the working group.
>
> The draft looks to be defining mechanisms to configure the use of existing QoS
> mechanisms and to report on their effects. As such, any new transport protocol
> impact would seem limited. The mechanisms described may make it easier to
> deploy QoS, but the QoS techniques exist and can be used irrespective of
> whether this draft is published.
>
> For AQM, this draft specifies configuration parameters for RED and WRED. These
> AQM algorithms have certainly been widely implemented and used, but there are
> more modern alternatives that have been defined in IETF and that are also
> starting to see use (e.g., PIE – RFC 8033, and several variants on CoDel – RFC
> 8289/8290). Has consideration been given to whether any other AQM algorithms
> should be included? Is the mechanism extensible to support these and other
> future AQM approaches? From a transport perspective I would not recommend use
> of RED or WRED today, since the alternatives perform better and are harder to
> misconfigure. Some discussion about extensibility and alternatives would be
> helpful.
>
> Similarly there are only two traffic classifiers specified, which may warrant
> an extension point.
>
> Otherwise, this seems broadly ready.
>
> Colin
>
>
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/tsv-art
I would like to add a few comments on definitions in this ID, following
the TSV-ART review above, as a TSVWG Co-Chair (since TSVWG maintains the
DiffServ Specs).
1. Remove duplicate deifinion?
DS behavior aggregate and BA are both defined, but I think they are the
same? Maybe you could choose BA?
2. Cite RFC for BA:
Behavior Aggregates (BAs) are defined in [RFC4594].
3. Cite RFC for Diffserv and the associated IANA Registry
The Differentiated Services (Diffserv) architecture provides
differentiated traffic forwarding based on the DSCP carried in the
Diffserv field of the IP packet header [RFC2474]. A common set of DSCPs
are defined for both IPv4 and IPv6, and both network protocols use a
common IANA registry [DSCP-registry].
4. For avoidance of doubt, please could you also add:
The IETF first defined QoS using ToS precedence for IP packets in
[RFC0791] and updated it to be part of the ToS field in [RFC1349]. Since
1998, this practice has been deprecated by [RFC2474].
5. Cite RFC for ECN:
ECN is defined in [RFC3168].
6.
“or will be classified based on source IPv4 address prefix.”
- Please update to include IPv6.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
