Re: [Roll] Request for Comments for ROLL Charter

Hello Pascal, Michael,

Isn't it too restrictive if we limit the text to the non-storing and 
storing modes only?
IMO other modes, like the "P2P Route Discovery" mode as defined inRFC6997
and future modes (if planned) could also benefit from those improvements.

How about:
Additional protocol elements to reduce bytes over the air and/or the 
amount of accumulated routing states.

On 06/28/2016 03:49 PM, Pascal Thubert (pthubert) wrote:
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>>     > Additional protocol elements to reduce source route headers in
>>     > non-storing mode and/or memory consumption in storing mode such as
>>     > route projection and BIER.
>> It sounds too prescriptive, as if we have limited ourselves in the charter to those two methods.  I don't think that this is your intention.
> Agreed, Michael. We can bar from " such as ..." on.
>
> Cheers,
>
> Pascal
>
>
>> -----Original Message-----
>> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson
>> Sent: mardi 28 juin 2016 14:47
>> To: Routing Over Low power and Lossy networks <roll@ietf.org>
>> Cc: peter van der Stok <stokcons@xs4all.nl>
>> Subject: Re: [Roll] Request for Comments for ROLL Charter
>>
>>
>> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>>      > Additional protocol elements to reduce source route headers in
>>      > non-storing mode and/or memory consumption in storing mode such as
>>      > route projection and BIER.
>>
>> It sounds too prescriptive, as if we have limited ourselves in the charter to those
>> two methods.  I don't think that this is your intention.
>>
>> If you wrote:
>>
>>      > Additional protocol elements to reduce source route headers in
>>      > non-storing mode and/or memory consumption in storing mode.
>>      > These elements may leverage mechanisms such as route projection and
>> BIER.
>>
>> would be clearer that these are not the only two admissible methods.
>> I'm not sure that we need to say what the methods are *at all*
>>
>>      > There is a wide scope of application areas for LLNs, including
>>      > industrial monitoring, building automation (HVAC, lighting, access
>>      > control, fire), connected homes, health care, environmental monitoring,
>>      > urban sensor networks (e.g. Smart Grid), asset tracking.  The Working
>>      > Group focuses on routing solutions for a subset of these: connected
>>      > home, building and urban sensor networks for which routing requirements
>>      > have been specified. These application-specific routing requirement
>>      > documents were used for protocol design.
>>
>>      > The Working Group focuses on IPv6 routing architectural framework for
>>      > these application scenarios. The Framework will take into consideration
>>      > various aspects including high reliability in the presence of time
>>      > varying loss characteristics and connectivity while permitting
>>      > low-power operation with very modest memory and CPU pressure in
>>      > networks potentially comprising a very large number (several thousands)
>>      > of nodes.
>>
>> I'd like these two paragraphs removed as being ancient motherhood text.
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -=
>> IPv6 IoT consulting =-
>>
>>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll