Goals of Detecting Network Attachment in IPv6
RFC 4135

Note: This ballot was opened for revision 04 and is now closed.

(Margaret Cullen) Yes

(Harald Alvestrand) No Objection

Comment (2004-12-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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?

(Bill Fenner) No Objection

(Sam Hartman) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

Comment (2004-12-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  In section 3.1, G8: s/man in the middle/man-in-the-middle/

(Allison Mankin) No Objection

Comment (2004-12-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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) (was Discuss) No Objection

(Bert Wijnen) No Objection

Comment (2004-12-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
*** 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.