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

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: coma@ietf.org
Archive:  http://www.ietf.org/mail-archive/web/coma/
To subscribe:  https://www.ietf.org/mailman/listinfo/coma 

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. 
"

Cheers,

Pascal

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] 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
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll