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