RE: [DNA-BOF] review of draft-park-dna-ipv6dadopt-requirement-01.txt

[Soohong Daniel Park <soohong.park@samsung.com>]

> Semi-substantial:
> 
> - Move the begining of Section 4 (all the way up to
>    the requirements) part so that the possible solution
>    ideas come after the requirements.

not bad... I think it can be done later.

> - Why isn't there a requirement that puts a number
>    on the speed that DAD must normally succeed (as
>    far as protocol limits go). I would suggest this:
> 
>     RQ 0: The optimistic DAD procedure MUST NOT introduce
>           more than 10 ms latency in the normal case.

Well. why do you suggest *10ms* value ? I am not sure it
should be added into requirements.

> - RQ 1 discussion is mostly irrelevant to RQ 1. Delete
>    everything and put this in instead: "The optimized
>    DAD mechanism MUST NOT break the RFC 2462 DAD mechanism,
>    if used on the link by other nodes."

done.

>    It may also be an idea to think about RQ1-4 again
>    and see if we can find a shorter or more fundamental
>    requirement relating to the backwards compatibility with
>    regular DAD.

I will do it after discussing in the mailing list, but I modified
RQ1 as *Backwards Compatibility with Original DAD*

> - I disagree about RQ 8 -- its not an optiDAD problem.

not problem but requirements/considerations.

> Editorial:
> 
> - Abstract is lengthy and hard to read. Rewrite it as follows:
> 
>    "In order to generate a unique address, IPv6 nodes perform
>     the Duplicate Address Detection (DAD) procedure. Payload
>     packets can not be sent or received before this procedure
>     is complete. In an environment where frequent movements are
>     expected, this delay can be problematic. As the reduction
>     or removal of the delay would be useful, an optimized
>     version of DAD has been proposed. This document discusses
>     the requirements for such "Optimized DAD" protocol."

looks good and done.

> - Section 1, s/In the current specifications, an .../An .../

done

> - I would delete the second last paragraph of Section 1.

done

> - I would also delete the second defined term from Section 2.

Well, originally I thought this term should be defined, but most
guys do not agree that, it can be removed easily.

> - Section 2, last paragraph... hmm... just import the defs
>    here if they are used. Shouldn't be too many, I think.

I will consider.

> - Section 3, reaplce "Note that this ... latency except other 
> latencies ...
>    such as ..." with
> 
>    "This document only considers the latency introduced by DAD.
>     There are also other protocols that introduce additional
>     network attachment latency, such as ..."

done.

> - Section 3, s/in a separate document as well/elsewhere/

replaced with *in a separate document and elsewhere.*

> - Rename PS 1 to "Introduction of Random Start Delays"

done

> - Rename PS 2 to "Introduction of Delays through Response Windows"

done

> - Section 3, the paragraph after PS 1 line. Replace "So, " with
>    "According to RFC 2462, ". Also, delete the "If a node abides"
>    sentence altogether, its repetition and seems to suggest RFCs
>    not be followed.

done

> - Section 4, remove the first two sentences of the second paragraph.
>    Repetition. Its getting obvious by now that you don't like delays,
>    but I think we all agree and you have made your point earlier ;-)

I will consider.

> - RQ 3, s/NDP (Neighbor Discovery Protocol)/ND (Neighbor Discovery)/

done

> - RQ 4, delete "not interfere ... a router has to".

done


Regards

Daniel