Re: [DNA] IESG Evaluation of draft-ietf-dna-goals-03.txt

[JinHyeock Choi <jinchoe@samsung.com>]

Dear Margaret

Thanks for your trouble advancing DNA Goals draft. 

> The IESG reviewed draft-ietf-dna-goals-03.txt on our telechat last 
> Thursday (2-Dec), and I have included our review comments below. 
> There was only one blocking issue (the "discuss" from Thomas), but 
> there were several comments that you will probably want to consider 
> when you update the document to address Thomas' issue.

We'll update the draft to address Thomas' issue. Also we'll reflect 
IESG comments into the draft. 
 
> You will need to address Thomas' discuss to his satisfaction before 
> the document will be approved.  The comments are merely advice, and 
> it is up to you how/if to reflect them in the new document.

ok. 

> Please let me know if you have any questions about this, or if you 
> need any further information to understand the IESG feedback.

I have a question. Among the following comments of Thomas, 
which is/are the blocking issue(s)? 

Thomas Narten:
Discuss:
[2004-12-02] These are all pretty minor, so should be easy to fix.

>                 Detecting Network Attachment in IPv6 Goals

change to something more readable?

>     When a host has established a new link-layer connection, it can send
>     and receive some IPv6 packets at the link, particularly those used
>     for configuration.  On the other hand, the host has full Internet

s/at the link/on the link/
s/particularly/including/

>     detects the identity of its currently attached link to ascertains the

s/ascertains/ascertain/

>     refer [10].

s/refer/refer to/ (or "see")

>     difficult for a single RA message to indicate a link change.  Third,
>     Router Discovery may take too long and result in service disruption.

clarify? are there some unstated assumptions being made here? e.g.,
why doesn't a host just send out an  RA immediately upon detecting a
link up? Is this "too long"?

>     Usually a host gets the information necessary for IP configuration
>     from RA messages.  Based on the current definition [1], it's
>     difficult for a host to check for link change upon a single RA
>     reception.

True, but there are huristics that make good hints. Not absolute, but
good hints.

>     Before a host sends an initial solicitation, it SHOULD delay the
>     transmission for a random amount of time between 0 and
>     MAX_RTR_SOLICITATION_DELAY (1 second).  Furthermore, any Router
>     Advertisement sent in response to a Router Solicitation MUST be
>     delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5
>     seconds).

is this text quoting another RFC? If so, please make that clear. Or,
is this document defining normative behavior (which is probably
inappropriate for this document).

>     G2 When upper-layer protocol sessions are being supported, DNA
>       schemes should detect the identity of an attached link with
>       minimal latency lest there should be service disruption.

What does this mean? In particular, if the intention is that
upper-layer communication failures should trigger DNA action, I
suspect that is not a good idea.

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock