Subject: [Detnet] proposed revised Charter

From: Janos Farkas <[email-masked]>
Date: Fri, 6 Mar 2020 14:29:31 +0000

WG,

As discussed at the last IETF, it is time for us to update our charter. We have put together the following proposal:

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 bounds on latency, loss,
and packet delay variation (jitter), and high reliability. The Working
Group addresses Layer 3 aspects in support of applications requiring
deterministic networking. The Working Group collaborates with the IEEE
802.1 Time-Sensitive Networking (TSN) Task Group, which is responsible
for Layer 2 operations, to ensure an aligned architecture for both Layer
2 and Layer 3. Example applications for deterministic networks include
professional and home audio/video, multimedia in transportation, engine
control systems, and industrial automation, as well as other general
industrial and vehicular applications being considered by the IEEE 802.1
TSN Task Group.

The Working Group will initially focus on solutions for networks that
are under a single administrative control or within a closed group of
administrative control; these include not only campus-wide networks but
also can include private WANs. The DetNet WG will not address solutions
for large groups of domains such as the Internet.

The Working Group is responsible for the overall DetNet architecture and
DetNet-specific specifications that encompasses the data plane, OAM
(Operations, Administration, and Maintenance), time synchronization,
management, control, and security aspects which are required to enable a
multi-hop path, and forwarding along the path, with the deterministic
properties of controlled latency, low packet loss, low packet delay
variation, and high reliability. The work applies to point-to-point
(unicast) and point-to-multipoint (multicast) flows which 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. Layer 3 data plane technologies that
can be used include: IP and MPLS, and Layer 2 encapsulations that run
over IP and/or MPLS, such as pseudowires and GRE.

The Working Group will document which deployment environments and types
of topologies are within (or outside) the scope of the DetNet
architecture. This work focuses on the data plane aspects and is
independent from any path setup protocol or mechanism. The working group
will also document DetNet Controller Plane [1] approaches that reuse
existing IETF solutions, such as Path Computation Element (PCE), and
identify the appropriate Working Group for any extensions needed to
support DetNet. Documents produced by the Working Group will be
compatible with the work done in IEEE802.1 TSN and other IETF Working
Groups.  The Working Group's scope explicitly excludes modifications of
transport protocols, OAM, Layer 3 forwarding, encapsulations, and
control plane protocols, but it may define requirements for such
modifications and identify the appropriate Working Group for any needed
modifications.

DetNet is chartered to work in the following areas:

Overall architecture: This work encompasses the data plane, OAM, time
synchronization, management, control, and security aspects.

Data plane: This work will document how to use IP and/or MPLS 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.

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.

Data flow information model: This work will identify the information
needed for flow establishment and control and be used by reservation
protocols and 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).

YANG models: 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. Control plane related information will be independent from the
protocol(s) which may be used to advertise this information (e.g. IS-IS
or GMPLS extensions). Any new YANG models will be coordinated with the
Working Groups that define any base models that are to be augmented.

As needed, vertical requirements: This effort will detail the
requirements for deterministic networks in various industries that have
previously not been documented or cannot be supported using defined
DetNet solutions.

To investigate whether existing data plane encryption mechanisms can be
applied, possibly opportunistically, to improve security and privacy.

The Working Group coordinates with other relevant IETF Working Groups,
including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, RAW, 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
and related solutions. The WG will liaise with appropriate groups in
IEEE and other Standards Development Organizations (SDOs).

[1] The DetNet Controller Plane is defined in RFC 8655 as "the
aggregation of the Control and Management Planes"

The difference compared to the current charter is available at:
https://etherpad.ietf.org:9009/p/detnet-recharter

Our plan is to submit revised charter to the IESG after IETF 107. Given the number of remote participants, we are happy to have the discussion fully on the list.

Please submit your comments on the list.

Regards,
Lou and Janos

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 6 Mar 2020 11:15:28 -0500

Lou and Janos,

It looks good to me, especially the sections regarding the controller plane.

Cheers,
Andy

On Fri, Mar 6, 2020 at 9:29 AM Janos Farkas <Janos.Farkas=
[email-masked]> wrote:

> WG,
>
>
>
> As discussed at the last IETF, it is time for us to update our charter. We
> have put together the following proposal:
>
>
>
> for any needed extensions..
>
>
>
> Our plan is to submit revised charter to the IESG after IETF 107. Given
> the number of remote participants, we are happy to have the discussion
> fully on the list.
>
>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Sat, 7 Mar 2020 01:08:47 +0000

Hi Lou and Janos,
This looks good to me also, though I have a question about the phrase “vertical requirements… this effort will detail the requirements for deterministic networks in various industries that have previously not been documented”.
The last time someone brought up a “new industry use case that had not been documented for DetNet”, our response (perhaps just my personal response, but I understood it to represented the WG) was that we understand and expect there to be new use cases for DetNet as time goes on, but that as long as they were satisfied by the existing documented DetNet common properties (for example as outlined in the Use Cases draft Common Themes section) it wasn’t particularly necessary to document each new use case in a DetNet-authored RFC.
So I can read the proposed text above in two ways, either “if you have a new use case, it our charter to document it” or, alternatively, “if a newly proposed use case implies addition of some new property/requirement that DetNet has not already taken into account and considered (e.g. as enumerated in the Use Case Common Themes), we will address the missing property/requirement by either incorporating it into DetNet, or by declaring that it is not supported by DetNet”.
So my point is, which of these interpretations is the authors’ intent there?  And if it is the latter, do we feel that the existing text makes this unambiguously clear? (Just because I read it in that ambiguous way doesn’t mean others do).
All in all, nice work.
Ethan (as WG member)

From: Andrew G. Malis <[email-masked]>
Sent: Friday, March 6, 2020 8:15 AM
To: Janos Farkas <Janos.Farkas=[email-masked]>
Cc: DetNet WG <[email-masked]>; DetNet Chairs <[email-masked]>
Subject: Re: [Detnet] proposed revised Charter

Lou and Janos,

Cheers,
Andy

On Fri, Mar 6, 2020 at 9:29 AM Janos Farkas <Janos.Farkas=[email-masked]<mailto:[email-masked]>> wrote:
WG,

The difference compared to the current charter is available at:
https://etherpad.ietf.org:9009/p/detnet-recharter<https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.ietf.org-3A9009_p_detnet-2Drecharter&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bXn6vVroSgf2XRzk9bbkPawRx-z8QWyiPikWlcNw03o&s=abcfl7uanOC0v5Tl0RbYDVW0Bcxiqon9CNlwHMfy_LQ&e=>

Regards,
Lou and Janos
_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bXn6vVroSgf2XRzk9bbkPawRx-z8QWyiPikWlcNw03o&s=FVUOpSHy-OwCaMUnZzTxacV7Zyc8eL4gBqbSrrTchxo&e=>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 7 Mar 2020 07:45:10 +0000

All great for me too.

Please note the typo in 6TiSCH ...

Regards,

Pascal

Le 7 mars 2020 à 02:09, Grossman, Ethan A. <[email-masked]> a écrit :

Hi Lou and Janos,

Lou and Janos,

Cheers,
Andy

Regards,
Lou and Janos

---

From: Balázs Varga A <[email-masked]>
Date: Sat, 7 Mar 2020 13:55:44 +0000

Great. It looks good to me.
Cheers
Bala’zs

From: detnet <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Saturday, March 7, 2020 8:45 AM
To: Grossman, Ethan A. <[email-masked]>
Cc: DetNet WG <[email-masked]>; DetNet Chairs <[email-masked]>
Subject: Re: [Detnet] proposed revised Charter

All great for me too.

Regards,

Pascal

Le 7 mars 2020 à 02:09, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Lou and Janos,

From: Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Sent: Friday, March 6, 2020 8:15 AM
To: Janos Farkas <Janos.Farkas=[email-masked]<mailto:Janos.Farkas=[email-masked]>>
Cc: DetNet WG <[email-masked]<mailto:[email-masked]>>; DetNet Chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] proposed revised Charter

Lou and Janos,

Cheers,
Andy

Regards,
Lou and Janos

---

From: Lou Berger <[email-masked]>
Date: Sat, 7 Mar 2020 09:19:01 -0500

Hi Ethan,

Thanks for the feedback.  See in-line below.

On 3/6/2020 8:08 PM, Grossman, Ethan A. wrote:
>
> Hi Lou and Janos,
>
> This looks good to me also, though I have a question about the phrase 
> “vertical requirements… this effort will detail the requirements for 
> deterministic networks in various industries that have previously not 
> been documented”.
>
For context, We tried to minimize changes to the current charter, i.e., 
change only what really needed to be changed/updated.

The related text in the original/current charter states:
     As needed, vertical requirements: This effort will detail the
     requirements for deterministic networks in various industries
     for example, professional audio, electrical utilities, building
     automation systems, wireless for industrial applications.

We left the first two lines alone, but replaced the second two with:
     that have previously not been documented or cannot be
     supported using defined DetNet solutions.

> The last time someone brought up a “new industry use case that had not 
> been documented for DetNet”, our response (perhaps just my personal 
> response, but I understood it to represented the WG) was that we 
> understand and expect there to be new use cases for DetNet as time 
> goes on, but that as long as they were satisfied by the existing 
> documented DetNet common properties (for example as outlined in the 
> Use Cases draft Common Themes section) it wasn’t particularly 
> necessary to document each new use case in a DetNet-authored RFC.
>
This was my read as well.
>
> So I can read the proposed text above in two ways, either “if you have 
> a new use case, it our charter to document it” or, alternatively, “if 
> a newly proposed use case implies addition of some new 
> property/requirement that DetNet has not already taken into account 
> and considered (e.g. as enumerated in the Use Case Common Themes), we 
> will address the missing property/requirement by either incorporating 
> it into DetNet, or by declaring that it is not supported by DetNet”.
>
I think this really comes down to if the word "or" in the lines should 
be an "and".

> So my point is, which of these interpretations is the authors’ intent 
> there?  And if it is the latter, do we feel that the existing text 
> makes this unambiguously clear? (Just because I read it in that 
> ambiguous way doesn’t mean others do).
>
While the ambiguity was not intentional, I now like the "or" as it 
explicitly allows the WG to document how future use cases can be 
supported using defined DetNet solutions.  This said, I personally don't 
object to changing it to an "and" if this is the WG's (or IESG's) 
preference.

Lou

> All in all, nice work.
>
> Ethan (as WG member)
>
> *From:* Andrew G. Malis <[email-masked]>
> *Sent:* Friday, March 6, 2020 8:15 AM
> *To:* Janos Farkas <Janos.Farkas=[email-masked]>
> *Cc:* DetNet WG <[email-masked]>; DetNet Chairs <[email-masked]>
> *Subject:* Re: [Detnet] proposed revised Charter
>
> Lou and Janos,
>
> On Fri, Mar 6, 2020 at 9:29 AM Janos Farkas 
> <Janos.Farkas=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     WG,
>
>     As discussed at the last IETF, it is time for us to update our
>     charter. We have put together the following proposal:
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.ietf.org-3A9009_p_detnet-2Drecharter&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bXn6vVroSgf2XRzk9bbkPawRx-z8QWyiPikWlcNw03o&s=abcfl7uanOC0v5Tl0RbYDVW0Bcxiqon9CNlwHMfy_LQ&e=>
>
>
>     Our plan is to submit revised charter to the IESG after IETF 107.
>     Given the number of remote participants, we are happy to have the
>     discussion fully on the list.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=bXn6vVroSgf2XRzk9bbkPawRx-z8QWyiPikWlcNw03o&s=FVUOpSHy-OwCaMUnZzTxacV7Zyc8eL4gBqbSrrTchxo&e=>
>
>

---

From: Lou Berger <[email-masked]>
Date: Sat, 7 Mar 2020 09:22:08 -0500

> Please note the typo in 6TiSCH ...
Thanks and fixed!

Lou

>> The last time someone brought up a “new industry use case that had 
>> not been documented for DetNet”, our response (perhaps just my 
>> personal response, but I understood it to represented the WG) was 
>> that we understand and expect there to be new use cases for DetNet as 
>> time goes on, but that as long as they were satisfied by the existing 
>> So I can read the proposed text above in two ways, either “if you 
>> have a new use case, it our charter to document it” or, 
>> alternatively, “if a newly proposed use case implies addition of some 
>> new property/requirement that DetNet has not already taken into 
>> account and considered (e.g. as enumerated in the Use Case Common 
>> Themes), we will address the missing property/requirement by either 
>> incorporating it into DetNet, or by declaring that it is not 
>> supported by DetNet”.
>>
>>     that have

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 8 Mar 2020 15:12:03 +0100

Hi Janos and Lou,
thank you for your diligent work on preparing to update the charter. I have
a question related to my favorite topic of OAM and what is the scope of
work the DetNet WG will do compared to the work expected to be done in
other groups. On the one hand, the proposed text states:

The Working Group is responsible for the overall DetNet architecture and
DetNet-specific specifications that encompasses the data plane,
OAM(Operations, Administration, and Maintenance) ...

But on the other, I find it is followed by this statement:

 The Working Group's scope explicitly excludes modifications of transport
protocols, OAM ...

If I take an example of the DetNet over MPLS data plane, in my opinion,
DetNet OAM needs some LSP ping extensions to support PREOF. Would work on
these extensions be considered "a  DetNet-specific specification" or "a
modification of OAM"?

I greatly appreciate you sharing your opinions, perhaps giving examples to
illustrate the former and the latter statements.

Best regards,
Greg

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Tue, 10 Mar 2020 03:11:38 +0000

Hi,

Thank for you updating the charter, and it looks good for me.
However, I'm a little confused about the controller plane work for DetNet in the revised charter:

1.        "The working group will also document DetNet Controller Plane [1] approaches that reuse existing IETF solutions, such as Path Computation Element (PCE), and identify the appropriate Working Group for any extensions needed to support DetNet"
It seems to me that protocol extensions are supposed to be done in DetNet.

2.       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.
This part seems to show the opposite conclusion: only protocol gaps are covered by DetNet.
The question behind this is: what is the new expected output based on the updated charter besides the current draft : "draft-malis-detnet-controller-plane-framework-03"? It is a little unclear for me.

Best Regards
Xuesong

From: detnet [mailto:[email-masked]] On Behalf Of Janos Farkas
Sent: Friday, March 6, 2020 10:30 PM
To: DetNet WG <[email-masked]>
Cc: DetNet Chairs <[email-masked]>
Subject: [Detnet] proposed revised Charter

WG,

Regards,
Lou and Janos

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 10 Mar 2020 03:47:57 +0000

Hi Lou,
Somehow I’m missing something in your reply about “and” vs “or”.
The current text says:
“This effort will detail the requirements for deterministic networks in various industries that have previously not been documented or cannot be supported using defined DetNet solutions.”
That is the only “or” that I see in that paragraph, but if you change that to an “and” it really makes no sense (as far as I can see).

Anyway I’m willing to just leave it as it is, as long as your read of it is as you said (“This was my read as well”).
Ethan.

From: Lou Berger <[email-masked]>
Sent: Saturday, March 7, 2020 6:19 AM
To: Grossman, Ethan A. <[email-masked]>; DetNet Chairs <[email-masked]>
Cc: DetNet WG <[email-masked]>
Subject: Re: [Detnet] proposed revised Charter

Hi Ethan,

Thanks for the feedback.  See in-line below.
On 3/6/2020 8:08 PM, Grossman, Ethan A. wrote:
Hi Lou and Janos,
This looks good to me also, though I have a question about the phrase “vertical requirements… this effort will detail the requirements for deterministic networks in various industries that have previously not been documented”.
For context, We tried to minimize changes to the current charter, i.e., change only what really needed to be changed/updated.

I think this really comes down to if the word "or" in the lines should be an "and".
So my point is, which of these interpretations is the authors’ intent there?  And if it is the latter, do we feel that the existing text makes this unambiguously clear? (Just because I read it in that ambiguous way doesn’t mean others do).

While the ambiguity was not intentional, I now like the "or" as it explicitly allows the WG to document how future use cases can be supported using defined DetNet solutions.  This said, I personally don't object to changing it to an "and" if this is the WG's (or IESG's) preference.

Lou
All in all, nice work.
Ethan (as WG member)

From: Andrew G. Malis <[email-masked]><mailto:[email-masked]>
Sent: Friday, March 6, 2020 8:15 AM
To: Janos Farkas <Janos.Farkas=[email-masked]><mailto:Janos.Farkas=[email-masked]>
Cc: DetNet WG <[email-masked]><mailto:[email-masked]>; DetNet Chairs <[email-masked]><mailto:[email-masked]>
Subject: Re: [Detnet] proposed revised Charter

Lou and Janos,

Cheers,
Andy

Regards,
Lou and Janos

detnet mailing list

https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMDaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=nIsdMgvhTfZgD5Cv4hp8fzUouF48528Lx19ORHiebek&s=Y7nslmHAuY1weQsaZgJlNykgsVN4rCUqXhsVX-lrZKU&e=>

---

From: Lou Berger <[email-masked]>
Date: Wed, 18 Mar 2020 08:23:57 -0400

All,

     Based on the feedback received to-date, we plan to submit the 
latest text of the revised charter to our AD on Friday.  Please comment 
before then if you'd like to see the comment addressed before 
submission. (See
https://etherpad.ietf.org:9009/p/detnet-recharter for latest rev).

Thank you,

Janos and Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 18 Mar 2020 08:15:51 -0400

Hi Greg,

     (catching up on email...)

On 3/8/2020 10:12 AM, Greg Mirsky wrote:
> Hi Janos and Lou,
> thank you for your diligent work on preparing to update the charter. I 
> have a question related to my favorite topic of OAM and what is the 
> scope of work the DetNet WG will do compared to the work expected to 
> be done in other groups. On the one hand, the proposed text states:
>
>     The Working Group is responsible for the overall DetNet
>     architecture and DetNet-specific specifications that encompasses
>     the data plane, OAM(Operations, Administration, and Maintenance) ...
>
>      The Working Group's scope explicitly excludes modifications of
>     transport protocols, OAM ...
>
> If I take an example of the DetNet over MPLS data plane, in my 
> opinion, DetNet OAM needs some LSP ping extensions to support PREOF. 
> Would work on these extensions be considered "a DetNet-specific 
> specification" or "a modification of OAM"?
>
It's hard to say without seeing a specific proposal.  I suggest that we 
discuss this once there is a specific required modification identified 
and then we can discuss in that context, and coordinate with the WG that 
defined the base technology.

> I greatly appreciate you sharing your opinions, perhaps giving 
> examples to illustrate the former and the latter statements.
>
Thanks,

Lou (and Janos)

> Best regards,
> Greg
>
>
>
> On Fri, Mar 6, 2020 at 3:29 PM Janos Farkas 
>     deterministic networking.. The Working Group collaborates with the
>     IEEE
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Mar 2020 15:53:15 +0000

Hi Lou,

Looking at the revised charter text through an OAM lens, I see:

DetNet OAM is going to be done in the detnet WG, not elsewhere, so that prohibition of "modifications of ... OAM" appears excessive, as work will almost certainly be required to adapt existing OAM protocols to DetNet.  I understand what was intended, see below ...

I also don't see OAM listed as a work area for the WG ... so ... I'm going to return Greg's favor ;-) of convincing me to work on DetNet IP OAM by suggesting that Greg write a short paragraph on an OAM area of work to include in the revised detnet WG charter.  I suggest removing OAM from the above "excludes modifications of" list in favor of that new OAM work area description text explaining that OAM protocol modifications are out of scope beyond adaptation of existing OAM protocols to DetNet.

OK?

Thanks, --David

> -----Original Message-----
> From: detnet <[email-masked]> On Behalf Of Lou Berger
> Sent: Wednesday, March 18, 2020 8:24 AM
> To: Janos Farkas; DetNet WG
> Cc: DetNet Chairs
> [EXTERNAL EMAIL]

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Mar 2020 07:21:01 -0400

Hi david,

On 3/18/2020 11:53 AM, Black, David wrote:
> I also don't see OAM listed as a work area for the WG

It currently says:

The Working Groupwill specify an_is responsible for 
the_overall_DetNet_architecture_and_
_DetNet-specific specifications_that encompasses the data plane, OAM
(Operations, Administration, and Maintenance), time synchronization,
management, control, and security aspects which are required to enable a
multi-hop path, and forwarding along the path, with the deterministic
properties of controlled latency, low packet loss, low packet delay
variation, and high reliability.

(hopefully the redline formatting cam through from 
https://etherpad.ietf.org:9009/p/detnet-recharter) 
<https://etherpad.ietf.org:9009/p/detnet-recharter>
> ... so ... I'm going to return Greg's favor ;-) of convincing me to work on DetNet IP OAM by suggesting that Greg write a short paragraph on an OAM area of work to include in the revised detnet WG charter.

I suggest the following changes add ", and related OAM," after "and/or 
MPLS" in the data plane paragraph

> I suggest removing OAM from the above "excludes modifications of" list in favor of that new OAM work area description text explaining that OAM protocol modifications are out of scope beyond adaptation of existing OAM protocols to DetNet.

This text came from the IESG during initial chartering.  I still think 
the IESG is going to continue to require the WG to check with the owners 
of the data plane before we are allowed make changes in DetNet.  I'll 
check with our AD on her opinion if we can drop "OAM" from this paragraph.

Thanks for the comments!

Lou

---

From: "Black, David" <[email-masked]>
Date: Thu, 19 Mar 2020 12:57:09 +0000

Addition of “related OAM” to data plane paragraph definitely helps.  That should suffice.

Thanks, --David

From: detnet <[email-masked]> On Behalf Of Lou Berger
Sent: Thursday, March 19, 2020 7:21 AM
To: Black, David; DetNet WG
Cc: DetNet Chairs
Subject: Re: [Detnet] proposed revised Charter

[EXTERNAL EMAIL]

Hi david,

Hi Lou,

modifications.

It currently says:
The Working Group will specify an is responsible for the overall DetNet architecture and

(hopefully the redline formatting cam through from  https://etherpad.ietf.org:9009/p/detnet-recharter)<https://etherpad.ietf.org:9009/p/detnet-recharter>

I suggest the following changes add ", and related OAM," after "and/or MPLS" in the data plane paragraph

This text came from the IESG during initial chartering.  I still think the IESG is going to continue to require the WG to check with the owners of the data plane before we are allowed make changes in DetNet.  I'll check with our AD on her opinion if we can drop "OAM" from this paragraph.

Thanks for the comments!

Lou

OK?

Thanks, --David

-----Original Message-----

From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger

Cc: DetNet Chairs

[EXTERNAL EMAIL]

All,

submission. (See

Thank you,

Janos and Lou

WG,

TSN Task Group.

modifications.

or GMPLS).

DetNet solutions.

Regards,

Lou and Janos

detnet mailing list

detnet mailing list

detnet mailing list

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Mar 2020 09:42:56 -0400

Thanks David!

On 3/19/2020 8:57 AM, Black, David wrote:
> *From:*detnet <[email-masked]> *On Behalf Of *Lou Berger
> *Sent:* Thursday, March 19, 2020 7:21 AM
> *To:* Black, David; DetNet WG
> *Cc:* DetNet Chairs
> The Working Group will specify an _is responsible for the _overall 
> _DetNet _architecture _and_
>
> _DetNet-specific specifications _that encompasses the data plane, OAM
>
> the IESG is going to continue to require the WG to check with the 
> owners of the data plane before we are allowed make changes in 
> DetNet.  I'll check with our AD on her opinion if we can drop "OAM" 
> from this paragraph.
>
> Thanks for the comments!
>
> Lou
>
>     OK?
>
>     Thanks, --David
>
>         From: detnet<[email-masked]>  <mailto:[email-masked]>  On Behalf Of Lou Berger
>