Re: [manet] #30 (aodvv2): Use of word "node"

[Thomas Heide Clausen <[e-mail]>]

I don't think that I claimed that 2501 did any of those things, Joe. 


-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

> On 5 avr. 2014, at 00:23, Joe Macker <[e-mail]> wrote:
> 
> RFC 2501 was not mandating terminology nor did it claim to.
> 
> It was an informational document to raise issues and design considerations relating to a particular problem space.
> 
> And certainly there are always more issues to consider than it raised at the time.
> 
> -joe
> 
> "To everything there is a season. A time to weep, and a time to laugh; a time to model using a graph"
> 
>> On Apr 3, 2014, at 7:42 PM, Thomas Heide Clausen <[e-mail]> wrote:
>> 
>> 3561 did it wrong.
>> 
>> What is the definition of "node"?
>> 
>> Sent from my iPad
>> 
>>> On 4 avr. 2014, at 01:20, Abdussalam Baryun <[e-mail]> wrote:
>>> 
>>> I think draft uses node and router the same way it is used in the RFC3561 which is good.  The AODVv2 is protocol between nodes. 
>>> 
>>> AB
>>> 
>>> On Thursday, April 3, 2014, manet issue tracker wrote:
>>> #30: Use of word "node"
>>> 
>>> (Thomas Clausen) I find the use of "node" unfortunate. I would much prefer
>>> "router", as this is a protocol running between routers. This applies both
>>> in the text and in the "terminology mnemonics". I note that the text
>>> sometimes uses "router" and sometimes "node", and it is not clear that/if
>>> there is a difference, or if there should be a difference.  The word
>>> "Router Client" is also used (albeit inconsistently capitalized) as is
>>> "client".
>>> 
>>> An application running on a host has very, very specific expectations as
>>> to how the underlying IP link behaves. Applications "Expect an IP Link
>>> that looks like an Ethernet". I believe that it was Dave Thaler that once
>>> said something like "don't expect Microsoft to rewrite their IP stack..."
>>> Applications expect what they expect. Even, a protocol such as NDP, which
>>> an IPv6-host uses to (among other things) configure its interfaces has
>>> this expectation. Therefore, unless the goal is to explicitly not support
>>> general applications and general IP stacks, an appropriate link model must
>>> be presented to hosts.
>>> 
>>> Yes, links between MANET routers are not "looking like an Ethernet".
>>> That's quite alright, as long as the *only* application seeing these
>>> "MANET links" is the routing application.  Expose the weirdness of "a
>>> MANET link" to an off-the-shelf app or protocol (such as NDP, mDNS, ...),
>>> and unpredictable behaviour ensures.
>>> 
>>> The way that other MANET routing protocols have taken is, to provide an IP
>>> hop isolation of the hosts (which run "off the shelf applications") from
>>> the "MANET links": in other words, a "regular IP link" ties the "host" to
>>> the "router" and the "router" then has one or more interfaces towards the
>>> "MANET links".
>>> 
>>> --
>>> -------------------------+-------------------------------------------------
>>> Reporter:               |      Owner:  draft-ietf-manet-
>>>  [e-mail]  |  [e-mail]
>>>     Type:  defect       |     Status:  new
>>> Priority:  minor        |  Milestone:
>>> Component:  aodvv2       |    Version:
>>> Severity:  Active WG    |   Keywords:
>>>  Document               |
>>> -------------------------+-------------------------------------------------
>>> 
>>> Ticket URL: <http://trac.tools.ietf.org/wg/manet/trac/ticket/30>
>>> manet <http://tools.ietf.org/manet/>
>>> 
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet
>