Subject: [tsvwg] Comments on draft-ietf-tsvwg-le-phb-04.txt

From: <[email-masked]>
Date: Mon, 12 Mar 2018 10:25:36 +0000

Hi Roland,

nice to see your draft making progress. I'm having  some minor an editorial comment below.

Regards,   Ruediger

Minor comments:

Section 3. Applicability

   The LE PHB allows networks to protect themselves from selected types

   of traffic as a complement to giving preferential treatment to other
   selected traffic aggregates.

Might only one of either "traffic" or "aggregate" be sufficient (instead of traffic aggregate)?

---------

Section 5.   Traffic Conditioning Actions

Please insert a reference to section 8, as section 8 allows for LE policing at domain-boundaries by a MAY.

---------
Section 8.   Remarking to other DSCPs/PHBs

>From this section on, the "user" seems to be able to set the LE DSCP ("user sets DSCP" or the like appears in 3 or 4 instances from there on) . Prior to this section, providers or applications seemed to be the ones to set the LE DSCP. If the concept of users setting the LE DSCP should be allowed in general, please add text prior to this section. If not, please adapt text from here on.

-------

Section 12.   Security Consideration

   There are no specific security exposures for this PHB. Since it
   defines a new class of low forwarding priority,

I'd suggest to replace "class" by "behavior aggregate" here, as class isn't well defined.

#####################

Editorial comments.

Section 3.  Applicability

Replace

   LE traffic SHOULD be congestion controlled (i.e., use a congestion

   controlled transport or implement a congestion control method
   [RFC8085]).

By

   LE traffic SHOULD use a congestion

   controlled transport or implement a congestion control method
   [RFC8085].

----------------

Replace

   In the case of

   multicast traffic packets from untrusted sources are forwarded as LE
   traffic, they will not harm traffic from non-LE behavior aggregates.

By

   If multicast traffic from untrusted sources is forwarded as LE
   traffic, it will not harm traffic from non-LE behavior aggregates.

---------

Section   8.  Remarking to other DSCPs/PHBs

Replace

   The reason for

   this is that later traversed DS domains may then have still the
   possibility to treat such packets according the LE PHB.

By

   The reason for

   this is to enable LE PHB compliant forwarding by downstream

   diffserv domains.

--------

   Applications that want to ensure the lower precedence

   compared to BE traffic SHOULD use additionally a corresponding Lower-

   than-Best-Effort transport protocol [RFC6297], e.g., LEDBAT
   [RFC6817].

"use additionally" --> "additionally use"

----------

Replace

   A DS domain that still uses DSCP CS1 for marking LE traffic
  (including Low Priority-Data as defined in [RFC4594]....

By
   A DS domain that still continues to mark LE traffic by CS1
    (including Low Priority-Data as defined in [RFC4594]....

-----------

Section 9.  The Update to RFC 4594

Replace by

9.  Update to RFC 4594

-----------
Replace
[RFC4594] recommended to use CS1 as codepoint in,

By

Section 4.10 of [RFC4594] recommended to use CS1 as LE DSCP,

---------

Replace

    Therefore, every occurrence of the CS1 DSCP is replaced by
    the LE DSCP.

By

   Therefore, every occurrence of the CS1 DSCP within RFC 4594 is replaced by
   the LE DSCP.

----------

The text from there on multiple times reads:

This update to RFC 4594 removes the following entry
....
and replaces this by the following entry:

I tend to

and replaces it by the following entry:

Please check with a native spreaker.

---

From: Roland Bless <[email-masked]>
Date: Sun, 18 Mar 2018 15:08:57 +0000

Hi Ruediger,

thanks for the suggestions. I'll try to cover them in the next version
of the draft. Your comment about who is setting the DSCP is important
and I'll try to clarify on that. I actually have to reread the draft
in its new structure to see whether other things now need forward
references, earlier explanations, etc.

On 12.03.2018 at 10:25 [email-masked] wrote:
> From this section on, the “user” seems to be able to set the LE DSCP
> (“user sets DSCP” or the like appears in 3 or 4 instances from there on)
> . Prior to this section, providers or applications seemed to be the ones
> to set the LE DSCP. If the concept of users setting the LE DSCP should
> be allowed in general, please add text prior to this section. If not,
> please adapt text from here on.

> [...]

> Please check with a native spreaker.

The last version already covered many suggestions from a review
by Gorry, who is a native speaker. :-)

Regards,
 Roland