Re: [OPSAWG] Review of draft-opsawg-ersue-coman-*-00
"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> Mon, 03 February 2014 19:27 UTC
Return-Path: <mehmet.ersue@nsn.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1919E1A01E7 for <opsawg@ietfa.amsl.com>; Mon, 3 Feb 2014 11:27:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 vcDOVW9PDlkS for <opsawg@ietfa.amsl.com>; Mon, 3 Feb 2014 11:27:30 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6D1A01CE for <opsawg@ietf.org>; Mon, 3 Feb 2014 11:27:29 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s13JRRSY018824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Feb 2014 20:27:28 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s13JRQRI002830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Feb 2014 20:27:27 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 3 Feb 2014 20:27:26 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Mon, 3 Feb 2014 20:27:26 +0100
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: "'ext Sehgal, Anuj'" <s.anuj@jacobs-university.de>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Review of draft-opsawg-ersue-coman-*-00
Thread-Index: AQHPCPQWWEuKpIexs0+SqAGsC1Q1oJpzxoIAgARU1bA=
Date: Mon, 03 Feb 2014 19:27:25 +0000
Message-ID: <E4DE949E6CE3E34993A2FF8AE79131F8275142@DEMUMBX005.nsn-intra.net>
References: <C200CA8E-03C7-4EE6-B01B-C0629CDCFD73@jacobs-university.de> <4BBB7BFA-A744-40F2-803E-83ADB957F198@jacobs-university.de> <4B92C175-DBEC-492B-B4B1-FEC68522D9A2@jacobs-university.de>
In-Reply-To: <4B92C175-DBEC-492B-B4B1-FEC68522D9A2@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.121]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 4559
X-purgate-ID: 151667::1391455648-00001A6F-D7E8FF08/0-0/0-0
Subject: Re: [OPSAWG] Review of draft-opsawg-ersue-coman-*-00
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 19:27:33 -0000
Hi Anuj, thank you for your thorough review. See below (ME: ). 1.3 Network Types and Characteristics in Focus ---------------------------------------------- (a) "Mobile Adhoc networks (MANET) are self-configuring _infrastructureless_ networks of mobile devices connected by wireless technologies." --> Why is a differentiation being made between MANETs and other types of wireless networks? Couldn't moblie phones technically fit into the IoT as well? Is the differentiation only made based on the _infrastructureless_ part of it? If so, does it make sense to have categories of infrastructure and infrastructureless, rather than MANET and non-MANET networks? ME: I can go with your proposal to use infrastructureless networks and give MANET as an example. I think Car-to-car networks is another example but this wouldn't be necessarily constrained. I think mobile phones shouldn't be counted as constrained devices. (b) "Wireline non-constrained networks are mainly used for specific applications like Building Automation or Infrastructure Monitoring. However, wireline and wireless networks with multi-hop or point-to- multipoint connectivity are especially in the interest of the analysis on the management of constrained devices in this document." --> This paragraph is unclear. What is it trying to convey? Is it saying that only wireline multi-hop and point-to-multipoint are within the scope of this document? Why not regular wireline networks that may have constrained devices as part of a non-constrained network? ME: By saying they are "especially in the interest of the analysis the text does not exclude the others. Non-constrained wireline networks with constrained devices are in scope (e.g. Building automation). --> There is talk about bandwidth, but not frame size, which is likely to have a bigger impact than the overall bandwidth available in a channel. Maybe this should be mentioned? ME: In section 3.11. Implementation Requirements we talk on protocol message size. Though we don't talk on frame size 1.6. Managing the Constrainedness of a Device or Network --------------------------------------------------------- (a) "might only be able to support one simple communication protocol, i.e. the management protocol needs to be possible to downscale from constrained (C2) to very constrained (C0) devices" --> Is it important that the same management protocol be applicable to the entire range of constrained devices? Why not allow the capabilities of the management protocol to scale up and down with the type/capabilities of the device at hand? SOLUTION: A new bullet point stating that different management protocols work on different class of devices. ME: It is for sure possible that different management protocols work on different class of devices. Though it is desirable that the protocol is prepared for downscaling enabling the use of same type of message and information exchange as well as easy mapping of protocol commands. (b) "might only be able to support limited or no user and/or transport security" AND "might only be able to support very simple encryption" --> Simple encryption doesn't make sense, maybe it should be efficient encryption instead? ME: I can agree with "efficient for memory and CPU usage". Efficient only does not explain what we want to say. (c) "might also need energy-efficient key management algorithms for security." --> Not just energy-efficient, but also memory, processing and etc. efficient. No? SOLUTION: Change text to only efficient key management. ME: I think it needs to described what kind of efficiency we mean. Cheers, Mehmet > -----Original Message----- > From: ext Sehgal, Anuj [mailto:s.anuj@jacobs-university.de] > Sent: Saturday, January 04, 2014 3:28 AM > To: opsawg@ietf.org > Cc: Ersue, Mehmet (NSN - DE/Munich); Schönwälder, Jürgen > Subject: Re: Review of draft-opsawg-ersue-coman-*-00 > > Hi, > > As per the call for reviewing the COMAN documents, I have taken a look at the latest > versions and have a few comments/recommendations for both. The reviews, along > with suggestions on fixing them, are attached to this email in appropriate files. > > Regards, > Anuj Sehgal
- Re: [OPSAWG] Review of draft-opsawg-ersue-coman-*… Sehgal, Anuj
- Re: [OPSAWG] Review of draft-opsawg-ersue-coman-*… Ersue, Mehmet (NSN - DE/Munich)