Subject: [DNA] REVIEWS NEEDED: draft-ietf-dna-network

From: Suresh Krishnan <[email-masked]>
Date: Tue, 04 Jul 2006 18:25:50 -0400

Hi Folks,
   The DNA routers draft (renamed to draft-ietf-dna-network-00) is ready
to be last called before being sent to the IESG for publication. Please
take some time to read the draft and respond to the mailing list with
your reviews.

Thanks
Suresh & Greg

---

From: Julien Laganier <[email-masked]>
Date: Wed, 05 Jul 2006 14:53:28 +0200

On Wednesday 05 July 2006 00:25, Suresh Krishnan wrote:
> Hi Folks,
>    The DNA routers draft (renamed to draft-ietf-dna-network-00) is
> ready to be last called before being sent to the IESG for
> publication. Please take some time to read the draft and respond to
> the mailing list with your reviews.

Folks, 

I reviewed the draft and I have some comments. Not being a native 
English speaker, apologize if some of the editorial suggestions don't 
make sense. I thought the draft was in very good shape; Most of my 
comments are editorial.

I have two suggestions which apply to the entire draft:

   - The document always refer to hosts, as opposed to routers. I 
     understand the point, but now that we have NEMO and mobile
     routers, what about replacing everywhere host by node? that
     would still maintain a difference between nodes and router which 
     I assume is what is wanted.

   - For consistency with RFC2461, I suggest replacing everywhere
     neighbour with neighbor.

Then throughout the draft:
                                                     
> Abstract
> 
>    Hosts experiencing rapid link-layer changes may require to do
>    configuration change detection procedures more frequently than
>    traditional fixed hosts.  This document describes practices  
>    available to network deployers in order to support such hosts in
>    Detecting Network Attachment in IPv6 networks.

Suggest to rephrase as:

   Mobile nodes experiencing rapid link-layer changes may have to 
   detect configuration change more frequently than fixed hosts.  
   This document describes practices for network deployers to support
   such nodes in Detecting Network Attachment in IPv6 networks.

> 1.  Introduction
> 
>    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.

Suggest to rephrase as:

   Nodes on the Internet are connected by various media.  Nowadays it
   is common that nodes are mobile and access Internet through
   wireless media.  The frequency of configuration changes for
   wireless and nomadic devices is elevated, due to the vagaries of
   wireless propagation or the motion of the hosts themselves.

>    Such hosts need to determine if they have moved to a new IPv6 
>    link rapidly, in order that configuration procedures may be run
>    and application packet delivery services restored.  Detecting
>    Network Attachment (DNA) is a strategy to assist such
>    configuration changes by rapidly determining whether they are
>    required. 

Suggest to rephrase as:

   Such nodes need to quickly determine if they have moved to a new
   IPv6 link, so that they can start reconfiguration procedures and
   restore packet delivery to applications. Detecting Network
   Attachment (DNA) is a strategy to assist such reconfiguration
   procedures by rapidly determining whether they are required. 

>
> [...]
>
>    It should be noted that many already deployed routers will not
>    support these recommendations, and that hosts SHOULD NOT rely on
>    their being in place, unless they have particular reason to do
>    so. 

Suggest to rephrase as:

   It should be noted that many routers already deployed will not
   support these recommendations. Therefore, nodes SHOULD NOT rely on
   them being in place unless they have a particular reason to do so.

> 1.1  Terms and Abbreviations
> 
>    Access network: A network where hosts are present.  Especially, a
>       network used for the support of visiting wireless hosts.

Suggest to rephrase as:

   Access Network: An IP network which has on its edge one or
      more routers handling the last hop to mobile nodes, typically
      but necessarily over a wireless link
 
>    Link: A link is the range across which communications can pass
>       without being forwarded through a router [1].
> 
>    Link-Change: Link-Change occurs when a host moves from a
>       point-of-attachment on a link, to another point-of-attachment
>       where it is unable to reach devices belonging to the previous
>       link, without being forwarded through a router.

Why not simply have:

    Link-Change: Link-Change occurs when a host moves from a
       point-of-attachment on a given link to another 
       point-of-attachment on a different link.

>
> [...]
>
> 2.1  Multicast and Unicast RA Responses
>
>   The dis-advantage in sending unicast RA is that the router will

=>  The disadvantage [...]
 
>   not be able to aggregate its response for multiple RS messages

=>  not be able to aggregate its responses to multiple RS messages

>   from multiple hosts received during the waiting period before RA
>   transmission.  Moreover, using unicast RA to respond to RS
>   disables routers' ability to limit the rate of unicast RA.
>
>   For multicast Router Advertisements, a minimum separating delay
>   exists so that these RAs may not be scheduled close to each other.

=>  exists so that these RAs may not be scheduled too close to each
    other.

>   When a host solicits and attempts to schedule a multicast RA

=>  When a host solicits and the router attempts to schedule a
   multicast RA

>   within MIN_DELAY_BETWEEN_RAS (or MinDelayBetweenRAs from Mobile
>   IPv6 [3]) of the previous multicast Router Advertisement, the
>   scheduling of a  response will be deferred until the minimum
>   separation expires. 
>
> [...]
>
>   It is noted that computational requirements for SEND may preclude

=>  It is noted that computational requirements of SEND may preclude

>   this subsequent aggregation in some environments.
>
> [...]
>
>    In some cases it is not possible to provide unicast responses, 
>    since solicitations may be sent with an unspecified address, or
>    solicitations do not provide enough link-layer addressing
>    information to send an unicast response without neighbour 
>    discovery exchange.  In these cases, a router may need to send
>    multicast responses, even if the expected delay is greater.

If the RS was sent from an unspecified address, would it be possible 
to send a multicast RA to a unicast link-layer address? (Fred L. 
Templin suggested that to me)
 
> 2.1.1  Recommendations
> 
>       Routers SHOULD respond to a RS message with unicast RA 
>       message. 
> 
>       Routers SHOULD aggregate RA messages into a multi-cast RA 

=>      Routers SHOULD aggregate RA messages into a multicast RA 

>       message if more than 3 unicast RA messages are queued for
>       transmission. 
>
> [...] 
>
> 2.2  Router Advertisement Parameters

   Where hosts often change their link attachment (e.g., because they

=>  Where hosts often change their link of attachment...
OR, Where hosts often change their point-of-attachment...

>   are mobile), there may be a number of prefixes or routers stored
>   in the host's memory, which are no longer directly reachable. 
>   This additional storage may make movement detection slower where
>   hosts rapidly pass through networks, or pass through networks
>   which have very long advertised timeouts.
>
> [...]
>
> 3.1  Link Extent and Composition
>
>   Most of today's access networks deploy link-layer bridging
>   technologies in order to extend their logical range beyond a

=>  technologies to extend their logical range beyond a

>   single Medium Access Control domain.
>
>   Consequently, while many routers will come with traditional wired
>   or optic-fibre interfaces, packets travelling within the same link

=>  or optic fibre interfaces, packets travelling within the same link

>   may have been bridged across from a wired segment to a wireless
>   segment. 
> 
> [...]
> 
> 3.2  Multiple Router Links

=> 3.2  Multiple Routers Links
OR, 3.2  Links with Multiple Routers

>
> [...]
>
> 5.1  Providing Router Authorization
>
>   In DNA, some hosts will begin configuration procedures based on a
>   single message transmitted by a router.  As such the ability of
>   routing infrastructure to prove its authenticity and authorization
>   is important to support correct operation of hosts. Authentication
>   and authorization mechanisms exist which allow hosts to check
>   security of routers when they receive Router Advertisements
>   indicating link change.

The mechanisms mentionned above are SEND, or there are others? If this 
is SEND only I suggest citing SEND here, by e.g. rephrasing as:

   In DNA, some hosts will begin configuration procedures based on a
   single message transmitted by a router.  As such the ability of
   routing infrastructure to prove its authenticity and authorization
   is important to support correct operation of hosts. Secure
   Neighbor Discovery (SEND) [4] defines authentication and
   authorization mechanisms which allow hosts to check security of
   routers when they receive Router Advertisements indicating link
   change.

> [...]
>
>   Hosts which wish to have secured exchanges with neighbours and on-
>   link routers may use Secured Neighbour Discovery (SEND) [4].  SEND

=>  link routers may use Secure Neighbour Discovery (SEND) [4].  SEND

(s/Secured/secure/)

>   provides authenticity as well as response matching, using nonces
>   copied from solicitations into advertisements.
>
> [...]

That's it.

Best,

--julien

-- 
-- Dr. Ing. Julien H. Laganier             
   Researcher
   DoCoMo Communications Laboratories Europe GmbH
   Landsbergerstrasse 312, 80687 Munchen, Deutschland

"So einfach wie m	glich. Aber nicht einfacher." -- Albert Einstein

"La perfection est atteinte non quand il ne reste rien à ajouter, 
mais quand il ne reste rien à enlever." -- Antoine de Saint-Exupéry

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian W.  Kernighan

---

From: [email-masked]
Date: Tue, 11 Jul 2006 00:13:35 +0300

Stupid question - did you want a review before a WGLC or during WGLC?

John 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>ext Suresh Krishnan
>Sent: 04 July, 2006 18:26
>To: Dna
>Cc: Greg Daley
>Subject: [DNA] REVIEWS NEEDED: draft-ietf-dna-network
>
>Hi Folks,
>   The DNA routers draft (renamed to 
>draft-ietf-dna-network-00) is ready to be last called before 
>being sent to the IESG for publication. Please take some time 
>to read the draft and respond to the mailing list with your reviews.
>
>Thanks
>Suresh & Greg
>
>
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 10 Jul 2006 17:31:15 -0400 (EDT)

Hi John,
    We would prefer if you could do the reviews before the WGLC, but if you
are stuck for time, commenting during the WGLC period would be fine as
well.

Thanks
Suresh & Greg

---

From: [email-masked]
Date: Wed, 12 Jul 2006 20:54:13 +0300

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:

   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