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

Hi, 

Could RFC6551 (the ex-metric draft) help ?

I think the metric container option could  embed a constraint to adress the NAP functionality you are describing 

Best,

Cédric.
-----Message d'origine-----
De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Abdussalam Baryun
Envoyé : vendredi 8 juin 2012 05:48
À : Pascal Thubert (pthubert)
Cc : roll; roll-owner
Objet : Re: [Roll] Node Ability to Participate (NAP)

Hi Pascal,

I was thinking of route-control enhancement, not network management, however, I agree it is an iteresting issue as well, you gave me a new point, thanks,

Abdussalam Baryun
=======================
On 6/7/12, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 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
>
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll