Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 02 May 2019 13:25 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 61CE9120375; Thu, 2 May 2019 06:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 GuaBlLz2pEDB; Thu, 2 May 2019 06:25:19 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5C9120372; Thu, 2 May 2019 06:25:18 -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=1556803124; h=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-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=B3reR37OpFIYG8lI//y7jmN1zY0XSyUJ3mTeSQ oY+8Q=; b=mC8JIBeI7C0/tARDunUaXXXlQ7tykPhLHcU4fKib 9z/3zOQb5fAxwmDO+pExYgWRcMa0Of+PWN39gq3i5tSpQW0OP+ pqcef1G/HkmVN81kVuSqb4pilqO+0KFDyua44lzWCQgaiACcSW dU/vAaRPYjhsXkQGTo+tFBzcjIthAQo=
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 0da1_0c30_7448c6d1_e5c7_47cd_956f_013d10dc5c9a; Thu, 02 May 2019 07:18:43 -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; Thu, 2 May 2019 07:24:49 -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; Thu, 2 May 2019 07:24:49 -0600
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 May 2019 07:24:48 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2551.namprd16.prod.outlook.com (20.177.225.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.16; Thu, 2 May 2019 13:24:46 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1835.018; Thu, 2 May 2019 13:24:46 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, Liang Xia <frank.xialiang@huawei.com>, "dots@ietf.org" <dots@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1kb3Rz?= =?utf-8?Q?-signal-channel-31:_(with_DISCUSS_and_COMMENT)?=
Thread-Index: AQHVAM4JdK3c8pci6021tTnw22KeZaZX0dZA
Date: Thu, 2 May 2019 13:24:46 +0000
Message-ID: <BYAPR16MB2790E1DF3439D452B8AB37E6EA340@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <155672175129.924.6789867477696592350.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68C1A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA68C1A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [49.37.205.191]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ca0b50ae-3a6f-48ed-35e1-08d6cf018bea
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2551;
x-ms-traffictypediagnostic: BYAPR16MB2551:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <BYAPR16MB255176E7B5B946F74AC216B2EA340@BYAPR16MB2551.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0025434D2D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(366004)(39860400002)(376002)(189003)(13464003)(32952001)(199004)(54906003)(6116002)(14444005)(256004)(71200400001)(53936002)(76116006)(26005)(25786009)(76176011)(14454004)(6246003)(81166006)(53546011)(66556008)(74316002)(110136005)(3846002)(186003)(2501003)(446003)(102836004)(81156014)(55016002)(66446008)(73956011)(66946007)(6436002)(72206003)(316002)(33656002)(4326008)(80792005)(6506007)(66066001)(6306002)(9686003)(66476007)(71190400001)(5660300002)(966005)(53946003)(476003)(7736002)(229853002)(68736007)(66574012)(99286004)(64756008)(305945005)(8936002)(7696005)(30864003)(11346002)(486006)(52536014)(224303003)(86362001)(478600001)(2906002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2551; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 3G+XLcOoRw85LMpw8CO3gXGRcW893iXOv3eUTtaUywN68X/uw5PzaJfHBsfypLfW8ar3R0hB7ZwThMdsILNMFHH7Zj2jasfew8WiYKLNK2yQvADA/mejlapmiKgWWGsxRMc0nlq5cI5OBbLj1hPbvHfuY+VasKQx7Bci9qUXmjpHSXv6s0/ygRfi09RmzggLrDl6c9LXRDujExIEHMfPaCwKHWMgixWqwp2SjnvE8KE32ucXsIDQOsVUyzQns9ZWbZbre++63twoCdJuBxzBFx2NoFY0VMTmFdKMPEYE/JJ/qDN8TkH+5lMZGPuwSX1m52T46GffuR4llSLRu60FkN+nNMUzqJu/Ybo3Hj7NRkJ5c9H6TtyThtkb2ovQVV4ZB0GCTQ8qCm4O3kSJ0fOioLcphLvqP5xy4PBNd7EDfLY=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ca0b50ae-3a6f-48ed-35e1-08d6cf018bea
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2019 13:24:46.7592 (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-Transport-CrossTenantHeadersStamped: BYAPR16MB2551
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 <6538> : inlines <7070> : streams <1820357> : uri <2839671>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/5bolruUq-s1iwxN9mMFIaNbcSJA>
Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-signal-channel-31=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Thu, 02 May 2019 13:25:25 -0000

> -----Original Message-----
> From: Dots <dots-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Thursday, May 2, 2019 3:31 PM
> To: Mirja Kühlewind <ietf@kuehlewind.net>et>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-dots-signal-channel@ietf.org; Liang Xia
> <frank.xialiang@huawei.com>om>; dots@ietf.org; dots-chairs@ietf.org
> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-
> channel-31: (with DISCUSS and COMMENT)
> 
> 
> 
> Hi Mirja,
> 
> Thank you for the detailed review.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Mirja Kühlewind via Datatracker [mailto:noreply@ietf.org] Envoyé
> > : mercredi 1 mai 2019 16:43 À : The IESG Cc :
> > draft-ietf-dots-signal-channel@ietf.org; Liang Xia; dots-
> > chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org Objet :
> > Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31: (with
> > DISCUSS and COMMENT)
> >
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-dots-signal-channel-31: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > 1) Port usage (see section 3):
> > The port request for DOTS was reviewed by the port expert team. Some
> > members of the team were concerned about the assignment of a separate
> > port number for DOTS as Coap is used and already has a designated port
> > number. I believe that Coap is used as a transport in the case and
> > DOTS provides a separate service compared to what Coap is usually used
> > for, however, it is not clear why DOTS needs a designated port.
> > Section 3 says that the port can either be preconfigured or
> > dynamically detected, therefore it is not clear why a fixed port is
> > needed (see also section 7.1. of RFC7605). In the port review process
> > the authored argued that a port is needed to differentiate the DOTS
> > service in the network. However, this is not an endorsed usage for
> > port numbers (see section 6.2. of RFC7605). Further, I believe
> > assigning a fixed port might actually add an attack vector for DOTS,
> > either by DDoSing the respective port at the DOTS server, or any
> > attempt to block DOTS traffic on the network from the DOTS client to
> > the DOTS server.
> 
> [Med] FWIW, below the reasons why we believe that a DOTS port is needed:
> 
> ========
> (1)
> 
> We are familiar with RFC7605. We confirm that the port we are asking for is:
> 
>    o  ... not intended to differentiate
>       performance variations within the same service, e.g., high-speed
>       versus ordinary speed.  Performance variations can be supported
>       within a single assigned port number in context of separate
>       pairwise endpoint associations.
> 
> The example about differentiated policies is not related to ** performance
> ** but about being able to deliver a ** basic/normal ** DOTS service. Such
> DOTS service takes place in attack times...during which links are saturated by
> nature.
> 
> The purpose of DOTS is as such different from the typical usage of CoAP by
> IoT devices, DOTS signal channel is a new service.
> 
> (2)
> 
> The WG already considered in previous versions of the specification to use
> the existing CoAP port number (in compliance with RFC7605), but that design
> was abandoned by the WG for the reasons documented in the draft.
> 
> (3)
> 
> The built-in discovery of services and resources discussed in RFC 7252
> requires request and response between the peers, but DOTS protocol is
> designed to work in congested networks (because of DDoS attack) and the
> DOTS client during a volumetric DDoS attack may not be able to discover
> services and resources.
> 
> During a DDoS attack, the incoming link is likely to be saturated and the DOTS
> client can only send requests but not receive responses from the server.
> Assigning a DOTS service port avoids the need for resource discovery and
> additional RTT involved before the mitigation request can be sent to the
> DOTS server.
> 
> (4)
> 
> During a DDoS attack, the traffic from the endpoints and IoT devices can be
> rate-limited or blocked, but DOTS protocol traffic needs to be allowed.
> Assigning a DOTS service port helps middleboxes to identify and not rate-
> limit the DOTS protocol traffic during DDoS attack.
> 
> (5)
> 
> Given the rise of DDoS attacks targeting CoAP-capable IoT objects (usually,
> low-cost, not maintained,..), policies to filter "legacy" CoAP messages (at the
> CPE + access/transit networks) will have implications on the delivery of DOTS
> service which is a key component for the emergence of protective
> networking architectures. Having means to differentiate traditional CoAP
> service from DOTS are important from a deployment standpoint.
> ====
> 
> >
> > 2) Section 4.3 says:
> > "In reference to Figure 4, the DOTS client sends two TCP SYNs and two
> >    DTLS ClientHello messages at the same time over IPv6 and IPv4."
> > However, RFC8305 explicitly states that connection attempts SHOULD NOT
> > be made simultaneously (see sec 5).
> >
> 
> [Med] This one is discussed in another thread.
> 
> > Further Figure 4 shows a different order of request as recommended in the
> > text
> > (text says: "UDP over IPv6, UDP over IPv4, TCP over IPv6, and finally TCP
> > over
> > IPv4").
> 
> [Med] Actually, the text says:
> 
>   "In reference to Figure 4, the DOTS client sends two TCP SYNs and two
>    DTLS ClientHello messages at the same time over IPv6 and IPv4. "
> 
> We will add annotations to the figure.
> 
>  Also why are the UDP connection attempts repeated? I guess that is
> > meant to be the retransmission of the DTLS Hello?
> 
> [Med] Yes.
> 
>  However, usually you should
> > receive the TCP SYNACK before you retransmit
> 
> [Med] What is retransmitted is DTLS.
> 
> or in the best case even before
> > you start the next connection attempt. Therefore that should be not
> displayed
> > like this in the figure or needs further explanation.
> 
> [Med] We will add annotations to the figure.
> 
> >
> > 3) Why are these statements SHOULDs and not MUSTs (see section 4.4)?
> >   "DOTS agents SHOULD follow the data transmission guidelines discussed
> >    in Section 3.1.3 of [RFC8085] and control transmission behavior by
> >    not sending more than one UDP datagram per round-trip time (RTT) to
> >    the peer DOTS agent on average."
> 
> [Med] because we are aligned with 8085 which says:
> 
> " SHOULD still control their transmission behavior by not
>    sending on average more than one UDP datagram per RTT to a
>    destination "
> 
> > and
> >   "If the DOTS client cannot maintain an RTT estimate, it
> >    SHOULD NOT send more than one Non-confirmable request every 3
> >    seconds"
> 
> [Med] because 8085 says:
> 
> "Such applications SHOULD NOT send more than one UDP
>        datagram every 3 seconds"
> 
> 
> > as well as in section 4.4.2.1:
> >   "If the DOTS server cannot maintain an RTT
> >    estimate, it SHOULD NOT send more than one asynchronous notification
> >    every 3 seconds"
> 
> [Med] Idem as above.
> 
> > and again in section 4.4.2.2:
> >  "The frequency of polling the DOTS server to get the
> >    mitigation status SHOULD follow the transmission guidelines in
> >    Section 3.1.3 of [RFC8085].
> 
> [Med] This is to accommodate the case where a local policy is provided to the
> DOTS agent.
> 
> > However, most of the communication pattern used by DOTS rely on a
> > request/reply
> > pattern and Coap specifies for this case that only one request can be
> > outstanding at a time (until the reply is received or message is assumed to
> > be
> > lost) (see section 4.7 and 4.2 of RFC7252) which therefore will be used in
> > this
> > case. Only migration updates are send without reply, and here a MUST
> would be
> > more appropriate.
> >
> > Please also note that if there can only be one request outstanding (before
> a
> > reply is received) it is also not possible that requests are received out of
> > order (see e.g. 4.4.3: "If UDP is used as transport, CoAP requests may arrive
> > out-of-order.").
> >
> > 4) draft-ietf-core-hop-limit is used in section 10:
> > "The presence of DOTS gateways may lead to infinite forwarding loops,
> >    which is undesirable.  To prevent and detect such loops, this
> >    document uses the Hop-Limit Option."
> > This sounds like it should be required (and normative language should be
> > used)
> > and therefore draft-ietf-core-hop-limit should also be a normative
> reference.
> > Also draft-ietf-core-comi should probably another normative reference.
> 
> [Med] These two items are already covered in the reply to Alexey's review.
> 
> >
> > 5)Section 4.5.2: You give recommendations for min and max in a note,
> however,
> > these values should be specified normatively and in best with a MUST.
> 
> [Med] We can use RECOMMENDED.
> 
> >
> > 6) Section 4.7: "the DOTS
> >    agent sends a heartbeat over the signal channel to maintain its half
> >    of the channel.  The DOTS agent similarly expects a heartbeat from
> >    its peer DOTS agent"
> > and
> > "DOTS servers MAY trigger their heartbeat requests immediately after
> >    receiving heartbeat probes from peer DOTS clients."
> > Actually heartbeat should only be send in one direction (as the other end
> > will
> > send an ack) and the protocol should clearly specify which endpoint is
> > responsible for triggering the ping.
> >
> 
> [Med] The current behavior us aligned with "SIG-004  Channel Health
> Monitoring" of https://tools.ietf.org/html/draft-ietf-dots-requirements-22.
> 
> > 7) sec 7.3:"To avoid DOTS signal message fragmentation and the
> subsequent
> >    decreased probability of message delivery, DOTS agents MUST ensure
> >    that the DTLS record MUST fit within a single datagram."
> > This should be handled by the DTLS record layer and not by DOTS that
> works on
> > top of DTLS (actually Coap), therefor it seems straight to have a normative
> > requirement here in the DOTS spec. Also note that the calculation provided
> is
> > not valid for early data (0-RTT) as the hello messages could be transmitted
> > in
> > the same datagram.
> >

DTLS handles fragmentation and reassembly only for handshake messages and not for the application data (please see https://tools.ietf.org/html/rfc6347#section-4.1.1). 

-Tiru

> 
> [Med] Will check this.
>
> 
> > 8) Also sec 7.3: "If the path
> >    MTU is not known to the DOTS server, an IP MTU of 1280 bytes SHOULD
> >    be assumed."
> >   Actually this is only true for IPv6. The later note mentions that the
> >   situation is different from IPV4, however, it should probably be made
> clear
> >   from the beginning that 1280 can only be assumed for IPv6.
> 
> [Med] Actually, we are echoing RFC7252:
> 
>    If the Path MTU is not known for a destination, an IP MTU of 1280
>    bytes SHOULD be assumed; if nothing is known about the size of the
>    headers, good upper bounds are 1152 bytes for the message size and
>    1024 bytes for the payload size.
> 
> >
> > 9) sec 9.6: What's the registration policy for the newly created registries?
> >
> 
> [Med] The text says the following:
> 
>    New codes can be assigned via Standards Action [RFC8126].
> 
> 
> > 10) The document should more explicitly provide more guidance about
> when a
> > client should start a session and what should be done (from the client side)
> > if
> > a session is detected as inactive (other than during migration which is
> > discussed a bit in 4.7). Is the assumption to have basically permanently an
> > active session or connect for migration and configuration requests
> separately
> > at a time?
> 
> [Med] In order to avoid cryptographic handshake for new mitigation
> requests, the session is assumed to be established and maintained.
> 
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 1) I really recommend to add subsections to section 4.4.1.
> >
> > 2) section 4.4.1: "The lifetime of the
> >          deactivated mitigation request will be updated to (retry-timer
> >          + 45 seconds), so the DOTS client can refresh the deactivated
> >          mitigation request after retry-timer seconds before expiry of
> >          lifetime and check if the conflict is resolved."
> > This wording is not fully clear to me. If the life time of a deactivated
> > request in updated, isn't it active again?
> 
> [Med] A request can be updated but the status may be flagged as active or
> deactivate.
> 
>  And if it is active and another
> > request is sent, isn't that request rejected again.
> 
> [Med] Likely
> 
>  Can you please further
> > clarify.
> >
> > 3) section 4.4.2: "lifetime:  The remaining lifetime of the mitigation
> > request,
> > in
> >       seconds."
> > Shouldn't lifetime we rather a timestamp because there is some unknown
> > transmission delay between the time when the reply is generated and the
> reply
> > is received, and as such a lifetime in seconds is quite meaningless for the
> > client.
> 
> [Med] We prefer lifetime because otherwise time synchronization will be
> needed. The use of lifetime is aligned with other similar usage: e.g., RFC6887,
> RFC8512, etc.
> 
> >
> > 4) section 4.4.2.1: " For DOTS server
> >    application, the message type MUST always be set to Non-confirmable
> >    even if the underlying COAP library elects a notification to be sent
> >    in a Confirmable message."
> > I'm not sure I understand this sentence. Can you please further explain?
> 
> [Med] What is meant is to relax this behavior from RFC 7641:
> 
>    A server that transmits notifications mostly in non-confirmable
>    messages MUST send a notification in a confirmable message instead of
>    a non-confirmable message at least every 24 hours.
> 
> DOTS application will override that behavior.
> 
> >
> > 5) section 4.4.4: "For example, if there is a financial
> >    relationship between the DOTS client and server domains, the DOTS
> >    client stops incurring cost at this point."
> > I find this sentence a bit problematic given the active-but-terminating
> > period
> > is defined by server. Wouldn't that mean the server can make me pay for
> > undefined period of time?
> 
> [Med] That is only an example if agreed between the client and server. Such
> considerations are out of scope.
> 
>  Also the max of 300 sec doesn't seem to be a
> > MUST...?
> >
> 
> [Med] Other values can be used in specific deployments/agreements.
> 
> > 6) In section Section 4.5 you talk about Caop Ping/Pong. However, these
> terms
> > are not used in RFC7252. Maybe clarify that empty confirmable  messages
> are
> > used and provide a pointer to section 4.2. of RFC7252 right here (instead of
> > only later).
> 
> [Med] Will do. Thanks.
> 
> >
> > 7) High-level question: Given this doc specifies a YANG model, why are
> > configuration are not retrieved and changed using NETCONF or RESTCONF?
> >
> 
> [Med] The draft says the following:
> 
>    This YANG module (ietf-dots-signal-channel) defines the DOTS client
>    interaction with the DOTS server as seen by the DOTS client.  A DOTS
>    server is allowed to update the non-configurable 'ro' entities in the
>    responses.  This YANG module is not intended to be used via NETCONF/
>    RESTCONF for DOTS server management purposes; such module is out of
>    the scope of this document.  It serves only to provide a data model
>    and encoding, but not a management data model.
> 
> Thank you again for the detailed review.
> 
> Cheers,
> Med
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots