Flow and Service Information Model for Deterministic Networking (DetNet)
draft-ietf-detnet-flow-information-model-14

In Section 1, I don't understand what the paragraph starting "In the IETF ..." means, because of those three words.  Is it different outside of the IETF?

Section 5.4.2:
OLD:
    Using wild cards for these attributes are specified ...
NEW:
    Use of wild cards for these attributes is specified ...

Thank you to Shawn Emery for the SECDIR review, and thank you for responding to it.

** Editorially, the style by which info model elements are described is different in Section 4 vs. 5.

** Editorially, the level of detail provided for the information elements seems vary a bit.  For example, Section 5.5a describes a time interval in the with Interval attribute of TrafficSpecification but provides no data type of units.  On the other hand, Section 5.9.2 describes MaxLatency as being an integer (data type) and unit (nanoseconds).

** Section 7.  What is an “information group”?

** Section 10
   The external interfaces of the DetNet domain need to be subject to
   appropriate confidentiality.  Additionally, knowledge of which flows/
   services are provided to a customer or delivered by a network
   operator may supply information that can be used in a variety of
   security attacks.  Security considerations for DetNet are described
   in detail in [I-D.ietf-detnet-security].  General security
   considerations are described in [RFC8655].  This document discusses
   modeling the information, not how it is exchanged.

-- Please clarify what is “appropriate confidentiality” and who determines that?

-- I didn’t follow why the external interface is such a key focus given the contents of the detnet-security draft.

Perhaps something more streamline as (roughly) the following could work if that meets the original intent:

NEW (Section 10)
This document describes an information model intended to principally describe network configuration information.  Knowledge of which flows or services are provided to a customer or delivered by a network operator can inform a variety of attacks.  

This information model will be instantiated with implementation level details in a data model.  Such data models (e.g., draft-ietf-detnet-yang) will need to address the security considerations for DetNet which are described in [I-D.ietf-detnet-security].  General security considerations are described in [RFC8655].

Thank you for the work put into this document. From a purist point of view, I appreciate to see this document being published as "informational" and *before* the data models.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

In general and may be I missed it, but I see no relationships between the three information models (app/flow/service) and relationships among entities are also quite an important part of information models.

-- Title --
The title is only about "flow" but the abstract and content are about "flow and services". Strongly suggest to update the title.

-- Section 1 --
Should "IP 6-tuple" have a reference? I guess that this is about the common 5-tuple + DSCP but a definition will be welcome (or add a reference to section 5.4.2)

Adding a reference to IEEE 802.1 TSN ?

-- Section 1.1 --
I am puzzled by this sentence "herefore, the DetNet flow and service information models described in this document are based on [IEEE8021Qcc]"... Does one information model supersede or contradict the other one ? Else, why redo the work at the IETF? It is partially answered in section 1.2 but still unclear to me.

-- Section 5.2 --
Is the list strictly limited to Ethernet, MPLS, and IP ?

-- Section 6.3.3 --
Isn't the word 'jitter' more common than 'Maximum Latency Variation' ?

-- Section 6.3.5 & 6.3.6 --
Missing the unit ?


== NITS ==

-- Section 2.3 --
To respect the convention of the previous sentence, I would have expected that "SourceMacAddress" would be written as "SourceMACAddress" as "MAC" is an acronym ;-)

-- Section 5 --
s/with fix packet size/with fixed packet size/ ?

-- Section 5.1 --
s/many to one/n:1/ to be consistent ?

The "models described in this document are based on [IEEE8021Qcc]".  Why is that reference not Normative?

I agree with Álvaro that IEEE8021Qcc should be normative.

I agree with Roman about consistently (not) specifying units.

Section 5.6

Please expand "UNI".

Section 5.9.4

Where is PLR precisely defined?

Section 5.9.6, 6.3.6

Over what time interval is the misordering tolerance measured/applied?

Section 7

I'm not sure what sense the word "applied" (in "applied from the user of
the DeNetService") is being used.  The sentences would parse more easily
if it was supposed to be "supplied", but I'm not 100% that's the
intended meaning.

Thanks for addressing my DISCUSS.

Hi,

Thanks for this document.  I found it pretty easy to read/follow, although the relationship between this document and the YANG configuration data model could perhaps be more clear in sections 1.1 and 1.2.  I.e. my interpretation is that this document is not defining a configuration information model because a configuration data mode (in YANG) is being defined instead.  In addition to that, the YANG configuration data model will also make use of some of the characteristics of the flow and service information models.  Is my interpretation correct?  If so, perhaps the text could be tweaked to make this a bit more explicit?

Otherwise, I only had a couple of minor comments:

(1) I would suggest that the summary section could probably be removed since the document doesn't really need it.  Particularly, if the relationship between the information model and YANG data model is further clarified in the introduction/goals/non-goals.

(2) In the introduction, the start of paragraph 4 ("In the IETF DetNet service ..."), doesn't scan for me, and perhaps should be rephrased.

Thanks,
Rob