Re: [dna] Review of draft-ietf-dna-simple-11

["Bernard Aboba" <[e-mail]>]

Ted Lemon said:

"From section 2.1:

  o  False positives are not acceptable.  A host should not conclude
     that there is no link change when there is one.

  o  False negatives are acceptable.  A host can conclude that there is
     a link change when there is none.

This seems backwards, unless there is no cost to a false negative.  If
a host concludes that there was a link change when there was none, and
as a consequence abandons the IP addresses it was using on the
previous link, that's going to create a (potentially noticeable)
hiccup while it reacquires its address.  Depending on the IP stack,
it's possible that connections might also be broken, e.g. if a syscall
returns EHOSTUNREACH due to a transient routing outage."

The paragraphs above do not correctly define the meaning of "false positive"
and
"false negative".  Here is what RFC 4436 says:

      o  As a performance optimization, it must not sacrifice
         correctness.  In other words, false positives are not
         acceptable.  DNAv4 must not conclude that a host has returned
         to a previously visited link where it has an operable IP
         address if this is not in fact the case.

      o  As a performance optimization, false negatives are acceptable.
         It is not an absolute requirement that this optimization
         correctly recognize a previously visited link in all possible
         cases.  For example, if a router ignores unicast ARP Requests,
         then DNAv4 will not be able to detect that it has returned to
         the same link in the future.  This is acceptable because the
         host still operates correctly as it did without DNAv4, just
         without the performance benefit.  Users and network operators
         who desire the performance improvement offered by DNAv4 can
         upgrade their routers to support DNAv4.