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.
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).
o 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.
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.
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.
