Subject: Re: [Roll] Comments For ROLL terminology-06

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Wed, 12 Dec 2012 10:51:47 +0000

Hi,

And sorry for the delay - 

On Aug 3, 2012, at 10:46 PM, Abdussalam Baryun wrote:

> Hi JP and All,
> 
> I need your comments/feedback on the below, and want to know if there
> will be update to the expired document.
> 
> Regards
> AB
> 
> On 7/5/12, Abdussalam Baryun <[email-masked]> wrote:
>> Hi Vasseur, and All,
>> 
>> Comments:
>> +++++++++
>> 
>> AB>general comment> ROLL is about routers/nodes/hosts Why not defined
>> :  Host, Node, Link, Interface
>> 
>> In the body of draft-06:-
>> 
>> Closed Loop Control: A process whereby a device controller controls
>> an actuator based on information sensed by one or more field devices.
>> 
>> AB>suggest> replace [process] with [procedure]
>> AB>suggest> replace [information] with [input information]
>> 
>> Downstream: Data direction traveling from outside of the LLN (e.g.
>> traffic coming from a LAN, WAN or the Internet) via a LBR.
>> 

JP> Done, thanks.

>> AB> suggest> remove the example, because first, ROLL is inside LLN not
>> outside, and second, most of the data-traffic MAY go from the LLN to
>> the Internet/LBR. IMHO downstream is in the direction of the havier
>> unit-flow.

JP> Ah but … the direction where the traffic is heavier really depends. There are applications/networks
where many packets travels upstream, few (but large) packets travel upstream; number of packets and
volume of traffic are thus different. Furthermore, upstream/downstream definition should stay agnostic to
the direction, otherwise this may lead to confusion and we need to keep it consistent with the RFCs.

>> 
>> AB> please note that if we use word [data] is different than
>> [message]. While using [message] we may mean all traffic includes data
>> and control messages, so the use of downstream and upstream as in
>> draft-06 will be ok, but if we mention data-direction IMHO the use
>> downstream-upstream will be the other way around.
>> 
>> AB> suggest> replace [data] with [message]
>> 

JP> Kept "data" to be consistent with RFC and usual IETF terminology.

>> Field Device:
>> AB> delete word> field

JP> This is the terminology used in literature though ...

>> MP2P: Multipoint-to-Point is used to describe a particular traffic
>> pattern (e.g. MP2P flows collecting information from many nodes
>> flowing inwards towards a collecting sink or an LBR).
>> 
>> AB>opinion> MP2P is not a traffic pattern it is a transmission method
>> 

JP> Ah no no … not in this case and this was debated on the mailing for quite some time. We are 
referring in this case to the traffic pattern, not the protocol (see RFC 6550).

Many thanks for your review !

JP.

>> I am not sure if the draft covers all terms used in ROLL protocols, I
>> will check and post on the same thread after. Thanking you,
>> 
>> Best Regards
>> 
>> Abdussalam Baryun
>> University of glamorgan, UK
>> +++++++++++++++++++++++++++++++++++++++++++++++++
>> I 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. 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 other purpose, nor disclose, nor distribute its
>> contents to any other person.
>> *****************************************************************************
>> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll