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

[Suresh Krishnan <suresh.krishnan@ericsson.com>]

Hi Thomas,
   Thanks for the review. Comments inline.

Thanks
Suresh

Thomas Narten wrote:
> 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.

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.

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

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

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

Will try to come up with some text for this.

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

Will remove the sentence.

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

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

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

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.

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

Can you suggest some text?

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

You are right. It is the latter.

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