The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4
draft-ietf-manet-dsr-10

[Ballot comment] I decided to change my DISCUSS to ABSTAIN. I don't understand why the authors have been unresponsive but since it's over ...

[Ballot comment]
I decided to change my DISCUSS to ABSTAIN. I don't understand why the authors
have been unresponsive but since it's over a year, let's be done with it, since
it's Experimental anyway.

This draft applies to IPv4 only. The title should say that by adding "using IPv4" to the end, or something like that. Furthermore, the text states that "... and operation of DSR with IPv6 [7], are covered in other documents." [7] is only a reference to the basic IPv6 spec. I'd expect to see at least a "work in progress" reference to substantive work on DSR for IPv6, if the quoted statement is correct.

[Ballot comment] I decided to change my DISCUSS to ABSTAIN. I don't understand why the authors have been unresponsive but since it's over ...

[Ballot comment]
I decided to change my DISCUSS to ABSTAIN. I don't understand why the authors
have been unresponsive but since it's over a year, let's be done with it, since
it's Experimental anyway.

This draft applies to IPv4 only. The title should say that by adding "using IPv4" to the end, or something like that. Furthermore, the text states that "... and operation of DSR with IPv6 [7], are covered in other documents." [7] is only a reference to the basic IPv6 spec. I'd expect to see at least a "work in progress" reference to substantive work on DSR for IPv6, if the quoted statement is correct.

State Change Notice email list have been change to <macker@itd.nrl.navy.mil>, <ian.chakeres@gmail.com>, dbj@cs.rice.edu from <macker@itd ...

State Change Notice email list have been change to <b><macker@itd.nrl.navy.mil>, <ian.chakeres@gmail.com>, dbj@cs.rice.edu from <macker@itd.nrl.navy.mil>, <idc@cs.ucsb.edu>, dbj@cs.rice.edu

[Ballot discuss] This draft applies to IPv4 only. The title should say that by adding "using IPv4" to the end, or something like that. Furthermore ...

[Ballot discuss]
This draft applies to IPv4 only. The title should say that by adding "using IPv4" to the end, or something like that. Furthermore, the text states that "... and operation of DSR with IPv6 [7], are covered in other documents." [7] is only a reference to the basic IPv6 spec. I'd expect to see at least a "work in progress" reference to substantive work on DSR for IPv6, if the quoted statement is correct.

Note: this is one of the four MANET protocols that's being publishes as experimental as part of moving forward with a standards-track protocol. This ...

Note: this is one of the four MANET protocols that's being publishes as experimental as part of moving forward with a standards-track protocol.  This took longer in AD review than the others (mostly my fault); meanwhile the others have been published as RFCs 3561, 3626, and 3684.

This new version updates the submission date from 24 Feb 2003 to 15 April 2003, and the expiration date from 24 August 2003 to 15 ...

This new version updates the submission date from 24 Feb 2003 to 15 April 2003, and the expiration date from 24 August 2003 to 15 October 2003, and nothing else.  Given that it appeared in July 2004, I am vaguely mystified as to the point of submitting a new version, especially with such odd dates.

To: dbj@cs.rice.edu dmaltz@cs.cmu.edu yihchun@cs.cmu.edu Subject: Initial AD-review comments on DSR Cc: zinin@psg.com corson@flarion ...

To: dbj@cs.rice.edu dmaltz@cs.cmu.edu yihchun@cs.cmu.edu
Subject: Initial AD-review comments on DSR
Cc: zinin@psg.com corson@flarion.com macker@itd.nrl.navy.mil fenner@research.att.com
Date: Tue, 18 Nov 2003 09:53:04 -0800

Folks,

  Below are my initial AD-review comments on DSR, mostly phrased
as questions.  As I mentioned to David in Minneapolis, I've been
avoiding sending them because I am concerned that some of them are
stupid questions and I was hoping that I could clear them up by
further reading of the spec.  However, as David pointed out, you
could help me understand what I got wrong and it's ridiculous to
have gone so many months without any feedback.  I apologize for
taking so long to get these comments back to you.

  Bill


How does IP->MAC resolution work?  Seems as though some of it could
be piggybacked on the route discovery, but there's no mention of this.
Does it do ARP?

In section 3.1, the timers are kind of underspecified; "..has recently
seen..", "..for some timeout period", "MUST limit the rate" - unclear
if this is further specified somewhere else.

In 3.3.4, I don't know if it's clear what to put in the TTL field
for "no hop limit".

In 3.4.1, I don't understand why TTL isn't enough to prevent a
salvaging loop and the salvage counter is required.

In 3.5.1, what's the TTL used for in the flow table?

In 3.5.6, what's the expected hop count?

In 3.5.7, what's an adjusted TTL?

Section 8.2.3 doesn't refer back to section 3.3.3 so it's not clear
exactly how the implosion-prevention delay fits in here.  Strictly
implementiong from 8.2.3 doesn't seem to include the random delay
so I'm concerned that the implosion prevention would get missed
since it's so long ago.  In particular, even though I read linearly
through the spec, when I got to 8.2.3 I wrote down a note about
multiple nodes decapsulating the same packet in a dense network,
even though this would be prevented if the delay in section 3.3.3
was inserted in the right place in the algorithm in 8.2.3 .  This
is a symptom of what I felt was a common theme in the spec - a feature
was introduced and described in a standalone section but not propagated
through the rest of the spec.

Another example of this latter concern is section 8.4.  It describes
when to insert the special addresses 127.0.0.1 and 127.0.0.2 into the
route, but there is no mention of what to do when processing a route
that contains these special addresses, even though the presence of
these special addresses should change which of the categories laid out
at the beginning of section 3.3.1 the caching node should consider for
this route.

Section 8.5 should be more clear about fragmentation and encapsulation,
e.g. specifying the size of the fragments (outgoing MTU minus ip-ip header
and DSR options header length?) and the source/destination addresses to
use in the outer packet.  A reference to RFC 2003 might also help?

For IP protocol number assignments:
1. Can you handle only having one, since you can tell the
flow state and options headers apart with the F bit?
2. Can you use the mechanisms described in
draft-narten-iana-experimental-allocations-04.txt ?

The IANA considerations section needs to specify a policy for
DSR options assignments (i.e., how does IANA decide whether or not
to grant a request for a new DSR option?).  See RFC 2434 for some
possibilities.


I'm afraid that I skipped over some of my questions on the flow state
extension and on packet salvaging because I don't understand them
well enough to formulate the question.  I will try to reread the document
to further my understanding.