Brian, reviewers,
I second Mischa's thanks for your time to read and comment. Please
find
my additional comments inline.
Thanks,
-Tim
Mischa Dohler wrote:
Dear Brian,
Apologies for not having responded earlier but this is the first
time
I have seen these comments - I am not sure why your first attempt
didn't get through. Many thanks for having taken your time to read
and
comment on the document. You can find my comments in-line. I would
expect that my co-authors will also reply asap.
Kind regards,
Mischa.
_____________________________
Dr Mischa Dohler
Senior Researcher
CTTC, Barcelona
Tel: +34 93 645 2900
Fax: +34 93 645 2901
Mob: +34 6 7909 4007
www.cttc.es/home/mdohler
_____________________________
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-roll-urban-routing-reqs-02.txt
Reviewer: Brian Carpenter
Review Date: 2008-12-13
IESG Telechat date: 18 December 2008
Summary: Almost ready, clarifications suggested
Comments:
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this
document are to be interpreted as described in RFC 2119
[RFC2119].
Well, I've read 2119 many times, and I still don't understand how it
can be applied to requirements documents. It seems quite clear
that it's
intended for use in protocol standards. I suggest that using English
(i.e. lower case must, should, etc.) is more appropriate.
MISCHA: Please, discuss this with JP Vasseur and Christian Jacquenet
as I have absolutely no preferences but they seem to have. Thanks.
Tim: Based on feedback when the document was in the WG, the document
was structured to separate informative text by using `should,
must, ...'
from specific normative requirements for the routing protocol(s)
using
`SHOULD, MUST, ...'
3.1.3. Routers
...
Routers may but generally do not suffer from any
form of (long-term) resource constraint, except that they need
to be
small and sufficiently cheap.
This surprises me. In disaster recovery situations (e.g. after a
major
storm
with prolonged power cuts) it seems that the routers will be
completely
dependent on battery lifetime.
MISCHA: They will indeed but only over a relatively short time. We
are
generally talking about lifetimes of a decade or slightly more.
6.2. Parameter Constrained Routing
...
Routing within urban sensor networks SHOULD require the U-LLN
nodes
to dynamically compute, select and install different paths
towards a
same destination, depending on the nature of the traffic. From
this
perspective, such nodes SHOULD inspect the contents of traffic
payload for making routing and forwarding decisions: for
example, the
analysis of traffic payload should encourage the enforcement of
forwarding policies based upon aggregation capabilities for the
sake
of efficiency.
The second half of this seems highly dubious to me. It encourages
layer
violation, and this is known to be a performance issue for routers.
It will complicate the router, slow it down, and increase its cost
and
power consumption. (It also won't work for encrypted payloads.)
There's no particular reason to believe that this would be a useful
tradeoff,
since the aggregation is presumably in the upstream direction (away
from sensors and actuators, and towards servers) where the power and
bandwidth issues will presumably be less critical.
If there is a desire to achieve traffic-based path selection, a
simpler
mechanism than deep packet inspection should be used. I don't want
to
stray
too far into solutionism, but diffserv comes to mind.
In any case this is written as an implementation requirement, not a
requirement on the routing protocol. The requirement stated in
"6.4. Support of Highly Directed Information Flows" seems much
closer to what is needed.
MISCHA: I agree with your comment. Tim, what is your thought on
this?
Could you maybe change this part of the document? Note that Phil
also
had alluded to the problem with violating e2e provisioning in the
case
of data aggregation.
Tim: I do understand the concern. There are certainly security
implications and end-to-end implications. I would however note that
there may be hops through less capable nodes in an U-LLN, even in an
upstream direction. In light of these and other comments related to
this text, I do agree that we can reword this requirement
somewhat. We
will make the proposed rewording available for further comment once
we
have got something worked out...
6.5. Support of Multicast, Anycast, and Implementation of
Groupcast
...
Routing protocols activated in urban sensor
networks SHOULD accommodate "groupcast" forwarding schemes, where
traffic is sent to a set of devices that implicitly belong to the
same group/cast.
This basically makes no sense as written, because of the the word
"implicitly". Routing protocols don't know things that are
implicit...
MISCHA: I agree. If you, Tim, agree, please, rephrase the statement.
Tim: The following comment will be incorporated as well. The
proposed
text would then read:
"With IP multicast, signaling mechanisms are used by a
receiver
to join a group and the sender does not know the receivers
of the
group. For a sender to address groups requires the
ability
to address a group of
receivers known by the sender even if the receivers do not
need to
know that they have been grouped by the sender (since
requesting each
individual node to join a multicast group would be very
energy-
consuming). Routing protocols activated in urban sensor
networks SHOULD accommodate "groupcast" forwarding
schemes, where
traffic is sent to a set of devices that belong to the
same group/cast."
What is required is the ability to address a group of
receivers known by the sender even if the receivers do not need
to
know that they have been grouped by the sender (since
requesting each
individual node to join a multicast group would be very energy-
consuming).
This seems to explain correctly what is meant by "groupcast" - can
this be
moved up by two paragraphs? It seems to be essentially the problem
addressed by "small group multicast" and the SAM research group
(http://www.irtf.org/charter?gtype=rg&group=samrg).
MISCHA: Ok. Tim, if you are ok too, please, move up.
Tim: Can be incorporated as in above response.
9. Acknowledgements
The in-depth feedback of JP Vasseur, Cisco, Jonathan Hui, Arch
Rock,
and Iain Calder is greatly appreciated.
We normally acknowledge individuals, not companies.
MISCHA: Ok.
Tim: The proposed text will then read:
"The in-depth feedback of JP Vasseur, Jonathan Hui
and Iain Calder is greatly appreciated."
Warnings from idnits:
== It looks like you're using RFC 3978 boilerplate. You should
update
this, as the boilerplate described in the IETF Trust License
Policy
document (see http://trustee.ietf.org/license-info) is accepted
from 10
November 2008, and will be required from 16 December 2008, 01:00
UTC. Version 1.34 of xml2rfc can be used to produce documents
with
boilerplate
according to the mentioned Trust License Policy document.
Tim: No problem, the new boilerplate can be incorporated.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is
what you
mean).
Found 'SHOULD not' in this paragraph:
With low computation power and scarce energy resources, U-
LLNs
nodes may not be able to resist any attack from high-power
malicious
nodes (e.g. laptops and strong radios). However, the amount of
damage
generated to the whole network SHOULD be commensurate with the
number of
nodes physically compromised. For example, an intruder taking
control
over a single node SHOULD not have total access to, or be able to
completely deny service to the whole network.
Tim: Good catch, will be incorporated.
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-04) exists of
draft-ietf-roll-home-routing-reqs-03
== Outdated reference: A later version (-02) exists of
draft-ietf-roll-indus-routing-reqs-01
Tim: Will be incorporated
