Re: [Roll] Proposal so as to reach a consensus on ** draft-ietf-roll-protocols-survey-02 **

On Thu, Dec 18, 2008 at 7:30 PM, Philip Levis <pal@cs.stanford.edu> wrote:

> Comment inline.
>
> On Dec 18, 2008, at 3:02 AM, Emmanuel Baccelli wrote:
>
>
>>
>> On Wed, Dec 17, 2008 at 9:05 PM, Philip Levis <pal@cs.stanford.edu>
>> wrote:
>>
>> On Dec 17, 2008, at 9:04 AM, JP Vasseur wrote:
>>
>>
>> Now, let's try to be constructive and address your concerns.
>>
>> 1) Lack of background, context, ... in the document. Emmanuel is quite
>> right that background is missing in the document as well as a clear
>> conclusion: "how have we chosen the protocols in the survey, why protocols
>> X, Y, Z, ... have not been included in the survey, ...". I saw that Phil
>> agreed to add some text to address this issue.
>> Emmanuel, does that address your concern (to be confirmed once you see the
>> text) ?
>> Phil, could you please propose some text ?
>>
>> The OSPF section will be renamed OSPF/IS-IS and I will add supporting text
>> that notes the distinctions between the two and why their analysis is the
>> same.
>>
>> I guess that's not all, right? I suppose there will be additional text
>> justifying why the set of protocols (and not just OSPF/IS-IS) chosen to be
>> evaluated is indeed a good sample of what is done in the IETF. Somewhere in
>> this additional text, we also need some justification why DTN protocols are
>> ignored and why there is not a word about NEMO-RO. I would rather recommend
>> that one or two protocols such as PRoPHET (DTN protocol put forward by
>> Stephen Farrell) be evaluated too, but if there is justification in the
>> draft why not to do it, it would be OK I guess (at least with me). In any
>> case, the goal of these additions would be to make the document both more
>> self-contained and self-explanatory, while easier to relate with the content
>> of the current charter.
>>
>>
>
> Emmanuel, did you read the rest of my message? I address NEMO/DTN on point
> 2. Please acknowledge.
>

Here are some relevant pointers (non-exhaustive list):

http://tools.ietf.org/html/draft-irtf-dtnrg-prophet-01
http://tools.ietf.org/html/draft-thubert-tree-discovery-06

They are in scope (NEMO space and DTN space) and they are describing routing
protocols that may be of interest for ROLL.

If we just add the line you proposed, there will be no justification why
they are not evaluated. Do you agree?

So we have a choice to make: either
(i) justify why such routing approaches are not in scope, or
(ii) evaluate a couple of such protocols in the draft, so as to partially
cover DTN and NEMO spaces, as the charter indicates.

I suppose the latter wouldn't take so long? It's just a couple of additional
paragraphs and a couple of additional lines in the pass/fail table, like for
the protocols already evaluated in the draft... Do you agree?

Emmanuel

>
>
>
>> 2) Missing protocols: we had to draw the line somewhere. *LOTS* of
>> protocols have been proposed over the last decade. We had many suggestions
>> to also look at protocol X, Y and Z. The decision was (according to our
>> charter) to limit our survey to existing IETF protocols (RFC or very mature
>> ID):  OSPF, OLSR, TBRPF, RIP, AODV, DYMO, DSR. The list is already fairly
>> long. The charter mentions DTN. The WG decided not to include DTN and this
>> needs to be documented.
>> Phil, could you please add some text ? Note that this does not mean that
>> we may not borrow mechanism(s) from existing protocols by the way if we get
>> re-chartered.
>>
>> The current text reads:
>>
>> "This document considers "existing routing protocols" to be protocols
>> that are specified in RFCs or, in the cases of DYMO
>> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
>> mature draft which will most likely become an RFC."
>>
>> I propose
>>
>> "This document considers "existing routing protocols" to be routing
>> protocols
>> that are specified in RFCs or, in the cases of DYMO
>> [I-D.ietf-manet-dymo] or OLSRv2 [I-D.ietf-manet-olsrv2] , a very
>> mature draft which will most likely become an RFC. It does not
>> examine the Network Mobility Basic Support Protocol (NEMO)[cite],
>> DTN bundles[cite], or the DTN Licklider protocol[cite] because they
>> are not routing protocols."
>>
>>
> Phil
>