Re: [Roll] Node Ability to Participate (NAP)

"Pascal Thubert (pthubert)" <> Thu, 07 June 2012 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E11121F86A6; Thu, 7 Jun 2012 14:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OEV8Mzhiz3qZ; Thu, 7 Jun 2012 14:04:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EC79121F86A0; Thu, 7 Jun 2012 14:04:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3101; q=dns/txt; s=iport; t=1339103049; x=1340312649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UJDIyjtzRM2Fex+/9IsmYdrwtPShMrzhr+jqaM7kODg=; b=l/ndFirvu7F5HAboaFGOtEasJug6SAV86QkD+9g+x7q0LQIJaO1pPL8J sTjDqdn3EDvgWmSPER+Spo105YK93d5WXMGtQUB6169rf4jr0lE0vNXmN Vj3Qnny5StCE/loUnCgYpsbofwBUcbfPjO3oQILPGNEXlvr6WK4KduFIJ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="90524047"
Received: from ([]) by with ESMTP; 07 Jun 2012 21:04:06 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q57L46RY007179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jun 2012 21:04:06 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Thu, 7 Jun 2012 16:04:06 -0500
From: "Pascal Thubert (pthubert)" <>
To: Abdussalam Baryun <>, roll <>
Thread-Topic: [Roll] Node Ability to Participate (NAP)
Thread-Index: AQHNRIwAf/4MdCQwJU6OqNpRkXdUw5bvBkaw
Date: Thu, 07 Jun 2012 21:04:06 +0000
Deferred-Delivery: Thu, 7 Jun 2012 21:04:00 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--49.132200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: roll-owner <>
Subject: Re: [Roll] Node Ability to Participate (NAP)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jun 2012 21:04:10 -0000

Hello Abdussalam:

I'd say it is a great discussion that might end up impacting routing. But also basic network operations (DNS, DHCP ...) and services.
So where is the right place to start with?
Tthe COMA mailing list is starting about network management, and I'd have thought that your discussion could begin there.

What do you think?

List address:
To subscribe: 

Purpose: This list is for the discussion related to the management of constrained networks and devices. The IETF so far has not developed specific technologies for the management of constrained networks. There is a need to understand the requirements for the management of such a constrained network and its devices. 



-----Original Message-----
From: [] On Behalf Of Abdussalam Baryun
Sent: jeudi 7 juin 2012 11:00
To: roll
Cc: roll-owner
Subject: [Roll] Node Ability to Participate (NAP)

+++++++++++++++++  Possible Duplication +++++++++++++++++++++++
Hi All,

I want to discuss is there a need to consider the node ability to participate (NAP) in LLN functions?

I think that the node ability (considering; energy consumption issue, routing issue, and environment-event issue), it is good for some node-originators to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP to-manage, or other abilities), but not sure if it is available in some of the ROLL or 6lowpan protocols, nor sure if it can make side effects to LLN performance. The node-ability can be useful if we have different devices capabilities and conditions. This knowledge-factor can be useful and may be included in some technique, or forwarding table in the protocol specification.

I want to know your advises and opinion, thanking you,

Best regards

Abdussalam Baryun,
University of Glamorgan, UK.
<  One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. IETF WGs are always right >
This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any purpose other than IETF procedures' purposes.
Roll mailing list