Re: [Gen-art] Gen-ART review of draft-ietf-roll-urban-routing-reqs-02.txt (corrected Subject)

[Tim Winter <[e-mail]>]

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: [phone]
> Fax: [phone]
> Mob: [phone]
>
> 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



_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art