From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>, roll <roll@ietf.org>
Thread-Topic: [Roll] Node Ability to Participate (NAP)
Thread-Index: AQHNRIwAf/4MdCQwJU6OqNpRkXdUw5bvBkaw
Date: Thu, 7 Jun 2012 21:04:06 +0000
Deferred-Delivery: Thu, 7 Jun 2012 21:04:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD806E78C95@xmb-rcd-x01.cisco.com>
References: <CADnDZ893+npCLZxStpOQtm=gNfyShh6o6q-pNxSQC5b7EsM0+A@mail.gmail.com>
 <CADnDZ8-EirrhjXvx1-iZBtKrVEZUbvP6MUhGBs=Jhbw0cYC=uA@mail.gmail.com>
 <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com>
 <13731.1338814785@marajade.sandelman.ca>
 <CADnDZ88prkVhco73YrHgnQ=8R9JH2GWnFTUj_GMouiQPWbkPyg@mail.gmail.com>
 <4787.1338995178@marajade.sandelman.ca>
 <CADnDZ8_3T-07UQ3h7MTLRU52qq6fhAv216vPdV4Wke-bFNyZYA@mail.gmail.com>
 <17448.1339014690@marajade.sandelman.ca>
 <CADnDZ89OYhXM=9BuAxfjo9xF8_oe+F_Cpfr1mN+f4_GXeFzVHA@mail.gmail.com>
In-Reply-To: <CADnDZ89OYhXM=9BuAxfjo9xF8_oe+F_Cpfr1mN+f4_GXeFzVHA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: roll-owner <roll-owner@ietf.org>
Subject: Re: [Roll] Node Ability to Participate (NAP)
Precedence: list

Hello Abdussalam:

I'd say it is a great discussion that might end up impacting routing. But a=
lso 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 t=
hought 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=20

Purpose: This list is for the discussion related to the management of const=
rained networks and devices. The IETF so far has not developed specific tec=
hnologies for the management of constrained networks. There is a need to un=
derstand the requirements for the management of such a constrained network =
and its devices.=20
"

Cheers,

Pascal


-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Abd=
ussalam 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 participa=
te (NAP) in LLN functions?

I think that the node ability (considering; energy consumption issue, routi=
ng issue, and environment-event issue), it is good for some node-originator=
s to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-r=
oute, 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, n=
or sure if it can make side effects to LLN performance. The node-ability ca=
n be useful if we have different devices capabilities and conditions. This =
knowledge-factor can be useful and may be included in some technique, or fo=
rwarding table in the protocol specification.

I want to know your advises and opinion, thanking you,

Best regards

Abdussalam Baryun,
University of Glamorgan, UK.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
<  One may be wrong, or may be right, but it does not matter if we work tog=
ether as a group to discuss and resolve all issues. IETF WGs are always rig=
ht >
***************************************************************************=
*************
This email and any attachments are confidential to the intended recipient a=
nd may also be privileged. If you are not the intended recipient please del=
ete it from your system and notify the sender. The contents are comply to t=
he IETF regulations, and WG procedures. You should not copy the email nor u=
se it for any purpose other than IETF procedures' purposes.
***************************************************************************=
**************
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll