Re: [DNA] Last Call: 'Link-layer Event Notifications for DetectingNetwork Attachments' to Informational RFC (draft-ietf-dna-link-information)

[Thomas Narten <narten@us.ibm.com>]

Overall, I think this document is not quite ready for publication as
an RFC and needs another revision. Specific comments follow.

> The IESG has received a request from the Detecting Network Attachment WG
> to consider the following document:

> - 'Link-layer Event Notifications for Detecting Network Attachments '
>    <draft-ietf-dna-link-information-05.txt> as an Informational RFC

I'm trying to figure out exactly what this document is inteded to
do. It's presumably not a protocol document, as its going for
informational. That said, I'm don't think it should make use of
MUST/MAY/SHOULD language at all.

The first usage:

>    process.  For example, the notification indicating that the node has
>    established a new link-layer connection MAY be used for immediately
>    probing the network for a possible configuration change.  In the

Seems inappropriate as this is just part of the introduction. Later
uses of upper case language is also suspect.  I'd suggest removing all
MUST/MAY/SHOULD langauge.

Also, I assume that this document is really more about giving examples
(using some current link types) of how/when a link up indication could
be given. That is fine, but the document could be more clear about
that. I'd suggest adding a paragraph clearly stating what the purpose
of this document is. Also, 

>    The document limits itself to the minimum set of information that is
>    necessary for solving the DNA problem [RFC4135].  A broader set of
>    information (e.g., signal strength, packet loss, etc.) and events
>    (e.g. link down) may be used for other problem spaces, such as
>    anticipation-based Mobile IP fast handovers [I-D.ietf-mobileip-
>    lowlatency-handoffs-v4]
>    [I-D.ietf-mipshop-fast-mipv6].  Separate documents that are backward-
>    compatible with this one can be generated to discuss further
>    enhancements.

The last sentence seems out of place, as it seems to give this
document more weight than I think it merits.


>    discussion).  A link up notification MAY be generated with an
>    appropriate attribute (e.g., "risk" indicated by R-flag) to convey
>    the event.  Alternatively, the link-layer implementation MAY choose
>    to delay the link up notification until the risk conditions cease to
>    exist.

the term "R-flag" seems a bit detailed given that this document isn't
defining an API in any detail. I'd remove all references to this term.

>    If a link up with the R-flag set was generated, another link up MUST
>    follow up as soon as the link-layer is capable of generating a
>    deterministic notification.  The event attributes MUST indicate
>    whether the packets transmitted since the previous notification were
>    presumed to be blocked (B-flag) or allowed (A-flag) by the network if
>    the link-layer could determine the exact conditions.  If the link-
>    layer cannot make a determination about the fate of these packets, it
>    MUST generate a link up without any additional indications (no flags
>    set).


The first MUST seems unnecessarily specific. This document is no a
spec.

Also, the B-flag is also too specific and sounds to much like a
spec. Why does an interface need to provide these semantics? I'd
suggest removing all references to "B-flag".

Same for A-flag. These flags are not defined in sufficient precision
to be useful.

>    A node may have to change its IP-layer configuration even when the
>    link-layer connection stays the same.  An example scenario is the
>    IPv6 subnet renumbering [RFC2461].  Therefore, there exist cases
>    where IP-layer configuration may have to change even without the IP-
>    layer receiving a link up notification.  Therefore, a link-layer
>    notification is not a mandatory indication of a subnet change.


The above isn't really saying what needs to be said clearly. I suspect
the point being made is that link-layer notifications are not
sufficient indicate all changes in subnet configuration.

at a minimum, reword last sentence to something like:

   Therefore, link-layer event notifications are not a sufficient
   mechanism to signal all potential subnet configuration changes.

>    layer technology as well.  The following subsections examine four
>    link-layer technologies and describe when a link-layer notification
>    must be generated and what information must be included in it.

reword ("must"), to make it sound less like requirments that this
document is making.

Section 2.1: some of the specifics in this section sound like
requirements of this spec. I'm not sure this document is supposed to
be a specification. e.g.:

>    With IPv4, the auxiliary information carried along with this
>    notification MUST be the IPv4 address of the MT which is obtained as
>    part of the PDP Context.  With IPv6, the PDP Context activation

Is the above a requirement? Or is it just saying what the existing
practice in IPv4 is today? (I would assume that the  latter is what
the document should do.)

>    The status of the link as determined by the Link Integrity Test is
>    stored in the variable 'link_status'.  Changes to the value of
>    link_status (for example due to Link Integrity Test failure) will
>    generate link indications if the technology dependent interface is
>    implemented on an Ethernet device [IEEE-802.3].

This is getting pretty detailed, and is presumably the way things work
at the device driver level...