> => So far I understand.
>
> once you go into
> > "router/host is
> > a per-interface thing" you need to describe such
> > combinaions in full
> > detail.
>
> => Not really. This is just a definition. When it comes to
> which interface forwards to which other interface this is
> a matter of policy/configuration. If we were writing a document
> about VPNs I would understand your expectation, but this is
> just a definition which applies, regardless of which interface
> is forwarding to any other interface.
as the Subject; line of the email says, once you define host/router
be per-interface thing, you will need to describe router behavior for
every possible combination of mixture of interface. i still think
we did not finish describing simple all-host-interface behavior nor
all-router-interface-without-virtual-router behavior, i strongly
object to the change.
> > yes. i see a big harm and disambiguity introduced by the change.
> > again, keep the document simple, and let vendors do funny/complex
> > things if they want to.
>
> => Please see above. The change is only intended to indicate
> that the forwarding is on a per interface basis and is not
> intended to explain to vendors/operators how to build VPNs.
>
> For instance, the definition of a router is a node that forwards
> packets, intended for other nodes, from one interface to another.
> This definition stands regardless of the type of interface
> a router might use (physical, tunnel ...etc).
see my objection above again. we do not have a document unambiguously
describes simple host-or-router nodes. we have to finish documenting
simple case first. other stuff (like some-interfaces-are-host-and-
some-are-not box) can become different document, if necessary.
itojun
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
