[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] IESG Evaluation of draft-ietf-dna-goals-03.txt
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.