[dhcwg] draft-dec-dhcpv6-route-option-02

[Alfred Hönes <ah at TR-Sys.de>]

Hello,
I have studied your recently updated Internet-Draft,
draft-dec-dhcpv6-route-option-02, and have a few comments on it.

Most significantly, the content of Sections 3.1 and 3.2 is in
obvious contradiction, as are the figures therein -- see (4) below.
Furthermore, I found a lot of less serious textual flaws.

Below, I'll perform an almost linear walk-through of the text.
Short replacements are indicated in POSIX edit command style.
To give more context, sometimes I quote larger blocks of text
literally and show the replacement proposed using the shorthand
notation:

   <original draft text>
---
   <modified text>

I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
RFC-Ed policy on style and punctuation etc. in my proposals.
rules, where appropriate.


(1)  Section 1

(1a)  1st para, 1st line

"[RFC2461]" ?? -- why using the obsoleted reference here?
I see no reason to not use "[RFC4861]".

(1b)  2nd para, 2nd line

   This document describes the DHCPv6 Route Option for provisioning
   static IPv6 routes by a DHCPv6 client.  [...]
                      ^^
Isn't provisioning (of its clients) performed _by_ the DHCP *server* ?
Please substitute "to", "on", or "for" for this "by" !

(1c)  2nd para, last line

What is a "non-recursive IPv6 routing table" ??
That term is not explained anywhere in the memo.
Do you simply mean the standard IP forwarding table (as supported
by the RFC 4292 MIB module) ?   Please clarify / simplify!


(2)  Section 2, 2nd para

What are "addresses from a global scope" ?  Are there multiple
global scopes, or why do you use the indefinite article?
Most likely, the text should simply say "addresses of global scope".

(3)  Section 3, last line

Missing white space in front of ref. tag:

     s/DHCPv4[RFC3442]./DHCPv4 [RFC3442]./
            ^^               ^^^

(4) Sections 3.1 and 3.2 -- severe technical issue

The initial paragraph of 3.1 says:

   A DHCPv6 server sends the Route Option to a DHCPv6 client to convey
   one or more IPv6 routes.  Each IPv6 route consists of an IPv6 prefix
   of a declared bit length (a prefix) and a next hop IPv6 address for
|  the prefix.  Multiple prefixes (routes) can be present in a single
|  option, when sharing the same next hop address.  The complete option
   is octet aligned by padding with 0s to the last octet boundary.

That looks promising and it let me expect an option layout
(in pseudo-RBNF style) of:

[E]
     <option-code> <option-len>
     <IPv6-NextHopAddr>
     1* ( <prefix-length> <prefix> )
     <padding>

(I tag this syntax chunk and the subsequent ones with capital letters
enclosed in square brackets; 'E' stands for 'expected', 'S' / 'M' are
for single/multiple routes, respectively, as specified in the draft.)

However, the subsequent diagram only shows a single pair of
( <prefix-length> <prefix> ) , i.e. in this shorthand notation:

[S]
     <option-code> <option-len>
     <IPv6-NextHopAddr>
     <prefix-length> <prefix>
     <padding>

The text in 3.2 immediately contradicts the text in 3.1 by saying:

   A single option can be used to covey multiple routes by means of
|  successively inserting additional combinations of the prefix and next
|  hop field.  The example below illustrates how two routes, consisting
   of Prefix A and Prefix B with two different next hop addresses Next
   Hop 1 and Next Hop 2 respectively, can be conveyed within a single
   option.

To emphasize: 3.1 says ...

    "Multiple prefixes (routes) can be present in a single option,
     when sharing the same next hop address."

... and 3.2 suddenly wants to repeat { NextHopAddr, Prefix } tuples.

Even worse, the second figure reverses the order of fields in the
option as:

[M]
     <option-code> <option-len>
     1* ( <prefix-length> <prefix> <IPv6-NextHopAddr> )
     <padding>

Please resolve these inconsistencies in the next draft revision.
Since the number of next hops will in general be lower than the
number of routes, I would prefer the most economical and intuitive
variant [E], with multiple instances of the option used to represent
different 'real' routes, i.e. different next hops together with the
prefixes they should 'attract'.
This form should also be easier to provision on the side of the
DHCP server, as commonalities are taken into account.


(5)  Section 5

Depending on the outcome of (4), the text needs to be synchronized.
If the 1st para of 3.1 'wins', please change:

|  A server MAY send a client the Route Option.  The server SHOULD
|  support sending the option as part of other DHCP options where such a
|  possibility exists, for example when sending the route option as part
   of an IA_NA or IA_PD option set.
---
|  A server MAY send one of more Route Options to the client.  The
|  server SHOULD support sending the option(s) as part of other DHCP
   options where such a possibility exists, for example when sending the
|  route option(s) as part of an IA_NA or IA_PD option set.


(6)   Section 6

The draft says:

|  IANA would be expected to assigned a DHCPv6 option number of TBD for
|  the "Route Option"

Why "would be" ?  What if not?  What's the alternative ?
Please use simple and clear language (and append a trailing period):

|  IANA is expected to assigned a DHCPv6 option number of TBD for the
|  "Route Option".


(7)  Section 9.2

Update  [RFC2461]  to become  [RFC4861] ,
and reorder the entries by ascending RFC number !


Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+