Re: [Detnet] Murray Kucherawy's No Objection on draft-ietf-detnet-ip-06: (with COMMENT)

[Lou Berger <[e-mail]>]

Hi,

Thank you for the comments.  Please see response (as co-author) in-line 
below.


On 6/20/2020 3:56 PM, Murray Kucherawy via Datatracker wrote:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-detnet-ip-06: 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Just a pile of nits here:
>
> Section 1:
>
> * "... defined to support IP flows, instead ..." -- "instead" should start a
> new sentence, or at least the comma should be a semi-colo
sure.
>
> * "... data plane in Section 3, considerations that ..." -- add "and" before
> "considerations"
okay
>
> Section 3:
>
> * The parentheses in the second paragraph are unbalanced.
>
> * "Same can be valid for flow aggregates." -- To what does "Same" refer?
agreed.  How about: s/Same be valid/This is also the case
>
> * "In such cases using smaller tuples are appropriate." -- s/are/is/
How about "In such cases, using fewer fields is fields is appropriate,"
>
> * "... forwarded unmodified, however ..." -- "however" should start a new
> sentence, or at least the comma should be a semi-colon

I think the following sentence is wrong and should read:

OLD

         Non-DetNet and DetNet IP packets are identical on the wire.
         Generally the fields used in flow identification are forwarded
         unmodified, however modification of these fields is allowed,
         for example changing the DSCP value, when required by the 
DetNet service.

NEW
         Non-DetNet and DetNet IP packets are identical on the wire.
         Generally the fields used in flow identification are forwarded
         unmodified. However, standard modification of the
                 differentiated services (DSCP) field <xref
                 target="RFC2474"/> is not precluded.

> * "Note, that Figure 1 and ..." -- remove the comma

Thanks


> * "TSN over MPLS is discribed in ..." -- s/discribed/described/
thanks
> Section 4.1:
>
> * "... treatment on the connected sub-network, see ..." -- the comma should be
> a semi-colon, or the references should be in parentheses, etc.
sure
> Section 4.2:
>
> * "... the underlying link / sub net specific ..." -- suggest
> "link/sub-network", if I'm reading the rest of this right (just to match other
> text, and tighten up the spaces)
yup.
>
> * Some places in this section use "end-to-end", some use "end to end".  I'm not
> sure which is correct, but in any case the document should be consistent.
this document has had many hands on it. changed to 'end-to-end' to match 
RFC8655
> * "... link / sub-network ..." -- same point as before, twice more
sure
> * ""R" and "E" denotes replication ..." -- s/denotes/denote/
thanks
> Section 4.3.2:
>
> * "... subject of a completed reservation, can disrupt ..." -- remove the comma
okay
> * "Remarking packets ..." -- this should be "Re-marking" (two instances)
sure
> Section 4.3.3:
>
> * "... when a single 5-tuple application flow experience reordering ..." --
> s/experience/experiences/
>
thanks
> Section 4.4:
>
> * "... flows can be aggregated using any of the 6-tuple, ..." -- I can't quite
> parse this.  Do you mean "any subset of the elements of the 6-tuple"?
>
> OLD:
>     It is the responsibility of the DetNet controller plane to properly
>     provision the use of these aggregation mechanisms.  This includes
>     ensuring that aggregated flows have compatible e.g., the same or very
>     similar QoS and/or CoS characteristics, see Section 4.3.2.  It also
>     includes ensuring that per component-flow service requirements are
>     satisfied by the aggregate, see Section 5.3.
>
> NEW:
>     It is the responsibility of the DetNet controller plane to properly
>     provision the use of these aggregation mechanisms.  This includes
>     ensuring that aggregated flows have compatible (e.g., the same or very
>     similar) QoS and/or CoS characteristics, per Section 4.3.2.  It also
>     includes ensuring that per component-flow service requirements are
>     satisfied by the aggregate, per Section 5.3.
yes, thank you.
>
> Section 5:
>
> * "... Traffic classification, for example ..." -- that should be a semi-colon,
> or start a new sentence
sure.
>
> Section 5.1:
>
> * "Note, that additional ..." -- remove comma
done
> Section 5.1.1.1:
>
> * "... prefix matching for this field, see ..." -- parenthesize the "see"
> clause, or maybe change "see" to "per"
okay
>
> Section 5.1.1.2:
>
> * Same issue with the tacked-on "see" and references.
>
> * "Note: any IP address ..." -- capitalize "any"
>
> Section 5.1.1.3:
>
> * "Other, non-zero values, MUST be ..." -- remove the commas
>
> Section 6:
>
> * "When used, can be used ..." -- suggest "When used, the field can be used ..."
>
> * "Exact and wildcard matching is required." (two instances) -- suggest
> "Support for both exact and wildcard matching is required."
>
> Section 7:
>
> * "... through whatever means is provided by the ..." -- s/is/are/
>
>
Accepted all the above.

Changes covered here can be previewed at: 
https://github.com/detnet-wg/data-plane-drafts/tree/working/lb/iesg-0625

https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/detnet-wg/data-plane-drafts/working/lb/iesg-0625/ip/draft-ietf-detnet-ip.xml

Thank you!

Lou




>