IESG review: applicability

[Tim Gleeson <tgleeson@cisco.com>]

> 2. (comment 1)
> This draft seems oriented to applications such as WebTV and similar scale
> uses.  One worries that other flavor applications, e.g. highly assymetric
> high-bandwidth inter-continental backbones, would find it not useful but be
> faced with "you're not doing it the ietf standard
> way."  Hence the addition of an applicibility statement to the draft
> would be helpful.
> 
> (comment 2)
> First, this document isn't as general as I would have expected it to
> be. From the title, I expected it to be a way to handle generic
> unidirectional links. However, the architecture seems to rule out two
> nodes connected to each other by unidirectional links. (Or maybe I'm
> just confused by the send/feed terminology) I.e., there are parts in
> the draft that seem to require that a receiver must have a
> bidirectional interface in addition to the unidirectional one:
> 
> >    A receiver has several interfaces, a receive-only interface and one
> >    or more additional bidirectional communication interfaces.
> 
> It might be good to make the applicability more clear, as I don't
> think this has the general applicability that one might expect from a
> unidirectional link mechanism.

Some applications, not needing a backchannel, wouldn't use this at
all. The asymmetric inter-continental backbone could use it, but other
mechanisms, as hinted, might be more appropriate. A pair of
unidirectional links seems like a good solution for some problems.

But I think the "Abstract" seems fairly clear about the domain of
applicability of this proposal. (But perhaps the phrase "bidirectional 
connectivity between nodes" could be replaced by "full bidirectional 
connectivity between all nodes"?)

Is this an issue with the title?  I thought the word "A" in "A
... Mechanism ... for Unidirectional Links" covered this (leading to
"An IETF way" rather than "The IETF way"), but maybe the title needs
completely reformulating?

Tim