[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-multi6-multihoming-requirements-03
Iljitsch van Beijnum wrote:
>
> On Mon, 1 Jul 2002, Joe Abley wrote:
>
> > > Some text indicating which requirements are absolutely essential and
> > > which
> > > are also important, but can be dropped if there aren't any multihoming
> > > solutions that satisfy them would be good, I think.
>
> > Do you have such text to incorporate?
>
> 3.1 Capabilities of IPv4 Multihoming
>
> The following capabilities of current IPv4 multihoming practices MUST
> be supported by an IPv6 multihoming architecture. IPv4 multihoming
> is discussed in more detail in [1].
>
> Would be replaced by:
>
> 3.1 Capabilities of IPv4 Multihoming
>
> The following capabilities of current IPv4 multihoming practices MUST
> be supported by an IPv6 multihoming architecture to a similar level as
> current IPv4 multihoming does. None of them is optional, but they can
> be omitted or only partially supported if an architecture supporting
> the capability to at least current IPv4 levels is unfeasible or
> doesn't meet the additional requirements listed in section 3.2.
>
> IPv4 multihoming is discussed in more detail in [1].
I wonder why we are using MUST (upper case) terminology in any case.
It isn't the IETF tradition to have strict requirements documents and
require mathematical conformance; this whole thing amounts to a strong
recommendation, not a standards-track MUST. Also "None of them is optional,
but they can be omitted..." makes my head hurt. Why not just change the
language in the whole document to must/should (lower case)?
(This also answers Masataka's point, I think.)
>
> Then there is:
>
> 3.1.4 Policy
>
> A customer may choose to multihome for a variety of policy reasons
> beyond technical scope (e.g. cost, acceptable use conditions, etc.)
> For example, customer C homed to ISP A may wish to shift traffic of a
> certain class or application, NNTP, for example, to ISP B as matter
> of policy. A new IPv6 multihoming proposal MUST provide support for
> site-multihoming for external policy reasons.
>
> I don't think this is the intention, but it _can_ be read as if IPv4
> multihoming has the capability to direct traffic for certain applications
> over one link and traffic for other applications over another link. Since
> this is certainly not the case, at least the example should go, possibly
> the whole thing. (Does it require anything useful anyway?)
Yes. Today this sort of policy is generally implemented by fiddling with
DNS entries and addresses. Maybe we can do better for IPv6 if we think about
it. The example is a valid *requirement* but it should be cited
in the IPv6 context.
Brian