Link-Layer Event Notifications for Detecting Network Attachments
draft-ietf-dna-link-information-06

[Ballot comment]
Section 1., paragraph 2:
>    But such indications may not be always available
>    (e.g.  DNAv6) to the node upon changing its point of attachment.

  What does DNAv6 refer to?


Section 3.1., paragraph 6:
>    Successful establishment of a PDP Context on a GPRS link signifies
>    the availability of IP service to the MT.  Therefore, this link-layer
>    event must generate a link up event notification sent to the IP
>    layer.

  Sounds like it places a requirement on non-IETF technology, which is
  inappropriate for an Informational document - rephrase. Maybe
  "...signifies the availability of IP service to the MT, which IP
  should treat as a link up notification" or something like that.
  (Similar wording is in 3.2, 3.3. and 3.4, same applies there.)


Section 8.2., paragraph 3:
>    [I-D.ietf-mipshop-fast-mipv6]

  Outdated reference: draft-ietf-mipshop-fast-mipv6 has been published
  as RFC4068

[Ballot comment]
The author address  seems to be
  out of date.

  From the SecDir Review by Steve Bellovin:

  From the security perspective, you might want to contemplate some
  mention of "evil twin" attacks on 802.11 networks -- you can attach
  to the wrong AP. 

  From a functionality perspective, you might want to note that on 802.3
  networks, NICs often return a speed and duplex indication to the host,
  and that changes in it *might* indicate a new IP network.

Two reviews have been received, one from Bernard Aboba (on the IESG list), and another one from Thomas Narten (on the WG list). Both point to a need for a revision before this can go forward.

AD review commens were finally taken into account in the latest revision. Asking for Last Call in case there are comments from the wider community (particularly when the holiday period means that this does not delay the draft).

Unfortunately, despite a promise from the chairs that the version they edited had addressed all issues, only one issue was really addressed. There is no way this number of changes can be accomplished with RFC Editor notes. This draft has to wait for a new revision.

AD review posted to the chairs and authors on May 22, 2006, and subsequent comments on May 23, 2006. Bernard Aboba's earlier reviews were checked, and he also re-reviewed the draft and posted comments to the list on May 23, 2006. Expecting authors to revise the document in response to the comments.

First part of AD review complete. The second part still needs to be done, and it will consist of checking whether draft-iab-link-indications has something that affects this document, and checking if Bernard Aboba or Thomas Narten have any review comments and/or if their comments have been taken into account.

PROTO Information
=================

Sheperding WG chair: Suresh Krishnan

Technical Summary
=================
Certain network access technologies are capable of providing various
link-layer status information to IP.  Link-layer event notifications
can help IP expeditiously detect configuration changes.  This
document provides a non-exhaustive catalogue of information available
from well-known access technologies.

Working Group Summary
=====================
The dna working group reached consensus on this document on the DNA
mailing list. There was strong support for the document from key
contributors to the WG and no opposition.

Protocol Quality
================
This document and has been reviewed by the dna working group and the
required changes have been incorporated into the document. The document has also been reviewed by a member of the IAB (Bernard Aboba) and wg chairs of the bridge and hubmib working groups (Dan Romascanu and David Harrington). Some of the information contained within has been derived from documents reviewed by other standards bodies.


PROTO Questionnare
==================

1.a) Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?
-> Yes.

1.b) Has the document had adequate review from both key WG members
    and key non-WG members?  Do you have any concerns about the
    depth or breadth of the reviews that have been performed?
-> Yes.

1.c) Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?
-> No.

1.d) Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of?  For
    example, perhaps you are uncomfortable with certain parts of the
    document, or have concerns whether there really is a need for
    it.  In any event, if your issues have been discussed in the WG
    and the WG has indicated it that it still wishes to advance the
    document, detail those concerns in the write-up.
-> No.

1.e) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with
    others being silent, or does the WG as a whole understand and
    agree with it?
-> Strong support from key contributors to the WG and no opposition from
the WG members at large.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email to the Responsible Area Director.
-> No.

1.g) Have the chairs verified that the document adheres to all of the
    ID nits? (see http://www.ietf.org/ID-Checklist.html).
-> Yes.

1.h) Is the document split into normative and informative references?
    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

-> Yes. The document is split into normative and informative references.
There are no normative references to IDs, which are not ready for
advancement. The only ID in the normative reference list has already
been published as an RFC. There are normative references to documents
from other standards bodies like 3GPP,3GPP2 and IEEE.