Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
draft-ietf-roll-routing-metrics-19
Yes
(Adrian Farrel)
(Stewart Bryant)
No Objection
(Gonzalo Camarillo)
(Jari Arkko)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
Abstain
Note: This ballot was opened for revision 19 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
Stewart Bryant Former IESG member
Yes
Yes
()
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2011-01-15)
Unknown
In 2.1: The A field has no meaning when the C Flag is set (i.e. when the Routing Metric/Constraint object refers to a routing constraint) and he only valid when the R bit is cleared. Otherwise, the A field MUST Is "he" should be here at all? be set to 0x00 and MUST be ignored on receipt. 4.1. Throughput Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format, In network byte order? (Also in 4.2) expressed in bytes per second.
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2011-01-18)
Unknown
1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then there are 5 bits labelled Flags on the diagram which are actually the currently reserved or un-allocated Flags. The A field and PRec filed are part of the Flag field, but there is no indication or indent to make this clear. 2. Expand DIO at first occurence 3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like Link Capacity.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2011-02-20)
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2011-01-19)
Unknown
Based on the reviews provided by IESG members more expert than I in the technology under consideration, I am ballotting "No Objection". That said, based on my own review I concur with the DISCUSS raised by Jari Arkko regarding the complexity of the system.
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
Abstain
Abstain
(2011-01-17)
Unknown
Section 1., paragraph 16: > flexibility to use link and node characterisics either as constraints Nit: s/characterisics/characteristics/ Section 1., paragraph 21: > and unneccessary routing changes. Nit: s/unneccessary/unnecessary/ Section 3., paragraph 1: > objet MUST silently be ignored. Nit: s/objet/object/ Section 4.1., paragraph 0: > 4.1. Throughput I think you mean (link) capacity here and not throughput. See the definition in RFC5136; could you adopt this definition here? Section 4.2., paragraph 0: > 4.2. Latency See the definitions in RFC2679, can they be adopted here? Also, is this metric supposed to include buffering/queueing delay (which is load dependent) or is it purely supposed to capture the link transmission delay? If the former, that can vary quite a bit more... Section 4.3.2., paragraph 12: > the path (cummulative path ETX calculated as the sum of the link ETX Nit: s/(cummulative/(cumulative/ Section 7., paragraph 1: > consist of making intermitment attacks on a link in an attempt to Nit: s/intermitment/intermittent/ Section 8., paragraph 1: > valuable comments. Special thank to Adrian Farrel for his thourough Nit: s/thourough/thorough/