Deterministic Networking
charter-ietf-detnet-04

[Ballot comment]
I have reviewed the changes to the current charter: they do make sense.

Alas, neither the current charter nor the revised one mention the intended status of the documents (they are only specified in the separate milestones). Most of the work items are "will document" and corresponding milestones of "informational" *EXCEPT* for the data plane one as it is both "will document" and "standards track", i.e., a contradiction. May I suggest to change the "will document" into "will specify" for the data plane work item ?

[Ballot comment]
This looks good to me. Even though TSVWG is mentioned in the charter, I was think as DETNET working group will touch on packet loss, delay and recovery which is very close to congestion control we do, it might be good to mention CCWG in this charter for potential collaboration. CCWG hosts good expertise on delay and loss related questions.

[Ballot comment]
In the block of text describing the coverage of wireless, would it be helpful for the charter to explicitly mention that it is picking up this work from the RAW WG?  I'm not sure that this comment will be useful longer term, but possible may be helpful for the next few years?

[Ballot comment]
To recap comments I made earlier in a different forum, I see this recharter effort as neither more nor less than the merger of two previously chartered WGs (RAW, now closed, is the other one) without any net increase in chartered work, but rather a net decrease in number of WGs to juggle.

In my view, this recharter doesn’t actually expand the scope of the WG, since the approved charter doesn’t restrict detnet from working on any particular media, including wireless. So, I think this only adds precision and transparency, and doesn’t reflect formal scope creep. That was my rationale for adding it to the agenda as a minor recharter.

Changed charter milestone "Submit Enhanced DetNet Data Plane Requirements document for publication as Informational", set description to "Submit Requirements for Scaling Deterministic Networks for publication as Informational", added draft-ietf-detnet-scaling-requirements to milestone

Changed charter milestone "Submit first Enhanced DetNet Data Plane solution document for publication", set description to "Submit first Enhanced DetNet Data Plane solution document for publication as Standards Track", set due date to December 2024 from December 2023

Changed charter milestone "Submit Enhanced DetNet Data Plane Requirements document for publication", set description to "Submit Enhanced DetNet Data Plane Requirements document for publication as Informational", set due date to July 2024 from July 2023

Changed charter milestone "Submit controller plane framework", set description to "Submit controller plane framework for publication as Informational", set due date to July 2024 from December 2022, added draft-ietf-detnet-controller-plane-framework to milestone

[Ballot comment]
The current text is confusing:

"The Working Group's scope generally excludes modifications of transport
protocols, OAM, Layer 3 forwarding, and encapsulations, but it may discuss
requirements for such modifications and the work will be coordinated with the
Working Group responsible for the technology"

"Data plane: This work will document how to use IP and/or MPLS, and related OAM,
to support a data plane method of flow identification, and packet treatment
(including, for example, forwarding, service protection, and queuing) over
Layer 3. Other IETF defined data plane technologies may also be used."

Given these two paragraphs, a reader would be confused as to whether Layer 3 forwarding is in scope or not. Talking to the AD, I now understand that this is a case where the WG coordination has already occurred, which is fine.

So there are two ways to make this clear:
(1) Just eliminate the reference in "data plane". Outside the text of the charter, people know that the coordination with TSVWG has already occurred, but the WG scope in general terms is clear to the reader, or

(preferred, 2) make the following change:
OLD
Data plane: This work will document how to use IP and/or MPLS, and related OAM,
to support a data plane method of flow identification, and packet treatment
(including, for example, forwarding, service protection, and queuing) over
Layer 3. Other IETF defined data plane technologies may also be used.

NEW
Data plane: This work will document how to use IP and/or MPLS, and related OAM,
to support a data plane method of flow identification, and packet treatment
(including, for example, service protection, and queuing) over
Layer 3. Other IETF defined data plane technologies may also be used. Due to prior
agreement with TSVWG, Layer 3 forwarding is in scope for [whatever scope was agreed].

[Ballot comment]
How strong is "coordinated with the Working Group responsible"?  E.g., I presume that means that if the work is done in Detnet rather than another WG then the other WG will be notified of any WGLCs, or perhaps a joint WGLC will be performed.  Hence, is it worth expanding on this text at all, or is it clear enough?

[Ballot comment]
Very little change in the charter but it seems important.

Just wondering whether "over Layer 3" is still relevant and applies to all given examples:
```
and packet treatment
(including, for example, forwarding, service protection, and queuing) over
Layer 3.
```

Regards

-éric

This version was discussed at the WG meeting at IETF-113. It revises the "Data Plane" description to change "packet forwarding" to "packet treatment (including, for example, forwarding, service protection, and queuing)". Otherwise the charter text is unchanged, other than trivial cleanup with respect to line wrapping.

[Ballot comment]
Is it clear how the "Data flow information model" will be defined?  Is the plan for this to be done using an adhoc format, or a specific information modelling language such as UML?  Should this be specified in the charter text at all?

[Ballot comment]
I don't particularly mind the "vertical requirements" bit; "cannot be
supported using defined DetNet solutions" does serve to limit scope.

I do think that clarity around "identify the appropriate WG" would be good,
though.

A couple nits:

    Data plane: This work will document how to use IP and/or MPLS, and
    related OAM, to support a data plane method of flow identification
    and packet forwarding over Layer 3. Other IETF defined data plane
    technologies may also be used.

nit: "IP and/or MPLS, and related OAM, [...] Other IETF defined data plane
technologies" is a somewhat awkward construction.

    Controller Plane: This work will document how to use IETF control
    plane solutions to support DetNet. This work includes identification
    of any gaps in existing solutions and identifying the appropriate
    Working Group for any needed extensions.

nit: maybe "for developing"?

[Ballot comment]
I share some of Alvaro's concern regarding the dispatching. I think the requirements angle is also interesting here. I fully expect DETNET to produce reasonable requirements on for example a transport protocol as perceived from the DETNET WGs. After a suitable WG has been identified I would expect that significant discussion over these requirements, likely resulting i changes, would occur. I hope this view is shared, but the usage of the word define, could be interpret as a bit more strict than what I expect was the intention here.

[Ballot comment]
(1) Given the close relationship with IEEE, I think we need external review.


(2) "identify the appropriate Working Group" 

This phrase shows up a couple of times.  I was first worried that it was meant as a means for the WG to simply decide which WG (including itself) would do the work, but now I think it is meant as a dispatch-like function: "we need this work done, WG x seems like the right place."  Is my interpretation correct?  Please try to clarify so that there is no confusion later...maybe something along the lines of "the work will be done in the WG responsible for the technology".


(3) Is the intent to publish the "vertical requirements" documents as RFCs?  Just wondering because it sounds like an open-ended effort.  Suggestion: if appropriate, scope the documents to industries that have new requirements which have not been addressed already.


(4) s/OSPF, IS-IS/LSR


(5) Milestones would be nice.

[Ballot comment]
-
  Data flow information model: This work will identify the information
  needed for flow establishment and control and be used by a
  reservation protocol or by YANG data models.

The "or" should "and", right?
Btw, when you see  in a single sentence, that's a clear candidate for splitting up.

-
  Identification of additional YANG models

Additional to what?
OLD:  Identification of additional YANG augmentations
NEW:  YANG models:

- What's the point to add "As standard track or informational RFCs"? To stress it's not a BCP or EXP?
Personal preference: clearly label the expected status for each document.

[Ballot comment]
Here are my more specific comments on the charter.

1) I am concerned about the “encapsulation of frames”.  This seems to imply that yet another data-plane encapsulation could be pictured.  The description of data plane as “This work will document a data plane method of flow
identification and packet forwarding over Layer 3.”  doesn't clarify this.  Could  “Candidate Layer 3 data plane technologies that may be used, without modification, include: IPv4, IPv6, MPLS” be updated to “The only candidate Layer 3 data plane technologies that may be used are IPv6 and MPLS; the selected technology must be used without modification.”?

This is also asking that IPv4 be taken off the table as a candidate.  I am suggesting this for three reasons.  First, pragmatically IPv6 has a flow label that can easily allow flow identification.  Second, if you consider sunset4 – we as the IETF – are trying to move towards IPv6.    Do tell me if and why you think this is a bad idea.

How does an L2 AVB packet get carried by a Router?  Is the idea to just encapsulate it in an MPLS or IP packet?  Where is this being defined or described?

2) I am concerned about the lack of scalability considerations for the deterministic data paths.  There have been several other efforts – starting with RSVP – to reserve buffers and resources.  This doesn’t scale to Internet-sized flows.  I’d like to see some words in the charter indicating what the approximate design center is.  This can affect the scaling in the hardware, the size of fields, and so on.

3) As I mentioned in my quick Block, we need to nail down how to clarify and constrain the scope of this technology to a reasonable domain that can be under single control and have the needed hardware and software functionality.  The current suggested text of “The Working Group will focus on solutions for constrained environments,    such as those that may be deployed in a single administrative domains.”  is not quite strong enough; for instance, that wording is frequently used with technology that is just getting started to bound the work effort.  This is specifically not expected to be seen in the general Internet but is constrained much more to purpose-built networks.

A related question is what constraints the timing synchronization imposes on the scope of the network?  I don’t have a lot of background knowledge here and the problem-statement claims that it is “done work” but AVB is strongly dependent on synchronized time across its L2 domain.

4) Although the charter says “The work will cover the characterization of flows, the
encapsulation of frames, the required forwarding behaviors, as well as the state that may need to be established in intermediate nodes; it will not include end-to-end considerations such as transport protocols, modification of OAM, L3 forwarding and encapsulations, or control plane
protocols.”, the interactions to other WGs seems to clearly indicate that DetNet would be selecting particular control protocols in the architecture and providing requirements to the associated WGs.  I think it would be better to clarify that DetNet will discuss and select appropriate existing control plane protocols and provide requirements as necessary to go to the appropriate WGs.  If, instead, the intent is to focus on the centralized controller approach (as suggested in draft-finn-detnet-problem-statement) – the I’d strongly suggest clarifying that.  The urge to start work on control plane protocols and claim that a favorite protocol is the right solution can seriously derail a WG.  This was an issue with both SFC and NVO3.  Because of the interactions described in this charter, it looks like there is a large open door towards requirements and picking control plane protocols.

5) I don’t see anything in the charter that indicates whether only unicast flows are being considered or whether multicast are also to be considered.  Can you please clarify in the charter?  I certainly see in Sec 3 of draft-finn-detnet-problem-statement-03 that the “critical packet flows that can be unicast or multicast”.

[Ballot comment]
Let me put this way: I believe the charter text now contains all what it needs (http://trac.tools.ietf.org/bof/trac/wiki/DetNetDraftCharter version 15), but the flow makes it difficult to read. However, I could live with it.

Regards, Benoit


===========================

The Deterministic Networking (DetNet) Working Group focuses on
deterministic data paths that operate over layer 2 bridged and layer 3
routed segments, where such paths can provide bounded latency, loss, and
packet delay variation (jitter).

EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION
Various industries, for example, professional audio, electrical
utilities, building automation systems, wireless for industrial
applications require this capability because...

The Working Group will collaborate with IEEE802.1 Time-Sensitive Networking (TSN),
which is responsible for layer 2 operations, to define a common architecture
for both layer 2 and layer 3. For this common architecture, a number of elements
such as the IEEE802.1 TSN host operation should be agnostic to the choice of
network used for the connectivity.

The work applies to flows that can be characterized in a manner that allows the
network to 1) reserve the appropriate resources for the flows in advance, and
2) release/reuse the resources when they are no longer required. 
The work covers the characterization of flows, the encapsulation of frames,
the required forwarding behaviors, as well as the state that may need to be
established in intermediate nodes.

Out of scope is the end-to-end considerations such the transport protocols,
modification of Operations, Administration, and Maintenance (OAM), L3 forwarding
and encapsulations, or control plane protocols.

DetNet is chartered to work in the following areas:

* Problem statement and requirements: These documents will not necessarily
  be published, but may be maintained in a draft form or on a collaborative
  Working Group wiki to support the efforts of the Working Group and help new comers.

* An architecture that encompasses the data plane, OAM, management, control,
  and security aspects required to enable a multi-hop path, and forwarding
  along that path, with the deterministic properties of controlled latency,
  low packet loss, low packet delay variation, and high reliability.
  As part of the overall architecture work, the working group will document
  which deployment environments and types of topologies that are within
  (or outside) the scope of the DetNet architecture. 

* Data plane: This work will document a data plane method of flow
  identification and packet forwarding over Layer 3. Candidate Layer 3 data
  plane technologies that may be used, without modification, include: IPv4,
  IPv6, MPLS. The data plane, which must be compatible with the work in
  IEEE802.1 TSN, is independent from any path setup protocol or
  mechanism.

* Data flow information model: This work will identify the information
  needed for flow establishment and control and be used by a
  reservation protocol or by YANG data models. The work will be
  independent from the protocol(s) used to control the flows
  (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).

* Identification of additional YANG augmentations: This work will
  document device and link capabilities (feature support) and resources
  (e.g. buffers, bandwidth) for use in device configuration and status
  reporting. Such information may also be used when advertising the
  deterministic network elements to a control plane. The work will be
  independent from the protocol(s) that may be used to advertise this
  information (e.g. IS-IS or GMPLS extensions). Any YANG work will be
  coordinated with the working groups that define the base models.
  THIS SECTION NEEDS CLARFIFICATION, BUT I NEED TO SPEAK TO DEBORAH FIRST

The WG will coordinate with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, LIME, and 6TisSCH. As
the work progresses, requirements may be provided to the responsible
Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal
point to maintain the consistency of the overall architecture. The WG
will liaise with appropriate groups in IEEE and other Standards
Development Organizations (SDOs), specifically IEEE802.1 TSN.

[Ballot block]
- There is a tendency in our industry to capitalize word, and to overuse acronyms:
    - Layer 2 Bridged and Layer 3
    - TSN
    - OAM

- I find the structure not ideal.
    Part 1 should express the motivation and high level intend
    Part 2, more details
    Part 3, out of scope, if any
    Part 4, deliverables
    Part 5, coordination

For example, the architecture is mentioned in multiple place

- "Identification of additional YANG augmentations:"
What does it mean? new YANG models, fine? This could be understood as YANG language augmentations, which is a different story.

- "Any YANG work will be  coordinated with the working groups that define the base models."
What are those base models?


- "The work will be  independent from the protocol(s) that may be used to advertise this  information (e.g. IS-IS or GMPLS extensions)." Well, you are in the YANG section, and YANG is bound to NETCONF/RESCONF.
"independent from the protocol(s) is for the information model

I have no objection to the work itself, but I believe that the charter text should be improved. I started with a list of improvements, and in the end, I started editing. There are still improvements to be made. I guess that makes it a BLOCK. An 1:1 with Deborah should be the next step.

===========================

The Deterministic Networking (DetNet) Working Group focuses on
deterministic data paths that operate over layer 2 bridged and layer 3
routed segments, where such paths can provide bounded latency, loss, and
packet delay variation (jitter).

EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION
Various industries, for example, professional audio, electrical
utilities, building automation systems, wireless for industrial
applications require this capability because...

The Working Group will collaborate with IEEE802.1 Time-Sensitive Networking (TSN),
which is responsible for layer 2 operations, to define a common architecture
for both layer 2 and layer 3. For this common architecture, a number of elements
such as the IEEE802.1 TSN host operation should be agnostic to the choice of
network used for the connectivity.

The work applies to flows that can be characterized in a manner that allows the
network to 1) reserve the appropriate resources for the flows in advance, and
2) release/reuse the resources when they are no longer required. 
The work covers the characterization of flows, the encapsulation of frames,
the required forwarding behaviors, as well as the state that may need to be
established in intermediate nodes.

Out of scope is the end-to-end considerations such the transport protocols,
modification of Operations, Administration, and Maintenance (OAM), L3 forwarding
and encapsulations, or control plane protocols.

DetNet is chartered to work in the following areas:

* Problem statement and requirements: These documents will not necessarily
  be published, but may be maintained in a draft form or on a collaborative
  Working Group wiki to support the efforts of the Working Group and help new comers.

* An architecture that encompasses the data plane, OAM, management, control,
  and security aspects required to enable a multi-hop path, and forwarding
  along that path, with the deterministic properties of controlled latency,
  low packet loss, low packet delay variation, and high reliability.
  As part of the overall architecture work, the working group will document
  which deployment environments and types of topologies that are within
  (or outside) the scope of the DetNet architecture. 

* Data plane: This work will document a data plane method of flow
  identification and packet forwarding over Layer 3. Candidate Layer 3 data
  plane technologies that may be used, without modification, include: IPv4,
  IPv6, MPLS. The data plane, which must be compatible with the work in
  IEEE802.1 TSN, is independent from any path setup protocol or
  mechanism.

* Data flow information model: This work will identify the information
  needed for flow establishment and control and be used by a
  reservation protocol or by YANG data models. The work will be
  independent from the protocol(s) used to control the flows
  (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).

* Identification of additional YANG augmentations: This work will
  document device and link capabilities (feature support) and resources
  (e.g. buffers, bandwidth) for use in device configuration and status
  reporting. Such information may also be used when advertising the
  deterministic network elements to a control plane. The work will be
  independent from the protocol(s) that may be used to advertise this
  information (e.g. IS-IS or GMPLS extensions). Any YANG work will be
  coordinated with the working groups that define the base models.
  THIS SECTION NEEDS CLARFIFICATION, BUT I NEED TO SPEAK TO DEBORAH FIRST

The WG will coordinate with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, LIME, and 6TisSCH. As
the work progresses, requirements may be provided to the responsible
Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal
point to maintain the consistency of the overall architecture. The WG
will liaise with appropriate groups in IEEE and other Standards
Development Organizations (SDOs), specifically IEEE802.1 TSN.

[Ballot block]
- There is a tendency in our industry to capitalize word, and to overuse acronyms:
    - Layer 2 Bridged and Layer 3
    - TSN
    - OAM

- I find the structure not ideal.
    Part 1 should express the motivation and high level intend
    Part 2, more details
    Part 3, out of scope, if any
    Part 4, deliverables
    Part 5, coordination

1. Section 1 speak about "The group will collaborate with IEEE802.1 TSN", which is not found in section 4.
2. The architecture is mentioned in multiple place

- "Identification of additional YANG augmentations:"
What does it mean? new YANG models, fine? This could be understood as YANG language augmentations, which is a different story.

- "Any YANG work will be  coordinated with the working groups that define the base models."
What are those base models?


- "The work will be  independent from the protocol(s) that may be used to advertise this  information (e.g. IS-IS or GMPLS extensions)." Well, you are in the YANG section, and YANG is bound to NETCONF/RESCONF.
"independent from the protocol(s) is for the information model

I have no objection to the work itself, but I believe that the charter text should be improved. I started with a list of improvements, and in the end, I started editing. There are still improvements to be made. I guess that makes it a BLOCK. An 1:1 with Deborah should be the next step.

===========================

The Deterministic Networking (DetNet) Working Group focuses on
deterministic data paths that operate over layer 2 bridged and layer 3
routed segments, where such paths can provide bounded latency, loss, and
packet delay variation (jitter).

EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION
Various industries, for example, professional audio, electrical
utilities, building automation systems, wireless for industrial
applications require this capability because...

The Working Group will collaborate with IEEE802.1 Time-Sensitive Networking (TSN),
which is responsible for layer 2 operations, to define a common architecture
for both layer 2 and layer 3. For this common architecture, a number of elements
such as the IEEE802.1 TSN host operation should be agnostic to the choice of
network used for the connectivity.

The work applies to flows that can be characterized in a manner that allows the
network to 1) reserve the appropriate resources for the flows in advance, and
2) release/reuse the resources when they are no longer required. 
The work covers the characterization of flows, the encapsulation of frames,
the required forwarding behaviors, as well as the state that may need to be
established in intermediate nodes.

Out of scope is the end-to-end considerations such the transport protocols,
modification of Operations, Administration, and Maintenance (OAM), L3 forwarding
and encapsulations, or control plane protocols.

DetNet is chartered to work in the following areas:

* Problem statement and requirements: These documents will not necessarily
  be published, but may be maintained in a draft form or on a collaborative
  Working Group wiki to support the efforts of the Working Group and help new comers.

* An architecture that encompasses the data plane, OAM, management, control,
  and security aspects required to enable a multi-hop path, and forwarding
  along that path, with the deterministic properties of controlled latency,
  low packet loss, low packet delay variation, and high reliability.
  As part of the overall architecture work, the working group will document
  which deployment environments and types of topologies that are within
  (or outside) the scope of the DetNet architecture. 

* Data plane: This work will document a data plane method of flow
  identification and packet forwarding over Layer 3. Candidate Layer 3 data
  plane technologies that may be used, without modification, include: IPv4,
  IPv6, MPLS. The data plane, which must be compatible with the work in
  IEEE802.1 TSN, is independent from any path setup protocol or
  mechanism.

* Data flow information model: This work will identify the information
  needed for flow establishment and control and be used by a
  reservation protocol or by YANG data models. The work will be
  independent from the protocol(s) used to control the flows
  (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).

* Identification of additional YANG augmentations: This work will
  document device and link capabilities (feature support) and resources
  (e.g. buffers, bandwidth) for use in device configuration and status
  reporting. Such information may also be used when advertising the
  deterministic network elements to a control plane. The work will be
  independent from the protocol(s) that may be used to advertise this
  information (e.g. IS-IS or GMPLS extensions). Any YANG work will be
  coordinated with the working groups that define the base models.
  THIS SECTION NEEDS CLARFIFICATION, BUT I NEED TO SPEAK TO DEBORAH FIRST

The WG will coordinate with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, LIME, and 6TisSCH. As
the work progresses, requirements may be provided to the responsible
Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal
point to maintain the consistency of the overall architecture. The WG
will liaise with appropriate groups in IEEE and other Standards
Development Organizations (SDOs), specifically IEEE802.1 TSN.

[Ballot block]
I would like to see restrictions and assumptions in the charter about the intended
reach of this technology.  I would be quite concerned if it is expected to go across the
general Internet - due to the hardware requirements, for instance - but I see no indications
of expected distance or scope.

Sorry for the very lateness of this concern - though I have mentioned it before - but I'm
on vacation and this charter showed up on the telechat after I was already out.

[Ballot comment]

Not a comment on the charter but more a (loaded:-)
question...

I believe, but don't have a citation to hand, that folks
have found that higher layer protocol performance is more
deterministic when payloads are encrypted. The logic, as I
understand it, is ciphertext means middleboxes are less
likely to mess about, whereas with plaintext, middlebox
messing affects latencies, jitter etc in unpredictable
ways.  Do we think that this WG might maybe conclude that
(perhaps opportunistically) encrypting the data plane may
be a fine way to make latency more predictable?  If so,
count me in to help write that text/draft!

If folks liked that idea enough, I guess one could even
add a work item to the charter along the lines of:

* Investigating the potential for (possibly
  opportunistic) encryption to increase determinism.

(At which point I'd be a yes ballot too:-)

[Ballot block]
- There is a tendency in our industry to capitalize word, and to overuse acronyms:
    - Layer 2 Bridged and Layer 3
    - TSN
    - OAM

- I find the structure not ideal.
    Part 1 should express the motivation and high level intend
    Part 2, more details
    Part 3, out of scope, if any
    Part 4, deliverables
    Part 5, coordination

1. Section 1 speak about "The group will collaborate with IEEE802.1 TSN", which is not found in section 4.
2. The architecture is mentioned in multiple place

- "Identification of additional YANG augmentations:"
What does it mean? new YANG models, fine? This could be understood as YANG language augmentations, which is a different story.

- "Any YANG work will be  coordinated with the working groups that define the base models."
What are those base models?


- "The work will be  independent from the protocol(s) that may be used to advertise this  information (e.g. IS-IS or GMPLS extensions)." Well, you are in the YANG section, and YANG is bound to NETCONF/RESCONF.
"independent from the protocol(s) is for the information model

I have no objection to the work itself, but I believe that the charter text should be improved. I started with a list of improvements, and in the end, I started editing. There are still improvements to be made. I guess that makes it a BLOCK. An 1:1 with Barbara should be the next step.

===========================

The Deterministic Networking (DetNet) Working Group focuses on
deterministic data paths that operate over layer 2 bridged and layer 3
routed segments, where such paths can provide bounded latency, loss, and
packet delay variation (jitter).

EXPLAIN IN ONE SENTENCE OR TWO THE MOTIVATION
Various industries, for example, professional audio, electrical
utilities, building automation systems, wireless for industrial
applications require this capability because...

The Working Group will collaborate with IEEE802.1 Time-Sensitive Networking (TSN),
which is responsible for layer 2 operations, to define a common architecture
for both layer 2 and layer 3. For this common architecture, a number of elements
such as the IEEE802.1 TSN host operation should be agnostic to the choice of
network used for the connectivity.

The work applies to flows that can be characterized in a manner that allows the
network to 1) reserve the appropriate resources for the flows in advance, and
2) release/reuse the resources when they are no longer required. 
The work covers the characterization of flows, the encapsulation of frames,
the required forwarding behaviors, as well as the state that may need to be
established in intermediate nodes.

Out of scope is the end-to-end considerations such the transport protocols,
modification of Operations, Administration, and Maintenance (OAM), L3 forwarding
and encapsulations, or control plane protocols.

DetNet is chartered to work in the following areas:

* Problem statement and requirements: These documents will not necessarily
  be published, but may be maintained in a draft form or on a collaborative
  Working Group wiki to support the efforts of the Working Group and help new comers.

* An architecture that encompasses the data plane, OAM, management, control,
  and security aspects required to enable a multi-hop path, and forwarding
  along that path, with the deterministic properties of controlled latency,
  low packet loss, low packet delay variation, and high reliability.
  As part of the overall architecture work, the working group will document
  which deployment environments and types of topologies that are within
  (or outside) the scope of the DetNet architecture. 

* Data plane: This work will document a data plane method of flow
  identification and packet forwarding over Layer 3. Candidate Layer 3 data
  plane technologies that may be used, without modification, include: IPv4,
  IPv6, MPLS. The data plane, which must be compatible with the work in
  IEEE802.1 TSN, is independent from any path setup protocol or
  mechanism.

* Data flow information model: This work will identify the information
  needed for flow establishment and control and be used by a
  reservation protocol or by YANG data models. The work will be
  independent from the protocol(s) used to control the flows
  (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS).

* Identification of additional YANG augmentations: This work will
  document device and link capabilities (feature support) and resources
  (e.g. buffers, bandwidth) for use in device configuration and status
  reporting. Such information may also be used when advertising the
  deterministic network elements to a control plane. The work will be
  independent from the protocol(s) that may be used to advertise this
  information (e.g. IS-IS or GMPLS extensions). Any YANG work will be
  coordinated with the working groups that define the base models.
  THIS SECTION NEEDS CLARFIFICATION, BUT I NEED TO SPEAK TO BARBARA FIRST

The WG will coordinate with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, LIME, and 6TisSCH. As
the work progresses, requirements may be provided to the responsible
Working Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal
point to maintain the consistency of the overall architecture. The WG
will liaise with appropriate groups in IEEE and other Standards
Development Organizations (SDOs), specifically IEEE802.1 TSN.

[Ballot comment]
Either there is a word missing here or there is an extraneous "that":

As part of the overall
architecture work, the working group will document which deployment
environments and types of topologies that are within (or outside) the
scope of the DetNet architecture.

[Ballot comment]
I have no objection to chartering this working group.

I agree with Barry's suggested text tweak. If Alvaro's suggestion about problem statement, etc. is accepted, that would be fine with me.

I have one question, just for my own background.

I'm remembering that early in the charter discussions people thought someone would need to define a new DSCP for packets that should be buffered, if they arrive too early. Is that still a possibility? Perhaps the working group would need to figure that out after being chartered, but I thought I'd ask if this is already known.

[Ballot comment]
The list of chartered work includes "As needed, problem statement…[and]…vertical requirements.”

I thought those items/documents were discussed at the BoF and were really the basis for knowing what the WG would work on.  IOW, I don’t think the WG should be chartered to produce problem statement and requirements documents.  I liked a lot more the text from the BoF [1] that called them WG sustaining documents and said: "These documents will not necessarily be published, but may be maintained in a draft form or on a collaborative Working Group wiki to support the efforts of the Working Group and help new comers”.

[1] http://trac.tools.ietf.org/bof/trac/wiki/DetNet

[Ballot comment]
A fine charter.  I have only one editorial comment.
I find the end of the first sentence hard to read, which gets things off to a confusing start:

    The Deterministic Networking (DetNet) Working Group will focus
    on deterministic data paths that operate over Layer 2 Bridged and
    Layer 3 routed segments, where such paths can provide bounded
    latency, loss and packet delay variation (jitter).

It's not immediately clear whether "bounded" applies only to latency or to the whole list, and the missing serial comma muddies things more.  One can certainly figure it out well enough, but we shouldn't make readers work that hard.  I suggest this:

NEW
    The Deterministic Networking (DetNet) Working Group will focus
    on deterministic data paths that operate over Layer 2 bridged and
    Layer 3 routed segments, where such paths can provide bounds on
    latency, loss, and packet delay variation (jitter).
END

[Ballot comment]
A fine charter.  I have only one editorial comment.
I find the end of the first sentence hard to read, which gets things off to a confusing start:

    The Deterministic Networking (DetNet) Working Group will focus on
    deterministic data paths that operate over Layer 2 Bridged and Layer 3
    routed segments, where such paths can provide bounded latency, loss and
    packet delay variation (jitter).

It's not immediately clear whether "bounded" applies only to latency or to the whole list, and the missing serial comma muddies things more.  One can certainly figure it out well enough, but we shouldn't make readers work that hard.  I suggest this:

NEW
    The Deterministic Networking (DetNet) Working Group will focus on
    deterministic data paths that operate over Layer 2 bridged and Layer 3
    routed segments, where such paths can provide bounds on latency, loss,
    and packet delay variation (jitter).
END