Re: [Detnet] draft-ietf-detnet-ip-02.txt - ECN changes

["Black, David" <[e-mail]>]

This seems to be mostly about which field appears in the 5.1.1.4 section title and hence the table of contents.    To retain that section title, the following change would make it clear that only the DSCP field is involved:

OLD
5.1.1.4.  IPv4 Type of Service and IPv6 Traffic Class Fields

   These fields are used to support Differentiated Services [RFC2474].
   Implementations of this document MUST support DetNet flow
   identification based on the IPv4 Type of Service field when
   processing IPv4 packets, and the IPv6 Traffic Class Field when
   processing IPv6 packets.  Implementations MUST support list based
   matching of DSCP values, where the list is composed of possible field
   values that are to be considered when identifying a specific DetNet
   flow.  Implementations SHOULD allow for this field to be ignored for
   a specific DetNet flow.
NEW
5.1.1.4.  IPv4 Type of Service and IPv6 Traffic Class Fields

   The DSCP field in these fields is used to support Differentiated Services [RFC2474][RFC2475].
   Implementations of this document MUST support DetNet flow
   identification based on the DSCP field in the IPv4 Type of Service field when
   processing IPv4 packets, and the DSCP field in the IPv6 Traffic Class Field when
   processing IPv6 packets.  Implementations MUST support list based
   matching of DSCP values, where the list is composed of possible field
   values that are to be considered when identifying a specific DetNet
   flow.  Implementations SHOULD allow for this field to be ignored for
   a specific DetNet flow.

I also added a citation of RFC 2475 (DiffServ Architecture) in the new text above, as that RFC is more useful than RFC 2474 for understanding Diffserv in general.  RFC 2475 would also need to be added to the list of Informative References.

Thanks, --David

From: Lou Berger <[e-mail]>
Sent: Wednesday, October 23, 2019 7:31 AM
To: Black, David; [e-mail]
Cc: [e-mail]
Subject: Re: [Detnet] draft-ietf-detnet-ip-02.txt - ECN changes


[EXTERNAL EMAIL]

Hi David,

I agree that the changes you mentioned are really editorial and it don't change anything from the implementation standpoint. But given that rfc791 is still in force, albeit updated by rfc2474, and it mentions the type of service field and we are saying that detnet operates on the IP header - I personally think it appropriate to continue to mentioned the field name defined in rfc 791. I think this will be particularly helpful for those who learn about IP through DetNet.

Lou

________________________________

On October 22, 2019 1:43:51 PM "Black, David" <[e-mail]<mailto:[e-mail]>> wrote:
Two more suggested edits to clean up the IPv4 and IPv6 header field text to focus on the DSCP field:

--- [1] Section 5.1.1.4

OLD
5.1.1.4.  IPv4 Type of Service and IPv6 Traffic Class Fields

   These fields are used to support Differentiated Services [RFC2474].
   Implementations of this document MUST support DetNet flow
   identification based on the IPv4 Type of Service field when
   processing IPv4 packets, and the IPv6 Traffic Class Field when
   processing IPv6 packets.  Implementations MUST support list based
   matching of DSCP values, where the list is composed of possible field
   values that are to be considered when identifying a specific DetNet
   flow.  Implementations SHOULD allow for this field to be ignored for
   a specific DetNet flow.

NEW
5.1.1.4.  Differentiated Services Codepoint (DSCP) Field

   This field in the IPv4 Type of Service Field and the IPv6 Traffic
   Class Field is used to support Differentiated Services [RFC2474].
   Implementations of this document MUST support DetNet flow
   identification based on the DSCP field of an IP packet.
   Implementations MUST support list based
   matching of DSCP values, where the list is composed of possible field
   values that are to be considered when identifying a specific DetNet
   flow.  Implementations SHOULD allow for this field to be ignored for
   a specific DetNet flow.

--- [2] Section 6

OLD
   o  For the IPv4 Type of Service and IPv6 Traffic Class Fields:

      *  If the DSCP field is to be used in flow identification.
         Ignoring the DSCP filed is optional.

      *  When the DSCP field is used in flow identification, a list of
         field values that may be used by a specific flow.

NEW
   o  For the IPv4 and IPv6 DSCP field:

      *  If the DSCP field is to be used in flow identification,
         ignoring the DSCP field is optional.

      *  When the DSCP field is used in flow identification, a list of
         field values that may be used by a specific flow.


Thanks, --David

From: Lou Berger <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 22, 2019 9:00 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Black, David; [e-mail]<mailto:[e-mail]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN


[EXTERNAL EMAIL]

Hi,

Here are the proposed changes to support dropping references to ECN:

Any objections?

1) deltas

https://github.com/detnet-wg/data-plane-drafts/compare/working/lb/drop-ecn

2) formatted draft
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/detnet-wg/data-plane-drafts/working/lb/drop-ecn/ip/draft-ietf-detnet-ip.xml

3) git diff format:

diff --git a/ip/draft-ietf-detnet-ip.xml b/ip/draft-ietf-detnet-ip.xml
index 086fe6f..dcb022b 100644
--- a/ip/draft-ietf-detnet-ip.xml
+++ b/ip/draft-ietf-detnet-ip.xml
@@ -163,7 +163,6 @@
             <t hangText="DN">DetNet.</t>
             <t hangText="DiffServ">Differentiated Services</t>
             <t hangText="DSCP">Differentiated Services Code Point</t>
-            <t hangText="ECN">Explicit Congestion Notification.</t>
             <t hangText="L2">Layer-2.</t>
             <t hangText="L3">Layer-3.</t>
             <t hangText="LSP">Label-switched path.</t>
@@ -237,9 +236,8 @@
         identification.
       </t>
       <t>
-        The DetNet IP data plane also allows for optional matching on two
-        additional data fields.  The optional fields are the ECN Field,
-        as in <xref target="RFC3168"/>, and the IPv6 flow label field,
+        The DetNet IP data plane also allows for optional matching on
+        the IPv6 flow label field,
         as defined in <xref target="RFC8200"/>.
       </t>
       <t>
@@ -542,9 +540,7 @@ DetNet                    |L2/SbN|          |L2/SbN|
         <t>
           Class of Service (CoS) for DetNet flows carried in IPv6 is provided using the standard
           differentiated services code point (DSCP) field <xref
-          target="RFC2474"/> and related mechanisms.  The 2-bit explicit
-          congestion notification (ECN) <xref target="RFC3168"/> field MAY
-          also be used.
+          target="RFC2474"/> and related mechanisms.
         </t>
         <t>
           One additional consideration for DetNet nodes which support CoS
@@ -565,7 +561,7 @@ DetNet                    |L2/SbN|          |L2/SbN|
           IP encapsulated DetNet flows are expected to be defined in a future
           document.  From an encapsulation perspective, the combination of the 6-tuple i.e.,
           the typical 5-tuple enhanced with the DSCP and previously
-          mentioned two optional fields, uniquely identifies a DetNet
+          mentioned optional field, uniquely identifies a DetNet
           service flow.
         </t>
         <t>
@@ -594,8 +590,8 @@ DetNet                    |L2/SbN|          |L2/SbN|
           highlight the implications of DetNet IP flow identification on
           path selection and next hops.  As mentioned above, the DetNet
           IP data plane identifies flows using "6-tuple" header
-          information as well as two additional optional header
-          fields. DetNet generally allows for both flow-specific traffic
+          information as well as the additional optional header
+          field. DetNet generally allows for both flow-specific traffic
           treatment and flow-specific next-hops.
         </t>
         <t>
@@ -643,7 +639,7 @@ DetNet                    |L2/SbN|          |L2/SbN|
           impacts DetNet IP data plane flow identification and resource
           allocation.  As discussed above, IP flow identification uses
           the IP "6-tuple" for flow identification.  DetNet IP flows can
-          be aggregated using any of the 6-tuple, or two additional optional fields defined in <xref
+          be aggregated using any of the 6-tuple, and an additional optional field defined in <xref
           target="ip-flow-id"/>.  The use of prefixes, wildcards,
           lists, and value ranges allows a DetNet node to identify
           aggregate DetNet flows.  From a resource allocation
@@ -786,8 +782,7 @@ DetNet                    |L2/SbN|          |L2/SbN|
           <section title="IPv4 Type of Service and IPv6 Traffic Class Fields">
             <t>
               These fields are used to support Differentiated Services
-              <xref target="RFC2474"/> and Explicit Congestion
-              Notification <xref target="RFC3168"/>.  Implementations of
+              <xref target="RFC2474"/>.  Implementations of
               this document MUST support DetNet flow identification
               based on the IPv4 Type of Service field when processing
               IPv4 packets, and the IPv6 Traffic Class Field when
@@ -798,15 +793,6 @@ DetNet                    |L2/SbN|          |L2/SbN|
               SHOULD allow for this field to be ignored for a specific
               DetNet flow.
             </t>
-            <t>
-              Implementations of this document MUST allow the ECN field
-              to be ignored as part of DetNet flow identification.
-              Additionally, implementations SHOULD support
-              identification of DetNet flows based on the value carried
-              in the ECN field.  When this field is used to identify a
-              specific DetNet flow, implementations MUST support a list
-              of ECN values that match a specific slow.
-            </t>
           </section>
           <section title="IPv6 Flow Label Field">
             <t>
@@ -945,10 +931,6 @@ DetNet                    |L2/SbN|          |L2/SbN|
                 identification. Ignoring the DSCP filed is optional.</t>
                 <t>When the DSCP field is used in flow identification, a
                 list of field values that may be used by a specific flow.</t>
-                <t>If the ECN field is to be used in flow
-                identification. Matching based on ECN filed values is optional.</t>
-                <t>When ECN field is used in flow identification, a
-                list of field values that may be used by a specific flow.</t>
               </list></t>
               <t>IPv6 flow label field. This field can be optionally used
               for matching.  When used, can be exclusive of matching
@@ -957,7 +939,7 @@ DetNet                    |L2/SbN|          |L2/SbN|
               required. Port ranges can optionally be used.</t>
               <t>TCP and UDP Destination Port. Exact and wildcard matching is
               required. Port ranges can optionally be used.</t>
-                          <t>IPsec Header SPI field. Exact matching is
+              <t>IPsec Header SPI field. Exact matching is
               required. </t>
             </list>
             This information MUST be provisioned per DetNet flow via
@@ -1058,7 +1040,6 @@ DetNet                    |L2/SbN|          |L2/SbN|
       <?rfc include="reference.RFC.1812"?>
       <?rfc include="reference.RFC.2119"?>
       <?rfc include="reference.RFC.2474"?>
-      <?rfc include="reference.RFC.3168"?>
       <?rfc include="reference.RFC.3473"?>
       <?rfc include="reference.RFC.4301"?>
       <?rfc include="reference.RFC.4302"?>

Lou
On 10/22/2019 8:19 AM, Stewart Bryant wrote:

The main flow identifiers will be SA+DA+SP+DP (sure there is type but there are only a couple of values used in practice)

You would only really use the DSCP bits to select a subgroup of the packets within a flow for special treatment.

It seems unlikely that you would select more than a tiny number of elements within the flow for special treatment on the basis for the DSCP bits, where tiny is likely to be one.

So it seems unlikely that there is any scaling impact.

- Stewart
On 22/10/2019 01:53, Grossman, Ethan A. wrote:
Does losing control over those two bits (ECN) adversely affect the upward scalability of the system in any meaningful way? I mean, can one think of it like “this reduces the number of flows that can be identified by a factor of 4”?  Does anyone working on “Large Scale DetNet” have any thoughts on this?
Thanks,
Ethan.

From: detnet <[e-mail]><mailto:[e-mail]> On Behalf Of Andrew G. Malis
Sent: Monday, October 21, 2019 6:29 AM
To: Stewart Bryant <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Lou Berger <[e-mail]><mailto:[e-mail]>; Black, David <[e-mail]><mailto:[e-mail]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN

I also don't have any objection to removing the ECN text.

Cheers,
Andy


On Mon, Oct 21, 2019 at 8:59 AM Stewart Bryant <[e-mail]<mailto:[e-mail]>> wrote:

Yes, let's delete the references to ECN from the text.

- Stewart
On 18/10/2019 22:57, Lou Berger wrote:

David,

    I'm personally okay with dropping all references to the ECN field.  But doing so is a change from previous discussions so is a WG call.

WG,

Are there any objections to removing the language related to the ECN field?

The implication is that the detnet IP standard will only cover the 6-bit DSCP field carried in what was once referred to as the 8-bit IP TOS Field.

Thanks,

Lou

(No hats)
On 10/16/2019 11:08 PM, Black, David wrote:

> While I understand you have concerns about a node providing different traffic treatment based on ECN markings on a local node, I believe this happens today –
> just look at the related config options for your favorite router vendor.  Can you live with SHOULD NOT vs MUST NOT?
I can live with removal of all mention of ECN from this draft.  I would suggest this course of action if the goal is to avoid “MUST NOT” wording.

Otherwise, I would need to be convinced that what the draft proposes to do/allow wrt ECN is consistent with RFC 3168.  The current text is not consistent with RFC 3168..

Thanks, --David

From: Lou Berger <[e-mail]><mailto:[e-mail]>
Sent: Wednesday, October 16, 2019 10:02 PM
To: Black, David; [e-mail]<mailto:[e-mail]>
Subject: Re: [Detnet] Fwd: draft-ietf-detnet-ip-02.txt - ECN


[EXTERNAL EMAIL]

sigh -I thought we went over all language in e-mail and over the phone.
On 10/16/2019 4:43 PM, Black, David wrote:
Forwarding to remove [e-mail]<mailto:[e-mail]> as a recipient.  Please respond to this email.

Thanks, --David ... Sent from my Android not-so-smartphone.


-------- Original message --------
From: "Black, David" <[e-mail]><mailto:[e-mail]>
Date: 10/16/19 3:13 PM (GMT-06:00)
To: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Subject: draft-ietf-detnet-ip-02.txt - ECN

The ECN material in this draft conflicts with RFC 3168 (a long-standing Proposed Standard).  I apologize to anyone who may have been under the impression that all ECN-related concerns were resolved in that call, as the text in this note did not come up during that call.

The TL;DR summary of my concerns is the rationale for change [3] below:

        Rationale: Use of ECN field for flow identification is not compatible with RFC 3168.

It was my understanding that your primary concern was split paths and this is what we covered in the language distributed on Monday.

While I understand you have concerns about a node providing different traffic treatment based on ECN markings on a local node, I believe this happens today -- just look at the related config options for your favorite router vendor.  Can you live with SHOULD NOT vs MUST NOT?

Thanks,

Lou



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

The following four changes will correct this problem:

[1] In Section 3.  DetNet IP Data Plane Overview

OLD
   The DetNet IP data plane also allows for optional matching on two
   additional data fields.  The optional fields are the ECN Field, as in
   [RFC3168], and the IPv6 flow label field, as defined in [RFC8200].
NEW
   The DetNet IP data plane also allows for optional matching on one
   additional data field, the IPv6 flow label field, as defined in [RFC8200].

Rationale: ECN field MUST NOT be used to subdivide a flow into sub-flows.  See RFC 3168.

[2] In  Section 4.3.1.  Class of Service

Remove this sentence:

   The 2-bit explicit congestion
   notification (ECN) [RFC3168] field MAY also be used.

Rationale: The ECN mechanism is not a Class of service mechanism.  See RFC 3168.

[3] In Section 5.1.1.4.  IPv4 Type of Service and IPv6 Traffic Class Fields

Remove this text:

   Implementations of this document MUST allow the ECN field to be
   ignored as part of DetNet flow identification.  Additionally,
   implementations SHOULD support identification of DetNet flows based
   on the value carried in the ECN field.  When this field is used to
   identify a specific DetNet flow, implementations MUST support a list
   of ECN values that match a specific slow.

If desired, replace it with:

   The ECN field MUST NOT be used as part of DetNet flow identification.

Rationale: Use of ECN field for flow identification is not compatible with RFC 3168.

[4] In Section 6.  Management and Control Information Summary

Remove these two bullets:

      *  If the ECN field is to be used in flow identification.
         Matching based on ECN filed values is optional.

      *  When ECN field is used in flow identification, a list of field
         values that may be used by a specific flow.

Rationale: Same as [3].

Thanks, --David

> -----Original Message-----
> From: I-D-Announce <[e-mail]><mailto:[e-mail]> On Behalf Of internet-
> [e-mail]<mailto:[e-mail]>
> Sent: Wednesday, October 16, 2019 3:49 PM
> To: [e-mail]<mailto:[e-mail]>
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: I-D Action: draft-ietf-detnet-ip-02.txt
>
>
> [EXTERNAL EMAIL]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Deterministic Networking WG of the IETF.
>
>         Title           : DetNet Data Plane: IP
>         Authors         : Balázs Varga
>                           János Farkas
>                           Lou Berger
>                           Don Fedyk
>                           Andrew G. Malis
>                           Stewart Bryant
>                           Jouni Korhonen
>        Filename        : draft-ietf-detnet-ip-02.txt
>        Pages           : 23
>        Date            : 2019-10-16
>
> Abstract:
>    This document specifies the Deterministic Networking data plane when
>    operating in an IP packet switched network.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-detnet-ip/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddetnet-2Dip_&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=mzbAKXUleGS8Bz7ajbUbKTPPDXTF0sMHaR30Jz1vx3I&e=>
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-detnet-ip-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddetnet-2Dip-2D02&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=U2KdtDL3CUVCsekPojtQVKIvgeP45L36pWIa_NTIOsA&e=>
> https://datatracker.ietf.org/doc/html/draft-ietf-detnet-ip-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Ddetnet-2Dip-2D02&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=v_m7-Vya44Tpf38IPNTfLFKd9vOPrwEKJ1koUg0xB-s&e=>
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-ip-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Ddetnet-2Dip-2D02&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=9FVm_p_MTKAngR5wvgnJsDRVpBhRs1VBb-HiEc9AuFw&e=>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=iQJB8fuxh1qkUEUNRcxmOvQFjWSriYN94CSHktRBwSw&e=>.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=4kQjX_H4U0HBUhyMvMm8v_ub2smEgNFOgcbS-JFjmCg&e=>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_i-2Dd-2Dannounce&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=iESW3uqZs6fiih_VYgFB-F-rtwNyaGqHl757qWRjZ94&e=>
> Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_shadow.html&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=Gi367w04OysBMQsqQk4D_FlH9mrlETnu55sSZQwWo8M&e=>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_ietf_1shadow-2Dsites.txt&d=DwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=YLkOGoZpigvSV1ZLn9IoiKXWyv2VoCYgoobywa8r3NE&e=>


_______________________________________________

detnet mailing list

[e-mail]<mailto:[e-mail]>

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=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=ZKMFjjpaWmbkFYiW3V6Z8NzpzleGBZFDJT0yhKFMOyU&e=>


_______________________________________________

detnet mailing list

[e-mail]<mailto:[e-mail]>

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=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=ZKMFjjpaWmbkFYiW3V6Z8NzpzleGBZFDJT0yhKFMOyU&e=>


_______________________________________________

detnet mailing list

[e-mail]<mailto:[e-mail]>

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=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=ZKMFjjpaWmbkFYiW3V6Z8NzpzleGBZFDJT0yhKFMOyU&e=>

_______________________________________________
detnet mailing list
[e-mail]<mailto:[e-mail]>
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=aXsW21APRn1D0lnb_8NZAAvhbFKvvtW7hNZN0L4OVkU&s=ZKMFjjpaWmbkFYiW3V6Z8NzpzleGBZFDJT0yhKFMOyU&e=>

_______________________________________________
detnet mailing list
[e-mail]<mailto:detnet%40ietf.org>
https://www.ietf.org/mailman/listinfo/detnet