Hello Vicky,
Well, what the heck. I get tired of being so darned formalistic all the
time. Here's something totally irrelevant:
https://www.youtube.com/watch?v=l7_bpeiIJ2A
I just learned how to play this on guitar. Next project: Claire de Lune
-----
Now, back to our regularly scheduled programming:
On 8/13/2015 2:26 AM, Victoria Mercieca wrote:
On Wed, Aug 12, 2015 at 8:20 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello Vicky,
Follow-up below. I will omit huge portions of the email to avoid
obscuring my comments...
On 8/12/2015 11:01 AM, Victoria Mercieca wrote:
Hi Charlie,
I've just made my way through Thomas Clausen's comments, but I
wanted to follow up on yours before summing up...
For the "Router Client" definition, how is this...?:
"An address or address range corresponding to one or more nodes
which require an AODVv2 router to initiate and respond to route
discoveries on their behalf so that they can send and receive IP
traffic to and from remote destinations. The AODVv2 router's
interface addresses are also configured as Router Clients."
This is good. The AODVv2 router also forwards data to/from its
clients. I don't know if you can work that into the definition.
This is more to do with the forwarding process than the AODVv2 process. Not sure it belongs in the Router Client definition? AODVv2 is about getting the routes. The forwarding process handles it from there. It also forwards for any packet source or destination, as long as there's a route, not just for clients.
“one of the sequence numbers maintained
by an AODVv2 router to ….”
That’s a little vague and ambiguous:
apparently that sequence number is not
enough — but we’re not told with what it
must be complemented in order to be
enough to determine if a route is fresh or
not.
Could that be written:
“SeqNum is the sequence number, which
does ______”
I'm O.K. to restrict AODVv2 routers to maintaining a single
Sequence Number for all of their addresses, but I believe we
were previously requested not to do this. I don't know what
"complemented" means in this comment.
I think in our Appendix we say something about complementing it
with an IP address.
Well, then this comment is simply wrong. The appendix suggests a
way to *expand* the specification to support a currently
unsupported feature. That is drastically different than saying
that "the sequence number is not enough"!!
Yeah, not sure then, whether that comment came about from the Multi-homing appendix saying to complement with an IP address, or if there was some other reason?
The document can explicitly say "sequence number information" at
the point where it mentions persistent state. However, I think
that information belongs elsewhere in the draft, because it is a
small bit of specification, not applicability. If you can find a
good place to put it, so much the better.
In Applicability currently we have:
"On routers unable to
store persistent AODVv2 state, recovery can impose a performance penalty (e.g., in case of
AODVv2 router reboot), since if a router loses its sequence number, there is a delay before
the router can resume full operations. "
is this clear enough?:
"An IP address of the originating node, i.e., the source address
of the IP packet triggering the route request. "
The application doesnt really have the IP address.
That's fine with me. But an application DOES have an IP address
when it's running.
Yeahh ok, will see what feedback comes in but we could update to
say IP address used by the application.
