[DNA] REVIEW of draft-ietf-dna-network

[john.loughney@nokia.com]

Hi all,

Here is a short review of the document.  Technically, it seems OK, but I
think
it needs a lot of editorial fixes, as the document doesn't really read
well. A 
general comment, I found a lot of the draft written in a quite awkward
manner,
especially in the abstract and first few sections.

More comments follow:

1) The style seems a bit forced and confused me in a number of places.
For example,
the Abstract says:

   Hosts experiencing rapid link-layer changes may require to do
   configuration change detection procedures more frequently than
   traditional fixed hosts.  

Could you actually state what "configuration change detection
procedures"
are?  I found this wording strange.

   ... This document describes practices available
   to network deployers in order to support such hosts in Detecting
   Network Attachment in IPv6 networks.

I know you are trying to reuse DNA here, but I think it could be
reworded:

   This document describes practices available
   to network deployers in order to support such hosts in Detecting
   Network Attachment in IPv6 networks.

I think what you are saying is that there are router-side solutions to
help detect when a note attaches, or re-attaches, to an IPv6 network.

2) The Introduction continues:

   Hosts on the Internet may be connected by various media.  It has
   become common that hosts have access through wireless media and are
   mobile.  The frequency of configuration change for wireless and
   nomadic devices are elevated, due to the vagaries of wireless
   propagation or the motion of the hosts themselves.

I think it might read better to say something like:

   Hosts on may connect to the Internet via different layer-2
technologies;
   many which may be wireless.  Has both wired and wireless hosts become
mobile,
   the frequency of attachment or re-attachment events may be more
frequent than
   traditional, fixed hosts.  Specific wireless technologies may also
have an
   impact upon this.

3) Also:

   Such hosts need to determine if they have moved to a new IPv6 link
   rapidly, ...

As the attachment is fairly binary, I don't think that the movement can
be
rapid, but it is more that the rate of change in re-attaching to
different
links may be rapid or not.  I think this should be re-worded.

4) General comment: can we replace "network-side" with a more exact
term? Do
we mean routers here?

5) Question on this definition:

   Reachability Detection: Determination that a device (such as a
      router) is currently reachable, over both a wireless medium, and
      any attached fixed network.  This is typically achieved using
      Neighbor Unreachability Detection procedure [1].

Is there a reason why it must be both wireless and wired?  Could you
have
only wireless links on the router?  I think reachability detection
doesn't
specifically require such a configuration.

6) Generally, might want to sync some of the terminology with
http://www.ietf.org/rfc/rfc3753.txt
(I don't exactly like the term "wireless medium") ...

7) minor nit: fix strange indenting in section 1.3.

8) I don't have time to fully go through all of the recommendations, but
I think
they generally look OK.

9) Appendicies are always non-normative in RFCs, I assume this document
is meant
to be informational, so maybe it is a non-issue. I found that having the
recommendations
as a non-normative appendicies is a little strange. I think it might
make sense if
this were in the body of the text.

John