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

From: Margaret Wasserman <[email-masked]>
Date: Sun, 05 Dec 2004 11:03:06 -0500

Hi JinHyeock and Greg,

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.

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.

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

Margaret

Discusses and Comments
Harald Alvestrand:
Comment:
[2004-12-01] Reviewed by Spencer Dawkins, Gen-ART

Only one serious concern raised, about the ambition level of goals:

3.  Goals for Detecting Network Attachment

   The DNA working group has been chartered to define an improved scheme
   for detecting IPv6 network attachment.  In this section, we define
   the goals that any such solutions should aim to fulfil.

   DNA solutions should correctly determine whether a link change has
   occurred.  Additionally, they should be sufficiently fast so that
   there would be no or at most minimal service disruption.  They should
   neither flood the link with related signaling nor introduce new
   security holes.

Spencer - concern - is this high-level "should be sufficiently fast" 
consistent with the 1.5-2-second delays described in section 2 of 
this document? I guess I'm asking, is interactive voice clearly in 
scope/out of scope?

Russ Housley:
Comment:
[2004-12-01]   In section 3.1, G8: s/man in the middle/man-in-the-middle/

Allison Mankin:
Comment:
[2004-12-02] Good, clear document

The IAB has a good document that's worth your reviewing, including issues
of links that can be confusing about whether there is a change or not:

draft-iab-link-indications-00.txt

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.

Bert Wijnen:
Comment:
[2004-12-02] *** matchref -- match citations and references.
     Input file: draft-ietf-dna-goals-03.txt

!! Missing citation for Normative reference:
   P013 L013:    [2]  Thomson, S. and T. Narten, "IPv6 Stateless Address

!! Missing citation for Informative reference:
   P013 L031:    [7]  Droms, R., Bound, J., Volz, B., Lemon, T., 
Perkins, C. and M.

!! Missing citation for Informative reference:
   P013 L035:    [8]  Thayer, R., Doraswamy, N. and R. Glenn, "IP 
Security Document

-----------

Additional comments from OPSDIR review (by Pekka):

This is a good document.

Substantial issue:
------------------

     G1 DNA schemes should detect the identity of the currently attached
       link to ascertain the validity of the existing IP configuration.
       They should recognize and determine whether a link change has
       occurred and initiate the process of acquiring a new configuration
       if necessary.

==> This may be worth a bit more discussion, and/or splitting to two
Goals.  Is it an explicit goal that the DNA scheme gets 100% certainty
whether a link change has occurred?  Or would it be OK to initiate the
IP reconfiguration event even if you've received a reasonably strong
hint about it (e.g., the link-local or link-layer addresses of a
router has changed)?

To me, it would seem that in most cases it would be very useful if one
would not have to reach absolute certainty of what has happened: the
typical IP configuration procedures actually work just fine (there's
just a bit of extra signalling) even if there has not been an actual
link change.

Comment:
--------

(There were numerous typos etc. which I have sent to the authors
directly.)

Section 2.3:
[...]
     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).

==> The text should be clearer that the uppercase keywords are just
quoting the specification from RFC2461, not that this spec is making a
specification of its own (without defininng the RFC2119 keywords).

5.  Security Considerations

     Because DNA schemes are based on Neighbor Discovery, its trust models
     and threats are similar to the ones presented in RFC 3756 [6].

==> this is not given, because we don't know what the DNA scheme will
be; using existing mechanisms is also just a goal.  A bit of rewording
needed here.

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 06 Dec 2004 19:16:32 +0900

Dear Margaret

Thanks for your trouble advancing DNA Goals draft. 

> 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. 
 
> it is up to you how/if to reflect them in the new document.

ok. 

> 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:

s/ascertains/ascertain/

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 17 Dec 2004 01:53:58 +0900

Dear Margaret
 
We discussed with Thomas to address his discuss and believe 
that we have reached an understanding. 
 
We reflected IESG review, both discuss & comments, to update 
the draft and the current version is available at 
 
http://www.diffeo.com/drafts/draft-ietf-dna-goals-04.txt
 
Kindly find in-line comments.  
 
> this document? I guess I'm asking, is interactive voice clearly in 
 
1.5-2 second delays in Sec 2 indicate the current state of art. 
They are the delays related to particular DNA schemes. DNA 
process can be faster & interactive voice is clearly in scope. 

ok.
 
> draft-iab-link-indications-00.txt
 
Thanks. 
 
> change to something more readable?
 
With Thomas' suggestion, we have changed the title to 
 
Goals of Detecting Network Attachment in IPv6

ok. 

ok. 

ok. 
 
> link up? Is this "too long"?
 
After discussing with Thoams, we have changed the above to 
 
   ............................................. Third, the current
Router Discovery
   specification specifies that routers wait a random delay of 0-.5
   seconds prior to responding with a solicited RA.  This delay can be
   significant and may result in service disruption.
 
> True, but there are huristics that make good hints. Not absolute, but
 
We wish to make those good hints into better confirmation.  
We found out that a few factors such as 'link-local router address'
or 'prefix omission', may result in a false link change detection. 
 
We explained more about the difficulties/ ambiguities concerning link 
identity detection with a single RA reception in Sub-sec 2.2 'Link 
identity detection with a single RA'. 
 
> inappropriate for this document).
 
After discussing with Thoams, we have changed the above to 
 
   According to RFC 2461 [1]:
 
   -  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).
 
> suspect that is not a good idea.
 
No, that is not our intention. 
 
We put 'upper-layer' part to underline the necessity of a fast DNA 
procedure. However, it seems that the part is not so much illuminating 
as confusing. So we have removed the part all together as below. 
 
   G2 DNA schemes should detect the identity of an attached link with
      minimal latency lest there should be service disruption.
 
>    P013 L035:    [8]  Thayer, R., Doraswamy, N. and R. Glenn, "IP 
 
We have removed all un-cited refs. 
 
> Additional comments from OPSDIR review (by Pekka):
 
We aims 'No false positive' but, if necessary, a reasonable false 
error rate is acceptable. WG will decide what reasonable/ acceptable 
error rate will be. We plan to design a DNA scheme with negligible, 
hopefully infinitesimal, error rate.
 
> just a bit of extra signalling) even if there has not been an actual
 
It may be ok for a host to falsely assume a link change when it 
remains at the same link. However, the inverse case that a host 
fails to detect a link change may cause more serious problem.  
For example, if a host checks for link change with the link-local 
address of its default router, it may fail to detect a chance and 
experience a service disruption. 

ok. 
 
> be; using existing mechanisms is also just a goal.  A bit of rewording
 
We have changed the above to 
 
   DNA process is intimately related to Neighbor Discovery protocol [1]
   and its trust model and threats have much in common with the ones
   presented in RFC 3756 [5]. 
 
Kindly let us know if there still is a blocking issue for the draft. 

Best Regards
 
JinHyeock