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