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 resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-roll-urban-routing-reqs-02.txt
Reviewer: Brian Carpenter
Review Date: 2008-11-19
IETF LC End Date: 2008-11-25
IESG Telechat date: (if known)
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.
> 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.
> 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.
> 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...
> 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).
> 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.
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.
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.
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_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
