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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Dec 2008 11:43:03 +1300

This is identical to my Last Call review, since I have
seen no response to that.

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

---

From: Mischa Dohler <[email-masked]>
Date: Sat, 13 Dec 2008 21:59:24 +0100

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.

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

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

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

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

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-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Dec 2008 12:20:22 +1300

Thanks, Tim, I'll look forward to the next version then.

As far as the MUST/SHOULD language is concerned, I'll be interested
to see the IESG's current view; my personal view is that capitalisation
isn't needed for design requirements.

    Brian

On 2008-12-14 11:29, Tim Winter wrote:
> 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.
>>
>> 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
>> ...
>> MISCHA: They will indeed but only over a relatively short time. We are
>> generally talking about lifetimes of a decade or slightly more.
>>
>> 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.
>>
>> 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...
> 
> 
> 
> 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
>            consuming).  Routing protocols activated in urban sensor
>            traffic is sent to a set of devices that belong to the
>            same group/cast."
> 
>  
> 
>> moved up by two paragraphs? It seems to be essentially the problem
>> addressed by "small group multicast" and the SAM research group
> Tim: Can be incorporated as in above response.
> 
> 
> 
>>> 9.  Acknowledgements
>>>
> 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:
>>
>>     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
> Tim:  No problem, the new boilerplate can be incorporated.
> 
> 
> 
>>  Miscellaneous warnings:
> Tim:  Good catch, will be incorporated.
> 
> 
> 
> Tim:  Will be incorporated
> 
> 
> 
>

---

From: Tim Winter <[email-masked]>
Date: Sat, 13 Dec 2008 17:29:27 -0500

Brian, reviewers,

Thanks,

-Tim

            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

---

From: JP Vasseur <[email-masked]>
Date: Wed, 17 Dec 2008 15:08:32 +0100

Thanks for the review Brian. We're finalizing the proposed comments  
and Tim/Mischa will go back to you.

Thanks.

JP.

On Dec 14, 2008, at 12:20 AM, Brian E Carpenter wrote:

>>> This surprises me. In disaster recovery situations (e.g. after a  
>>> major
>>> storm
>>> mechanism than deep packet inspection should be used. I don't want  
>>> to
>>> stray

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Dec 2008 10:28:11 +1300

(gen-art list added for proper archiving)

Thanks Dominique. I believe that the -03 version fully
addresses my concerns.

       Brian

On 2008-12-20 09:59, [email-masked] wrote:
> Hello Brian,
> 
> On behalf of the authors of draft-ietf-roll-urban-routing-reqs-02.txt, we would like to thank you again for your comments.
> Please find attached our response to them, along with the proposed new text for the draft and a diff file highlighting the changes.
> Should you consider that the corrections do adequately answer your concerns, please let us know and we'll move the new text to become the working group next version of the document. We'll also be delighted to see Russ'es "Discuss" flag cleared.
> If they don't answer your concerns, can you please let us know of your remaining comments, at your earliest convenience?
> With best regards
> 
> Dominique
> 
> 
> -----Message d'origine-----
> De : Brian E Carpenter [mailto:[email-masked]] 
> Envoyé : dimanche 14 décembre 2008 00:20
> À : Tim Winter
> Cc : Mischa Dohler; General Area Review Team; Dave Ward; [email-masked]; [email-masked]; [email-masked]; JACQUENET Christian ROSI-ITNPS-NAD-TIP
> Objet : Re: Gen-ART review of draft-ietf-roll-urban-routing-reqs-02.txt (correctedSubject)
> 
> As far as the MUST/SHOULD language is concerned, I'll be interested to see the IESG's current view; my personal view is that capitalisation isn't needed for design requirements.
> 
>     Brian
> 
>

---

From: JP Vasseur <[email-masked]>
Date: Sat, 20 Dec 2008 12:04:10 +0100

Thanks Brian.

On Dec 19, 2008, at 10:28 PM, Brian E Carpenter wrote:

>> On behalf of the authors of draft-ietf-roll-urban-routing- 
>> reqs-02.txt, we would like to thank you again for your comments.
>> Please find attached our response to them, along with the proposed  
>> new text for the draft and a diff file highlighting the changes.
>> Should you consider that the corrections do adequately answer your  
>> concerns, please let us know and we'll move the new text to become  
>> the working group next version of the document. We'll also be  
>> delighted to see Russ'es "Discuss" flag cleared.
>> If they don't answer your concerns, can you please let us know of  
>> your remaining comments, at your earliest convenience?
>> With best regards
>>
>> Dominique
>>
>>
>> Cc : Mischa Dohler; General Area Review Team; Dave Ward; [email-masked] 
>> ; [email-masked]; [email-masked]; JACQUENET  
>> Christian ROSI-ITNPS-NAD-TIP
>> to see the IESG's current view; my personal view is that  
>> capitalisation isn't needed for design requirements.
>>
>>    Brian
>>
>>
>