Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Sun, 21 July 2019 06:52 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A53C12008D for <dots@ietfa.amsl.com>; Sat, 20 Jul 2019 23:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=mcafee.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_r72qhFIOQe for <dots@ietfa.amsl.com>; Sat, 20 Jul 2019 23:52:30 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE86E120088 for <dots@ietf.org>; Sat, 20 Jul 2019 23:52:29 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1563691275; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=aLZrZv6rslYl91R2kQBIqJqybdmq/+3wNSnl9H NwpBk=; b=KIsarbA8mRExeEywpj4PBn+r1qyA928+TcHK9RGt wzU/yJxgkNFWQpdvmCw7XdfcKe9Vdi0cmXrjKRBg3scsOnDsrz k0rHEXkBT66zCMspDoWnlW00UUCikdXDKwbB/RcQxlSkfxFqgv 10F0e72wcEhGX8pHDk2K6se28sCcFKw=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-219-nx7O1WOSNI6r2Km_46yMZQ-1; Sun, 21 Jul 2019 02:52:24 -0400
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6bfd_485b_b77d2ced_762a_4a07_aa93_4b699fef6b61; Sun, 21 Jul 2019 00:41:14 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 21 Jul 2019 00:52:21 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sun, 21 Jul 2019 00:52:21 -0600
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 21 Jul 2019 00:52:20 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ht/mrKdSLClApio+Gm8oJaWvafd9SD99etneu1hVlHigSgpbNNJ1eA5w0Dy81czvaWkbxv0PDUSjTmsBaI2rwBj8+X9vykFP/4zK45Kmsjg9FrHQ6E3o22eGtzA5eKyKqddfEvrgPyDfeZm9DrGI76WAKREeJUzS8rX3+BBD3SAlyIN3NQwQojLhwiQqcR1gQmM6RIAga1IUlfi7jye/bflsGCyfkrrse5EbrGoaeUuz1u2+gUCqeifhYN8ifavqX8JEhm7YV56BgsgtWakVgBKly5EJ7j2juXILFA0gHpmebyN/ycCMfIsyJeuLoWOtDgNQ1Vow+RCCtBNVSxD4FA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aLZrZv6rslYl91R2kQBIqJqybdmq/+3wNSnl9HNwpBk=; b=bGxj8HEPUfusf54PVCVUimXZuoZ+INQdCnjby0/a14a2VRxhJatpCrZoumRkLnbvFAqFvGPTwwUQDWtpZhOL/OHJTsfMP4CeAQI3khCoOy5EgwElCnQaJrPB5pkhwy/iN/QBIbtMgF1Umhq/tEehtJcor4x0v+4Cq8iZQVMb6jZPVo3G7TeD5Jw+lQQYKhK5eaeYiOo2dJiUYQYwNcEGPjnwjrCCNRyhtIqkglFuxPMzxSF6FGavhoV89QRP775KfM2d1hUY2WfNdP3xzrOVclohqAPPe0MIDrDeoJsFaLlYweVJEL2OE09Wr8cujYbfGHAt5ZayYsNKO7bQ/nEmrg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1484.namprd16.prod.outlook.com (10.173.210.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.14; Sun, 21 Jul 2019 06:52:18 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2094.013; Sun, 21 Jul 2019 06:52:18 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Valery Smyslov <valery@smyslov.net>
CC: "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
Thread-Index: AdU9/zWZw7DhsbF6RNCA2PYrEJMCCAAJ+IgAAFSa1gAAAzHm8A==
Date: Sun, 21 Jul 2019 06:52:18 +0000
Message-ID: <DM5PR16MB1705B068DCF6AB20658EF826EAC50@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <787AE7BB302AE849A7480A190F8B93302FA841A9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00c201d53e27$194cfc20$4be6f460$@smyslov.net> <20190721040520.GS23137@kduck.mit.edu>
In-Reply-To: <20190721040520.GS23137@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 22269e55-d805-4f2c-f25d-08d70da7f8e5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1484;
x-ms-traffictypediagnostic: DM5PR16MB1484:
x-ms-exchange-purlcount: 10
x-microsoft-antispam-prvs: <DM5PR16MB14848A921CC9F4A7ED773A6EEAC50@DM5PR16MB1484.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0105DAA385
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39850400004)(346002)(136003)(366004)(396003)(376002)(51444003)(32952001)(199004)(189003)(13464003)(6246003)(486006)(86362001)(68736007)(25786009)(2171002)(66066001)(30864003)(3846002)(6116002)(8936002)(6436002)(229853002)(33656002)(71200400001)(71190400001)(2906002)(53936002)(9686003)(6306002)(256004)(55016002)(14444005)(5024004)(316002)(478600001)(74316002)(186003)(54906003)(14454004)(66946007)(8676002)(76116006)(7696005)(110136005)(99286004)(7736002)(476003)(446003)(11346002)(76176011)(305945005)(66476007)(52536014)(5660300002)(53546011)(6506007)(966005)(4326008)(80792005)(66446008)(64756008)(66556008)(26005)(81156014)(102836004)(81166006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1484; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: rbxIFzZAOvU8hU5ApuyZsonoefaRgUzY0BFbdEesv/UsGsB9pb414pCnBktm8cncM+lC6EZih5XIC8881nSUTfTL5kDSpxIQLLvIAswSVPb8FWL6dJ30OhD7UkWL3c7/f7r/zNIlAFXf8JBZc5GaOgnMo/UlI/Ai9VyWIrSi4OCJ4GHTIOZZVn1lH9OLu3vsE7ZyaCw7Nxd+o1N/hynMT5mJ6/xnXehu7OlGn72kPvg7APupmf7kxs5Vttefxa0reZ+hKSYR3hvVCHcmkKIxORMuXQoNBHNUT22iHgfSNB7O7dBLdks+JHyBitZAXFo0PtgGrSw2nyj2YXgx1WPMmrUWg1n9tYqbVEkHOg5WgJRjPGKz25hlWzIxOq8dkfKFIpKPK03ClS/hGFTpbDL0nJTZI2+ILlHfzWtYGskdoXo=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 22269e55-d805-4f2c-f25d-08d70da7f8e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2019 06:52:18.1182 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1484
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6594> : inlines <7122> : streams <1827974> : uri <2870170>
X-MC-Unique: nx7O1WOSNI6r2Km_46yMZQ-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/lwM-0vWUyg3DxYf_Vf-qO_Z076o>
Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2019 06:52:34 -0000

Hi Ben,

There seems to several confusions regarding the heartbeat mechanism, I will try to address all the comments/Discuss from you, Mirja and Valery below:

[1] https://tools.ietf.org/html/rfc7252 is specific to UDP transport (and does not deal with TCP). Please see the first paragraph in https://tools.ietf.org/html/rfc7252#section-3. The message transmission parameters (max-retransmit, ack-timeout and ack-random-factor) and missing-hb-allowed discussed in DOTS signal channel are specific to UDP transport.

[2] CoAP over TCP is discussed in https://tools.ietf.org/html/rfc8323. Please see the following differences b/w CoAP-over UDP and CoAP-over-TCP relevant to our discussion:

a) CoAP ping/pong defined in RFC7252 (uses Empty confirmable message and reset) will not work for CoAP-over-TCP. As per https://tools.ietf.org/html/rfc8323#section-3.4, Empty messages (Code 0.00) can always be sent and MUST be ignored by the recipient. CoAP-over-TCP defines its own CoAP ping/pong for connection health (see https://tools.ietf.org/html/rfc8323#section-5.4).  

b)Confirmable  and Non-confirmable message types are specific to UDP, and are not supported in CoAP-over-TCP.

[3] For TCP, if no ack is received for CoAP ping for specific duration, TCP will close the connection, and the DOTS client will have to re-establish the TCP connection. missing-hb-allowed is of no use for TCP. We are all in the same page for TCP, and the draft can probably 
      be updated for better clarity.

[4] Now coming to UDP, please see my responses below:

a) As you already know, DOTS signal channel uses heartbeat exchange in both directions, and hence CoAP ping is sent by both DOTS client and server.
b) CoAP ping is a confirmable message and hence the exponential back-off with the default value of MAX_RETRANSMIT is 4 (https://tools.ietf.org/html/rfc7252#section-4.8).
c) CoAP ping is the only confirmable message exchanged during attack (all other messages exchanged during an attack are non-confirmable).  The specification allows distinct values for message transmission parameters and missing-hb-allowed to be used during attack and peace times.

To handle congestion conditions during an attack, the specification allows two options:

[Option a] By setting MAX_RETRANSMIT to 1, exponential-back off is avoided and missing-hb-allowed set to a very higher value (e.g. 20) to handle congestion (high packet loss). The draft can be updated to explain [Option a] in more detail.
[Option b] The CoAP MAX_RETRANSMIT default value of 4 is not modified, and for example, missing-hb-allowed can be set to 5 (since 4 transmits are not sufficient to detect the peer is not alive during congestion). 

The Discuss from Mirja is not to rely on the CoAP ping/pong but to define it in the DOTS layer itself (please see https://mailarchive.ietf.org/arch/msg/dots/V6vv28zDpdY5eR_kaB7L-60bhkk) and suggested to go with an alternate design using non-confirmable messages. The alternate design won't work is our assessment, please see my response https://mailarchive.ietf.org/arch/msg/dots/QRMfsmhPTFksN6a_nBBKimVx-lM 

Cheers,
-Tiru

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> Sent: Sunday, July 21, 2019 9:35 AM
> To: Valery Smyslov <valery@smyslov.net>
> Cc: dots-chairs@ietf.org; mohamed.boucadair@orange.com; dots@ietf.org
> Subject: Re: [Dots] Mirja's DISCUSS: Pending Point (AD Help Needed)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Valery,
> 
> On Fri, Jul 19, 2019 at 02:42:50PM +0300, Valery Smyslov wrote:
> > Hi Med,
> >
> > I believe Mirja's main point was that if you use liveness check
> > mechanism in the transport layer, then if it reports that liveness check fails,
> then it _also_ closes the transport session.
> >
> > Quotes from her emails:
> > "Yes, as Coap Ping is used, the agent should not only conclude that the
> DOTS signal session is disconnected but also the Coap session and not send
> any further Coap messages anymore."
> >
> > and
> >
> > "Actually to my understanding this will not work. Both TCP heartbeat and
> Coap Ping are transmitted reliably. If you don’t receive an ack for these
> transmissions you are not able to send any additional messages and can only
> close the connection."
> >
> > I'm not familiar with CoAP, but I suspect she's right about TCP - if
> > TCP layer itself doesn't receive ACK for the sent data after several
> retransmissions, the connection is closed.
> 
> Thanks for this crisp summary (and thanks Med for the detailed writeup as
> well)!
> 
> > As far as I understand the current draft allows underlying liveness
> > check to fail and has a parameter to restart this check several times
> > if this happens. It seems that a new transport session will be created
> > in this case (at least if TCP is used). In my reading of the draft
> > this seems not been assumed, it is assumed that the session remains the
> same. So, I think that main Mirja's concern is that it won't work (at least with
> TCP).
> 
> My sense is similar; if I could attempt to summarize Mirja's stance, it's that
> we're invoking a transport-level feature that does its own retransmit and
> backoff, but then if the transport comes back and says "the peer is gone", we
> say "but we're under attack, so I don't believe you; try again".
> This kicks of another independent set of "retransmits" (I know it's not
> technically the right word) with a fresh exponential backoff.  There's two
> complaints about this: (1) we're changing the transport, since if the transport
> concludes the peer is gone then the transport "normally" tears down the
> connection (*) entirely, and (2) the assembly of (exponential backoff 1),
> (exponential backoff 2), (exponential backoff 2) is strange pacing, and might
> be better served by a similar number of "retransmits" but with different
> pacing, since the long delay at the end of each backoff period is not expected
> to add a huge amount of value in terms of letting congestion ease during
> attack time, and we would be just as well served by capping the delay
> between retransmits and having more retransmits.
> 
> The asterisk on (1) is of course because, as is noted later in the thread, only
> TCP tears down the association when it concludes the peer is gone (assuming
> I'm reading the right parts of 7252).  Quoting 7252:
> 
>                                                         If the
>    retransmission counter reaches MAX_RETRANSMIT on a timeout, or if the
>    endpoint receives a Reset message, then the attempt to transmit the
>    message is canceled and the application process informed of failure.
>    On the other hand, if the endpoint receives an acknowledgement in
>    time, transmission is considered successful.
> 
> So all CoAP does is to tell the application "that request didn't work", but CoAP
> is happy to try additional requests on the connection; the teardown logic is
> indeed left up to the application.
> 
> I'm not sure that we've seen much discussion about (2), though (sorry if I
> missed it) -- why is the repeated backoff-and-restart the right pacing for this
> purpose?
> 
> -Ben
> 
> > I didn't participate in the WG discussion on this, so I don't know
> > what was discussed regarding this issue. If it was discussed and the
> > WG has come to conclusion that this is not an issue, then I believe
> > more text should be added to the draft so, that people like Mirja, who
> didn't participate in the discussion, don't have any concerns while reading the
> draft.
> >
> > Regards,
> > Valery.
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: mohamed.boucadair@orange.com
> > > <mohamed.boucadair@orange.com>
> > > Sent: Friday, July 19, 2019 9:57 AM
> > > To: Benjamin Kaduk (kaduk@mit.edu) <kaduk@mit.edu>du>; dots-
> > > chairs@ietf.org; dots@ietf.org
> > > Subject: Mirja's DISCUSS: Pending Point (AD Help Needed)
> > >
> > > Hi Ben, chairs, all,
> > >
> > > (restricting the discussion to the AD/chairs/WG)
> > >
> > > * Status:
> > >
> > > All DISCUSS points from Mirja's review were fixed, except the one
> > > discussed in this message.
> > >
> > > * Pending Point:
> > >
> > > Rather than going into much details, I consider the following as the
> > > summary of the remaining DISCUSS point from Mirja:
> > >
> > > > I believe there are flaws in the design. First it’s a layer
> > > > violation, but if more an idealistic concern but usually designing
> > > > in layers is a good approach. But more importantly, you end up
> > > > with un-frequent messages which may still terminate the connection
> > > > at some point, while what you want is to simply send messages
> > > > frequently in an unreliable fashion but a low rate until the attack is over.
> > >
> > > * Discussion:
> > >
> > > (1) First of all, let's remind that RFC7252 does not define how CoAP
> > > ping must be used. It does only say:
> > >
> > > ==
> > >       Provoking a Reset
> > >       message (e.g., by sending an Empty Confirmable message) is also
> > >       useful as an inexpensive check of the liveness of an endpoint
> > >       ("CoAP ping").
> > > ==
> > >
> > > How the liveness is assessed is left to applications. So, there is
> > > ** no layer violation **.
> > >
> > > (2) What we need isn't (text from Mirja):
> > >
> > > > to simply send messages frequently in an unreliable fashion but a
> > > > low rate until the attack is over "
> > >
> > > It is actually the other way around. The spec says:
> > >
> > >   "... This is particularly useful for DOTS
> > >    servers that might want to reduce heartbeat frequency or cease
> > >    heartbeat exchanges when an active DOTS client has not requested
> > >    mitigation."
> > >
> > > What we want can be formalized as:
> > >  - Taking into account DDoS traffic conditions, a check to assess
> > > the liveness of the peer DOTS agent + maintain NAT/FW state on on-path
> devices.
> > >
> > > An much more elaborated version is documented in SIG-004 of RFC 8612.
> > >
> > > * My analysis:
> > >
> > > - The intended functionality is naturally provided by existing CoAP
> messages.
> > > - Informed WG decision: The WG spent a lot of cycles when specifying
> > > the current behavior to be meet the requirements set in RFC8612.
> > > - Why not an alternative design: We can always define messages with
> > > duplicated functionality, but that is not a good design approach
> > > especially when there is no evident benefit.
> > > - The specification is not broken: it was implemented and tested.
> > >
> > > And a logistic comment: this issue fits IMHO under the non-discuss
> > > criteria in https://www.ietf.org/blog/discuss-criteria-iesg-review/#stand-
> undisc.
> > >
> > > * What's Next?
> > >
> > > As an editor, I don't think a change is needed but I'd like to hear
> > > from Ben, chairs, and the WG.
> > >
> > > Please share your thoughts and whether you agree/disagree with the
> > > above analysis.
> > >
> > > Cheers,
> > > Med
> >
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots