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

[Abdussalam Baryun <[e-mail]>]

The node is defined in RFC3561 which was published before RFC3626. Both
published by the WG, but the definition of RFC3561 is the best suitable for
AODVv2. The definition of node in RFC3626 is best suitable for OLSRv2.

AB

On Friday, April 4, 2014, Christopher Dearlove wrote:

> However, it clearly shows that not everyone uses the word node
> identically. For that matter RFC 3626 defines a node as a router.
>
> In other words, best not to use the word without defining it.
>
> --
> Christopher Dearlove
> [e-mail] <javascript:;> (iPhone)
> [e-mail] <javascript:;> (home)
>
> > On 4 Apr 2014, at 23: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               |
> >>>
> -------------------------+-------------------------------------------------
> >>>
>