Hi Charlie,
On Wed, Aug 5, 2015 at 10:02 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,
Here is some follow-up regarding Clausen's remarks. Feel free to forward
these comments to the list but first take my name off.
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.
Similarly in the neighbor table:
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.
However, we are looking at a reactive protocol which is going to acto The interaction “routing process”—“forwarding process”
needs to be called out very
carefully, much more rigorously than in Appendix A, and
not in an appendix.
I do not believe this.
what's said in the draft already, and we havent rigourously updated it aso 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
Vicky.
o I strongly think that the security considerations will
not fly past the SEC-ADs, and I think
that they’d be right in not letting it. I’ve got some
detailed comments that will follow as I
get through typing them all up, but this is a heads up
that I consider this to be a major
undertaking still to be done.
We're waiting for the security review.
I'll look at the .pdf now.
Regards,
Charlie P.
Regards,
