Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 03 September 2019 08:23 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6015112002E; Tue, 3 Sep 2019 01:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, 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=ericsson.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 KAuBq0juKxEU; Tue, 3 Sep 2019 01:23:51 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70071.outbound.protection.outlook.com [40.107.7.71]) (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 2D4FA120041; Tue, 3 Sep 2019 01:23:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L+2Ax2/Apr/piRqZ8uAhyy14d+cCASGZw6L1yfRLs2pW3/rqrZ70AittWSUIiinnOEyPGg/SZUGw0EinDKebhE1hDQuk7o8EubWPQIRFNkqum1eDb0VG/Cbsw3Djm4SZEahA78EBeavlY9iI8XdgzMYxBPmDsynDK84Re4p1PrbHs15AL5dTG/32RlhXN62fDVGhj33Y0QWykgWbWn0Fs8z1Ttd7jOcCLbo0nw1ep2Osh3Pocu/8jZiFtGtYt7hHTvkXHm5ytR+PZZNUsjFtYmgBMt/wTidoOopTF3IfD6dq6tcjooDBq+1zY+IMBUdZt3w4/6uDRr91SEW472mOpg==
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=v745Kx5S8fMXoIBqz1j0bm6bX6uSn1pb3zkPLrKxXiI=; b=iK3LwGPkWyBWdjL8wryRPTf1bX49Aq1nwPHOIF7P61G8bSgip09bqm63Hx2C2P0Qb7m1lbU3Oi0aEDqdl7OFSorsEFKOfMHzQPy+dedWdNpwQ95JrFQvtNJwSR98SqCt1Jy1MzY7YLY6E2JLY8PfdbjQETuB3msK+rT983Q1hakNlruZ/m6i2Bbnwr6GXMi2Qc9SLDyr631Gam31tKbeSmIRqTBzHZJkdePVP3ULOKfTWaMiqKCtC4vDYAd2Xg4i4DhefTY6mcLek4ZyR2RTkybi6uLnmyKP7cpTUfRoHS2a6/495itQAaH1a5h1gQ3ywyn5bRJZIYOBYtjRkMUy+Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v745Kx5S8fMXoIBqz1j0bm6bX6uSn1pb3zkPLrKxXiI=; b=V/vuJgW3DuhEZ/7o0p/veU8LgmkUgjOjZUF6C2pC2ra2nwo5k0gD0cuSRU+nUiT3Qghh9Y/+Bz6fON9mnMOWnBuqKu7MxXbYjhmAzNcq2v+mNmclW+uZesOMH9pW+qXv6n+ubqD+kUViVwenmMZlWBLHvAXrulhqOPnXgFlg0WE=
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB5861.eurprd07.prod.outlook.com (20.177.192.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.5; Tue, 3 Sep 2019 08:23:48 +0000
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772%6]) with mapi id 15.20.2241.012; Tue, 3 Sep 2019 08:23:48 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "6lo@ietf.org" <6lo@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "lijo@cdac.in" <lijo@cdac.in>
CC: "shwethab@cisco.com" <shwethab@cisco.com>, "satishnaidu80@gmail.com" <satishnaidu80@gmail.com>, "anand@ece.iisc.ernet.in" <anand@ece.iisc.ernet.in>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "samitac.ietf@gmail.com" <samitac.ietf@gmail.com>, "charles.perkins@earthlink.net" <charles.perkins@earthlink.net>
Thread-Topic: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
Thread-Index: AQHVX1qtpYRpdae6DU+NKmlnchQ68qcZoxqA
Date: Tue, 03 Sep 2019 08:23:48 +0000
Message-ID: <1cc56ea4bd18c70c4bbf4911fdb4ffc81958b60e.camel@ericsson.com>
References: <155801295610.19776.17352306388780302849.idtracker@ietfa.amsl.com> <aaf94f20-fdde-ff3c-aacb-1332e2ae080a@earthlink.net> <359EC4B99E040048A7131E0F4E113AFC01B3442DBB@marathon> <000001d55f5a$7f5db280$7e191780$@in>
In-Reply-To: <000001d55f5a$7f5db280$7e191780$@in>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [158.174.130.105]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: eeec7cff-30bc-4267-4557-08d730480b68
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DB7PR07MB5861;
x-ms-traffictypediagnostic: DB7PR07MB5861:
x-microsoft-antispam-prvs: <DB7PR07MB586114ED2204A927E226B65095B90@DB7PR07MB5861.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01494FA7F7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(396003)(136003)(346002)(51914003)(199004)(189003)(51444003)(43544003)(13464003)(3846002)(6116002)(305945005)(99286004)(102836004)(229853002)(186003)(14454004)(4326008)(53936002)(86362001)(53946003)(7736002)(76176011)(91956017)(64756008)(81166006)(81156014)(66446008)(8676002)(2906002)(2201001)(66556008)(110136005)(66616009)(66476007)(25786009)(66946007)(966005)(6506007)(2501003)(478600001)(6436002)(53546011)(6512007)(6306002)(8936002)(5660300002)(2616005)(476003)(446003)(54906003)(76116006)(256004)(14444005)(6486002)(118296001)(71190400001)(71200400001)(66066001)(44832011)(486006)(36756003)(316002)(11346002)(30864003)(99936001)(6246003)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5861; H:DB7PR07MB5736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: qJpdEtjHtrSnNH0i5hbbyWgiOI3Rm4zyFUpirRvtvHP4Tl2C9P43KBoAgexHdg/0KMOeQqx7slgGJ6oojlVk361keRWRneR/XKz4WyqD7gNE2ih9s+l5RN7EF6K4li/4dSxk/wcYSAIaq/IBCIeipaPV6Nu3qKa2LCMjY9p3/w2oclTsekGU9u6Qx8BvZpXY5ZwGN6Hm74ear8Tm09dtQywpCsDPljVkx3ltnQrLutPKnUDAlU3DgkCNi8AYK+uDbv4lYQit1xqQd608E5UOu7V8ypZT7S23hq80bh5og69Tc30RBi/oCx46UXIHBQCAphiH7GnGJ8O/VW3+C8g1eRxC0IAtJvxZx3KC4nsEPY7CAWwhftd7o9IL2Mst+sBm2NSLo9xiz+gN4DJekQa436emkquqW2rkduT3kSjtYVM=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-FXw37BM6hyY9MG5Xaarl"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: eeec7cff-30bc-4267-4557-08d730480b68
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2019 08:23:48.1547 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oiC5EpjywhlG4pON2sE3mUiM/bBHfouknen0UdvB33K6uyEClqnvyBdWmw5pXfoKJK+DLjdO6HH3wdwfWCSmNwuFmFagJnEYPTiwQ1vTIng=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5861
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/vzHayqucLrpwzFm4b4MdeFs0C2c>
Subject: Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2019 08:23:55 -0000

Hi,

I have cleared my discuss. 

Cheers

Magnus


On Fri, 2019-08-30 at 23:13 +0530, Lijo Thomas wrote:
> Hello Magnus:
> 
> Please recall the Discuss in regard with our deadline-time draft and
> we believe we addressed your comments in the current revision (05).
> 
> It will be great if you could pass the Discuss positions in the
> record, if the security concerns raised are addressed.
> 
> The relevant text from security portion of 05 revision is below, for
> your quick reference.
> 
> <<
> 
>    The protocol elements specified in this document are designed to
> work
>    in controlled operational environments (e.g., industrial process
>    control and automation).  In order to avoid misuse of the deadline
>    information that could potentially result in a Denial of Service
>    (DoS) attack, proper functioning of this deadline time mechanism
>    requires the provisioning and management of network resources for
>    supporting traffic flows with deadlines, performance monitoring,
> and
>    admission control policy enforcement.  The network provisioning
> can
>    be done either centrally or in a distributed fashion.  For
> example,
>    tracks in a 6tisch network could be established by a centralized
> PCE,
>    as described in the 6tisch architecture
>    [I-D.ietf-6tisch-architecture].
> 
>    The Security Considerations of Detnet architecture
>    [I-D.ietf-detnet-architecture] mostly apply to this document as
> well,
>    as follows.  To secure the request and control of resources
> allocated
>    for tracks, authentication and authorization can be used for each
>    device, and network controller devices.  In the case of
> distributed
>    control protocols, security is expected to be provided by the
>    security properties of the protocols in use.
> 
>    When deadline bearing flows are identified on a per-flow basis,
> which
>    may provide attackers with additional information about the data
>    flows, when compared to networks that do not include per-flow
>    identification.  The security implications of disclosing that
>    additional information deserve consideration when implementing
> this
>    deadline specification.
>    
>    Because of the requirement of precise time synchronization, the
>    accuracy, availability, and integrity of time synchronization is
> of
>    critical importance.  Extensive discussion of this topic can be
> found
>    in [RFC7384].
> > > 
> 
>  Kindly let us know if your comments and valuable inputs.
> 
>  Thanks & Regards
>  Lijo Thomas
> 
> 
> -------------------------------------------------------------------
> ---------------------------
> 
> Subject: 	Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-
> 6lo-deadline-time-04: (with DISCUSS and COMMENT)
> Date: 	Thu, 6 Jun 2019 09:46:17 +0530
> From: 	Lijo Thomas <lijo@cdac.in>
> 
> To: 	'Magnus Westerlund' <magnus.westerlund@ericsson.com>
> 
> CC: 	6lo@ietf.org
> 
> 
> 
> Hi Magnus,
> 
> Thanks for the great response, we will update the draft accordingly.
> 
> Thanks & Regards,
> Lijo Thomas 
> -----Original Message-----
> From: Magnus Westerlund <magnus.westerlund@ericsson.com> Sent: 05
> June 2019 17:23
> To: Lijo Thomas <lijo@cdac.in>; 'Charlie Perkins'
> <charles.perkins@earthlink.net>; 'The IESG' <iesg@ietf.org>
> Cc: 6lo-chairs@ietf.org; 'Samita Chakrabarti' <samitac.ietf@gmail.com
> >;
> 'Shwetha Bhandari' <shwethab@cisco.com>; 6lo@ietf.org;
> anand@ece.iisc.ernet.in; 'satish anamalamudi' <
> satishnaidu80@gmail.com>;
> draft-ietf-6lo-deadline-time@ietf.org
> Subject: Re: [6lo] Magnus Westerlund's Discuss on
> draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
> 
> Hi,
> 
> Thanks for providing some background information. From my perspective
> I
> think there are some benefit to indicate the context the solution was
> developed in. Note this is really comment level and not required.
> 
> 
> 
> On 2019-06-05 07:54, Lijo Thomas wrote:
> 
> Hi Magnus,
> 
> Thanks for your detailed review and really appreciate your time taken
> for the effort !!!!.
> 
> Please find our below response for the frame work query addressed by
> you.
> 
> One of the main use cases of the draft is the industrial automation
> and control applications. The end point of such applications puts the
> deadline information as per its delay requirements.
> I agree that the underlying 6Lo network needs to ensure that the
> deadline is met using its delay sensitive routing and scheduling
> mechanisms while forwarding the packet along the path. The 6Lo
> network can support such a QoS requirement through end-to-end
> provisioning of the required network resources either centrally
> and/or in a distributed
> fashion .
> 
> 
> In the case of a 6tisch network, one could think of setting up tracks
> [draft-ietf-6tisch-architecture] along with delay aware Scheduling
> Function implemented by the intermediate nodes. The deadline draft
> works well within the context of the framework described in the
> draft-6tisch-architecture draft. The 6tisch architecture draft
> defines tracks which could either be set up by a centralised entity
> PCE or by setting up tracks in a distributed fashion by reserving
> network resources that provide end-to-end delay guarantees. Packets
> of application flows can be sent over these tracks and scheduled
> based on their deadlines. The CAC can be exercised where reservation
> fails for a new track setup. There are situations like asynchronous
> time critical emergency messages where track set up delay is not
> acceptable. In such cases, we can use distributed on-the-fly
> scheduling using 6P protocol described in RFC 8480 that takes into
> consideration the deadline information.
> 
> There are several deadline based scheduling algorithms that have
> proposed in the literature including the basic Earliest Deadline
> First (EDF). Based on our deadline draft, we implemented this scheme
> over a 6tisch network running on OpenWSN protocol stack and our draft
> implementation has been merged with the OpenWSN environment for
> future
> downloads too.
> 
> We would be happy to add some additional text specifying that ** a
> network monitoring entity with call admission policy is expected to
> be in place for observation and consequently better results during
> real
> implementations**.
> 
> The proposed sentence appears problematic from two perspective. One
> that it
> might be an overly complex solution for certain closed systems.
> Secondly, is it really "call admission" rather than flow admission?
> 
> I think the right way forward here is that you document the security
> issues
> that anyone that intend to deploy this needs to consider. I think
> that
> discussion can discuss potential mitigations, but without specific
> surround
> contexts it is impossible to mandate any such.
> 
> Cheers
> 
> Magnus
> 
> 
> 
> 
> Hope this address your few concerns and based on your response we
> will update the draft.
> 
> Happy to receive your further thoughts and valuable inputs.
> 
> Thanks & Regards,
> Lijo Thomas
> 
> -----Original Message-----
> From: 6lo <6lo-bounces@ietf.org> On Behalf Of Magnus Westerlund
> Sent: 03 June 2019 18:27
> To: Charlie Perkins <charles.perkins@earthlink.net>; The IESG <
> iesg@ietf.org>
> Cc: draft-ietf-6lo-deadline-time@ietf.org; 6lo-chairs@ietf.org;
> Samita Chakrabarti <samitac.ietf@gmail.com>; Shwetha Bhandari <
> shwethab@cisco.com>; 6lo@ietf.org
> Subject: Re: [6lo] Magnus Westerlund's Discuss on
> draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
> 
> Hi Charlie,
> 
> Please see for further comments inline.
> 
> On 2019-05-30 23:16, Charlie Perkins wrote:
> 
> On 5/13/2019 6:41 AM, Magnus Westerlund via Datatracker wrote:
> 
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-6lo-deadline-time-04: Discuss
> 
> 
> 
> 
> --------------------------------------------------------------------
> -
> -
> DISCUSS:
> --------------------------------------------------------------------
> -
> -
> 
> The security consideration section have significant short comings as
> this mechanism enables multiple ways to attack both the packet and
> the system to my understanding. I would appreaciate your
> clarifications
> on these matters.
> 
> First of all by changing the dead-line so that it gets dropped
> because it is already late, alternatively move the deadline time out
> further in time (later), so that the forwarders may deliver it so
> late that the receiver considers it to late.
> Agreed that this vulnerability should be mentioned in the Security
> Considerations.
> 
> 
> 
> Secondly, there is the question if extensive use of this header will
> cause overload or affect the scheduling of packet transmission affect
> other traffic negatively. There appear to exist potential for new
> ways of bad interflow interactions here.
> If other packet transmissions have to be pre-empted in order for the
> deadline to be met for a particular packet, then indeed this could
> affect other traffic. It is also a matter of possible interest what
> might happen if there were two packets in the transmission queue with
> the same or different deadlines. However, the processing in these
> cases is a local matter at each intermediate point, and out of scope
> for
> this
> 
> draft. Does this also belong to be mentioned in the Security
> Considerations?
> Yes, I think so, as it points to a requirement to consider either
> admission control or other solutions to keep the interaction on an
> acceptable level.
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> -
> -
> COMMENT:
> --------------------------------------------------------------------
> -
> -
> 
> Looking at this mechanism it appears to me as something that should
> fit into a frame work, but that is not explicitly given. The main
> reason I am raising that is that it appears to not care about a
> number of interesting and challenging questions for a mechanism like
> this. Questions that a particular framework can take care of, or
> which any user of this mechanism would need to consider in their
> deployment before they can determine if they can safely deploy it. It
> might be that some of the questions have answers and I missed. In
> that case please straighten me out. And if you have some additional
> document that provides more detailed usage which discuss any of these
> issues I would appreciate a pointer.
> 
> This mechanism is a simple kind of signaling that could fit into
> various frameworks, and exploring that space would be pretty
> interesting. But it would represent a huge digression away from the
> point of this draft, which all along was intended to offer a simple
> mechanisms without getting involved with messy issues of policy. If
> there is something missing in the basic mechanism, then that should
> be fixed. But I don't see what is missing. Some of the discussion
> below is also relevant to this point.
> 
> So, there no specific first initial framework that this solution has
> been developed to support? And you say you do not want to deal with
> policy, and instead put that on the ones attempting to utilize it.
> Considering the security issues, and the higher layer requirements
> that this solution appears to create I think that is far from
> optimal. I really think this document should have a section making
> the assumptions about its expected deployments clear.
> 
> 
> 
> 
> So quesitons that I got when reading this specification:
> 
> 1. Are there any mechanism to provide feedback if the packets reach
> the receiver in time? If the sender sets the deadline shorter than
> the minimal one-way path delay, then all packets will be late. Will
> any feedback be provided that this is happening? In cases D=1 this
> appear to be a recipe for a black hole for the traffic. One can also
> end up in situation where a large fraction of the packet are late.
> This kind of signaling is far more appropriate at the application
> level. To fully characterize the expected distribution of latency
> values is out of scope for the draft, and the information needed
> would usually depend on the application. Some applications don't care
> much for dropped packets but don't want to handle packets coming in
> too late. For other applications, knowing the distribution would
> allow for setting a deadline that would usually all reception of 85%
> of the packets (or some percentage predetermined by the application).
> It's hard for me to see that as in scope for our draft.
> 
> Sure, but the document could make it clear that there exist a need to
> monitor the actual performance to know if the application will work
> successful
> 
> 
> 
> 
> 
> 2. Any mechanism that exist to determine what the expected latency
> are from sender to receiver?
> As above, I think this is most properly handled by the application
> 
> 
> 
> 3. Are there any type of admittance or policy approval to use this
> mechanism?
> 
> The policy details are out of scope for this draft. However, it might
> be worthwhile to mention that (similar to many QoS efforts) care must
> be taken to avoid abuse.
> 
> Please do.
> 
> 
> 
> 
> 4. What is the relationship between traffic with a dead-line and
> other traffic without a dead-line. Are traffic with a dead-line
> implicitly allowed to pre-empt other traffic or at least to delay it
> in
> its queue?
> 
> We don't specify that, and since it's a local matter at each node, a
> mandate would be unenforceable. However, if it is important, we could
> design an advisory extension to the draft for this purpose. The
> problem is that the application should not necessarily need to be
> involved with changing its behavior in response to (highly dynamic)
> traffic conditions.
> 
> Ok, I can agree that there is difficult to be descriptive here. As
> long at the potential impact is a discussed security issue I think
> this will be considered addressed.
> 
> 
> 5. As Barry noted, what are the protection against missuse?
> 
> These are issue that a framework or architecture would consider, I
> note that 
> https://datatracker.ietf.org/doc/draft-ietf-detnet-architecture/
> include some discussion of these topics. Still DETNET architecture
> appear
> more constrained when it comes to usage than what this mechanism
> through its examples.
> 
> I think it would be best to enlarge the discussion in the draft to
> explain about the potential for abuse. I don't see just how the
> simple mechanism at the level of 6LoRH should be charged with the
> responsibility for an entire framework, and I really hope that simple
> mechanisms such as this one can be found to have value even without
> specification of a much larger set of protections and repairs.
> 
> My questions where more coming from the aspect, how do you have been
> part of developing this technical solution without having at least
> one framework that addresses the raised issue?
> 
> Thus, my preference that in the absence of a framework to point at,
> that the assumptions on the hypothetical framework are documented.
> 
> Cheers
> 
> Magnus Westerlund
> 
> -------------------------------------------------------------------
> ---
> Network Architecture & Protocols, Ericsson Research
> -------------------------------------------------------------------
> ---
> Ericsson AB | Phone +46 10 7148287
> Torshamnsgatan 23 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> -------------------------------------------------------------------
> ---
> 
> 
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
> 
> 
> -------------------------------------------------------------------
> ---
> --------------------------------------
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
> 
> This e-mail is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. If you are not the
> intended recipient, please contact the sender by reply e-mail and
> destroy all copies and the original message. Any unauthorized review,
> use, disclosure, dissemination, forwarding, printing or copying of
> this email is strictly prohibited and appropriate legal action will
> be
> taken.
> 
> -------------------------------------------------------------------
> ---
> --------------------------------------
> 
> 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------