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.
>>
>> _____________________________
>>
>> 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
>
>
>
>
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
