Subject: [dhcwg] Fwd: AD Review of draft-ietf-dhc-dhcpv6-failover-requirements

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 01 Jul 2013 17:07:11 +0200

FYI

-------- Original Message --------
Subject: AD Review of draft-ietf-dhc-dhcpv6-failover-requirements
Resent-To: [email-masked], [email-masked]
Date: Sun, 30 Jun 2013 17:51:57 -0400
From: Ted Lemon <[email-masked]>
To: [email-masked]

I'm doing the pre-submission review for this document now (sorry I took
so long to get started) and have a couple of comments that should be
addressed before I submit this to the IESG:

There's no such thing as a zone name.   A zone is just a point in the
DNS tree where there's an SOA record.   Suggested fix:
OLD:
      FQDN - a fully qualified domain name.  A fully qualified domain
      name generally is a host name with at least one zone name.  For
      example "dhcp.example.org" is a fully qualified domain name.
NEW:
      FQDN - a fully qualified domain name.  A fully qualified domain
      name generally is a host name with at least one domain label under
      the top-level domain.  For example "dhcp.example.org" is a fully
      qualified domain name.

Prior to section 8, this document was pretty agnostic about how the
problem would be solved, but section 8 makes the transition to
specifying what looks like requirements for a failover protocol much
like the DHCPv4 failover protocol.  It would help to add some text
justifying this transition, since I don't think you really did prior to
section 8.   The basic point you need to get across is that a two-way
failover protocol is much simpler than a multi-way failover protocol,
and a multi-way failover protocol doesn't add a whole lot of value.

Also, you can't use MUST, MUST NOT, etc in a requirements document,
because you aren't specifying protocol behavior.   You never reference
RFC2119, so you don't have to follow or avoid its conventions—it makes
sense to just use the english words without uppercasing them.

What's the point of section 9.1?   This is a rather long section about
another protocol, almost as if you'd done a DHCPv4 failover requirements
document.

>From Section 10:

   The design of a security protection MUST take into consideration the
   fact that the protocol MUST operate despite network failures.  In
   particular, relying on any external infrastructure (e.g. any form of
   Certificate Authority) is discouraged (or at least must be optional).

What's the motivation for this text?   TLS certs work without access to
the certifying server, although you don't get revocation.   This is a
pretty big requirement to place on the protocol, because it excludes the
use of TLS.   It's hard to see the value in it.

Anyway, as I say, sorry for taking so long to do this review.   The
above comments are significant enough that I'd like to see them
addressed before we go to IESG review.   If you think I'm mistaken about
any of these observations, an appropriate response would be to explain
why—I don't claim to be omniscient.