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

From: The IESG <[email-masked]>
Date: Mon, 11 Dec 2006 10:19:35 -0500

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

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-12-31.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dna-link-information-05.txt

---

From: Thomas Narten <[email-masked]>
Date: Wed, 13 Dec 2006 13:38:49 -0500

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

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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 14 Dec 2006 11:14:51 -0500

Hi Thomas,
   Thanks for the review. Comments inline.

Thanks
Suresh

> MUST/MAY/SHOULD language at all.

Since it is not a standards track protocol document, the normative 
language is not required for interoperability. But I think it still has 
utility as guidance for implementers of the hints.

> MUST/MAY/SHOULD langauge.

I will replace the capitalized MAY with a lower case may.

> be given. That is fine, but the document could be more clear about

Will try to come up with some text for this.

> document more weight than I think it merits.

Will remove the sentence.

> defining an API in any detail. I'd remove all references to this term.

The R-flag just indicates a non-deterministic link indication. If you 
would prefer using that term instead, I can make the change.

> Same for A-flag. These flags are not defined in sufficient precision

Does this text work for you?

If a non-deterministic link up was generated, another link up must
follow as soon as the link-layer is capable of generating a
deterministic notification.  The event attributes may indicate
whether the packets transmitted since the previous notification were
presumed to be blocked or allowed by the network, if
the link-layer could determine the exact conditions.

> reword ("must"), to make it sound less like requirments that this

Can you suggest some text?

> practice in IPv4 is today? (I would assume that the  latter is what

You are right. It is the latter.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 19 Dec 2006 17:59:35 -0500

Hi Pekka,
   Thanks for your comments. Please find comments inline.

Cheers
Suresh

Pekka Savola wrote:
> On Mon, 11 Dec 2006, The IESG wrote:
> I re-read the document, and I couldn't find much to to comment on it, 
> but I don't know the details of underlying link layers very well.
> 
> I do however have one bigger "meta-comment".  The draft is aiming 
> Informational, but includes normative specification (also in 
> uppercase).  What is the goal of this draft?  Offer information on how 
> various link layers specify L2 notifications (aimed at the general 
> public/background for DNA WG, and possibly implementors), and/or to make 
> implementation specifications of its own (aimed at implementors)?

It is the former.

> 
> At the moment it seems to attempt both, but clarification is needed. If 
> the draft ends up doing the latter, Informational category might not be 
> appropriate (though I don't have a strong opinion on that). Also I hope 
> these issues have been (or will be) reviewed by the appropriate 
> organiztions via liaison statements.
> 
> editorial
> ---------
> The event attributes MUST indicate
> ==> I was a bit confused about this blocked/allowed separation. Why do 
> you need two flags?  This seems to be a binary value.  Not sure if 
> rewording is needed because this is the underlying reasons for this kind 
> of design are not necessarily very relevant here..
> 

We cannot condense this into a single bit because there are three 
possible values 1) packets were blocked 2) packets were allowed 3) link 
layer does not know one way or the other.