From abdussalambaryun@gmail.com  Tue Jul  3 04:24:12 2012
Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C9621F87EC; Tue,  3 Jul 2012 04:24:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.468
X-Spam-Level: 
X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k26AMwQ85M6R; Tue,  3 Jul 2012 04:24:09 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C82E21F86FA; Tue,  3 Jul 2012 04:24:09 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so4536036vbb.31 for <multiple recipients>; Tue, 03 Jul 2012 04:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m083XjFfH0EUxb6vgYU8i6j1omQNdjqvt27IPivW5Zw=; b=viY/egFGImJapOLlKWhl2U8A9AZCkAsnivzuEd4XwMsHaetUOPqByiUS5wFyd1Aa6y WYTNEOsysgPtlZObZhf/mfdKkYFD4tMK3NlLjtkn4pajR/x+QnX91S878vxm/gLFj5x2 anhNohIFMhAj22KoSk5/EBodAa412wlJsEzzu+o6ZElkEcd6Vvs3dD6o1yb8JtGU+Oib ruoymrtB+W9Q6cwYvsrN+2vhE1uhGvpLu9rYYlSFAQlQcfCm5BL04797PKz3Cl9wvdSp YtsO06XsE2aDpIPH+i4m8jIKzPf2hc09o/unLkUEuaXI8khp46MFmdTGZ5iOQCAeDup8 27ZQ==
MIME-Version: 1.0
Received: by 10.52.100.4 with SMTP id eu4mr6531999vdb.66.1341314656627; Tue, 03 Jul 2012 04:24:16 -0700 (PDT)
Received: by 10.220.110.130 with HTTP; Tue, 3 Jul 2012 04:24:16 -0700 (PDT)
Date: Tue, 3 Jul 2012 13:24:16 +0200
Message-ID: <CADnDZ89NQS+tFVDsBjb_TZ2B-jL-o95Gx2HA5AbpRf2a8CstSg@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: manet <manet@ietf.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: roll <roll@ietf.org>, ietf <ietf@ietf.org>
Subject: Re: [Roll] [manet] MANET Terminology Update
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2012 11:24:12 -0000

Dear All

I completed the first version of draft on terminology and submited the
draft yesterday (with getting some techniq problem), but needed to
post to know the community feedback and advise. There are other terms
that was not yet included which will need some advise from you.
Thanking you,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Abbreviations Used in The submitted Document

   AH   Authentication Header
   DAD  Duplicate Address Detection
   DPD  Duplicate Packet Detection
   DoS  Denial of Service
   ESP  Encapsulating Security Payload
   IP   IPv4 or IPv6
   ICMP Internet Control Message Protocol
   IIB  Interface Information Base
   ETX  Estimated Expected number of Transmission
   FIB  Forwarding Information Base
   LQI  Link Quality Indicator
   L2   Data Link Layer (i.e. 2nd layer in ISO model)
   L3   Internet Layer (i.e. 3rd layer in ISO model)
   LLN  Low power and Lossy Network
   MAC  Mediam Access Control
   MIB  Management Information Base
   MTU  Maximum Transmission Unit
   NBMA Non-Broadcast Multi-Access link
   NHDP Neighborhood Discovery Protocol
   ND   IP Neighbor Discovery
   OSPF Open Shortest Path First
   RIB  Routing Information Base
   SMF  Simplified Multicast Forwarding
   TCP  Transmission Control Protocol
   UDP  User Datagram Protocol

2.3 Definitions for MANET Terms

2.3.1 Terms Definition of MANET Communication:

Communications=92 Technology or Facility:
   The means employed by two or more devices/subsystems to transfer
   and/or receive information between them in one way or two way
   communication.  MANET communications often uses the wireless
   transmission medium(s) and MAY use some wired mediums (e.g. free
   space, air, water, antenna, coaxial cables, etc.)

Communication Medium:
   The transceiver system (e.g. such as L2 systems, IEEE802.11 systems,
   satellite system, etc.) that the routing device uses to communicates
   through the transmission medium(s), by providing connectionless and/or
   connection services that MAY be established. The system medium
   includes MAC layer and MAY include the physical Layer.

Communication Channel:
A subdivision of the physical communication medium (i.e. radio carrier
signal bandwidth, or the system bandwidth) allowing possibly shared
independent uses of the medium. Channels may be made available by
subdividing the medium into; distinct time slots, distinct spectral
bands, or coding sequence, etc.

MANET Protocol:
The communication system/subsystem that operates and maintains the
ad hoc communication technology or facility within MANET. MANET routing
Protocols often apply distributed algorithms/techniques to disseminate
or forward routing messages within a MANET routing domain.

Topology:
An abstract representation of a network (physical or logical), as a
graph (G) whose topology is defined by a set of routers/bridges (V) that
communicate through set of links (E), where the G =3D (V, E).

Physical-level Topology:
A topology of the communication medium networks consists of routing
devices and physical links. This topology information is updated by
devices=92 technology in the L2 information Base.

Network-level Topology:
A topology of the communication system networks consists of routers and
links. This topology information is updated by routers in its RIB.

Multihop MANET:
A MANET that its node(s) MAY need(s) more than one IP hop to reach the
destination.

Reactive Routing:
An on-demand based routing protocol that operates route discover and
maintainance the route(s), to reach the demanded destination(s).

Proactive Routing:
A topology RIB based routing protocol that operates routes and maintains
the network topology, to reach its known destination(s). Each router
maintains routes to all reachable destinations at all times, whether or
not there is currently any demand to deliver packets to those
destinations.

Upper Layer:
a protocol layer above IP layer (e.g. as TCP, UDP, OSPF).

MANET Domain: TBD

MANET Signaling:
Sending and exchanging some MANET messages/information.

2.3.2 Terms Definition of MANET Elements

Node:
A device/subsystem that MUST implement IP and SHOULD participate in
MANET signaling. It either runs a MANET routing protocol or participate
in MANET signaling.

Router:
A MANET node that MUST implement a MANET routing protocol and forwards
IP packets not explicitly addressed to itself.

Host:
A node that is not a router. All destinations in MANET that receive
delivered data are hosts.

Link:
A link between two node interfaces. This link may be Logical
(i.e. virtual) link or physical link. Logical links are between two
logical interfaces and physical links are between two physical
interfaces. Links are either unidirectional or bidirectional
(links may be on-link and off-link: see RFC4861).


Physical Link:
a communication facility or medium over which the nodes can
communicate at the link layer, i.e., the layer immediately below
IP. Physical interfaces are the nodes=92 attachment to physical links.
Physical Link types are point-to-point, NBMA, multicast capable,
and shared-media, etc (see link types in ND [RFC4861]).

Logical (virtual) Link:
a communication facility (at L3, or upper-layer) over which nodes can
communicate. This logical link is between two MANET interfaces exists
if either can be heard by the other.

Link MTU:
the maximum transmission unit (i.e. maximum unit size in octets), that
can be conveyed in one transmission unit over the link.


Node Interface:
A node's point of attachment to a link. Each node MUST have at least one
interface that SHOULD be assigned an IP address. If there is/are more
than one interface(s) per node then the additional interface(s) MAY be
assigned an IP address. If an interface is not assigned to an IP address
it MUST be identified by the MANET routing protocol. An interface MAY be
assigned one or more addresses.

MANET Interface:
A node interface that participate in; exchange MANET information used in
MANET routing or exchange information in MANET neighbor node discovery
(e.g as the term used in RFC6130). A MANET interface MUST be assigned to
least one  address to communicate. A router interface MUST be
assigned a routable address which is the main address for the interface.


2.3.3 Terms Definition of MANET Identifications:

An interface MAY be assigned one or more addresses. If the interface is
a logical interface it MAY be assigned to only logical addresses, but if
it is a physical interface MAY be assigned with physical address
(e.g. MAC address) and/or logical address(es) (e.g. IP addresses,
MANET addresses).


MANET Address
A MANET-subnet, node, or interface address. Node and interface addresses
are either IP addresses or RFC5444 addresses. All subnet addresses are
unicast IP addresses.

Address Block and TLV: as specified in RFC5444

Routable address:
A subnet address which can be a destination address. A router MUST be
able to distinguish a routable address from a non-routable address.
Broadcast, and multicast addresses, limited in scope to less than the
entire MANET, MUST NOT be considered as routable addresses. Anycast
addresses MAY be considered as routable addresses.

Main address
A routable address (MANET address) that is assigned to one router's
MANET interface.

Originator address:
A node address of the node that originated a MANET message (this message
MUST include the originator address). It MAY be a routable or an
unroutable address.

subnet prefix
A bit string that consists of some number of initial bits of an IP
address.

Interface identifier
the remaining low-order bits in the node's IP address after the subnet
prefix. A number used to identify a node's interface on a link.

2.3.4 Terms Definition of MANET exchange information formats:

Packet:
A MANET packet of a header plus payload. These packets are either
IP packets or RFC5444 packets. RFC5444 packet MUST be encapsulated
in IP packet. Packets are generated by nodes to be sent to
destination(s) through MANET or through the Internet. RFC5444 packets
information MAY not be used only by MANET routers.

Message:
A MANET data message or routing control message. Routing control
messages are either MANET routing protocol messages or/and RFC5444
messages.

Type Length Value coding (TLV):
A generic way to represent MANET information (as in [RFC5444] and
[RFC5497]).

Frame:
A L2 protocol TLV with a header and payload. In some technologies the L2
operates a MANET routing protocol as a local area networking system.
Frames MAY encapsulate MANET packets to be tunneled through a
telecommunication network.

Route Request Message (RREQ)
A message is used to discover a valid route to a particular
destination address, called the RREQ Target Node. When a router
processes a RREQ it learns routing information on how to Originator
Node.

Route Reply Message (RREP)
A message is used to disseminate routing information about
the RREP Target Node to the RREQ Originator Node and the intermediate
routers.

Route Error Message (RERR)
A message is used to disseminate the information that a route is
not available for one or more particular addresses. A RERR message is
used to indicate that a router does not have a forwarding route
to one or more particular addresses.

2.3.5 Terms Definition Related to MANET Protocol Operation:

Hop-by-hop Routing: (TBD)
A dynamic routing that routes to destination by routing table.

Source Routing: (TBD)
A dynamic routing that its route path is provided in the IP packet.

Route Discovery: TBD

Route Maintenance: TBD

Neighbor discovery: (TBD)
A node discovers neighbors only if the node receives from it's
neighbors.


Multipoint relay (MPR): (TBD)
A router X1 is an MPR for a router Y1, if router Y1 has indicated
its selection of router X1 as an MPR in a recent HELLO message.
Router X1 may be a flooding MPR for Y1 if it is indicated to
participate in the flooding process of messages received from
router Y1, or it may be a routing MPR for Y1, if it is indicated to
declare link-state information for the link from X1 to Y1. It may
also be both at the same time.

MPR selector:
A router, Y, is a flooding/routing MPR selector of router X if
router Y has selected router X as a flooding/routing MPR.

Router Parameters:
boolean or numerical values, specified for each router, and not
specific to an interface. A router MAY change router parameter
values at any time, subject to some MANET constraints.

MANET Routing Metric:
A MANET routing cost that is governed by specific rules and properties
defined by the MANET routing protocol which captures specific link or
node characteristics. Examples of basic metrics are hop-count, ETX, LQI,
etc.

Distance Vector Metric
A metric class related to rules of the MANET interface and MANET path
distance. The metric can be calculated by the distance vector routing
algorithm class used by the MANET routing protocol. A metric of the
distance a message or piece of information has traversed. The minimum
value of distance is the number of IP hops traversed.

Link State Metric
A metric type related to the MANET network-topology status and logical
links' states. This metric is calculated by the link state routing
algorithm class used by the MANET routing protocol. A metric type maybe
EXT, LQL, etc.

Link Metric: TBD

Neighbor Metric: TBD

Path accumulated:
The RREQ message accumulates intermediate routers that are in path to
destination(s).

Protocol Sequence Number:
A Sequence Number related to a MANET protocol that maintained by each
protocol subsystem process. This sequence number is used by other
subsystems to identify the temporal order of protocol information
generated.

Router Sequence Number:
A router sequence number is maintained by each router process. The
sequence number is used by other routers to identify the temporal
order of routing information generated and ensure loop-free routes.

MANET Information Base:
A collection of information (in Table or Cache structure) maintained
by MANET protocols and which is to be made available to MANET routing
protocols. An Information Base may be associated with a MANET router
or with MANET interface (e.g. route request table, IIB, RIB, FIB, MIB).

RIB Entry:
The RIB entry is a conceptual data structure. Implementations may use
any internal representation that conforms to the semantics of a route
as specified in the router specification.

3. IP Considerations and Terminology

   All MANET nodes MUST implement IP and all MANET routers MUST
   run/implement  at least one MANET routing protocol. The
   terminologies described in this document can be used for
   IPv4-MANET and IPv6-MANET. The IPv4 addresses MAY be used in IPv6
   packets but IPv6 addresses MUST not be in IPv4 packets.

   IP address:
   IPv4 addresses or IPv6 addresses.

   IP Packet:
   The packet header plus payload as specified in [RFC791] and [RFC2460]
   for IPv4 and IPv6 respectively. It can encapsulate RFC5444 packets as
   specified by RFC5498.

   Mobile IP considerations:
   Mobile IP terms are provided in [RFC6275], and this technology
   assists nodes while connected through the Internet domain(s). MANET
   is an infrastructure-less network that is able to communicate with
   the Internet (i.e. an IP infrastructure network).

4. Security Consideration and Terminology

   It is RECOMMENDED that MANET routing protocols consider security
   issues because the MANET's transmission medium is wireless which make
   it vulnerable to attacks [ANJUM][RFC4593]. In some situations the
   routing information while traversing the MANET MAY be used by an
   intruder node, to obtain MANET data traffic or/and attack the MANET
   [HERBERG]. Forwarding protocols that use DPD techniques MAY be
   vulnerable to DoS attacks such as [RFC6621]. MANETs MAY be secured
   by using IPsec, AH, DAD, and ESP techniques, and other. However,
   it is RECOMMENDED that MANET detects attackers and possible threats.

   The following are some terminology related to MANET threats and
   security.

Attacker: A node, present in the network and which intentionally seeks
to compromise information based in MANET router(s). The Attacker MAY be
a compromised MANET router if obtained MANET identity or routing
information.

Compromised MANET Router: An attacker router, present in MANET and
which generates syntactically correct routing control messages. Control
messages emitted by compromised router(s) may contain additional
information, or omit information, as compared to a control message
generated by a non-compromised router located in the same MANET
topological position.

Legitimate MANET Router: A MANET router, which is not a Compromised
MANET Router.

Jamming Attack:
The attacker transmits massive amounts of interfering radio traffic,
which will prevent legitimate traffic (e.g., routing and data traffic)
on all or part of the MANET. Indirect jamming attacks MAY occur by
influencing Legitimate MANET Router to transmit unnecessary information.

Eavesdropping:
Obtaining a copy by the attacker of the transmitted MANET routing
information or the transmitted data information from its neighbor's
transmitted radio packet. Attacker=92s processes MANY be used by attacker
to mislead routing. Eavesdropping does not pose a direct threat to the
MANET or to its routing.

Identity Spoofing:
Attacker sends routing messages, pretending to have the MANET identity
of another node.

Link Spoofing:
Compromised MANET router sends routing messages to neighbor node(s)
providing incorrect set of link information.

Replay Attack:
A Compromised router in one MANET region records control traffic
information and replays the recorded information in a different MANET
region (this type of attack is also called the Wormhole attack).

Broadcast Storm:
Compromised MANET router may attack the MANET by attempting to change
the MANET flooding algorithm(s) to increase routing overheads or/and to
increase the route discovery delay. Broadcast storm degrades the data
traffic delivery and MANET performance.

Falsification in MANET:
The compromised MANET router sends false routing information into MANET.
False routing information received in MANET, MAY create unrealistic
information bases.

ICMP Attacks:
The generation of ICMPv6 error messages may be used by compromised MANET
router to attempt DoS attacks by sending an error-causing source routing
header in back-to-back datagrams. As the ICMP messages are passed to the
upper-layer processes, it is possible to perform attacks on the upper
layer protocols (e.g., UDP, TCP). Protocols at the upper layers are
RECOMMENDED to perform some form of validation to ICMP messages (using
the information contained in the payload of the ICMP message) before
acting upon them.

Source Routing Attacks: TBD

Acknowledgments:

This work has used/modified terms of the following documents: RFC2462,
RFC2501, RFC3561, RFC3626, RFC3753, RFC4728, RFC4861, RFC5444,
RFC6130,  RFC6621, [AODVv2], [OLSRv2], and [HERBERG],
Gratefully acknowledge to the IETF community and all contributions.

Reference:
   [HERBERG] Herberg, U., Yi, J., Clausen, T.,"Security Threats for
             NHDP", Work in progress, March, 2012.
   [ANJUM]   Anjum, F. and Mouchtaris, P. "Security for Wireless Ad Hoc
             Networks", John Wiley & Sons, March 2007.
             ISBN: 978-0-471-75688-0.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I hope to get some advise from the Internet community to make the
definitions more suitable/accurate, because I MAY misunderstood.
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

From abdussalambaryun@gmail.com  Thu Jul  5 08:36:44 2012
Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34BE21F873A for <roll@ietfa.amsl.com>; Thu,  5 Jul 2012 08:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.458
X-Spam-Level: 
X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixTn8ShfPUPR for <roll@ietfa.amsl.com>; Thu,  5 Jul 2012 08:36:44 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 132C321F86C9 for <roll@ietf.org>; Thu,  5 Jul 2012 08:36:43 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so6080208vbb.31 for <roll@ietf.org>; Thu, 05 Jul 2012 08:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=M4yLmjpzCSj5h99YPdkrsih392Ae7wCOSwLfiqh698I=; b=F+1R2kRRANtb4gzc2sOrMpgHhqAm/dfK4kL/Ibo/nCQtWfxDFeNa0VCRnaGvD3dZYl VdIm++OdagvuIUH8IdLgzjQxlhlbcpctb2LBUpeuQd0e2DaICNM9DAwYgxdS4pEXgylk LVd1NWhCAAp3mwJvZErr/K/vce4RmkfrkpLBhFLfOE5EjFqVOMhZZLznSEG/CxAFx3vO w2UmVafKpLJQdFoZLtdCPjVA2NA8MCNxWmUOl3PKZgvC/Zzsnahfg0+Gj5faufZye9wR 3ckpOQAXCsJzzXLSQHp4Rs7ktKZ6E1SWI070IDOE65E3JzyuP7sI3cIdJFaOCcfHtYeD JJ5Q==
MIME-Version: 1.0
Received: by 10.220.149.15 with SMTP id r15mr12834083vcv.1.1341502617528; Thu, 05 Jul 2012 08:36:57 -0700 (PDT)
Received: by 10.220.110.130 with HTTP; Thu, 5 Jul 2012 08:36:57 -0700 (PDT)
Date: Thu, 5 Jul 2012 17:36:57 +0200
Message-ID: <CADnDZ8_kjUidiPu-ZwGDoFdVdACPRYUGwrFg-euxnBb5WP7tuQ@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: JP Vasseur <jpv@cisco.com>, roll <roll@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Abdussalam Baryun <abdussalambaryun@googlemail.com>
Subject: [Roll] Comments For ROLL terminology-06
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2012 15:36:45 -0000

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.

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.

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]

Field Device:

AB> delete word> field

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

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

From mcr@sandelman.ca  Thu Jul  5 10:43:01 2012
Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2722221F8744 for <roll@ietfa.amsl.com>; Thu,  5 Jul 2012 10:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.626
X-Spam-Level: 
X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.328,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoXBzA6+z8iP for <roll@ietfa.amsl.com>; Thu,  5 Jul 2012 10:43:00 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D6A9221F872A for <roll@ietf.org>; Thu,  5 Jul 2012 10:42:59 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id A287A818B for <roll@ietf.org>; Thu,  5 Jul 2012 13:39:57 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 8488398C40; Thu,  5 Jul 2012 13:43:11 -0400 (EDT)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 68B8898C2D for <roll@ietf.org>; Thu,  5 Jul 2012 13:43:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
In-Reply-To: <10134.1337103877@marajade.sandelman.ca>
References: <20120430114209.21250.82110.idtracker@ietfa.amsl.com> <18151.1335822136@marajade.sandelman.ca> <BD8E8F5A-E564-49C9-96D0-55B76DA23AB0@cisco.com> <10134.1337103877@marajade.sandelman.ca>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 05 Jul 2012 13:43:11 -0400
Message-ID: <32407.1341510191@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] proposal for common table of contents for applicability statements
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2012 17:43:01 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


Here is my proposal for a common table of contents for applicability
statements.  I will turn this into an ID tomorrow.

Proposed template table of contents for applicability statements.

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  (RFC2119 reference)
     1.2.  References/Overview of requirements documents, both
           IETF and industry group.  (two pages maximum.  This text
           should be (very) technical, should be aimed at IETF *participant=
s*,
           not industry group participants, and should explain this
           industries' specific issues)
     1.3   Out of scope requirements.
           This should list other documents (if any) which deal with
           situations where things are not in scope for this document.

           (For instance, the AMI document tries to cover both line-powered
           urban metering networks, and energy-constrained metering network=
s,
           and also tries to deal with rural requirements.  This should
           be three or four documents, so this section should list the
           limits of what this document covers)

   2.  Deployment Scenario
     2.1.  Network Topologies=20
       I would like to see a single scenario described, with possibly
       multiple topologies that a single utility would employ.=20=20

     2.2.  Traffic Characteristics  . . . . . . . . . . . . . . . . .  6
       Explain what kind of traffic is being transmitted, where it is
       initiated, and what kinds of protocols (CoAP, multicast, HTTPS, etc.)
       are being used.  Explain what assumptions are being made about
       authentication and authorization in those protocols.

     for instance:
     2.2.1.  General=20=20
     2.2.2.  Source-sink (SS) communication paradigm=20
     2.2.3.  Publish-subscribe (PS, or pub/sub) communication
           paradigm=20
     2.2.4.  Peer-to-peer (P2P) communication paradigm=20=20
     2.2.5.  Peer-to-multipeer (P2MP) communication paradigm=20
     2.2.6.  Additional considerations: Duocast and N-cast=20
     2.2.7.  RPL applicability per communication paradigm=20


     2.3 Layer 2 applicability.
       Explain what layer-2 technologies this statement applies to, and
       if there are options, they should be listed generally here, and
       specifically in section 4.2.

   3.  Using RPL to Meet Functional Requirements=20=20
=20=20=20=20=20
     This should explain in general terms how RPL is going to be used=20
     in this network topology.  If trees that are multiple
     layers deep are expected, then this should be described so that the fa=
n=20
     out is understood.=20=20
     Some sample topologies (from simulations) should be explained, perhaps
     with images references from other publications.

     This section should tell an *implementer* in a lab, having a simulation
     tool or a building/city/etc. to use as a testbed, how to construct
     an LLN of sufficient complexity (but not too much) to validate an
     implementation.

   4.  RPL Profile=20=20
     This section should list the various features of RPL plus other layers
     of the LLN, and how they will be used.

     4.1.  RPL Features=20
       4.1.1.  RPL Instances=20
       4.1.2.  Storing vs. Non-Storing Mode
       4.1.3.  DAO Policy=20
       4.1.4.  Path Metrics=20
       4.1.5.  Objective Function=20
       4.1.6.  DODAG Repair=20
       4.1.7.  Multicast=20=20
       4.1.8.  Security=20
       4.1.9.  P2P communications=20

     4.2.  Layer-two features
       4.2.1.  Need layer-2 expert here.
       4.2.2.  Security functions provided by layer-2.
       4.2.3.  6LowPAN options assumed.
       4.2.4.  MLE and other things

      4.3.  Recommended Configuration Defaults and Ranges=20=20
       4.3.1.  Trickle Parameters=20
       4.3.2.  Other Parameters=20

   5.  Manageability Considerations=20
   6.  Security Considerations=20=20
     6.1. Security Considerations during initial deployment.
        (This section explains how nodes get their initial trust anchors,
        initial network keys.  It explains if this happens at the factory,
        in a deployment truck, if it is done in the field, perhaps
        like
        http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers=
/CullenJennings.pdf)

     6.2. Security Considerations during incremental deployment=20
        (This section explains how that replaces a failed node takes
        on the dead nodes' identity, or not.  How are nodes retired.
        How are nodes removed if they are compromised)

   7.  Other Related Protocols=20=20
   8.  IANA Considerations=20=20
   9.  Acknowledgements=20
   10. References=20
     10.1. Informative References=20
     10.2. Normative References=20


=2D-=20
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works=20
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQCVAwUAT/XSLoqHRg3pndX9AQItmwQAuhhpBBaaBq+sDd5Nh8HB4+nqSdUyhMqN
mCeULGwmgsq12NmuwHTBPHT3DAFqYDxdnDpTTHFJSc92jQ50rIhY7fGqiyHYoIDt
qWNZYAo/cTsdsY7WOwhg/5+uq8R1lgXmrTCyuEAmI1tsTZLn66D7fqUinDF3p8/7
OQO+PJsjNdQ=
=jSjZ
-----END PGP SIGNATURE-----
--=-=-=--

From abdussalambaryun@gmail.com  Fri Jul  6 01:24:39 2012
Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCB521F85E4 for <roll@ietfa.amsl.com>; Fri,  6 Jul 2012 01:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.469
X-Spam-Level: 
X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYvF-3cRD+7C for <roll@ietfa.amsl.com>; Fri,  6 Jul 2012 01:24:38 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 612C821F8630 for <roll@ietf.org>; Fri,  6 Jul 2012 01:24:38 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so6537702vbb.31 for <roll@ietf.org>; Fri, 06 Jul 2012 01:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mi5UeWJP5VQaa8VhPMjCVowkR6E73ycgN/R86+FuM/8=; b=PRBFEXI+b/43LEGK6n0NS0yiVNukJpcpclH+YKfBQXj4AanLMp5G5pnfAQbtjU6d2Q Egtd5xIxhiZC8osmuOmpGh0a+7GbYzvknuADkkpZt2bkCgdG6AALVzFvr1BmrOrLYwWN 3KcW/fS4O4OG2Blwsg5iyUD38S6MbKfzGGVgE25D+anjA8lysxGexqFo9lxqweeZnYcz jACgIPGdWDi7eeY1DKo4yuur/ELWUGG2wqSxoPLWc9agDs+8iaGu1cmwCyY33nCwykTV GSRFVOep1gmtJ2O28QgCVpKAf3hDc6B9UVusvXzqaXeJB90BDsyL4H6Zr23Qj3VMsnla +4gg==
MIME-Version: 1.0
Received: by 10.220.149.148 with SMTP id t20mr14086034vcv.12.1341563093795; Fri, 06 Jul 2012 01:24:53 -0700 (PDT)
Received: by 10.220.110.130 with HTTP; Fri, 6 Jul 2012 01:24:53 -0700 (PDT)
In-Reply-To: <CADnDZ883aso4+_2C=K=dpjqW+5nqXB0U2x7RP7nP5cqGFYkhWw@mail.gmail.com>
References: <CADnDZ883aso4+_2C=K=dpjqW+5nqXB0U2x7RP7nP5cqGFYkhWw@mail.gmail.com>
Date: Fri, 6 Jul 2012 10:24:53 +0200
Message-ID: <CADnDZ88rnMykqFLJxKPr0CbjPAcZ-betL5c1wmA-rR0EoXGbjA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll <roll@ietf.org>
Subject: Re: [Roll] proposal for common table of contents for applicability statements
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jul 2012 08:24:39 -0000

+1

I will do my best to participate and review, thanking you,

Regards
AB

> Date: Thu, 05 Jul 2012 13:43:11 -0400
> From: Michael Richardson <mcr+ietf@sandelman.ca>
> To: roll@ietf.org
> Subject: Re: [Roll] proposal for common table of contents for
>         applicability   statements
> Message-ID: <32407.1341510191@marajade.sandelman.ca>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Here is my proposal for a common table of contents for applicability
> statements.  I will turn this into an ID tomorrow.
>
> Proposed template table of contents for applicability statements.
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>      1.1.  Requirements Language  (RFC2119 reference)
>      1.2.  References/Overview of requirements documents, both
>            IETF and industry group.  (two pages maximum.  This text
>            should be (very) technical, should be aimed at IETF
> *participants*,
>            not industry group participants, and should explain this
>            industries' specific issues)
>      1.3   Out of scope requirements.
>            This should list other documents (if any) which deal with
>            situations where things are not in scope for this document.
>
>            (For instance, the AMI document tries to cover both line-powered
>            urban metering networks, and energy-constrained metering
> networks,
>            and also tries to deal with rural requirements.  This should
>            be three or four documents, so this section should list the
>            limits of what this document covers)
>
>    2.  Deployment Scenario
>      2.1.  Network Topologies
>        I would like to see a single scenario described, with possibly
>        multiple topologies that a single utility would employ.
>
>      2.2.  Traffic Characteristics  . . . . . . . . . . . . . . . . .  6
>        Explain what kind of traffic is being transmitted, where it is
>        initiated, and what kinds of protocols (CoAP, multicast, HTTPS,
> etc.)
>        are being used.  Explain what assumptions are being made about
>        authentication and authorization in those protocols.
>
>      for instance:
>      2.2.1.  General
>      2.2.2.  Source-sink (SS) communication paradigm
>      2.2.3.  Publish-subscribe (PS, or pub/sub) communication
>            paradigm
>      2.2.4.  Peer-to-peer (P2P) communication paradigm
>      2.2.5.  Peer-to-multipeer (P2MP) communication paradigm
>      2.2.6.  Additional considerations: Duocast and N-cast
>      2.2.7.  RPL applicability per communication paradigm
>
>
>      2.3 Layer 2 applicability.
>        Explain what layer-2 technologies this statement applies to, and
>        if there are options, they should be listed generally here, and
>        specifically in section 4.2.
>
>    3.  Using RPL to Meet Functional Requirements
>
>      This should explain in general terms how RPL is going to be used
>      in this network topology.  If trees that are multiple
>      layers deep are expected, then this should be described so that the
> fan
>      out is understood.
>      Some sample topologies (from simulations) should be explained, perhaps
>      with images references from other publications.
>
>      This section should tell an *implementer* in a lab, having a
> simulation
>      tool or a building/city/etc. to use as a testbed, how to construct
>      an LLN of sufficient complexity (but not too much) to validate an
>      implementation.
>
>    4.  RPL Profile
>      This section should list the various features of RPL plus other layers
>      of the LLN, and how they will be used.
>
>      4.1.  RPL Features
>        4.1.1.  RPL Instances
>        4.1.2.  Storing vs. Non-Storing Mode
>        4.1.3.  DAO Policy
>        4.1.4.  Path Metrics
>        4.1.5.  Objective Function
>        4.1.6.  DODAG Repair
>        4.1.7.  Multicast
>        4.1.8.  Security
>        4.1.9.  P2P communications
>
>      4.2.  Layer-two features
>        4.2.1.  Need layer-2 expert here.
>        4.2.2.  Security functions provided by layer-2.
>        4.2.3.  6LowPAN options assumed.
>        4.2.4.  MLE and other things
>
>       4.3.  Recommended Configuration Defaults and Ranges
>        4.3.1.  Trickle Parameters
>        4.3.2.  Other Parameters
>
>    5.  Manageability Considerations
>    6.  Security Considerations
>      6.1. Security Considerations during initial deployment.
>         (This section explains how nodes get their initial trust anchors,
>         initial network keys.  It explains if this happens at the factory,
>         in a deployment truck, if it is done in the field, perhaps
>         like
>
> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/CullenJennings.pdf)
>
>      6.2. Security Considerations during incremental deployment
>         (This section explains how that replaces a failed node takes
>         on the dead nodes' identity, or not.  How are nodes retired.
>         How are nodes removed if they are compromised)
>
>    7.  Other Related Protocols
>    8.  IANA Considerations
>    9.  Acknowledgements
>    10. References
>      10.1. Informative References
>      10.2. Normative References
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 307 bytes
> Desc: not available
> URL:
> <http://www.ietf.org/mail-archive/web/roll/attachments/20120705/81bc77ee/attachment.sig>
>
> ------------------------------
>

From rdroms.ietf@gmail.com  Fri Jul  6 09:38:33 2012
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DBC21F86A7 for <roll@ietfa.amsl.com>; Fri,  6 Jul 2012 09:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.58
X-Spam-Level: 
X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNrUbOA5s1dS for <roll@ietfa.amsl.com>; Fri,  6 Jul 2012 09:38:31 -0700 (PDT)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 53E9F21F869E for <roll@ietf.org>; Fri,  6 Jul 2012 09:38:25 -0700 (PDT)
Received: by qcsg15 with SMTP id g15so7292315qcs.27 for <roll@ietf.org>; Fri, 06 Jul 2012 09:38:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=2taZ1Mwzvz0lJLI312am+/C7Bb1piijSxp8Vk5vd0NY=; b=HXtE6vb7rLTuu5ULqgny1gWoNZWPRyRVg2uVngVznay7KCNLMgX1DoU53kfhsUBIob 6P7BlIt2364W1a+SwPWqGMZ4GTP3SQSejDGT3/lng+MHxlXIVZ4Pzp8eGoNQuLr9Obyb QHvmiij9RXe3kFNM67iFIZP10ZLB6pX28Rek46e1D1fy5az3eldpKJkOAKLIfoJwUFmL 0gw/Ghg0th0hY/BzI9rcLUZixFPHMnU8qHFFGXez6l3yrxSYGA8YfH4WQ8QZ1GLQCqit gVv5o/WJXsoEpSx8RTs9JtodvnbM/iePvMiRHw9zGJMWUk5TOjDDD5Q56UjdOGyvQHDN OGRw==
Received: by 10.229.135.10 with SMTP id l10mr12100599qct.103.1341592721598; Fri, 06 Jul 2012 09:38:41 -0700 (PDT)
Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id p12sm50795526qae.0.2012.07.06.09.38.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 09:38:40 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu>
Date: Fri, 6 Jul 2012 12:38:37 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <914AE372-FA64-4A62-A029-F83F73CF9545@gmail.com>
References: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E30D@DLEE10.ent.ti.com> <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu>
To: roll <roll@ietf.org>
X-Mailer: Apple Mail (2.1278)
Subject: Re: [Roll] MRHOF ETX
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jul 2012 16:38:34 -0000

I'm reviewing the draft-ietf-roll-minrank-hysteresis-of-11, and I have a =
question...

On Jun 8, 2012, at 1:36 PM 6/8/12, Philip Levis wrote:

>=20
> On Jun 8, 2012, at 10:24 AM, Reddy, Joseph wrote:
>=20
>> The advertised Rank of the parent is a 16-bit value that has integer =
and fractional parts. The MinHopRankIncrease parameter determines the =
length of the Integer/Fraction parts.=20
>=20
> I think you're misreading MRHOF, and misinterpreting =
MinHopRankIncrease. The MRHOF draft tries to be very explicit about =
this. MRHOF with ETX encodes the ETX in Rank, but MinHopRankIncrease can =
change the computation. If MinHopRankIncrease is greater than 128, then =
Rank no longer really encodes a fixed-point version of ETX, it encodes =
ETX plus a per-hop penalty.
>=20
>> Now when the draft says to add the Rank and link ETX parameters, =
clearly this cannot be a simple addition of the Rank with either ETX or =
(ETX*128). Instead, the ETX value must be converted to the same =
Integer/Fraction representation as the Rank ( i.e., using =
MinHopRankIncrease )
>=20
> Disagree -- the draft is pretty explicit on what you do, and it's not =
this.

One place where the document is not explicit about operation with ETX - =
at least as far as I can tell - is in section 3.1:

   A non-root node
   computes a neighbor's path cost by adding two components:

   1.  If the selected metric is a link metric, the selected metric for
       the link to a candidate neighbor.  If the selected metric is a
       node metric, the selected metric for the node.

   2.  The value of the selected metric in the metric container in the
       DIO sent by that neighbor.

But, ETX is not carried in the metric container for this OF.  Perhaps =
the correct action, which I think would be to use the neighbor's rank as =
its ETX metric, can be inferred from section 3.4:

   Instead, a node MUST advertise an approximation of
   its ETX in its advertised Rank value, following the rules described
   in Section 3.3.

But section 3.3 isn't exactly clear, as it specifies how to convert a =
path cost to a rank.  And I might be entirely wrong about inferring how =
to compute a path cost using ETX.

Anyway, I suggest step 2 in section 3.1 ought to have some additional =
text explicitly describing how to compute a neighbor's path cost when =
the selected metric is ETX.

Just out of curiosity, and apologizing for not taking part in the =
discussion that lead to the design decision, why is ETX treated =
specially and is there danger of some information loss leading to =
less-than-optimal route generation with the way ETX is used?

- Ralph

>=20
> Phil
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From jvasseur@cisco.com  Fri Jul  6 11:39:23 2012
Return-Path: <jvasseur@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A12F11E80A5 for <roll@ietfa.amsl.com>; Fri,  6 Jul 2012 11:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb-450KVDEMl for <roll@ietfa.amsl.com>; Fri,  6 Jul 2012 11:39:22 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C6BC311E8079 for <roll@ietf.org>; Fri,  6 Jul 2012 11:39:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1461; q=dns/txt; s=iport; t=1341599980; x=1342809580; h=from:to:cc:subject:date:message-id:mime-version; bh=XvphRYf2rH5invVm1paQZJ1yB7PMCBkip5L6UQ5PWa4=; b=Kc5qWez+HCa93xdgKaw+j05NVL0TrChPfbzuAs78uM2Dctn+1GKo6z45 baUs63WW2sneVXxbNArIMWQrulZOVCie223j0zZmuTe5DoV/Qv2wyhb7j JvKYVbnGlflPDYNIUkDQ6rLLcrAi38YhFe1B2PcC/xaYIovOKTtXw+8NV U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EABsw90+tJV2Z/2dsb2JhbABFt0+BB4IPEBIBZhIBCwF0JwQBDSeHaZpWoCiQf2ADlTeOHYFmgl+BXw
X-IronPort-AV: E=Sophos;i="4.77,540,1336348800"; d="scan'208,217";a="99500467"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 06 Jul 2012 18:39:39 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q66IddVg005256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Jul 2012 18:39:39 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Fri, 6 Jul 2012 13:39:39 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: roll WG <roll@ietf.org>, Daniel King <daniel@olddog.co.uk>
Thread-Topic: Slot request IETF meeting in Vancouver
Thread-Index: AQHNW6ay7SATz9Ue2026sEvy4CbJtQ==
Date: Fri, 6 Jul 2012 18:39:38 +0000
Message-ID: <6BB369BB-FCF7-4211-86E9-A9BCC41535F2@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.114.232]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19024.001
x-tm-as-result: No--23.167500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_6BB369BBFCF7421186E9A9BCC41535F2ciscocom_"
MIME-Version: 1.0
Subject: [Roll] Slot request IETF meeting in Vancouver
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jul 2012 18:39:23 -0000

--_000_6BB369BBFCF7421186E9A9BCC41535F2ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

The ROLL WG will meet on:

   roll Session 1 (1:30:00)
   Friday, Afternoon Session I 1120-1220
   Room Name: Georgia B
   ---------------------------------------------

Please send an email to Dan and copy Michael and I for slot requests.

Thanks.

JP and Michael.

--_000_6BB369BBFCF7421186E9A9BCC41535F2ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <94055AFB7508EB47914E564B665A147B@cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
Dear all,&nbsp;
<div><br>
</div>
<div>The ROLL WG will meet on:</div>
<div><br>
</div>
<div>&nbsp; <b><i>&nbsp;roll Session 1 (1:30:00)</i></b></div>
<b><i>&nbsp;&nbsp;&nbsp;Friday, Afternoon Session I 1120-1220<br>
&nbsp;&nbsp;&nbsp;Room Name: Georgia B<br>
&nbsp;&nbsp;&nbsp;---------------------------------------------<br>
</i></b>
<div><br>
</div>
<div>Please send an email to Dan and copy Michael and I for slot requests.<=
/div>
<div><br>
</div>
<div>Thanks.</div>
<div><br>
</div>
<div>JP and Michael.</div>
</body>
</html>

--_000_6BB369BBFCF7421186E9A9BCC41535F2ciscocom_--

From abdussalambaryun@gmail.com  Sat Jul  7 03:15:48 2012
Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF5521F85A5 for <roll@ietfa.amsl.com>; Sat,  7 Jul 2012 03:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.161
X-Spam-Level: 
X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 248VkGoApayV for <roll@ietfa.amsl.com>; Sat,  7 Jul 2012 03:15:48 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF11921F858F for <roll@ietf.org>; Sat,  7 Jul 2012 03:15:47 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so7157438vbb.31 for <roll@ietf.org>; Sat, 07 Jul 2012 03:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6c82+vaa//C9P61RDH9CP5w2KLlw/dqxXL4hGAhVzqA=; b=sO2CsAS7B0qPIYJ/BJ0S5+4WlplZ+JfhEjfzpXOjGIQhWhccElp064D3q2H/iWwJE2 6CfGx9+WZSX+qow/+nTSTEeDxNbB8wsSQXdh5gyYaRCJrURAHwiUdLBqL/sTPSXh8ANH hbmDFlotOSAJZu7JpA0i8n5uwg9VBSC1TwwO1xu6bxsS3p6fY1IM/U2xoLI/SPsLROgF nACahLUttlsxFWdF1cBjXHwBJC/EdvG+BL0WGni8OUC8/7LEkI3bKenuAC4dWF1BgjT2 aPiL2dXK58YFl/js9AedYbT3AkBrAraKa8ZGoKYbK/GyTBympKckzZr97vt/Kc1MBFMS /vpQ==
MIME-Version: 1.0
Received: by 10.52.94.36 with SMTP id cz4mr13576565vdb.10.1341656166527; Sat, 07 Jul 2012 03:16:06 -0700 (PDT)
Received: by 10.220.110.130 with HTTP; Sat, 7 Jul 2012 03:16:06 -0700 (PDT)
In-Reply-To: <CADnDZ8_kjUidiPu-ZwGDoFdVdACPRYUGwrFg-euxnBb5WP7tuQ@mail.gmail.com>
References: <CADnDZ8_kjUidiPu-ZwGDoFdVdACPRYUGwrFg-euxnBb5WP7tuQ@mail.gmail.com>
Date: Sat, 7 Jul 2012 12:16:06 +0200
Message-ID: <CADnDZ8_2qXNrwvb9JOFSMw=KqJitAnEE0o+Ojdt=YPNx04PJdA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: roll <roll@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Roll] Comments For ROLL terminology-06
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jul 2012 10:15:49 -0000

I suggest also to add in section-4 [1], security terms that are
related to ROLL (or Terminology in ROLL security). IMO in any document
of defining terms, we can consider their implications or when do we
use these terms and terms related to the technology under study (e.g.
ROLL, MANET,  etc) . I use this approach in I-D [2].

[1] http://tools.ietf.org/id/draft-ietf-roll-terminology-06.txt
[2] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt

AB
+++++++++++++++++++++++++++++++++++++++++++++++++++++
On 7/5/12, Abdussalam Baryun <abdussalambaryun@gmail.com> 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.
>
> 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.
>
> 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]
>
> Field Device:
>
> AB> delete word> field
>
> 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
>
> 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.
> *****************************************************************************
>

From gnawali@cs.uh.edu  Sat Jul  7 04:09:48 2012
Return-Path: <gnawali@cs.uh.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0E721F85B1 for <roll@ietfa.amsl.com>; Sat,  7 Jul 2012 04:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.677
X-Spam-Level: 
X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgxuS8x3z9uS for <roll@ietfa.amsl.com>; Sat,  7 Jul 2012 04:09:47 -0700 (PDT)
Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 852CE21F8564 for <roll@ietf.org>; Sat,  7 Jul 2012 04:09:47 -0700 (PDT)
Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id E19C723CA8A for <roll@ietf.org>; Sat,  7 Jul 2012 06:09:58 -0500 (CDT)
X-Virus-Scanned: amavisd-new at cs.uh.edu
Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi2-C+lFuMkb for <roll@ietf.org>; Sat,  7 Jul 2012 06:09:56 -0500 (CDT)
Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 57C8623CA89 for <roll@ietf.org>; Sat,  7 Jul 2012 06:09:56 -0500 (CDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by it.cs.uh.edu (Postfix) with ESMTP id 33B532A2807B for <roll@ietf.org>; Sat,  7 Jul 2012 06:09:44 -0500 (CDT)
Received: by pbcwy7 with SMTP id wy7so16501413pbc.31 for <roll@ietf.org>; Sat, 07 Jul 2012 04:09:57 -0700 (PDT)
Received: by 10.66.82.2 with SMTP id e2mr51724515pay.67.1341659397677; Sat, 07 Jul 2012 04:09:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.9.202 with HTTP; Sat, 7 Jul 2012 04:09:37 -0700 (PDT)
In-Reply-To: <914AE372-FA64-4A62-A029-F83F73CF9545@gmail.com>
References: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E30D@DLEE10.ent.ti.com> <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu> <914AE372-FA64-4A62-A029-F83F73CF9545@gmail.com>
From: Omprakash Gnawali <gnawali@cs.uh.edu>
Date: Sat, 7 Jul 2012 04:09:37 -0700
Message-ID: <CAErDfUQwb50PuqgCHU2LeO1b48a1dF9iFNWGfOe2z5ygiH3P8A@mail.gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: roll <roll@ietf.org>
Subject: Re: [Roll] MRHOF ETX
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jul 2012 11:09:49 -0000

On Fri, Jul 6, 2012 at 9:38 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
> I'm reviewing the draft-ietf-roll-minrank-hysteresis-of-11, and I have a =
question...
>
> On Jun 8, 2012, at 1:36 PM 6/8/12, Philip Levis wrote:
>
>>
>> On Jun 8, 2012, at 10:24 AM, Reddy, Joseph wrote:
>>
>>> The advertised Rank of the parent is a 16-bit value that has integer an=
d fractional parts. The MinHopRankIncrease parameter determines the length =
of the Integer/Fraction parts.
>>
>> I think you're misreading MRHOF, and misinterpreting MinHopRankIncrease.=
 The MRHOF draft tries to be very explicit about this. MRHOF with ETX encod=
es the ETX in Rank, but MinHopRankIncrease can change the computation. If M=
inHopRankIncrease is greater than 128, then Rank no longer really encodes a=
 fixed-point version of ETX, it encodes ETX plus a per-hop penalty.
>>
>>> Now when the draft says to add the Rank and link ETX parameters, clearl=
y this cannot be a simple addition of the Rank with either ETX or (ETX*128)=
. Instead, the ETX value must be converted to the same Integer/Fraction rep=
resentation as the Rank ( i.e., using MinHopRankIncrease )
>>
>> Disagree -- the draft is pretty explicit on what you do, and it's not th=
is.
>
> One place where the document is not explicit about operation with ETX - a=
t least as far as I can tell - is in section 3.1:
>
> =A0 =A0A non-root node
> =A0 =A0computes a neighbor's path cost by adding two components:
>
> =A0 =A01. =A0If the selected metric is a link metric, the selected metric=
 for
> =A0 =A0 =A0 =A0the link to a candidate neighbor. =A0If the selected metri=
c is a
> =A0 =A0 =A0 =A0node metric, the selected metric for the node.
>
> =A0 =A02. =A0The value of the selected metric in the metric container in =
the
> =A0 =A0 =A0 =A0DIO sent by that neighbor.
>
> But, ETX is not carried in the metric container for this OF. =A0Perhaps t=
he correct action, which I think would be to use the neighbor's rank as its=
 ETX metric, can be inferred from section 3.4:
>
> =A0 =A0Instead, a node MUST advertise an approximation of
> =A0 =A0its ETX in its advertised Rank value, following the rules describe=
d
> =A0 =A0in Section 3.3.
>
> But section 3.3 isn't exactly clear, as it specifies how to convert a pat=
h cost to a rank. =A0And I might be entirely wrong about inferring how to c=
ompute a path cost using ETX.
>
> Anyway, I suggest step 2 in section 3.1 ought to have some additional tex=
t explicitly describing how to compute a neighbor's path cost when the sele=
cted metric is ETX.


Here is an excerpt from the terminology section:

Selected metric:  The metric chosen by the network operator to use
         for path selection.  MRHOF supports using a single metric for
         path selection.  The decision to use a metric (other than ETX)
         as the selected metric is indicated by the presence of the
         chosen metric in the DIO metric container.  The selection of
         the ETX metric is indicated by the absence of the metric
         container.


I believe that addresses your concern about the potential to confuse
the implementers about the use of ETX or other metric. The sentences
about how the selected metric is indicated (including ETX) in the
definition of selected metric was one the updates in -11.


> Just out of curiosity, and apologizing for not taking part in the discuss=
ion that lead to the design decision, why is ETX treated specially and is t=
here danger of some information loss leading to less-than-optimal route gen=
eration with the way ETX is used?

It is likely that ETX will be the most commonly used metric so we
decided to make this case the most byte-efficient. We don't see any
danger of loss of information due to this design decision.

- om_p

From rdroms.ietf@gmail.com  Sat Jul  7 17:29:03 2012
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DB721F85CE; Sat,  7 Jul 2012 17:29:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2lAAIvZ3rGj; Sat,  7 Jul 2012 17:29:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAFD21F850C; Sat,  7 Jul 2012 17:29:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "Ralph Droms" <rdroms.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.30p2
Message-ID: <20120708002902.10115.33905.idtracker@ietfa.amsl.com>
Date: Sat, 07 Jul 2012 17:29:02 -0700
Cc: roll <roll@ietf.org>, draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll-chairs@tools.ietf.org
Subject: [Roll] Ralph Droms' No Objection on	draft-ietf-roll-minrank-hysteresis-of-11: (with COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Jul 2012 00:29:03 -0000

Ralph Droms has entered the following ballot position for
draft-ietf-roll-minrank-hysteresis-of-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.




----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss points in the most recent
rev of this document.  I've cleared my Discuss.

While these comments are non-blocking, they should be considered
carefully as they are based on implementation experience with this
draft.

1. The second component of the path cost in section 3.1:

   2.  The value of the selected metric in the metric container in the
       DIO sent by that neighbor.

is incompletely described.  While an implementor should realize from
section 3.5 that the rank advertised by the neighbor is an
approximation for ETX and should be used here, the text as written is
incomplete.

2. Also for completeness, the document should specify the
representation used for ETX to be used in path cost computation; e.g.,
as specified for the ETX sub-object in RFC 6551.

3. Related to point 2, explanation of the relationship between the
representation used for ETX and rank should be explained, especially
considering what I think will be unexpected side effects of the value
of DEFAULT_MIN_HOP_RANK_INCREASE defined to be 256 in RFC 6550
interacting with the (presumed) default representation of ETX as
defines in RFC 6551.

4.  In section 3.4:

   If ETX is the selected metric, a node SHOULD NOT advertise it in a
   metric container.

s/SHOULD NOT/MUST NOT/ (and this text is redundant relative to the
last sentence of section 3.5).

5. Are the parameter values in section 5 recommended only for use when
the selected metric is ETX; seems to me MAX_LINK_METRIC, MAX_PATH_COST
and PARENT_SWITCH_THRESHOLD depend on the selected metric and the
recommended values wouldn't make much sense for, e.g., hop count.

These comments are purely editorial and offered to improve the clarity
of the document.

1. The paragraph immediately following table seems superfluous.  The
list of metrics for which the rank is undefined is not complete (from
RFC 6551).  The paragraph begs the question "why would the deployment
choose a metric for which the rank is undefined?"

2. Readability would be improved by writing the details of the
special-case treatment of ETX (currently in section 3.5) to the point
at which that special-case treatment modifies other behavior specified
in the document; e.g., the second component of the path cost cited
above.

3. The second sentence of section 6 is pretty opaque.  Is the point
that the "List of supported metrics" from section 18.2.3 need not be
supported if MRHOF is used?

4. Isn't the last paragraph of section 6.1 true for any selected metric?



From jvasseur@cisco.com  Sun Jul  8 05:58:42 2012
Return-Path: <jvasseur@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD77021F864E for <roll@ietfa.amsl.com>; Sun,  8 Jul 2012 05:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGhYr5ptKC8P for <roll@ietfa.amsl.com>; Sun,  8 Jul 2012 05:58:41 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6649821F8631 for <roll@ietf.org>; Sun,  8 Jul 2012 05:58:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9521; q=dns/txt; s=iport; t=1341752343; x=1342961943; h=from:to:cc:subject:date:message-id:references: mime-version; bh=2oeSfxw8ojgXbo98hsmvQa5Delo3wzn9OwtQf41gPDE=; b=Ta0B0QY9rZdLHuU8lvdLHUKGRwpTVOK4494l9y7hSBPEJVm/4PcGrAd1 4cj3xb1iceKp7fMQWUGAOAj0Rc5zAjqAvuvSTm3BMcCdjaACqfA+sfcSo ryLb0LtAVGtB/KoGS+knUDWKJQj8QTgVwYh71PGfycovlkeTbqF1Jnudn Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAAGD+U+tJXHA/2dsb2JhbABFt12BB4IcBAEBAQICAQEBDwFbCxACARkDAQIoBycLFAcCCAIEDgUJEAmFJweCJBkLmjeebItABRaFEWADlTaBEol1gxiBZoJf
X-IronPort-AV: E=Sophos;i="4.77,546,1336348800"; d="scan'208,217";a="96776944"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 08 Jul 2012 12:59:03 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q68Cx2Cx018609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jul 2012 12:59:02 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Sun, 8 Jul 2012 07:59:02 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: roll WG <roll@ietf.org>
Thread-Topic: I-D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt
Thread-Index: AQHNXQly3K+lnTPI2EmaRs91kVud0Q==
Date: Sun, 8 Jul 2012 12:59:02 +0000
Message-ID: <6E36F5C2-73CB-41FA-82E8-BFED6B6158D4@cisco.com>
References: <20120705134832.29937.21373.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.114.55]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19026.004
x-tm-as-result: No--43.725700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_6E36F5C273CB41FA82E8BFED6B6158D4ciscocom_"
MIME-Version: 1.0
Subject: [Roll] Fwd: I-D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Jul 2012 12:58:42 -0000

--_000_6E36F5C273CB41FA82E8BFED6B6158D4ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

As promised during the last IETF, here is an informational draft, showing o=
ne of the first large scale RPL-enabled networks in
production; the document will be updated soon with several other ones.

http://www.ietf.org/id/draft-hui-vasseur-roll-rpl-deployment-01.pdf

Thanks.

JP and Jonathan.

Begin forwarded message:

From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Subject: I-D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt
Date: July 5, 2012 3:48:32 PM GMT+02:00
To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Reply-To: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


Title           : RPL deployment experience in large scale networks
Author(s)       : JP Vasseur
                         Jonathan Hui
                         Sukrit Dasgupta
                         Giyoung Yoon
Filename        : draft-hui-vasseur-roll-rpl-deployment-01.txt
Pages           : 12
Date            : 2012-07-05

Abstract:
  Low power and Lossy Networks (LLNs) exhibit characteristics unlike
  other more traditional IP links.  LLNs are a class of network in
  which both routers and their interconnect are resource constrained.
  LLN routers are typically resource constrained in processing power,
  memory, and energy (i.e. battery power).  LLN links are typically
  exhibit high loss rates, low data rates, are are strongly affected by
  environmental conditions that change over time.  LLNs may be composed
  of a few dozen to thousands of routers.  A new protocol called the
  IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) has been
  specified for routing in LLNs supporting multipoint-to-point, point-
  to-multipoint traffic, and point-to-point traffic.  Since RPL's
  publication as an RFC, several large scale networks have been
  succesfully deployed.  The aim of this document is to provide
  deployment experience on real-life deployed RPL-based networks.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deployment

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-hui-vasseur-roll-rpl-deployment-=
01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--_000_6E36F5C273CB41FA82E8BFED6B6158D4ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <C55C62AF0568524D900B6CD7DDA91E4A@cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
Hi,
<div><br>
</div>
<div>As promised during the last IETF, here is an informational draft, show=
ing one of the first large scale RPL-enabled networks in</div>
<div>production; the document will be updated soon with several other ones.=
</div>
<div><br>
</div>
<div><a href=3D"http://www.ietf.org/id/draft-hui-vasseur-roll-rpl-deploymen=
t-01.pdf">http://www.ietf.org/id/draft-hui-vasseur-roll-rpl-deployment-01.p=
df</a></div>
<div><br>
</div>
<div>Thanks.</div>
<div><br>
</div>
<div>JP and Jonathan.<br>
<div><br>
<div>Begin forwarded message:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>From:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">&lt;<=
a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>&gt;=
<br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>Subject:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;"><b>I-=
D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt</b><br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>Date:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">July =
5, 2012 3:48:32 PM GMT&#43;02:00<br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>To:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">&lt;<=
a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org</a>&gt;<br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>Reply-To:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">&lt;<=
a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>&gt;=
<br>
</span></div>
<br>
<div><br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
<br>
<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Title &nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: RPL deployment exp=
erience in large scale networks<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Author(s) &=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: JP Vasseur<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
Jonathan Hui<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
Sukrit Dasgupta<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
Giyoung Yoon<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Filename &n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: draft-hui-vasseur-roll-rpl-deploy=
ment-01.txt<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Pages &nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 12<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Date &nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 2012-07-05<br=
>
<br>
Abstract:<br>
&nbsp;&nbsp;Low power and Lossy Networks (LLNs) exhibit characteristics unl=
ike<br>
&nbsp;&nbsp;other more traditional IP links. &nbsp;LLNs are a class of netw=
ork in<br>
&nbsp;&nbsp;which both routers and their interconnect are resource constrai=
ned.<br>
&nbsp;&nbsp;LLN routers are typically resource constrained in processing po=
wer,<br>
&nbsp;&nbsp;memory, and energy (i.e. battery power). &nbsp;LLN links are ty=
pically<br>
&nbsp;&nbsp;exhibit high loss rates, low data rates, are are strongly affec=
ted by<br>
&nbsp;&nbsp;environmental conditions that change over time. &nbsp;LLNs may =
be composed<br>
&nbsp;&nbsp;of a few dozen to thousands of routers. &nbsp;A new protocol ca=
lled the<br>
&nbsp;&nbsp;IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) ha=
s been<br>
&nbsp;&nbsp;specified for routing in LLNs supporting multipoint-to-point, p=
oint-<br>
&nbsp;&nbsp;to-multipoint traffic, and point-to-point traffic. &nbsp;Since =
RPL's<br>
&nbsp;&nbsp;publication as an RFC, several large scale networks have been<b=
r>
&nbsp;&nbsp;succesfully deployed. &nbsp;The aim of this document is to prov=
ide<br>
&nbsp;&nbsp;deployment experience on real-life deployed RPL-based networks.=
<br>
<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-depl=
oyment">https://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deploym=
ent</a><br>
<br>
There's also a htmlized version available at:<br>
http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01<br>
<br>
A diff from previous version is available at:<br>
http://tools.ietf.org/rfcdiff?url2=3Ddraft-hui-vasseur-roll-rpl-deployment-=
01<br>
<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
ftp://ftp.ietf.org/internet-drafts/<br>
<br>
_______________________________________________<br>
I-D-Announce mailing list<br>
I-D-Announce@ietf.org<br>
https://www.ietf.org/mailman/listinfo/i-d-announce<br>
Internet-Draft directories: http://www.ietf.org/shadow.html<br>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<br>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>

--_000_6E36F5C273CB41FA82E8BFED6B6158D4ciscocom_--

From gnawali@cs.uh.edu  Sun Jul  8 06:18:23 2012
Return-Path: <gnawali@cs.uh.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F390C21F8534 for <roll@ietfa.amsl.com>; Sun,  8 Jul 2012 06:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.737
X-Spam-Level: 
X-Spam-Status: No, score=-5.737 tagged_above=-999 required=5 tests=[AWL=0.240,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXYd598QO8Ag for <roll@ietfa.amsl.com>; Sun,  8 Jul 2012 06:18:22 -0700 (PDT)
Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0CC21F84FB for <roll@ietf.org>; Sun,  8 Jul 2012 06:18:22 -0700 (PDT)
Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id BD6BC23CAA4 for <roll@ietf.org>; Sun,  8 Jul 2012 08:18:41 -0500 (CDT)
X-Virus-Scanned: amavisd-new at cs.uh.edu
Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1yQylZkbJxo for <roll@ietf.org>; Sun,  8 Jul 2012 08:18:39 -0500 (CDT)
Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id A9EC823CAA2 for <roll@ietf.org>; Sun,  8 Jul 2012 08:18:39 -0500 (CDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by it.cs.uh.edu (Postfix) with ESMTP id 99DCA2A280C3 for <roll@ietf.org>; Sun,  8 Jul 2012 08:18:32 -0500 (CDT)
Received: by pbcwy7 with SMTP id wy7so18077775pbc.31 for <roll@ietf.org>; Sun, 08 Jul 2012 06:18:41 -0700 (PDT)
Received: by 10.68.237.105 with SMTP id vb9mr51997385pbc.103.1341753521207; Sun, 08 Jul 2012 06:18:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.9.202 with HTTP; Sun, 8 Jul 2012 06:18:20 -0700 (PDT)
In-Reply-To: <6E36F5C2-73CB-41FA-82E8-BFED6B6158D4@cisco.com>
References: <20120705134832.29937.21373.idtracker@ietfa.amsl.com> <6E36F5C2-73CB-41FA-82E8-BFED6B6158D4@cisco.com>
From: Omprakash Gnawali <gnawali@cs.uh.edu>
Date: Sun, 8 Jul 2012 06:18:20 -0700
Message-ID: <CAErDfUQLxpkaSUAzy_5ONbXtRwhLX+rHV1WZqd0_A+QCCWLNfw@mail.gmail.com>
To: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: roll WG <roll@ietf.org>
Subject: Re: [Roll] Fwd: I-D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Jul 2012 13:18:23 -0000

Thanks for sharing this experience. Very useful. Looking forward to
future versions of this document with more information. I hope there
are some lessons and experiences from this deployment we can suggest
as guidelines for future deployment
(draft-gnawali-roll-rpl-recommendations).

I was wondering if there were multiple roots in this deployment.

- om_p

On Sun, Jul 8, 2012 at 5:59 AM, JP Vasseur (jvasseur)
<jvasseur@cisco.com> wrote:
> Hi,
>
> As promised during the last IETF, here is an informational draft, showing
> one of the first large scale RPL-enabled networks in
> production; the document will be updated soon with several other ones.
>
> http://www.ietf.org/id/draft-hui-vasseur-roll-rpl-deployment-01.pdf
>
> Thanks.
>
> JP and Jonathan.
>
> Begin forwarded message:
>
> From: <internet-drafts@ietf.org>
> Subject: I-D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt
> Date: July 5, 2012 3:48:32 PM GMT+02:00
> To: <i-d-announce@ietf.org>
> Reply-To: <internet-drafts@ietf.org>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: RPL deployment experience in large =
scale networks
> Author(s) =A0=A0=A0=A0=A0=A0: JP Vasseur
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0Jonathan Hui
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0Sukrit Dasgupta
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0Giyoung Yoon
> Filename =A0=A0=A0=A0=A0=A0=A0: draft-hui-vasseur-roll-rpl-deployment-01.=
txt
> Pages =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 12
> Date =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2012-07-05
>
> Abstract:
> =A0=A0Low power and Lossy Networks (LLNs) exhibit characteristics unlike
> =A0=A0other more traditional IP links. =A0LLNs are a class of network in
> =A0=A0which both routers and their interconnect are resource constrained.
> =A0=A0LLN routers are typically resource constrained in processing power,
> =A0=A0memory, and energy (i.e. battery power). =A0LLN links are typically
> =A0=A0exhibit high loss rates, low data rates, are are strongly affected =
by
> =A0=A0environmental conditions that change over time. =A0LLNs may be comp=
osed
> =A0=A0of a few dozen to thousands of routers. =A0A new protocol called th=
e
> =A0=A0IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) has be=
en
> =A0=A0specified for routing in LLNs supporting multipoint-to-point, point=
-
> =A0=A0to-multipoint traffic, and point-to-point traffic. =A0Since RPL's
> =A0=A0publication as an RFC, several large scale networks have been
> =A0=A0succesfully deployed. =A0The aim of this document is to provide
> =A0=A0deployment experience on real-life deployed RPL-based networks.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deployment
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01
>
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-hui-vasseur-roll-rpl-deploymen=
t-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>

From abdussalambaryun@gmail.com  Tue Jul 10 08:08:37 2012
Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F3321F851C for <roll@ietfa.amsl.com>; Tue, 10 Jul 2012 08:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.455
X-Spam-Level: 
X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HpORUiuKoc7 for <roll@ietfa.amsl.com>; Tue, 10 Jul 2012 08:08:36 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCD121F851A for <roll@ietf.org>; Tue, 10 Jul 2012 08:08:36 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so63776vbb.31 for <roll@ietf.org>; Tue, 10 Jul 2012 08:09:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KmH3z58ViJwwTur3MVCdrEJPCo2KpHoj7w2gBrEzYHU=; b=Nc6J1T2ThVM2sO3BkxNl2t+4hvd59XmFWO5wuA0o5bzA2LZGzwtj7BHB4+MGAvvXHU y5YndP8KQh/qg8/rXMiTdStRWfDImvOvPP60F9dhW5nXCKUCkwFuJuWcnJESTHWmGrUL FKkzO1k1c3L4TmQVRKX6ygb09TLDREzBZuhf5gdQNe1I385iiqAncaM+Y4pmRJRnXJi0 ERtKq2aXpOdZ9PPh3UndYJZjySIddYQ0VTpHs5bWpC3uG5iIll5usSOjbsd5uUOBafqe XqucIY1TzpkbWRHsHUn2hpHEs2YKWZAjg58euU4M+KFL/VFemTjOCSgaNIjVRXlc7nax KQAA==
MIME-Version: 1.0
Received: by 10.52.97.227 with SMTP id ed3mr6600594vdb.103.1341932943902; Tue, 10 Jul 2012 08:09:03 -0700 (PDT)
Received: by 10.220.110.130 with HTTP; Tue, 10 Jul 2012 08:09:03 -0700 (PDT)
Date: Tue, 10 Jul 2012 17:09:03 +0200
Message-ID: <CADnDZ8_QeuVDNtiqqWEddqvmg1kb2sSMqEQiz5+GG29wxz39GQ@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: roll <roll@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Roll] Presenting about a draft
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 15:08:37 -0000

I am preparing the draft to submit (within some days) about the node
ability to participate (NAP) to the ROLL WG. I got a request for the
meeting purposes, to post this message about the draft objective and
introduction,

The Draft initial Objectives:

1) NAP Applicability (use cases).
2) NAP Protocol Considerations.
3) NAP Operation.

Introduction:

NAP protocol is intended to be used for LLN and wireless ad hoc networks.
The NAP protocol considers; 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 (TBD)). The node-ability can be useful if we have
different devices capabilities or/and conditions. This
knowledge-factor can be useful and may be included in some technique,
or forwarding table in the protocol specification. The general idea is
that each node may get to a situation to advertise its *ability*
limits for the network benefit, on the other hand, some nodes in some
situation may request information about such *ability* for their
benefit.

Thanking you,

Abdussalam Baryun
University of Glamorgan, UK

From adrian@olddog.co.uk  Tue Jul 10 11:56:35 2012
Return-Path: <adrian@olddog.co.uk>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF1321F86E3; Tue, 10 Jul 2012 11:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.39
X-Spam-Level: 
X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEpPduUrK6iV; Tue, 10 Jul 2012 11:56:35 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5B21F86DF; Tue, 10 Jul 2012 11:56:34 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6AIv1S0014929;  Tue, 10 Jul 2012 19:57:01 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q6AIuxnd014919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Jul 2012 19:57:00 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Ralph Droms'" <rdroms.ietf@gmail.com>, "'The IESG'" <iesg@ietf.org>
References: <20120708002902.10115.33905.idtracker@ietfa.amsl.com>
In-Reply-To: <20120708002902.10115.33905.idtracker@ietfa.amsl.com>
Date: Tue, 10 Jul 2012 19:57:01 +0100
Message-ID: <02cb01cd5ecd$ca83bbf0$5f8b33d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQC5u8ChSyKl6BkRGbtnD4M2QfJaHplKIulQ
Content-Language: en-gb
Cc: 'roll' <roll@ietf.org>, draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll-chairs@tools.ietf.org
Subject: Re: [Roll] Ralph Droms' No Objection on	draft-ietf-roll-minrank-hysteresis-of-11: (with COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 18:56:35 -0000

Authors,

Although the Discusses are now cleared thanks to your latest revision, =
it would be good if you could look at the comments that Ralph has =
raised.

Are there changes you would like to make to address these comments? Will =
you spin a new revisions or can you express them in RFC Editor notes?

Thanks,
Adrian

> -----Original Message-----
> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf =
Of Ralph
> Droms
> Sent: 08 July 2012 01:29
> To: The IESG
> Cc: roll; draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org; roll-
> chairs@tools.ietf.org
> Subject: Ralph Droms' No Objection on =
draft-ietf-roll-minrank-hysteresis-of-11:
> (with COMMENT)
>=20
> Ralph Droms has entered the following ballot position for
> draft-ietf-roll-minrank-hysteresis-of-11: No Objection
>=20
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut =
this
> introductory paragraph, however.)
>=20
>=20
> Please refer to =
http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> Thank you for addressing my Discuss points in the most recent
> rev of this document.  I've cleared my Discuss.
>=20
> While these comments are non-blocking, they should be considered
> carefully as they are based on implementation experience with this
> draft.
>=20
> 1. The second component of the path cost in section 3.1:
>=20
>    2.  The value of the selected metric in the metric container in the
>        DIO sent by that neighbor.
>=20
> is incompletely described.  While an implementor should realize from
> section 3.5 that the rank advertised by the neighbor is an
> approximation for ETX and should be used here, the text as written is
> incomplete.
>=20
> 2. Also for completeness, the document should specify the
> representation used for ETX to be used in path cost computation; e.g.,
> as specified for the ETX sub-object in RFC 6551.
>=20
> 3. Related to point 2, explanation of the relationship between the
> representation used for ETX and rank should be explained, especially
> considering what I think will be unexpected side effects of the value
> of DEFAULT_MIN_HOP_RANK_INCREASE defined to be 256 in RFC 6550
> interacting with the (presumed) default representation of ETX as
> defines in RFC 6551.
>=20
> 4.  In section 3.4:
>=20
>    If ETX is the selected metric, a node SHOULD NOT advertise it in a
>    metric container.
>=20
> s/SHOULD NOT/MUST NOT/ (and this text is redundant relative to the
> last sentence of section 3.5).
>=20
> 5. Are the parameter values in section 5 recommended only for use when
> the selected metric is ETX; seems to me MAX_LINK_METRIC, MAX_PATH_COST
> and PARENT_SWITCH_THRESHOLD depend on the selected metric and the
> recommended values wouldn't make much sense for, e.g., hop count.
>=20
> These comments are purely editorial and offered to improve the clarity
> of the document.
>=20
> 1. The paragraph immediately following table seems superfluous.  The
> list of metrics for which the rank is undefined is not complete (from
> RFC 6551).  The paragraph begs the question "why would the deployment
> choose a metric for which the rank is undefined?"
>=20
> 2. Readability would be improved by writing the details of the
> special-case treatment of ETX (currently in section 3.5) to the point
> at which that special-case treatment modifies other behavior specified
> in the document; e.g., the second component of the path cost cited
> above.
>=20
> 3. The second sentence of section 6 is pretty opaque.  Is the point
> that the "List of supported metrics" from section 18.2.3 need not be
> supported if MRHOF is used?
>=20
> 4. Isn't the last paragraph of section 6.1 true for any selected =
metric?



From internet-drafts@ietf.org  Fri Jul 13 09:55:59 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0239411E80FB; Fri, 13 Jul 2012 09:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.509
X-Spam-Level: 
X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPUULsEkjp9V; Fri, 13 Jul 2012 09:55:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6211E80D9; Fri, 13 Jul 2012 09:55:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.30p3
Message-ID: <20120713165558.30055.32447.idtracker@ietfa.amsl.com>
Date: Fri, 13 Jul 2012 09:55:58 -0700
Cc: roll@ietf.org
Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-01.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2012 16:56:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Routing Over Low power and Lossy networks=
 Working Group of the IETF.

	Title           : Multicast Forwarding Using Trickle
	Author(s)       : Jonathan W. Hui
                          Richard Kelsey
	Filename        : draft-ietf-roll-trickle-mcast-01.txt
	Pages           : 19
	Date            : 2012-07-13

Abstract:
   Low power and Lossy Networks (LLNs) are typically composed of
   resource constrained nodes communicating over links that have dynamic
   characteristics.  Memory constraints coupled with temporal variations
   in link connectivity makes the use of topology maintenance to support
   IPv6 multicast challenging.  This document describes the use of
   Trickle to efficiently forward multicast messages without the need
   for topology maintenance.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From johui@cisco.com  Fri Jul 13 09:58:57 2012
Return-Path: <johui@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D719D21F8692 for <roll@ietfa.amsl.com>; Fri, 13 Jul 2012 09:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0Bh5pd-GS-m for <roll@ietfa.amsl.com>; Fri, 13 Jul 2012 09:58:56 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AD00521F85D8 for <roll@ietf.org>; Fri, 13 Jul 2012 09:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johui@cisco.com; l=4651; q=dns/txt; s=iport; t=1342198773; x=1343408373; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=enWafG7YLkm7S16fEURYYUGg369ffVfWkLGOcImb1ns=; b=iT/CPekiFJWruH9vmGEKTxG1XWLEfvLUioK5MDlGudEyH6eEoNzfZTLg SBHB2PbmrUWYJDlLPX4GINhjLaFbncpsn9UGThvGS9ziq5mnYR7InJZfg 3vU15U/fqxTO4QquVBHO+18sQpeTQUhhaRvL+Y4DVuUf5zAafuqXW/OOb 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAMhSAFCtJV2a/2dsb2JhbABFuBiBB4IgAQEBAwEBAQEPASc0GwIBCDYQJwslAgQTIodlBgubR6AyizwUB4R7YAOVOoESjQ6BZoJfgVY
X-IronPort-AV: E=Sophos;i="4.77,579,1336348800"; d="scan'208";a="101702401"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 13 Jul 2012 16:59:33 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6DGxXOY008014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <roll@ietf.org>; Fri, 13 Jul 2012 16:59:33 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 11:59:31 -0500
From: "Jonathan Hui (johui)" <johui@cisco.com>
To: "roll@ietf.org WG" <roll@ietf.org>
Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-01.txt
Thread-Index: AQHNYRje6uUOjVx1GUeiXE7ejTSA2g==
Date: Fri, 13 Jul 2012 16:59:30 +0000
Message-ID: <3B108D01-B647-49B1-BE38-17E118B74C3D@cisco.com>
References: <20120713165558.30055.32447.idtracker@ietfa.amsl.com>
In-Reply-To: <20120713165558.30055.32447.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.21.75.107]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19036.004
x-tm-as-result: No--49.629100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A5148998C0C4D14394507B3A52435391@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-01.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2012 16:58:58 -0000

Activity on this draft has been dormant for far too long.  We've resubmitte=
d the draft with no substantive changes in attempt to move this work forwar=
d.

>From my perspective, there are a number of areas to improve on this draft:

1) Format of the HBH Option.

- The HBH Option does not currently have any version field.  I know the Zig=
Bee folks are anxious to lock the format down, yet I don't believe we are a=
t a point where we can (given the issues below and other issues that we hav=
e yet to find).  Finding a way to version the HBH Option will give us a pat=
h forward not only as we work on the initial specification but for future s=
pecifications as well.

- The SeedID is limited to 2 or 16 bytes.  That seems a bit constrained.  F=
irst, I have seen use cases where only a single multicast seed is used with=
in a network, and it would be beneficial to completely elide the SeedID (wi=
th an assumed value of zero).  Second, different applications have differen=
t upper bounds on the number of seeds and/or how the SeedIDs are allocated/=
configured, which can dictate what size  the SeedID should actually be.  On=
e thought is to allow the SeedID to vary between 0 and 16 bytes.

- The Sequence field is 15 bits.  I would be nice to have a Sequence field =
that is a multiple of 8 bits to make Serial Number Arithmetic more convenie=
nt.

- I'm aware of one technical bug with the HBH Option when trying to utilize=
 a sliding window larger than 1.  In particular, a device processing the HB=
H Option does not know if the Sequence value represents the largest sequenc=
e value received by the neighboring node or an older message that it happen=
s to be retransmitting.  Ideally, a device only resets its Trickle timer wh=
en receiving indication that a neighboring device has not yet received a me=
ssage yet.  I propose adding a flag to the HBH Option that indicates whethe=
r the Sequence value is the latest.

2) Format of the ICMPv6 Message

- The format of the ICMPv6 message is not as compact as it could be.  Curre=
ntly it explicitly lists each sequence value within a sliding window.  An a=
lternative is to have a field that indicates the base and length, then use =
a bit vector to indicate what sequence values are buffered.

3) Use of IPv6-in-IPv6 Tunneling

- This draft was written before the RPL Option and RPL Source Route Header =
drafts went through extensive review.  What we learned from doing the RPL O=
ption and Source Route Header is that IPv6-in-IPv6 encapsulation is necessa=
ry whenever adding/removing fields from an IPv6 packet en-route.  It is esp=
ecially necessary when adding to ensure that we don't break Path MTU discov=
ery.  It is convenient when removing to ensure that the original packet rem=
ains unmodified.

4) In general, a lot of work needs to be done to the draft to make the forw=
arder behavior rules more explicit.

Thoughts?

--
Jonathan Hui


On Jul 13, 2012, at 9:55 AM, <internet-drafts@ietf.org>
 <internet-drafts@ietf.org> wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Routing Over Low power and Lossy network=
s Working Group of the IETF.
>=20
> 	Title           : Multicast Forwarding Using Trickle
> 	Author(s)       : Jonathan W. Hui
>                          Richard Kelsey
> 	Filename        : draft-ietf-roll-trickle-mcast-01.txt
> 	Pages           : 19
> 	Date            : 2012-07-13
>=20
> Abstract:
>   Low power and Lossy Networks (LLNs) are typically composed of
>   resource constrained nodes communicating over links that have dynamic
>   characteristics.  Memory constraints coupled with temporal variations
>   in link connectivity makes the use of topology maintenance to support
>   IPv6 multicast challenging.  This document describes the use of
>   Trickle to efficiently forward multicast messages without the need
>   for topology maintenance.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-01
>=20
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-01
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From abdussalambaryun@gmail.com  Fri Jul 13 15:17:55 2012
Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC4411E8130 for <roll@ietfa.amsl.com>; Fri, 13 Jul 2012 15:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.47
X-Spam-Level: 
X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woGAWp7q6BL3 for <roll@ietfa.amsl.com>; Fri, 13 Jul 2012 15:17:54 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6926B11E812F for <roll@ietf.org>; Fri, 13 Jul 2012 15:17:54 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so2792734vbb.31 for <roll@ietf.org>; Fri, 13 Jul 2012 15:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3EiVU2LnIqMEY/F0L8lJRUvhctnNwf35okCaTLOPXwE=; b=S130as7fnEoNtRLRZpimapnLIHDiQRftWHAhQ9eMuLIaQ5hnhrDhOLihleE23Mej9z DyKTHhY8ZQ5eI5xXaDujGiSbU0hjQQuuF5ZDE5VqBbsBwiUV4mCIOaA6r50TyUSvqBMK HMMxqc2dPTu7LO7EW6o3lmXDbd3A/JckZ2Vcw4RaY5XD90j6rGRhLRQgN2D0xXKIySAC Zz0wJvlLZSj+nUW04H8k9pkDIrSbum9OOMeiHSDYuNHV9z5jv2sk84kL/qDYAgtg0TZv U/SuFwujod6KHdx3gzYGt3BrCmzTwrdSwpNOxZYP6U4ObeiuqAlTEurCQ0e6yfJwC2HJ pGgg==
MIME-Version: 1.0
Received: by 10.52.24.179 with SMTP id v19mr1192497vdf.127.1342217911322; Fri, 13 Jul 2012 15:18:31 -0700 (PDT)
Received: by 10.220.110.130 with HTTP; Fri, 13 Jul 2012 15:18:31 -0700 (PDT)
In-Reply-To: <13278.1342120421@herring.sandelman.ottawa.on.ca>
References: <CADnDZ8_QeuVDNtiqqWEddqvmg1kb2sSMqEQiz5+GG29wxz39GQ@mail.gmail.com> <13278.1342120421@herring.sandelman.ottawa.on.ca>
Date: Sat, 14 Jul 2012 00:18:31 +0200
Message-ID: <CADnDZ8_8rxw654O8SHt329n4s-SAFMoyZVjhtfkNwndutH2KAA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll <roll@ietf.org>
Subject: Re: [Roll] Presenting about a draft
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2012 22:17:55 -0000

Hi Michael,

I thank you for your comments,

AB

On 7/12/12, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>>>>>> "Abdussalam" == Abdussalam Baryun <abdussalambaryun@gmail.com>
>>>>>> writes:
>     Abdussalam> knowledge-factor can be useful and may be included in
>     Abdussalam> some technique,
>     Abdussalam> or forwarding table in the protocol specification. The
>     Abdussalam> general idea is
>     Abdussalam> that each node may get to a situation to advertise its
>     Abdussalam> *ability*
>
> I believe that we have no current way for nodes to distinguish
> themselves as being better routers or less good routers, except that
> they can increment their rank a lot if they feel they shouldn't be used.
>
> It seems that this NAP kind of thing needs to be included into the
> metrics.  I could be way off here.
>
> --
> ]       He who is tired of Weird Al is tired of life!           |  firewalls
>  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
> driver[
>    Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.
>

From stokcons@xs4all.nl  Sat Jul 14 06:26:23 2012
Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D843621F870B for <roll@ietfa.amsl.com>; Sat, 14 Jul 2012 06:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.154
X-Spam-Level: 
X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elW1nKarSbYr for <roll@ietfa.amsl.com>; Sat, 14 Jul 2012 06:26:23 -0700 (PDT)
Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id E683721F86FA for <roll@ietf.org>; Sat, 14 Jul 2012 06:26:22 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube1.xs4all.net [194.109.20.195]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id q6EDQUea088940 for <roll@ietf.org>; Sat, 14 Jul 2012 15:26:30 +0200 (CEST) (envelope-from stokcons@xs4all.nl)
Received: from AMontpellier-556-1-306-50.w81-251.abo.wanadoo.fr ([81.251.50.50]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 14 Jul 2012 15:26:30 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Sat, 14 Jul 2012 15:26:30 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: <consultancy@vanderstok.org>
Message-ID: <2dec670ff1a72412ba6a7800ee8d95b7@xs4all.nl>
X-Sender: stokcons@xs4all.nl (Ki6Vt3DWZ8ea6UGjpmzizFqMlwHTR6In)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: [Roll] Fwd: New Version Notification for draft-vanderstok-roll-mcreq-02.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jul 2012 13:26:24 -0000

-------- Originele bericht --------
Onderwerp: New Version Notification for 
draft-vanderstok-roll-mcreq-02.txt
Datum: 2012-07-14 15:20
Afzender: internet-drafts@ietf.org
Ontvanger: consultancy@vanderstok.org
Kopie: armand.lelkens@philips.com, esko.dijk@philips.com


A new version of I-D, draft-vanderstok-roll-mcreq-02.txt
has been successfully submitted by Peter van der Stok and posted to the
IETF repository.

Dear roll wg,

We have submitted a draft summarizing our experiences with and 
recommendations for the trickle Multicast algorithm.
One of our main concerns is the timeliness aspects of TRickle multicast 
, and we are confident that given the
network configurations that we expect we can deploy trickle multicast 
for building control

More information in the draft.

Greetings,

peter van der stok



Filename:	 draft-vanderstok-roll-mcreq
Revision:	 02
Title:		 Multicast requirements for control over LLN
Creation date:	 2012-07-11
WG ID:		 Individual Submission
Number of pages: 15
URL:             
http://www.ietf.org/internet-drafts/draft-vanderstok-roll-mcreq-02.txt
Status:          
http://datatracker.ietf.org/doc/draft-vanderstok-roll-mcreq
Htmlized:        
http://tools.ietf.org/html/draft-vanderstok-roll-mcreq-02
Diff:            
http://tools.ietf.org/rfcdiff?url2=draft-vanderstok-roll-mcreq-02

Abstract:
    This is a working document intended to focus discussion on
    requirements for multicast in Low-power and Lossy Networks in the
    area of M2M communication for control applications.  The Trickle
    algorithm, which uses random re-broadcasting to assure that messages
    arrive at all destinations, has been proposed in the Trickle
    Multicast Forwarding ROLL WG draft as the basis for a multicast
    routing protocol.  In this draft additional requirements on 
multicast
    routing are presented, such as timeliness, motivated by building
    control.  Random re-broadcasting and timeliness can be difficult to
    reconcile.  This draft presents some simulation results in typical
    control settings which show that achieving latencies below 400 ms is
    feasible with Trickle.  Recommendations are proposed for the current
    Trickle Multicast Forwarding draft to achieve optimal performance 
and
    meet the stated requirements.




The IETF Secretariat


From gnawali@cs.uh.edu  Sat Jul 14 10:08:32 2012
Return-Path: <gnawali@cs.uh.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D2A21F84D6; Sat, 14 Jul 2012 10:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.777
X-Spam-Level: 
X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyhEKMpiDZ54; Sat, 14 Jul 2012 10:08:31 -0700 (PDT)
Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5BC21F84D3; Sat, 14 Jul 2012 10:08:31 -0700 (PDT)
Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id D183B23CA6E; Sat, 14 Jul 2012 12:09:07 -0500 (CDT)
X-Virus-Scanned: amavisd-new at cs.uh.edu
Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mg9-At2nITjW; Sat, 14 Jul 2012 12:09:07 -0500 (CDT)
Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 9F5AD23CA78; Sat, 14 Jul 2012 12:09:04 -0500 (CDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by it.cs.uh.edu (Postfix) with ESMTP id A91CD2A280C3; Sat, 14 Jul 2012 12:09:25 -0500 (CDT)
Received: by pbcwy7 with SMTP id wy7so7757252pbc.31 for <multiple recipients>; Sat, 14 Jul 2012 10:09:05 -0700 (PDT)
Received: by 10.68.194.201 with SMTP id hy9mr12738095pbc.69.1342285745568; Sat, 14 Jul 2012 10:09:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.9.202 with HTTP; Sat, 14 Jul 2012 10:08:45 -0700 (PDT)
In-Reply-To: <02cb01cd5ecd$ca83bbf0$5f8b33d0$@olddog.co.uk>
References: <20120708002902.10115.33905.idtracker@ietfa.amsl.com> <02cb01cd5ecd$ca83bbf0$5f8b33d0$@olddog.co.uk>
From: Omprakash Gnawali <gnawali@cs.uh.edu>
Date: Sat, 14 Jul 2012 12:08:45 -0500
Message-ID: <CAErDfUR_zApNAAOnOAyteVQZnmNyq=4G9ZPnA-M-uTXFtSdJ_Q@mail.gmail.com>
To: adrian@olddog.co.uk
Content-Type: text/plain; charset=ISO-8859-1
Cc: roll <roll@ietf.org>, roll-chairs@tools.ietf.org, draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [Roll] Ralph Droms' No Objection on draft-ietf-roll-minrank-hysteresis-of-11: (with COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jul 2012 17:08:32 -0000

We can work with the RFC editor on those comments from Ralf. Thanks.

- om_p

On Tue, Jul 10, 2012 at 1:57 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> Authors,
>
> Although the Discusses are now cleared thanks to your latest revision, it would be good if you could look at the comments that Ralph has raised.
>
> Are there changes you would like to make to address these comments? Will you spin a new revisions or can you express them in RFC Editor notes?
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Ralph
>> Droms
>> Sent: 08 July 2012 01:29
>> To: The IESG
>> Cc: roll; draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org; roll-
>> chairs@tools.ietf.org
>> Subject: Ralph Droms' No Objection on draft-ietf-roll-minrank-hysteresis-of-11:
>> (with COMMENT)
>>
>> Ralph Droms has entered the following ballot position for
>> draft-ietf-roll-minrank-hysteresis-of-11: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thank you for addressing my Discuss points in the most recent
>> rev of this document.  I've cleared my Discuss.
>>
>> While these comments are non-blocking, they should be considered
>> carefully as they are based on implementation experience with this
>> draft.
>>
>> 1. The second component of the path cost in section 3.1:
>>
>>    2.  The value of the selected metric in the metric container in the
>>        DIO sent by that neighbor.
>>
>> is incompletely described.  While an implementor should realize from
>> section 3.5 that the rank advertised by the neighbor is an
>> approximation for ETX and should be used here, the text as written is
>> incomplete.
>>
>> 2. Also for completeness, the document should specify the
>> representation used for ETX to be used in path cost computation; e.g.,
>> as specified for the ETX sub-object in RFC 6551.
>>
>> 3. Related to point 2, explanation of the relationship between the
>> representation used for ETX and rank should be explained, especially
>> considering what I think will be unexpected side effects of the value
>> of DEFAULT_MIN_HOP_RANK_INCREASE defined to be 256 in RFC 6550
>> interacting with the (presumed) default representation of ETX as
>> defines in RFC 6551.
>>
>> 4.  In section 3.4:
>>
>>    If ETX is the selected metric, a node SHOULD NOT advertise it in a
>>    metric container.
>>
>> s/SHOULD NOT/MUST NOT/ (and this text is redundant relative to the
>> last sentence of section 3.5).
>>
>> 5. Are the parameter values in section 5 recommended only for use when
>> the selected metric is ETX; seems to me MAX_LINK_METRIC, MAX_PATH_COST
>> and PARENT_SWITCH_THRESHOLD depend on the selected metric and the
>> recommended values wouldn't make much sense for, e.g., hop count.
>>
>> These comments are purely editorial and offered to improve the clarity
>> of the document.
>>
>> 1. The paragraph immediately following table seems superfluous.  The
>> list of metrics for which the rank is undefined is not complete (from
>> RFC 6551).  The paragraph begs the question "why would the deployment
>> choose a metric for which the rank is undefined?"
>>
>> 2. Readability would be improved by writing the details of the
>> special-case treatment of ETX (currently in section 3.5) to the point
>> at which that special-case treatment modifies other behavior specified
>> in the document; e.g., the second component of the path cost cited
>> above.
>>
>> 3. The second sentence of section 6 is pretty opaque.  Is the point
>> that the "List of supported metrics" from section 18.2.3 need not be
>> supported if MRHOF is used?
>>
>> 4. Isn't the last paragraph of section 6.1 true for any selected metric?
>
>

From jvasseur@cisco.com  Mon Jul 16 03:58:36 2012
Return-Path: <jvasseur@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4421F878A for <roll@ietfa.amsl.com>; Mon, 16 Jul 2012 03:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1DwxGJMaNW5 for <roll@ietfa.amsl.com>; Mon, 16 Jul 2012 03:58:35 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D72D721F8776 for <roll@ietf.org>; Mon, 16 Jul 2012 03:58:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=9441; q=dns/txt; s=iport; t=1342436359; x=1343645959; h=from:to:subject:date:message-id:references:mime-version; bh=kgJ+WkYy/fFhjpnw3zmTs0qm24usnWO5JQGS00Cv/tU=; b=FOxfSTFehw4BINUvGVtnpF42dO+ZL0VOSxcMRulCmYye9EAJZYRgnBn+ alLduX0ZLYgnWhEQEm/b/7l8lfcDKBxfmDdUGzShBYf97lITiSRV5HUwY S0wbaRKc6l++jucvNfTTviDj9gAohG5lDDMo5BTWiMiC4nRzUmCHywBYF I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EADjzA1CtJV2a/2dsb2JhbABFuR6BB4IcBAEBAQICAQEBDwFbGwIBGQMBAigHJwsUBwIIAgQTCRAJhScHgiQZC5twnzWLQAUWhUxgA5U7gRKJdYMZgWaCXw
X-IronPort-AV: E=Sophos;i="4.77,593,1336348800";  d="scan'208,217";a="102207113"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 16 Jul 2012 10:59:19 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6GAxIVU015141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <roll@ietf.org>; Mon, 16 Jul 2012 10:59:19 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 05:59:18 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: roll WG <roll@ietf.org>
Thread-Topic: I-D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt
Thread-Index: AQHNY0IMxoyo/uQNoUKbmROAesIq2w==
Date: Mon, 16 Jul 2012 10:59:18 +0000
Message-ID: <ACF4EE7B-6058-477B-B98A-A0FE4E779E01@cisco.com>
References: <20120705134832.29937.21373.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.114.229]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.004
x-tm-as-result: No--39.281300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_ACF4EE7B6058477BB98AA0FE4E779E01ciscocom_"
MIME-Version: 1.0
Subject: [Roll] Fwd: I-D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 10:58:36 -0000

--_000_ACF4EE7B6058477BB98AA0FE4E779E01ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

As promised during the last IETF, here is an information draft, showing one=
 of the first large scale RPL-based based network in
production; the document will be updated soon with several other ones.

http://www.ietf.org/id/draft-hui-vasseur-roll-rpl-deployment-01.pdf



Begin forwarded message:

From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Subject: I-D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt
Date: July 5, 2012 3:48:32 PM GMT+02:00
To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>
Reply-To: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


Title           : RPL deployment experience in large scale networks
Author(s)       : JP Vasseur
                         Jonathan Hui
                         Sukrit Dasgupta
                         Giyoung Yoon
Filename        : draft-hui-vasseur-roll-rpl-deployment-01.txt
Pages           : 12
Date            : 2012-07-05

Abstract:
  Low power and Lossy Networks (LLNs) exhibit characteristics unlike
  other more traditional IP links.  LLNs are a class of network in
  which both routers and their interconnect are resource constrained.
  LLN routers are typically resource constrained in processing power,
  memory, and energy (i.e. battery power).  LLN links are typically
  exhibit high loss rates, low data rates, are are strongly affected by
  environmental conditions that change over time.  LLNs may be composed
  of a few dozen to thousands of routers.  A new protocol called the
  IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) has been
  specified for routing in LLNs supporting multipoint-to-point, point-
  to-multipoint traffic, and point-to-point traffic.  Since RPL's
  publication as an RFC, several large scale networks have been
  succesfully deployed.  The aim of this document is to provide
  deployment experience on real-life deployed RPL-based networks.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deployment

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-hui-vasseur-roll-rpl-deployment-=
01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--_000_ACF4EE7B6058477BB98AA0FE4E779E01ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <58FDF25259591E4E8C63356534E9D2FC@cisco.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
Hi,
<div><br>
</div>
<div>As promised during the last IETF, here is an information draft, showin=
g one of the first large scale RPL-based based network in</div>
<div>production; the document will be updated soon with several other ones.=
</div>
<div><br>
</div>
<div><a href=3D"http://www.ietf.org/id/draft-hui-vasseur-roll-rpl-deploymen=
t-01.pdf">http://www.ietf.org/id/draft-hui-vasseur-roll-rpl-deployment-01.p=
df</a></div>
<div><br>
</div>
<div><br>
<div><br>
<div>Begin forwarded message:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>From:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">&lt;<=
a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>&gt;=
<br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>Subject:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;"><b>I-=
D Action: draft-hui-vasseur-roll-rpl-deployment-01.txt</b><br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>Date:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">July =
5, 2012 3:48:32 PM GMT&#43;02:00<br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>To:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">&lt;<=
a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org</a>&gt;<br>
</span></div>
<div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margi=
n-left: 0px;">
<span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, =
0, 1.0);"><b>Reply-To:
</b></span><span style=3D"font-family:'Helvetica'; font-size:medium;">&lt;<=
a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a>&gt;=
<br>
</span></div>
<br>
<div><br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
<br>
<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Title &nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: RPL deployment exp=
erience in large scale networks<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Author(s) &=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: JP Vasseur<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
Jonathan Hui<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
Sukrit Dasgupta<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
Giyoung Yoon<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Filename &n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: draft-hui-vasseur-roll-rpl-deploy=
ment-01.txt<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Pages &nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 12<br>
<span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>Date &nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;: 2012-07-05<br=
>
<br>
Abstract:<br>
&nbsp;&nbsp;Low power and Lossy Networks (LLNs) exhibit characteristics unl=
ike<br>
&nbsp;&nbsp;other more traditional IP links. &nbsp;LLNs are a class of netw=
ork in<br>
&nbsp;&nbsp;which both routers and their interconnect are resource constrai=
ned.<br>
&nbsp;&nbsp;LLN routers are typically resource constrained in processing po=
wer,<br>
&nbsp;&nbsp;memory, and energy (i.e. battery power). &nbsp;LLN links are ty=
pically<br>
&nbsp;&nbsp;exhibit high loss rates, low data rates, are are strongly affec=
ted by<br>
&nbsp;&nbsp;environmental conditions that change over time. &nbsp;LLNs may =
be composed<br>
&nbsp;&nbsp;of a few dozen to thousands of routers. &nbsp;A new protocol ca=
lled the<br>
&nbsp;&nbsp;IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) ha=
s been<br>
&nbsp;&nbsp;specified for routing in LLNs supporting multipoint-to-point, p=
oint-<br>
&nbsp;&nbsp;to-multipoint traffic, and point-to-point traffic. &nbsp;Since =
RPL's<br>
&nbsp;&nbsp;publication as an RFC, several large scale networks have been<b=
r>
&nbsp;&nbsp;succesfully deployed. &nbsp;The aim of this document is to prov=
ide<br>
&nbsp;&nbsp;deployment experience on real-life deployed RPL-based networks.=
<br>
<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-depl=
oyment">https://datatracker.ietf.org/doc/draft-hui-vasseur-roll-rpl-deploym=
ent</a><br>
<br>
There's also a htmlized version available at:<br>
http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01<br>
<br>
A diff from previous version is available at:<br>
http://tools.ietf.org/rfcdiff?url2=3Ddraft-hui-vasseur-roll-rpl-deployment-=
01<br>
<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
ftp://ftp.ietf.org/internet-drafts/<br>
<br>
_______________________________________________<br>
I-D-Announce mailing list<br>
I-D-Announce@ietf.org<br>
https://www.ietf.org/mailman/listinfo/i-d-announce<br>
Internet-Draft directories: http://www.ietf.org/shadow.html<br>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<br>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>

--_000_ACF4EE7B6058477BB98AA0FE4E779E01ciscocom_--

From jvasseur@cisco.com  Mon Jul 16 09:08:36 2012
Return-Path: <jvasseur@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9980F11E809F for <roll@ietfa.amsl.com>; Mon, 16 Jul 2012 09:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYMv+atHPNFF for <roll@ietfa.amsl.com>; Mon, 16 Jul 2012 09:08:36 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAA611E8091 for <roll@ietf.org>; Mon, 16 Jul 2012 09:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=228; q=dns/txt; s=iport; t=1342454961; x=1343664561; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=oA6So0/K9gxGcfjrqN18r//cUL4LGZxTiZyD9hJ3qDE=; b=i3srkm/BMJXCeeqivLzswiXRloxetGwJJ7DvzN5DIcRgHueTNJgja3q2 zNpUbS4jJjKdZ4mFXZqnojj00vX5sv/440PxQ4SgFHowv0ZTlF4hSB3wO ZU4gcj04HpWl5AfEe0TMXeF/nmSeIishHnVJoLz7+qJXQ5rldgTMsmi1Q g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak4JAOQ7BFCtJXHB/2dsb2JhbABFuAYEBIEqgQeCJxIBJz8SAT5CJwQOJ4drnDqfbZEnYAOVO44ggWaCXw
X-IronPort-AV: E=Sophos;i="4.77,594,1336348800"; d="scan'208";a="102314611"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 16 Jul 2012 16:09:21 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6GG9K91019792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jul 2012 16:09:20 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.223]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 11:09:20 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: roll WG <roll@ietf.org>
Thread-Topic: Reminder - ROLL WG meeting
Thread-Index: AQHNY21aOR1fxVMj9kyDkFzCXQEGKw==
Date: Mon, 16 Jul 2012 16:09:19 +0000
Message-ID: <A2F3198C-33FD-4446-99D8-2F360D954BB7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.114.229]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19042.006
x-tm-as-result: No--34.300000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A401FBCAB2836A47B64C51F47CE04ED9@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Michael Richardson <mcr@sandelman.ca>
Subject: [Roll] Reminder - ROLL WG meeting
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 16:08:36 -0000

Dear all,

Please let Dan and the ROLL WG chairs know by July 18th if you plan to requ=
est a slot for the WG meeting (indicate the name of the document, requested=
 time and presenter).

Many Thanks.

JP and Michael.=

From iesg-secretary@ietf.org  Mon Jul 16 09:32:19 2012
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FD111E8112; Mon, 16 Jul 2012 09:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J462YGHdDRey; Mon, 16 Jul 2012 09:32:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A8011E8113; Mon, 16 Jul 2012 09:32:18 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.30p3
Message-ID: <20120716163218.30543.358.idtracker@ietfa.amsl.com>
Date: Mon, 16 Jul 2012 09:32:18 -0700
Cc: roll mailing list <roll@ietf.org>, roll chair <roll-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Roll] Protocol Action: 'The Minimum Rank with Hysteresis Objective	Function' to Proposed Standard	(draft-ietf-roll-minrank-hysteresis-of-11.txt)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 16:32:20 -0000

The IESG has approved the following document:
- 'The Minimum Rank with Hysteresis Objective Function'
  (draft-ietf-roll-minrank-hysteresis-of-11.txt) as Proposed Standard

This document is the product of the Routing Over Low power and Lossy
networks Working Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/




Technical Summary

  An objective function specifies how RPL [RFC6550] selects paths.
  Objective functions can choose paths based on routing metrics or
  constraints. For example, if an RPL instance uses an objective
  function that minimizes hop-count, RPL will select paths with minimum
  hop count.

  The nodes running RPL might use a number of metrics to describe a
  link or a node [RFC6551] and make it available for route selection. 
  These metrics are advertised in RPL Destination Information Object
  (DIO) messages using a Metric Container suboption. An objective
  function can use these metrics to choose routes. The only exception
  is the ETX metric, which is used without the metric container as
  described in Section 3.5.

  To decouple the details of an individual metric or objective function
  from forwarding and routing, RPL describes routes through a value
  called Rank. Rank, roughly speaking, corresponds to the distance
  associated with a route. An objective function is responsible for
  computing a node's advertised Rank value based on the Rank of its
  potential parents, metrics, and other network properties.

  This specification describes MRHOF, an objective function for RPL.
  MRHOF uses hysteresis while selecting the path with the smallest
  metric value. The metric that MRHOF uses is determined by the
  metrics in the DIO Metric Container. For example, the use of MRHOF
  with the latency metric allows RPL to find stable minimum-latency
  paths from the nodes to a root in the DAG instance. The use of MRHOF
  with the ETX metric allows RPL to find the stable minimum-ETX paths
  from the nodes to a root in the DAG instance.

  MRHOF can only be used with an additive metric that must be minimized
  on the paths selected for routing.

Working Group Summary

  A relatively quiet WG process with no discontent. There were several late-
  breaking review comments that caused the document to be recycled
  after WG last call, but this was not contentious.

Document Quality

  There are several known implementations of this specification. 

Personnel

  JP Vasseur (jpv@cisco.com) is the Document Shepherd.
  Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD

From j.schoenwaelder@jacobs-university.de  Wed Jul 18 04:44:42 2012
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A545B21F86EE for <roll@ietfa.amsl.com>; Wed, 18 Jul 2012 04:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.209
X-Spam-Level: 
X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkVjPGxMvh7w for <roll@ietfa.amsl.com>; Wed, 18 Jul 2012 04:44:41 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 394C721F86EC for <roll@ietf.org>; Wed, 18 Jul 2012 04:44:41 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EE3320BE8; Wed, 18 Jul 2012 13:45:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lW_WwwDogz8W; Wed, 18 Jul 2012 13:45:30 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEC9020BE3; Wed, 18 Jul 2012 13:45:29 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 75FE820A6D77; Wed, 18 Jul 2012 13:45:26 +0200 (CEST)
Date: Wed, 18 Jul 2012 13:45:26 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: roll@ietf.org
Message-ID: <20120718114525.GA53759@elstar.local>
Mail-Followup-To: roll@ietf.org, Anuj Sehgal <s.anuj@jacobs-university.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Anuj Sehgal <s.anuj@jacobs-university.de>
Subject: [Roll] rpl-mib update and open issues
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2012 11:44:42 -0000

--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,

we have posted an update of the RPL-MIB. This version includes a
JSON representation of the data for those who prefer to look at
a more modern format. ;-)

http://tools.ietf.org/html/draft-sehgal-roll-rpl-mib-04

There are a number of markers throughout the document which we went
through in order to compile a proper list of open issues.  I am
attaching the list and it would be extremely valuable to receive some
feedback so that we can close issues.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="issues.org"

This file is used to track issues related to the RPL-MIB. The issues
covered here concern major design choices; this file does not attempt
to track minor clarification requests etc.

To comment on issues on the mailing list, please include the issue
number in the subject line of the email message.

* [OPEN] rpl-mib-01: inetCidrRoutePolicy

  The IPv6 routing table should be exposed via the inetCidrRouteTable
  defined in the IP-FORWARD-MIB [RFC4292]. The inetCidrRoutePolicy
  column of this table has the following semantics:

       "This object is an opaque object without any defined
        semantics.  Its purpose is to serve as an additional
        index that may delineate between multiple entries to
        the same destination.  The value { 0 0 } shall be used
        as the default value for this object."

  Since an RPL node can participate in multiple RPL instances, it
  might be useful to specify that the inetCidrRoutePolicy should
  identify the RPL instance the inetCidrRouteTable entry belongs to.

** Solution #01-01

   Specify that inetCidrRoutePolicy should carry the OID of the
   rplInstanceID instance in case the inetCidrRouteTable entry belongs
   to a specific RPL instance.

** Solution #01-02

   Leave it to implementations to come up with a suitable usage 
   of inetCidrRoutePolicy.

** Resolution

   TBD

* [OPEN] rpl-mib-02: RPL TCs

  The MIB module defines a number of TCs for RPL data types, some only
  used a very few times.

** Solution #02-01:

   Having the TCs is useful, increases readability and may allow
   future reuse and consistency.

** Solution #02-02:

   Inline all TCs that are only used a very few times in order to
   shorten the document.

** Resolution

   Proposal: Adopt solution #02-01

* [OPEN] rpl-mib-03: modeling objective functions 

  Should we model objective functions, e.g., by introducing a table
  that includes objective function specific parameters such as
  MinHopRankIncrease and MaxRankIncrease?

** Solution #03-01:

   Lets not go there because the various objective functions likely
   will have different parameters. Listing the objective function code
   points supported and enabled in the rplOCPTable should be good
   enough.

** Resolution

   Proposal: Adopt solution #03-01

* [OPEN] rpl-mib-04: global vs. per instance configuration 

  RFC 6550 leaves it unclear to what extend configuration parameters
  are global to an RPL implementation or specific for each RPL
  instance maintained by an RPL implementation.

** Solution #04-01:

   All configuration parameters are global to an RPL
   implementation. This simplifies the MIB module.

** Solution #04-02:

   All configuration parameters are global and used to initialize the
   per instance configuration parameters when a new instance is
   created. This allows to make per instance changes without changing
   the global default. Of course, this requires to duplicate
   configuration objects.

** Solution #04-03:

   Like solution #04-02 but in addition we define a conformance
   statement such that per instance configuration objects are not
   mandatory to implement.

** Resolution

   TBD

* [OPEN] rpl-mib-05: DIS parameters 

  Section 18.2.1.1 of RFC 6550 requires that a node sending DIS
  messages has a configurable number of retries and a configurable
  timeout after which the node generates a floating DODAG.

** Solution #05-01:

   Add new rplDefaultDISMessages and rplDefaultDISTimout objects below
   rplGeneral.

** Solution #05-02:

   Replace the rplDefaultDISMode object with new rplDefaultDISMessages
   and rplDefaultDISTimout objects. If rplDefaultDISMessages is zero,
   the node is in silent mode.

** Resolution

   TBD

* [OPEN] rpl-mib-06: rplActiveDodagDAOSequence 

  Is it useful to capture the DAOSequence in a MIB module?

** Solution #06-01:

   Remove the object since it is potentially fast changing and likely
   not useful for network management purposes.

** Solution #06-02:

   Keep the object as defined.

** Resolution

   TBD

* [OPEN] rpl-mib-07: rpl instance creation 

  Do we have to support the creation of RPL instances via network
  management operations? This could be achieved by turning the
  rplInstanceTable into a read-create table.

** Solution #07-01:

   We decide that the creation of RPL instances via network management
   operations is not useful and leave the rplInstanceTable read-only
   as it is right now.

** Solution #07-02:

   We add a RowStatus column to the rplInstanceTable (and perhaps a
   StorageType column) to support the creation of RPL instances via
   network management operations. This does not affect the read-only
   compliance, except that a value for the new objects would have to
   be returned.

** Resolution

   TBD

* [OPEN] rpl-mib-08: rplInstanceDisMode 

  This needs to align with the resolution of rpl-mib-05 and
  rpl-mib-04.

* [OPEN] rpl-mib-09: missing global configuration parameters 

  The RPL instance table has the configuration parameters
  rplInstanceDAOAckEnabled and rplInstanceModeOfOperation but there
  are no matching global configuration parameters.

** Solution #09-01:

   Add corresponding rplDefaultDAOAckEnabled and
   rplDefaultModeOfOperation objects and align the semantics
   with the resolution of rpl-mib-04.

** Solution #09-02:

   Like #09-01 but drop per instance configuration objects, depending
   on the resolution of rpl-mib-04.

** Resolution

   TBD

* [OPEN] rpl-mib-10: configuration of dodag parameters 

  The root of a DODAG pushes parameters down the DODAG. The question
  is where these parameters come from and whether it is meaningful to
  modify these parameters for an active DODAG through a management
  interface.

** Solution #10-01:

   Add new writable objects rplDefaultDodagDAODelay,
   rplDefaultDodagPreference, rplDefaultDodagMinHopRankIncrease
   rplDefaultDodagMaxRankIncrease with suitable DEFVAL clauses
   following the recommendations in RFC 6550. These objects are
   consulted whenever a new DODAG is being created. The corresponding
   objects in the rplDodagTable all become read-only.

** Resolution

   TBD

* [OPEN] rpl-mib-11: configuration of trickle parameters 

  The trickle parameters are current read-write for each DODAG.
  It seems they are only meaningful to configure at the root.

** Solution #11-01:

  Following solution #10-01, add new writable objects
  rplDefaultIntervalDoublings, rplDefaultIntervalMin,
  rplDefaultRedundancyConstant with suitable DEFVAL clauses and the
  corresponding objects in the rplDodagTable become read-only.

** Resolution

   TBD

* [OPEN] rpl-mib-12: rplDodagState 

  In which circumstances can a node be associated and neither grounded
  or floating?

** Solution #12-01:

   It seems the associated(1) state does not make sense since once a
   node participates in a DODAG, it will learn from the root that the
   DODAG is either grounded or floating. Hence, the associated(1)
   enumeration can be removed.

** Resolution

   TBD

* [OPEN] rpl-mib-13: table indexing 

  The rplDodagTable, rplDodagParentTable, rplDodagChildTable, and
  rplDodagPrefixTable are all indexed by both an rplInstanceID (a
  small number) and the rplDodagRoot (and IPv6 address). Is this
  necessary or can things be simplified?

** Solution #13-01:

   There are situations where a node knows information about multiple
   DODAGs in an RPL instance and it is useful to export that
   information via a management interface, even though the node will
   only join one of the DODAGs within an RPL instance.

** Solution #13-02:

   Since a node will only be participating in exactly one DODAG of an
   RPL instance, we can simplify the indexing structure by removing
   rplDodagRoot from the index of the rplDodagTable, the
   rplDodagParentTable, the rplDodagChildTable, and the
   rplDodagPrefixTable. Since the root is an IPv6 address, this
   significantly simplifies the indexes and shortens the instance
   identifiers. Should a node obtain knowledge about DODAGs it does
   choose to not participate in, this information is not exported to a
   management system.

** Resolution

   TBD

* [OPEN] rpl-mib-14: rplDodagPrefixTable vs ipAddressPrefixTable 

  Does the rplDodagPrefixTable duplicate information already available
  from the ipAddressPrefixTable?

** Solution #14-01:

   It seems logical to export information about known prefixes via the
   ipAddressPrefixTable. The value of ipAddressPrefixOrigin should be
   routeradv(5). The rplDodagPrefixTable can be removed.

** Solution #14-02:

   Like solution #14-01 but in addition we sparsely augment the
   ipAddressPrefixTable with conceptual column(s) indicating the RPL
   instance or DODAG or both (rplAddressPrefixInstance,
   rplAddressPrefixDodag) where the prefix is originating from. Which
   objects to add depends on the resolution of rpl-mib-13.

** Resolution

   TBD

#+TODO: [OPEN] | [CLOSED]

--45Z9DzgjV8m4Oswq--

From esko.dijk@philips.com  Wed Jul 18 06:27:35 2012
Return-Path: <esko.dijk@philips.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EBB21F869D for <roll@ietfa.amsl.com>; Wed, 18 Jul 2012 06:27:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.05
X-Spam-Level: 
X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[AWL=-0.051,  BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va8w4mBDkfX5 for <roll@ietfa.amsl.com>; Wed, 18 Jul 2012 06:27:33 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0462C21F8685 for <roll@ietf.org>; Wed, 18 Jul 2012 06:27:32 -0700 (PDT)
Received: from mail104-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 18 Jul 2012 13:28:22 +0000
Received: from mail104-am1 (localhost [127.0.0.1])	by mail104-am1-R.bigfish.com (Postfix) with ESMTP id 94A3A4A01CE; Wed, 18 Jul 2012 13:28:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -43
X-BigFish: VPS-43(zz217bL98dI15d6O9371I9251J936eIfb6I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah107ah)
Received: from mail104-am1 (localhost.localdomain [127.0.0.1]) by mail104-am1 (MessageSwitch) id 1342618099990553_28829; Wed, 18 Jul 2012 13:28:19 +0000 (UTC)
Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.236])	by mail104-am1.bigfish.com (Postfix) with ESMTP id EF15714007D; Wed, 18 Jul 2012 13:28:19 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 18 Jul 2012 13:28:18 +0000
Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.136]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.02.0309.003; Wed, 18 Jul 2012 14:27:23 +0100
From: "Dijk, Esko" <esko.dijk@philips.com>
To: "Jonathan Hui (johui)" <johui@cisco.com>, "roll@ietf.org WG" <roll@ietf.org>
Thread-Topic: Review draft-ietf-roll-trickle-mcast-01
Thread-Index: AQHNZOkQ23b4ymIbiESORoJU7UO3iw==
Date: Wed, 18 Jul 2012 13:27:24 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618A9E4EB@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <20120713165558.30055.32447.idtracker@ietfa.amsl.com> <3B108D01-B647-49B1-BE38-17E118B74C3D@cisco.com>
In-Reply-To: <3B108D01-B647-49B1-BE38-17E118B74C3D@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.101]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: [Roll] Review draft-ietf-roll-trickle-mcast-01
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2012 13:27:35 -0000

Dear Jonathan,

we are glad to see interest and renewed activity for this draft. We would b=
e very willing to help move it forward.
As a first step we provide below a review of the current draft to identify =
some issues. If needed we can later provide more constructive feedback (e.g=
. provide or edit text). Hopefully this helps towards an improved -02 versi=
on!

best regards,

Esko Dijk
Peter van der Stok
Armand Lelkens

Philips Group Innovation, Research
High Tech Campus 34, Eindhoven, The Netherlands
esko.dijk@philips.com

--------- Review comments ---------

General
- Terms "transmit", "retransmit" and "forward" seem to be used interchangea=
bly.
  It would be good to check for this and have uniform terms. Suggested: "re=
transmit" for (re)transmitting Trickle Multicast Messages, "transmit" for t=
ransmitting Trickle ICMP Messages, and "forward" use only if accompanied by=
 one of the other terms. Such as in the sentence "nodes simply retransmit m=
ulticast messages they are trying to forward" it's clear.

Section 3
"A multicast message is
   only retransmitted upon receiving positive indication that a neighbor
   has not yet received that multicast message."
-> But it's not immediately retransmitted (as some readers may think at thi=
s point based on their background idea of 'retransmissions'). Maybe add ear=
ly in the text somewhere that retransmissions only happen at the time t the=
 Trickle algorithm transmits (and define that moment as "transmission event=
"). Such definition could be added to Section 2.

"The Trickle timer period doubles when the period expires and no
   "inconsistent" advertisements have been received, reducing control
   overhead when the network is in a consistent state."
-> it should be made clear if this is only about "inconsistent" advertiseme=
nts, or also "inconsistent" transmissions as defined in section 6.2, which =
includes more than just advertisements.
The term advertisement usually means the Trickle ICMP message, but here it'=
s not so clear.
It would be even better to unify the terminology, e.g. use only "inconsiste=
nt" transmissions and do not mention "inconsistent" advertisements here.

"Instead, nodes simply retransmit multicast messages they
   are trying to forward."
-> replace 'nodes' with 'forwarders' here. 'they are trying to forward' cou=
ld be specified better here e.g. as in
 'all multicast messages they have buffered'.

Section 4

Parameters in general: should there be requirements on what parameter range=
s an implementation supports?
For example, an implementation could only support k=3Dinfinity to reduce co=
de size. Is this allowed?
Can it claim to be compliant to this protocol?

"Tactive ... Specified in units of Imax."
-> does this imply integer multiples of Imax? Or are fractions of Imax okay=
 too.
(Same point for Tdwell)

Stating Tdwell MUST be >=3D Tactive would be useful here for completeness.

The conservative parameter settings example:
- Imax is 30 min, which is not an integer number of doublings of Imin as de=
scribed in RFC6206. Maybe use Imax=3D14 (doublings) gives Imax =3D 27.3 (mi=
nutes) ?
- Tdwell is 6 hours in this example. Correct? It seems quite a long period =
to keep sliding window state.

Section 5.2

"The link-local all-nodes (FF02::1) or link-local all-routers (FF02::2) mul=
ticast address."
-> why is all-nodes allowed, if the ICMP message is only intended for route=
rs?

Section 5.2.1

"SeedID    Copied from a recently received Trickle Multicast option."
-> better to describe what it means first, then how it was obtained. So a S=
eedID description to be inserted.

Section 6.1

"Every Trickle multicast forwarder MUST maintain a sliding window of
   Sequence values for each SeedID "
-> there is an exception to the MUST, if memory constraints don't allow it.=
 Best to mention this directly in the paragraph perhaps?

"When only one entry for a sliding window remains, that entry MUST NOT
   be reclaimed until its dwell timer expires"
-> here the usage of value Tdwell should be mentioned explicitly e.g. "dwel=
l timer > Tdwell" means it expired.
-> typo: previous paragraph mentions "dwell time" not "dwell timer"?
-> concept of dwell timer not fully explained. The use of "reclaiming entry=
" in the text suggests that each entry has a dwell timer, but the text in d=
efinition of Tdwell suggests that an entire sliding window has one dwell ti=
mer.
A need to formally define the dwell timer and the active timer?

In general, the situation when a new entry within a sliding window can't be=
 created due to memory constraints is not considered. (Reclaiming entries t=
o gain memory is considered on the other hand - so why not the reverse.)
If in the future the idea of bit masks in a sliding window would be introdu=
ced then the individual entry creation/deletion is not relevant for memory =
considerations probably.

Section 6.2

"A Trickle multicast forwarder maintains two Trickle timers
   parameterized on the S flag."
-> M flag

"...transmission event consists of transmitting a Trickle ICMP message.
   If an "inconsistent" advertisement was received during that period,
   multicast messages that caused the inconsistency are also
   retransmitted."
-> should the mentioned 'multicast messages' be defined as part of the tran=
smission event for k finite? Currently the transmission event seems defined=
 as only the ICMP message. While for k =3D infinite, the transmission event=
 is defined as retransmitting all buffered multicast messages.

"When suppression is enabled (i.e. k is finite), a Trickle
   transmission event consists of transmitting a Trickle ICMP message.
   If an "inconsistent" advertisement was received during that period,
   multicast messages that caused the inconsistency are also
   retransmitted."
-> If I read correctly, "multicast messages" here includes Trickle Multicas=
t Messages but also IP multicast datagrams. The latter is for example sent =
by a host and received by a Trickle Multicast Forwarder which adds the HbH =
option. It would be good to add a definition, and consider what to do, for =
IP multicast datagrams which do not (yet) have the Trickle HbH option.

-> text suggests (in its context) that retransmissions are probably a part =
of the "transmission event". But some may also interpret this differently, =
based on the prior definition; i.e. that multicast messages that caused inc=
onsistency are retransmitted directly, regardless of whether the transmissi=
on event is suppressed or not. In this view, retransmissions are not part o=
f the Trickle transmission event.
Improved definitions of "retransmission" and "transmission event" could sol=
ve that.

-> the order of Trickle ICMP Message / Trickle Multicast Messages is not de=
fined. Is any order allowed? We would prefer so. E.g. first send all retran=
smissions and then the ICMP message can have specific latency advantages.
-> any requirements on the time between messages, if multiple messages are =
sent in one transmission event?

"This document defines receiving a "consistent" transmission as
   receiving a Trickle ICMP message that indicates neither the receiving
   nor transmitting node has new multicast messages to offer.
   This document defines receiving an "inconsistent" transmission as
   receiving a Trickle ICMP message that indicates either receiving or
   transmitting node has a new multicast message to offer.    An "inconsist=
ent"
   transmission also includes receiving a new multicast message."
-> so a "transmission" consists of a single message. This makes it differen=
t from a "transmission event" which may consist of multiple messages. Just =
wondering if this complies with RFC 6206 which was probably written with a =
single message per event in mind? Any thoughts?

Section 6.3

"Upon accepting the message, the forwarder MUST enter the sequence
   value in the sliding window and decrement the IPv6 Hop Limit.  If the
   IPv6 Hop Limit is non-zero, the forwarder MUST buffer the message for
   retransmission for the duration specified by Tactive."
-> to do: specify behaviour if the buffer for the message can't be allocate=
d?

Section 6.4
"Processing a Trickle ICMP message involves determining if either the
   receiver or transmitter has new multicast messages to offer."
-> Processing a Trickle ICMP message by a multicast forwarder involves ...
   (edited to clarify whether it is the sender or the receiver that is late=
r in this section called "multicast forwarder")

"The transmitter has new multicast messages to offer if any (SeedID,
   Sequence) pair falls within an existing sliding window for SeedID but
   does not have an associated entry."
-> The transmitter has new multicast messages to offer if any (SeedID,
   Sequence) pair from the message falls within an existing sliding window =
for SeedID but
   does not have an associated entry in this sliding window.

"The transmitter has new multicast messages to offer if the (SeedID,
   Sequence) pair is great than the upper bound of an existing sliding
   window for SeedID."
-> The transmitter has new multicast messages to offer if any (SeedID,
   Sequence) pair is greater than the upper bound of an existing sliding
   window for SeedID.

"logs an inconsistent event by resetting Trickle timer T[M]"
-> logs an inconsistent event by resetting Trickle timer T[M] and setting c=
=3D0
   (addition c=3D0 to clarify only)
-> maybe add that reset is only when I > Imin.
   But it should be clear that the action of scheduling of "all new message=
s that the receiver can offer" is done always, even if I=3D=3DImin already.=
 E.g. in situations where two ICMP messages with inconsistent info are rece=
ived in rapid succession, this is relevant.
-> The above statement about the scheduling action for some readers of the =
draft may seem to contradict step 6 of the Trickle algorithm,
   "If I is equal to Imin when Trickle hears an "inconsistent" transmission=
, Trickle does nothing"
   which requires that nothing should be done.

"All new messages that the receiver can offer MUST be scheduled"
-> "All new messages that the receiver can offer to the transmitter MUST be=
 scheduled"
   (aim to clarify. This statement is not about any messages it can offer i=
n general, probably.)
-> What if the sending of scheduled multicast transmissions takes so long t=
hat the next Trickle "transmission event" already happens when the previous=
 one is still ongoing (e.g. for very small I=3DImin)?




-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon=
athan Hui (johui)
Sent: Friday 13 July 2012 18:59
To: roll@ietf.org WG
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-01.txt


Activity on this draft has been dormant for far too long.  We've resubmitte=
d the draft with no substantive changes in attempt to move this work forwar=
d.

>From my perspective, there are a number of areas to improve on this draft:

1) Format of the HBH Option.

- The HBH Option does not currently have any version field.  I know the Zig=
Bee folks are anxious to lock the format down, yet I don't believe we are a=
t a point where we can (given the issues below and other issues that we hav=
e yet to find).  Finding a way to version the HBH Option will give us a pat=
h forward not only as we work on the initial specification but for future s=
pecifications as well.

- The SeedID is limited to 2 or 16 bytes.  That seems a bit constrained.  F=
irst, I have seen use cases where only a single multicast seed is used with=
in a network, and it would be beneficial to completely elide the SeedID (wi=
th an assumed value of zero).  Second, different applications have differen=
t upper bounds on the number of seeds and/or how the SeedIDs are allocated/=
configured, which can dictate what size  the SeedID should actually be.  On=
e thought is to allow the SeedID to vary between 0 and 16 bytes.

- The Sequence field is 15 bits.  I would be nice to have a Sequence field =
that is a multiple of 8 bits to make Serial Number Arithmetic more convenie=
nt.

- I'm aware of one technical bug with the HBH Option when trying to utilize=
 a sliding window larger than 1.  In particular, a device processing the HB=
H Option does not know if the Sequence value represents the largest sequenc=
e value received by the neighboring node or an older message that it happen=
s to be retransmitting.  Ideally, a device only resets its Trickle timer wh=
en receiving indication that a neighboring device has not yet received a me=
ssage yet.  I propose adding a flag to the HBH Option that indicates whethe=
r the Sequence value is the latest.

2) Format of the ICMPv6 Message

- The format of the ICMPv6 message is not as compact as it could be.  Curre=
ntly it explicitly lists each sequence value within a sliding window.  An a=
lternative is to have a field that indicates the base and length, then use =
a bit vector to indicate what sequence values are buffered.

3) Use of IPv6-in-IPv6 Tunneling

- This draft was written before the RPL Option and RPL Source Route Header =
drafts went through extensive review.  What we learned from doing the RPL O=
ption and Source Route Header is that IPv6-in-IPv6 encapsulation is necessa=
ry whenever adding/removing fields from an IPv6 packet en-route.  It is esp=
ecially necessary when adding to ensure that we don't break Path MTU discov=
ery.  It is convenient when removing to ensure that the original packet rem=
ains unmodified.

4) In general, a lot of work needs to be done to the draft to make the forw=
arder behavior rules more explicit.

Thoughts?

--
Jonathan Hui


On Jul 13, 2012, at 9:55 AM, <internet-drafts@ietf.org>
 <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Routing Over Low power and Lossy network=
s Working Group of the IETF.
>
>       Title           : Multicast Forwarding Using Trickle
>       Author(s)       : Jonathan W. Hui
>                          Richard Kelsey
>       Filename        : draft-ietf-roll-trickle-mcast-01.txt
>       Pages           : 19
>       Date            : 2012-07-13
>
> Abstract:
>   Low power and Lossy Networks (LLNs) are typically composed of
>   resource constrained nodes communicating over links that have dynamic
>   characteristics.  Memory constraints coupled with temporal variations
>   in link connectivity makes the use of topology maintenance to support
>   IPv6 multicast challenging.  This document describes the use of
>   Trickle to efficiently forward multicast messages without the need
>   for topology maintenance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-01
>
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-01
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From sensys@cfpmail.info  Tue Jul 10 01:16:16 2012
Return-Path: <sensys@cfpmail.info>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957E021F8661 for <roll@ietfa.amsl.com>; Tue, 10 Jul 2012 01:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZKKCRSrgeB1 for <roll@ietfa.amsl.com>; Tue, 10 Jul 2012 01:16:14 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F221F8569 for <roll@ietf.org>; Tue, 10 Jul 2012 01:16:13 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so12028843ghb.31 for <roll@ietf.org>; Tue, 10 Jul 2012 01:16:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=vO8lmO395t9wIWqLD6mIRZQRKPCzjDm26T3aSat/DiM=; b=Hqre0TofvWbcacovZHQuP1DwiVhQQ8q5I+3x+ShRoW8p1MgE7RpDgIvLVWEc/VviEO BYtFdjCXEbu/m83CzIQv0zZ0BGhBt7w8R8aUj7Yg0oolFY0JQH6XauVOWon8NUKPT4L+ nYHLZmTcq1tfVX2N16qnCtwG9w1dQNqkXb8RHtn8HCCFmp4LYSULTKK9936S3yYW2DRv L5JEo01pdMuinYARxYxAQ9+f+3zH4jtkZ7YhHxXYb8xNGOGiaj9kzJxFJrdr8qwfUqAq jti081exCyszr62K5+476enGHTqTGlGMZX41k/joZYkDJXGP4k7Ww9rO0bg8ICZEZSNH KuFA==
MIME-Version: 1.0
Received: by 10.236.174.66 with SMTP id w42mr11211202yhl.106.1341908200129; Tue, 10 Jul 2012 01:16:40 -0700 (PDT)
Received: by 10.146.121.8 with HTTP; Tue, 10 Jul 2012 01:16:40 -0700 (PDT)
X-Originating-IP: [109.68.196.26]
Date: Tue, 10 Jul 2012 01:16:40 -0700
Message-ID: <CADROuzxnM1eroopdb_wUA=mdPzNCcangurcdO=Fb=n6OxR0dvQ@mail.gmail.com>
From: "SenSys'12 Publicity" <sensys@cfpmail.info>
To: "SenSys'12 Publicity" <sensys@cfpmail.info>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnAe+Ryo1G/OzoYHKCU17vJpQYbEAgfgKXWlJhLWWczsKzw8fpjVghMSAHEPnOg4w0Uf7Z1
X-Mailman-Approved-At: Mon, 23 Jul 2012 09:13:02 -0700
Subject: [Roll] CFP: PhoneSense2012 (with SenSys 2012), Toronto, Canada, 6 Nov 2012
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 08:16:16 -0000

(We apologize if you receive multiple copies of this CFP.)
=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
Call for Papers

PhoneSense 2012 (collocated with ACM SenSys 2012)

Toronto, Canada

6 November 2012

http://research.microsoft.com/en-us/um/redmond/events/phonesense2012



IMPORTANT DATES
=95 Paper submissions due: 25 July 2012, 9:00 p.m. PDT
=95 Notification of acceptance: 12 September 2012

ORGANIZERS

PROGRAM CO-CHAIRS
David Chu (Microsoft Research)
Ramesh Govindan (USC)

PROGRAM COMMITTEE
Gaetano Borriello (University of Washington)
Eyal de Lara (University of Toronto)
Deborah Estrin (UCLA)
Deepak Ganesan (UMass Amherst)
Shyamnath Gollakota (MIT)
Ben Greenstein (Google)
Richard Han (University of Colorado)
Anthony LaMarca (Intel Labs)
Jie Liu (Microsoft Research)
Alexander Varshavsky (AT&T Labs)

STEERING COMMITTEE
Deborah Estrin (UCLA)
Aman Kansal (Microsoft Research)
Deepak Ganesan (UMass Amherst)

OVERVIEW
Mobile phones provide a widespread platform for deploying sensing
applications. Multiple factors, including the large number of sensors
available on phones with new ones being introduced in newer models,
proximity to user=92s immediate environment, broadband connectivity, and
the potential to provide actionable information, make the phone a
compelling platform for many sensing applications. The emergence of
the mobile computing cloud further expands the scope of possible use
cases. Sensing applications can use the mobile phones and cloud
resources to sense, mine, and learn human behaviors and intentions to
provide personalized feedback and persuasion. Example sensing
application domains include personalized mobile information delivery,
context aware social networking, healthcare, games and entertainment,
education, device and environment customization, safety, and mobile
business.

The efficient and effective design of mobile sensing applications
opens up many interesting technical challenges. The PhoneSense
workshop promotes exchange of ideas among academic and industrial
researchers in research areas such as sensing, mobile computing,
location, energy efficiency, data management, data mining, machine
learning, inference, privacy, user incentives and applications.

The workshop considers hot topics, position papers, novel ideas,
in-progress work on system architecture, enabling technologies, and
emerging applications. Topics of interest include, but are not limited
to:

=95 Novel Applications
=95 Mining large scale sensor and location data
=95 Mobile cloud and sensing interfaces
=95 Incentive models for mobile data collection
=95 Interaction between phones and humans
=95 Novel mobile sensor accessories
=95 Sensing and machine learning techniques
=95 Persuasion models and techniques to close the loop with users
=95 Privacy
=95 Participatory sensing, crowdsourcing, and opportunistic sensing paradig=
ms
=95 Activity recognition and subjective sensing
=95 Programming models
=95 Experiment and campaign design
=95 Integration of on-phone and off-phone sensing
=95 Personalization, geo-targeting
=95 Personal health monitoring using mobile phones
=95 Data quality issues
=95 Experience with app store delivery systems and large scale deployment

WHAT TO SUBMIT
Submissions must be at most 5 single-spaced 8.5" x 11" pages,
including figures, tables, and references, two-column format, using
10-point type with ACM proceedings format. Submissions will be
reviewed by the program committee for novelty, relevance, and quality.

PhoneSense is single-blind, so authors should include their names on
their paper submissions.  For more details, see
http://research.microsoft.com/en-us/um/redmond/events/phonesense2012.

From sensys@cfpmail.info  Tue Jul 10 12:02:01 2012
Return-Path: <sensys@cfpmail.info>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D752A11E80E7 for <roll@ietfa.amsl.com>; Tue, 10 Jul 2012 12:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBeFJO5u98AU for <roll@ietfa.amsl.com>; Tue, 10 Jul 2012 12:02:00 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 58E3A11E80E3 for <roll@ietf.org>; Tue, 10 Jul 2012 12:02:00 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so372922ghb.31 for <roll@ietf.org>; Tue, 10 Jul 2012 12:02:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=5yTsK94a4Zdlp105g4wdeA8Vq6E36WObKO2B1BXtoZQ=; b=oSka7J9wrgXk+xa6Oq9xL50Cb2UTR2MyZld2vO7JWgUUaI9Pjl8kwSjI1ni0cmHyRW cetkPWUeRhfSfySFrP9/FR57VhXp0tWoJajSPtSWXSAE5hE0TuN+lqS1DYiqs3XtLfPj 698U3poYWYBC0Df8tsaBA2b39xEFEoI358RnfGnjGUawmtaUbDtfL9T8Fxi8GkjI9WUV LZHdQ2RLqLXuS4PH+r8eonowj0FzLUyhyfwjcCS8ClmRVcJN1EnGt7n++PUqVMuOukCB 1lrSevvmaHGd7UBY+UCeMlVc3HnkDmMcyoSCCWqJTQ2ot5cI8Ej3tYhuUhQ4TZTPszmf 5POA==
MIME-Version: 1.0
Received: by 10.236.174.66 with SMTP id w42mr13819309yhl.106.1341946948442; Tue, 10 Jul 2012 12:02:28 -0700 (PDT)
Received: by 10.146.121.8 with HTTP; Tue, 10 Jul 2012 12:02:28 -0700 (PDT)
X-Originating-IP: [106.187.39.232]
Date: Wed, 11 Jul 2012 03:02:28 +0800
Message-ID: <CADROuzxoeqTVBS+OiegTSeknNwab6-g9r24_wrH4k1Wec3vnHA@mail.gmail.com>
From: "SenSys'12 Publicity" <sensys@cfpmail.info>
To: undisclosed-recipients:;
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnuHh9EkGIoFtt2JZVaaU1waCycuBIyQJMqXjuU36zzC6Ua8fhr71oeCN+0G5fBxx7bLpV1
X-Mailman-Approved-At: Mon, 23 Jul 2012 09:13:02 -0700
Subject: [Roll] [CFP] SenSys 2012 Demo: The ACM Conference on Embedded Networked Sensor Systems / Demo
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 19:02:02 -0000

SenSys 2012 solicits demonstrations showing innovative research and
applications. Demos which demonstrate working systems, new platforms
and tools, innovative applications, ground breaking ideas, and other
revolutionary concepts related to SenSys are welcome. Submissions from
both industry and universities are encouraged. Demos will be evaluated
based on technical merit and innovation as well as their potential to
stimulate interesting discussions and exchange of ideas. All accepted
demos will appear in Sensys 2012 proceedings.

Best Demo Award(s)
During the conference, all demos will be evaluated based on technical
merit, innovation, implementation completeness, and presentation
quality to select the best demo(s). The selected demos will receive
awards that will be announced during the conference.

DEMO SUBMISSION INSTRUCTIONS
Submit a two-page description of your demo explaining the details of
what you will be presenting in as much detail as possible. If you plan
to demonstrate any technology involving non-standard RF transmissions,
please state this explicitly in your demo description. This will allow
us to minimize interference between demos.

Demos should be submitted to:
http://dachs.ece.utah.edu/sensys_demo_submissions/

Authors should format their two-page demo abstracts according to the
formatting guidelines provided for full paper submissions. Demo
submissions should be in PDF format.

IMPORTANT DATES
Two-page demo descriptions: 11:59pm (PST), July 27, 2012
Notification of acceptance: August 6, 2012
Camera-ready abstract: August 17, 2012
Conference dates: November 6-9, 2012

SenSys 2011 DEMO CHAIRS
Jakob Eriksson (University of Illinois, Chicago), jakob@uic.edu
Pei Zhang (CMU), peizhang@cmu.edu

From wwwrun@rfc-editor.org  Wed Jul 18 02:12:10 2012
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A620A21F8650 for <roll@ietfa.amsl.com>; Wed, 18 Jul 2012 02:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.217
X-Spam-Level: 
X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhc5dWImxSB8 for <roll@ietfa.amsl.com>; Wed, 18 Jul 2012 02:12:10 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 096F021F8643 for <roll@ietf.org>; Wed, 18 Jul 2012 02:12:10 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id E9B21621A1; Wed, 18 Jul 2012 02:12:25 -0700 (PDT)
To: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com, stbryant@cisco.com, adrian@olddog.co.uk, mcr+ietf@sandelman.ca, jpv@cisco.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20120718091225.E9B21621A1@rfc-editor.org>
Date: Wed, 18 Jul 2012 02:12:25 -0700 (PDT)
X-Mailman-Approved-At: Mon, 23 Jul 2012 09:13:02 -0700
Cc: roll@ietf.org, nduong@purdue.edu, rfc-editor@rfc-editor.org
Subject: [Roll] [Editorial Errata Reported] RFC6550 (3287)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2012 09:12:10 -0000

The following errata report has been submitted for RFC6550,
"RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=3287

--------------------------------------
Type: Editorial
Reported by: Duong Nguyen <nduong@purdue.edu>

Section: 6.5.1

Original Text
-------------
     127-255:  Rejection; the node sending the DAO-ACK is unwilling to
               act as a parent.

Corrected Text
--------------
     128-255:  Rejection; the node sending the DAO-ACK is unwilling to
               act as a parent.

Notes
-----
The status code range of "Rejection" overlaps with status code range of "Not an outright rejection".

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6550 (draft-ietf-roll-rpl-19)
--------------------------------------
Title               : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
Publication Date    : March 2012
Author(s)           : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander
Category            : PROPOSED STANDARD
Source              : Routing Over Low power and Lossy networks
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

From Mehdi.Mani@itron.com  Wed Jul 25 07:02:14 2012
Return-Path: <Mehdi.Mani@itron.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F5D21F850C for <roll@ietfa.amsl.com>; Wed, 25 Jul 2012 07:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.184
X-Spam-Level: 
X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFtkWUzrBdO3 for <roll@ietfa.amsl.com>; Wed, 25 Jul 2012 07:02:13 -0700 (PDT)
Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 540F121F84F2 for <roll@ietf.org>; Wed, 25 Jul 2012 07:02:13 -0700 (PDT)
Received: from ITR-EXMBXVS-1.itron.com ([192.168.9.111]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Wed, 25 Jul 2012 07:02:12 -0700
From: "Mani, Mehdi" <Mehdi.Mani@itron.com>
To: "roll@ietf.org" <roll@ietf.org>
Date: Wed, 25 Jul 2012 07:02:10 -0700
Thread-Topic: [Roll] MRHOF draft-11 comments
Thread-Index: Ac1qbhWCRB0vAOVZR0ycuOBJkWog0Q==
Message-ID: <10F62A0D440ACA41A85C7CB02936A1DB5B37679AE0@ITR-EXMBXVS-1.itron.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
Content-Type: multipart/alternative; boundary="_000_10F62A0D440ACA41A85C7CB02936A1DB5B37679AE0ITREXMBXVS1it_"
MIME-Version: 1.0
Subject: [Roll]  MRHOF draft-11 comments
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jul 2012 14:02:14 -0000

--_000_10F62A0D440ACA41A85C7CB02936A1DB5B37679AE0ITREXMBXVS1it_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In section 3.3, it seems that the rank value using the case 3 is always les=
s than the one calculated in case 2; then it is useless to have it. (if my =
understanding is true!)  This is basically because the highest "rank increa=
se" that would be possible is equal to MaxRankIncrese.

As an example imagine that a node (say N) has 3 father F1, F2 and F3 with r=
espectively the ranks 50, 40 and 30. Imagine that MaxRankIncrese is 20 and =
MinRankIncrease is 2. Then imagine that:

Link  N --> F1 gives a rank increase =3D 6
Link N --> F2  gives a rank increase =3D MaxRankIncrese =3D 20
Link N --> F3  gives a rank increase =3D 10

Case 2 gives:

Rank=3D52 (Worst Father rank belongs to F1)

Case 3 gives:
40+20-20=3D40 (Since the highest rank is through F2)

Now consider the same example but with this changes (this is the worst case=
 where the link to the father with worst rank gives also the highest rank i=
ncrease):

Link  N --> F1 gives a rank increase =3D MaxRankIncrese =3D 20
Link N --> F2  gives a rank increase =3D 8
Link N --> F3  gives a rank increase =3D 10


Case 2 gives:
Rank=3D52

Case 3 gives:
50+20-20=3D50 (Since the highest rank is through F1)

Thanks
-Mehdi




--_000_10F62A0D440ACA41A85C7CB02936A1DB5B37679AE0ITREXMBXVS1it_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content=
=3D"text/html; charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Micr=
osoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DFR link=3Dblue vlink=
=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span lang=3DEN-US=
>In section 3.3, it seems that the rank value using the case 3 is always le=
ss than the one calculated in case 2; then it is useless to have it. (if my=
 understanding is true!) =A0This is basically because the highest &#8220;ra=
nk increase&#8221; that would be possible is equal to MaxRankIncrese.<o:p><=
/o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></=
span></p><p class=3DMsoNormal><span lang=3DEN-US>As an example imagine that=
 a node (say N) has 3 father F1, F2 and F3 with respectively the <b>ranks 5=
0, 40 and 30.</b> Imagine that MaxRankIncrese is 20 and MinRankIncrease is =
2. Then imagine that:<o:p></o:p></span></p><p class=3DMsoNormal><span lang=
=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span lang=3DEN-U=
S>Link =A0N </span><span lang=3DEN-US style=3D'font-family:Wingdings'>=E0</=
span><span lang=3DEN-US> F1 gives a rank increase =3D 6<o:p></o:p></span></=
p><p class=3DMsoNormal><span lang=3DEN-US>Link N </span><span lang=3DEN-US =
style=3D'font-family:Wingdings'>=E0</span><span lang=3DEN-US> F2=A0 gives a=
 rank increase =3D MaxRankIncrese =3D 20<o:p></o:p></span></p><p class=3DMs=
oNormal><span lang=3DEN-US>Link N </span><span lang=3DEN-US style=3D'font-f=
amily:Wingdings'>=E0</span><span lang=3DEN-US> F3=A0 gives a rank increase =
=3D 10<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US><o:p>&n=
bsp;</o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>Case 2 gives:<=
o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o=
:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>Rank=3D52 (Worst Fath=
er rank belongs to F1)<o:p></o:p></span></p><p class=3DMsoNormal><span lang=
=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span lang=3DEN-U=
S>Case 3 gives:<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-U=
S>40+20-20=3D40 (Since the highest rank is through F2)<o:p></o:p></span></p=
><p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p cla=
ss=3DMsoNormal><span lang=3DEN-US>Now consider the same example but with th=
is changes (this is the worst case where the link to the father with worst =
rank gives also the highest rank increase): <o:p></o:p></span></p><p class=
=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoN=
ormal><span lang=3DEN-US>Link =A0N </span><span lang=3DEN-US style=3D'font-=
family:Wingdings'>=E0</span><span lang=3DEN-US> F1 gives a rank increase =
=3D MaxRankIncrese =3D 20<o:p></o:p></span></p><p class=3DMsoNormal><span l=
ang=3DEN-US>Link N </span><span lang=3DEN-US style=3D'font-family:Wingdings=
'>=E0</span><span lang=3DEN-US> F2=A0 gives a rank increase =3D 8<o:p></o:p=
></span></p><p class=3DMsoNormal><span lang=3DEN-US>Link N </span><span lan=
g=3DEN-US style=3D'font-family:Wingdings'>=E0</span><span lang=3DEN-US> F3=
=A0 gives a rank increase =3D 10<o:p></o:p></span></p><p class=3DMsoNormal>=
<span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span l=
ang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span lang=3DE=
N-US>Case 2 gives:<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DE=
N-US>Rank=3D52<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US=
><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>Case 3=
 gives:<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US>50+20-=
20=3D50 (Since the highest rank is through F1)<o:p></o:p></span></p><p clas=
s=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMso=
Normal><span lang=3DEN-US>Thanks<o:p></o:p></span></p><p class=3DMsoNormal>=
<span lang=3DEN-US>-Mehdi<o:p></o:p></span></p><p class=3DMsoNormal><span l=
ang=3DEN-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span lang=3DE=
N-US><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US><o=
:p>&nbsp;</o:p></span></p></div></body></html>=

--_000_10F62A0D440ACA41A85C7CB02936A1DB5B37679AE0ITREXMBXVS1it_--

From mcr+ietf@sandelman.ca  Tue Jul 31 17:26:34 2012
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5283011E80E1 for <roll@ietfa.amsl.com>; Tue, 31 Jul 2012 17:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.142
X-Spam-Level: 
X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.457,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqEd88kNmY2i for <roll@ietfa.amsl.com>; Tue, 31 Jul 2012 17:26:33 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id D399311E80DF for <roll@ietf.org>; Tue, 31 Jul 2012 17:26:33 -0700 (PDT)
Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 96D622016A for <roll@ietf.org>; Tue, 31 Jul 2012 20:38:53 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: roll@ietf.org
In-Reply-To: <32407.1341510191@marajade.sandelman.ca>
References: <20120430114209.21250.82110.idtracker@ietfa.amsl.com> <18151.1335822136@marajade.sandelman.ca> <BD8E8F5A-E564-49C9-96D0-55B76DA23AB0@cisco.com> <10134.1337103877@marajade.sandelman.ca> <32407.1341510191@marajade.sandelman.ca>
X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Tue, 31 Jul 2012 20:26:29 -0400
Message-ID: <9322.1343780789@obiwan.sandelman.ca>
Subject: Re: [Roll] proposal for common table of contents for applicability statements
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Aug 2012 00:26:34 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


I have posted
  http://datatracker.ietf.org/doc/draft-richardson-roll-applicability-templ=
ate

this includes the text that I had posted on July 5.
It includes quite a number of places where security parameters or
statements must be filled in.=20

I would like some comments about what pieces I've missed, particularly
From=20people with more Zigbee and 802.15.4 clue than I have.

=2D-=20
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works=20
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQCVAwUAUBh3tYqHRg3pndX9AQLsNgQAmTCDGeZJNVTHeiHDiAQv/jQZQNOTGZjF
ZN2fjEO2H3AKoezU185Ho3JcF5mki/+wj+XDL44LF9U2ECz9/bbQxIirrDktoje+
f68v8iGFxFD7tHA8bKvgkqq3c0k3l7hBdzRqVfI/0bQLQl4j5GgdB2Gp1hDPxZ1z
B61jpDEBzDA=
=qOMP
-----END PGP SIGNATURE-----
--=-=-=--