Hello Vicky,
Follow-up below...
On 8/7/2015 2:39 AM, Victoria Mercieca wrote:
On 8/5/2015 12:04 PM, Thomas Clausen wrote:
o “Multiple interfaces” and “multiple addresses
per interface” — it is murky in the document
if the latter are supported, and I am not
convinced that what is written about the support
for the former is correct and complete. There
are some subtleties that are hard to
get right with multiple interfaces, and this
is something that needs to be worked through.
It is not murky, and multiple addresses per interface are supported.
In order to respond to this comments, more specifics are needed.
When we say in the seqnum section:
"All route messages created on behalf of Router Clients on a particular interface MUST include the sequence number of that interface's IP address."
How do we know what interface the message will be sent on? Especially if it's multicast, it might go out on all interfaces? Therefore how can we know what seqnum to use?
It makes more sense to have either
A) one seqnum for everything the router is up to, no matter what interface,
or
B) to have one seqnum per router client? We call it OrigSeqNum...and OrigAddr etc all refer to the originator of the traffic that we're requesting a route for.
o On the previous point, the terms “Router
Client” and “Node” and the like actually
make it tedious/impossible to work through if
the specification supports multiple
interfaces/addresses.
For example, a phrase “the IP address of a
node” used in a processing description is
not precise enough (I think): interpreted
literally it implies “a single IP Address is supported
per ’node'”. Interpreted generously, it means
“any IP Address of the node” which would
make the protocol break in at least one
instance. Interpreted in a way which would not
“break the protocol in that instance” is not
supported by the signalling as described (at least,
according to my understanding).
As stated in the document, the IP address of the interface to be
used is the one used by the application.
Similarly in the neighbor table:
"Neighbor.IPAddress
An IP address of the neighboring router."
Should we say there would be a neighbor entry for each IP address the neighboring router used?
I have tried to clarify throughout the specific IP address that would be used, rather than make one statement that people will forget about, or not know if it applies in every case.
o Appendix D must go. I am less lenient than
Chris here, since IMO having two different
descriptions of the same processing and
signalling in the same document is bound to
(given that it’s human to err) be a source of
inconsistencies.
I also do not believe this. The rationale given (i.e., it's human
to err) means we should all just give up trying, thereby surely
making fewer mistakes.
I'm almost inclined to agree with Thomas. This section is huge, it repeats what's said in the draft already, and we havent rigourously updated it as we've updated the draft, so there are inconsistencies. I'd prefer to have a note in there that example code is available from the authors on request? The main text should really be clear enough that this isnt necessary.
