Re: [DNA-BOF] FW: I-DACTION:draft-park-dna-ipv6dadopt-requirement-00.txt

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Daniel and YounHee,

Sorry about my quietness recently.

I've been reading your document.

I know it's a draft, so I'm not worried about
style unless the meaning is not clear.

Overall it's good.

Normally I'm not sure if hints about
implementations (section 4) are placed in
requirements/goals documents.
The section provides a good non-specific
background on the state of the art, though, so
I think it is helpful.

Section 5 starts with:

"5. Requirements for IPv6 DAD Optimization

      This section describes the requirements for IPv6 DAD Optimization
      and following requirements are referred to as IPv6 DAD Optimization
      solutions hereafter.  "

The meaning here is not clear.

Do you mean something like this?:

"5. IPv6 DAD Optimization Goals

    This section defines a set of goals and requirements for IPv6
    DAD Optimization.  Within this section, future solutions which
    embody the goals presented here are referred to as
    'DAD Optimization solutions'. "


for RQ2. I'm not sure what is meant by the phrases:


" For effective DAD optimization, there are no restrictive
   requirements to modify Neighbor Cache entry in the specific cases.
   Immediately on completing the appropriate DAD procedure for
   either original DAD or DAD optimization, all Neighbor's NC
   (Neighbor Cache) MUST be updated appropriately."

The first statement regarding the recoverability of the NC
modifications is clear though.

Are you trying to express that:

"Changes to peers' Neighbor Caches which are due to DAD
Optimization must be repaired in the case of a collision.
Additionally, cache state created by optimizations
should be updated upon completion of DAD procedures if the
created state could cause inconsistent neighbor discovery
behaviour."


Also in RQ4:

"For DAD optimization, a router MUST provide host requirements."

I think that what you're trying to indicate here is that

"A router which has been modified for DAD optimization
should not interfere with hosts operating correctly
in conformance with the host requirements document[HREQ]."

Please tell me if you have a different idea.

in RQ7:

"At this case, all nodes MUST detect address duplication either
      original DAD or DAD optimization.
"

I think we have to be careful when we say all nodes must
detect the duplicate address.

Since we've said that the systems must allow recovery from
a duplicate event, this should take care of the other peer
nodes' neighbor cache state.

I think the main issue is to ensure that both the configuring and
the owner node (or both configuring nodes) are aware if an address
configuration attempt is made.

How about this text?:

"In the case that collision occurs, the configuring node MUST
  inform the owner (or simultaneously configuring node) that the
  configuration attempt has occurred.  In RFC-2462, this occurs
  through the sending of the original Neighbor Solicitation packet.
  Additionally, if intermediate neighbor cache state on peers
  has been created, it must be repaired in conformance to RQ2."

Please let us know what you think about these ideas

I think things are shaping up quite nicely for this document.

Thanks for your hard work.

Greg